Checklist: Scoping an Operational Risk Survey for Regulators
Scoping an operational risk survey for regulators means fixing seven things in writing before any fieldwork starts: the organizational perimeter, the regulatory anchors you are answering to, the inventory of business processes in scope, the risk taxonomy, the control and data sources you will test, the named owners of each finding, and the governance forum that receives the report. An operational risk survey — a structured, evidence-based mapping of non-financial risk (NFR), meaning every exposure that is not credit or market risk: operational failure, fraud and embezzlement, cyber exposure inside the business process, business continuity, and now artificial intelligence — is judged by supervisors less on how thick the report is and more on whether its boundaries were deliberate and justified. A survey that quietly excludes outsourced payment operations, a subsidiary, or a newly deployed AI model is not a narrower survey; it is an incomplete one, and that is exactly what an audit finding looks like.
For supervised institutions in Israel — banks, insurers, credit and fintech companies — the anchors are familiar: ISO 31000 for risk-management principles, ISO 27001 for information security controls, the Bank of Israel's Proper Conduct of Banking Business directives covering operational risk, continuity and cyber management, and, entering 2026, the EU AI Act as a reference point for AI governance expectations. LT RISKMGMT, the boutique consultancy led by Lea Tzur, approaches non-financial risk through the business process itself rather than the technology stack — the logic behind its exclusive BPT (Business Penetration Test) method, a risk analysis of the working process that looks for weaknesses in handoffs, approvals and exceptions. The checklist that follows turns that business-process-first mindset into scoping decisions you can defend to a regulator, an internal auditor, and your board's risk oversight committee.
What belongs on a scoping checklist for a regulatory operational risk survey?
Narrowing the frame: this part deals only with what belongs in the four scoping artefacts a supervisor asks to see first — so treat each checklist entry below as a field with a name, permitted values, and a decision it drives. Everything else (fieldwork, interviews, reporting) sits outside this scope on purpose.
Scoping memo — a short, board-visible document that fixes the objective, sponsor, regulatory trigger, method, and, critically, the explicit out-of-scope declarations of the review.
- Permitted values: regulatory trigger (audit finding, supervisory letter, directive such as Israel's Proper Conduct of Banking Business directives on operational risk management and outsourcing), sponsor level (board committee, CRO, CEO), method reference (ISO 31000 as the risk-management framework baseline).
- Why it matters: supervisors judge whether an exclusion was a deliberate, documented decision or an accident.
Reporting perimeter — the enumerated set of legal entities, business lines, processes, and third parties inside the assessment boundary.
- Permitted values: group-consolidated, entity-level, business-line level, or process-level; each outsourced or cloud-hosted service marked in-scope or out-of-scope with a reason.
- Why it matters: perimeters leak at outsourcing and at intra-group service arrangements, which is exactly where examiners probe.
Loss data collection exercise (LDCE) — the structured gathering of internal loss and incident events that gives the review an evidence base rather than opinion.
- Permitted values: capture threshold; date basis (occurrence, discovery, or accounting date); gross versus net of recoveries and insurance; near-misses included or excluded; boundary events with credit and market risk flagged.
- Why it matters: an inconsistent date basis or threshold makes trend analysis and any benchmarking indefensible.
Operational risk taxonomy — the controlled vocabulary that classifies events, causes, and controls so that findings aggregate.
- Permitted values: level-1 event categories (internal fraud, external fraud, execution and process failure, technology and business disruption, people, third party, and AI-related events), each mapped to a cause and a named control owner.
- Why it matters: without one vocabulary, fraud, cyber, and continuity findings never roll up into a single risk oversight view for the board.
Lock the taxonomy and the perimeter before fieldwork starts: that is what turns fraud, cyber, continuity and operational findings into one coherent NFR (non-financial risk) narrative for the regulator instead of four unrelated reviews.
How do you define the survey population and reporting perimeter?
Before you can size the sample, you have to define the survey population — and that depends on what you mean by "the organization." Supervisors almost never accept an implicit perimeter; they expect a written statement of which entities, processes and locations were examined, and which were deliberately left out. Two readings of "population" dominate in practice, and choosing the wrong one is the most common reason a scoping document gets sent back.
Reading one: the solo, legal-entity perimeter. Here the population is the licensed, supervised entity itself — its own processes, controls and loss events, filed under its own licence. A non-bank credit provider or a payments subsidiary inside a larger group typically reports on this basis, because the regulatory obligation attaches to the licence holder, not to the parent's consolidated accounts.
Reading two: the consolidated group perimeter. Here the population follows the accounting consolidation: parent plus subsidiaries, plus foreign branches, plus material outsourced and cloud-hosted processes. A fintech with an offshore development arm and a separately incorporated collections company usually belongs in this category, since the operational exposure sits outside the parent's four walls.
Treatment rules worth fixing in writing before fieldwork begins:
| Unit type | Usual treatment | What to document |
|---|---|---|
| Foreign branch | In scope with the parent (no separate legal personality) | Local regulatory overlay, language of evidence |
| Subsidiary | In or out by consolidation basis and licence | Which basis was applied, and why |
| Joint venture / minority holding | Narrative or proportional coverage | Control rights and influence |
| Outsourced or cloud process | In scope as a process, out of house as an operator | Contractual audit and continuity rights |
| Dormant or immaterial unit | Excluded | Explicit rationale for exclusion |
Set materiality cut-offs on process criticality and recovery-time objectives drawn from your continuity mapping, not on headcount. Our view: a consolidated perimeter with a solo-basis annex is the most defensible default — and whichever basis you choose, fix it in writing before the first interview is scheduled.
Which risk taxonomy and loss thresholds fit different survey objectives?
Choosing a risk taxonomy — the structured list of categories used to classify loss events — and setting loss collection thresholds are decisions that should follow the survey objective, not precede it. Weight four criteria before you compare options: peer comparability (can the data sit alongside industry pools?), granularity (does the category depth support root-cause analysis or only reporting?), causal framing (does it separate the event from the cause and the impact?), and re-tagging cost (how much historical data must be reclassified?). Comparability dominates for capital work; granularity and causal framing dominate for thematic reviews.
| Option | Granularity & framing | Peer comparability | Best-fit objective | Main tradeoff |
|---|---|---|---|---|
| Basel event-type categories | Event-type view organised in levels; limited cause detail | Highest — the common supervisory language | Capital calibration, regulatory loss data reporting | Weak at explaining why an event happened |
| ORX-style reference taxonomy | Separates event, cause and impact; deeper sub-levels | Strong within the industry loss-data community | Thematic review, control-gap and root-cause analysis | Heavier mapping and data-quality effort |
| Bespoke supervisory taxonomy | Tailored to local directives and the institution's process map | Low outside the institution | Resilience benchmarking, board-level risk oversight, directive-specific findings | Requires a crosswalk back to Basel categories |
For gross loss collection, the practical rule is objective-driven: a lower threshold for thematic and fraud-focused surveys, where the pattern lives in high-frequency, low-severity events; a higher threshold when the aim is capital calibration or cross-institution comparison, where consistency matters more than volume. Resilience benchmarking needs a third lane entirely — near-misses, no-loss events and recovery-time data have no monetary trigger at all, so a threshold cannot be your only filter. They need a dual-tag model — Basel event type for reportable data under local supervisory directives, plus a cause dimension for management insight — so that a single collection effort serves the supervisor, the audit committee and the process owner.
Verdict: classify under Basel event types for defensibility, add a causal layer for usefulness, and set thresholds per objective rather than institution-wide.
Why does scope creep inflate reporting burden and how is it contained?
Scope creep inflates the reporting burden for a simple mechanical reason: every question added widens the population that must answer it, the volume of evidence that must be collected behind it, and the number of findings someone must later remediate. It follows that a survey which doubles its question count does not double its cost — it multiplies it, because each item generates chase-up, validation and sign-off work downstream. This means discipline on question count is not administrative tidiness; it is the primary cost control of the whole exercise.
The proportionality principle in frameworks such as ISO 31000 cuts the same way: a smaller credit provider or fintech is expected to demonstrate that controls match its risk profile, not to replicate a large bank's control inventory. LT Risk Management's Risk Manager as a Service model is deliberately sized to that logic, supplying outsourced risk-management capacity to the volume the client actually requests rather than a fixed full-time standard.
| Do this | But watch out for |
|---|---|
| Cap the questionnaire and force every new item to displace an existing one | Genuinely material risk areas being squeezed out by legacy questions kept for historical reasons |
| Use risk-based sampling of processes and units instead of a full census | Sampling blind spots — an unsampled subsidiary or outsourced provider carrying concentrated exposure |
| Push for granular, evidence-backed answers on critical processes | Respondent fatigue: over-granularity produces fast, low-quality self-assessment ticking |
| Fix the assessment period and freeze scope before fieldwork opens | Late regulatory or audit findings that legitimately need coverage mid-cycle |
Highest-impact mitigation: run a census only on the handful of processes where failure is unrecoverable — payments, client onboarding, trading and settlement controls in the middle office — and sample everything else.
What data quality, validation and confidentiality controls should be scoped upfront?
Data quality rules and template validation logic have to be agreed at scoping — not improvised once the returns are already flowing in from business units. Six control families belong in the scope document:
- Field-level quality rules — completeness, timeliness and accuracy definitions per field, with permitted values, units, currency and reporting period fixed in advance.
- Plausibility checks — range and outlier tests that flag the impossible (a loss larger than the underlying exposure, a recovery dated before the event).
- Reconciliation checks — tying reported loss data back to the general ledger, the incident register and the ticketing system, so figures reconcile to an independent source rather than to a spreadsheet.
- Template validation logic — locked cells, controlled drop-downs, mandatory fields and a single taxonomy mapping aligned to the risk vocabulary of ISO 31000, preventing free-text categories that cannot be aggregated.
- Audit trail — an immutable log of who entered, amended and approved each value, with version history; without it, a supervisor cannot test the return's provenance.
- Confidentiality and legal basis — pseudonymising customer and employee identifiers in fraud and misconduct records, need-to-know access under ISO 27001-style controls, defined retention, and an explicit statement of which supervisory directive authorises the collection.
You may also be wondering: who attests to the numbers? Name the attesting owner per data domain and the second-line reviewer before collection starts; unassigned ownership is the most common cause of late, contradictory resubmissions.
And what if AI tooling generated part of the dataset? Then model inputs, validation evidence and human review points must be documented too — the transparency logic the EU AI Act pushes toward.
Risk surveys in breadth and depth for supervised organisations are core to LT RISKMGMT's operational risk consulting, and its advisory and training work is cited by clients including Bank Discount, Bank Leumi, Bank of Israel, Menora Mivtachim, Visa Cal and the Ministry of Justice; the team responds to initial enquiries within 24 hours.
Frequently Asked Questions
How often should a supervised institution re-scope its operational risk survey for regulators?
Most supervised financial institutions in Israel treat the scoping of an operational risk survey — the documented decision about which processes, units, systems and third parties fall inside the review — as an annual exercise, refreshed out of cycle whenever a material trigger appears. Typical triggers include a new product line, a core system migration, a merger, an outsourcing arrangement, a supervisory finding, or the introduction of generative AI into a customer-facing process. These same events — a new regulatory requirement, a cyber or fraud incident, a board demand, an audit finding, or an organisational crisis — are the typical reasons supervised organisations bring LT RISKMGMT in for a risk survey.
Who owns scoping decisions — the board, the CRO, or internal audit?
Accountability sits with the board and senior management, execution sits with the CRO or risk manager, and internal audit tests the result independently. Supervisory frameworks and ISO 31000 — the international standard describing risk management principles and governance responsibilities — both place ultimate risk oversight with the governing body, which is why an undocumented scope exclusion becomes a board-level exposure rather than a working-level one. Internal audit should never author the scope it later examines; that conflict is one of the first things a supervisor probes.
What documentation should be kept so a supervisor can retrace the scoping logic?
Keep the artefacts that reconstruct why the boundary was drawn where it was:
- The process inventory and the criticality criteria used to rank it
- Written justification for every material exclusion, with an owner and a review date
- Mapping of each in-scope process to the relevant supervisory directives and to controls under frameworks such as ISO 27001
- Interview logs, walkthrough notes and evidence samples
- Board or risk-committee minutes approving the scope
Which AI exposures belong in scope in 2026?
In 2026 the practical additions are data provenance and quality, model validation, prompt and output controls, AI red-teaming of decision-support tools, vendor model dependencies, and the legal duties emerging under the EU AI Act. These do not fit neatly under the CISO's mandate, because cyber is only one arm of AI exposure. LT RISKMGMT addresses this gap through its Chief AI Officer service and a dedicated AI risk map covering the technology's full lifecycle; Lea Tzur, the company's CEO, is certified as a Chief AI Officer by Copenhagen Compliance.
What if the organisation has no full-time risk manager to run the survey?
Mid-sized organisations, non-bank credit providers and government bodies frequently need the function without the headcount. LT RISKMGMT provides Risk Manager as a Service, an outsourced risk-manager arrangement scaled to the volume the client actually requires, so the risk-management function is staffed by senior practitioners with decades of in-house experience in supervised organisations rather than juniors. Initial enquiries receive a response within 24 hours — a service commitment from the consulting team, not a contractual service level.
How can an in-house team learn to scope surveys itself?
LT RISKMGMT runs a certification course for operational risk, cyber and AI risk managers of roughly 40 academic hours, recognised by IRM (Institute of Risk Management), an international body in risk-manager education. The programme is experiential: workshops, hands-on exercises, a visit to a leading SOC, and guest lecturers from major organisations in Israel and abroad.