Operational Risk RCSA Template (Basel, DORA)

Operational Risk RCSA: [Business unit or process]

Risk and control self-assessment (RCSA) record for one business unit or end-to-end process in a bank or other financial institution: scope, scoring method, process inventory, inherent risks classified by the Basel operational risk event types, controls with design and operating effectiveness, residual risk compared with risk appetite, action plans, key risk indicator (KRI) mapping, links to loss events and incidents, operational resilience and ICT third-party dependencies, and second-line challenge. It follows the Basel Committee Revised Principles for the Sound Management of Operational Risk (March 2021) and Principles for Operational Resilience (March 2021), both cited by name, and supports the ICT risk management duties of the Digital Operational Resilience Act (Regulation (EU) 2022/2554, applicable from 17 January 2025). Replace every [bracketed] value and every row marked Example. The worked example uses the payments operations unit of the fictional Fernhollow Bank. This is a document format, not legal, regulatory or financial advice. Obtain the principles and laws for the normative text.

Document control

Approvals

Revision history

Contents

• 1. Scope and unit profile
• 2. Participants and roles
• 3. Methodology and scales
• 4. Process inventory
• 5. Inherent risk assessment
• 6. Control inventory and effectiveness
• 7. Residual risk and appetite comparison
• 8. Issues and action plans
• 9. KRI mapping
• 10. Loss events, incidents and external events
• 11. Operational resilience and third-party dependencies
• 12. Second-line challenge and sign-off
• 13. Glossary and references
• Standard and licence note

1. Scope and unit profile

This RCSA covers the [Payments operations] unit, which runs the end-to-end processing of outgoing and incoming customer payments for the group. The assessment covers all activities performed by the unit and by providers acting on its behalf, from the receipt of a payment instruction to final settlement and reconciliation. It excludes card issuing and acquiring, which are assessed in a separate RCSA, and the payment product design, which belongs to the product owner.

The unit profile gives reviewers the context needed to judge whether ratings are plausible. Volumes and values show exposure; recent changes show where new risks may have appeared; the loss and incident history shows where risks have already materialised.

2. Participants and roles

The workshop is prepared by the operational risk partner, who pre-populates the record with the previous RCSA, loss events, incidents, audit findings, KRI history and control test results. Participants then confirm or change each rating with reasons. The workshop agenda follows the section order of this template.

3. Methodology and scales

3.1 Approach

Inherent risk is the exposure before the controls in this RCSA are considered, assuming the process and its volumes as they are. Residual risk is the exposure after taking account of the controls as they actually operate, not as they are designed on paper. Both are rated on impact and likelihood for a reasonably severe but plausible event over a one-year horizon. Ratings follow the general methodology in the Risk Assessment Methodology (compliance/risk-methodology) with the operational risk scales below.

3.2 Impact scale

The impact rating is the highest of the dimensions. Financial thresholds are calibrated to the operational loss appetite (RAS-OPR-01, EUR 12.0 million a year group-wide) so that a single level 5 event would consume a large share of the annual appetite.

3.3 Likelihood scale

3.4 Score and rating

A multiplied score treats a 5 by 1 risk (severe but rare) like a 1 by 5 risk (minor but frequent). Review every risk with impact 5 separately, whatever its score, because tail events drive capital and resilience decisions.

3.5 Control effectiveness

Control effectiveness informs the residual rating; it is not applied as a fixed percentage reduction. Participants re-estimate residual impact and likelihood with the controls in mind and explain the change in the rationale column.

3.6 Running the assessment well

Prepare before the workshop, not during it. Send participants the pre-populated record at least five business days in advance, with the previous ratings, the loss events and incidents of the period, the KRI trends, open audit and regulatory findings, and the control test results. Ask each participant to mark the ratings they disagree with. The workshop then spends its time on disagreements rather than reading tables aloud.

Anchor every rating in evidence. For likelihood, ask how often the event, or a near miss, happened here and at peers. For impact, describe a concrete scenario (for example, "a 5-hour outage of domestic payments on the last business day of the month") and estimate its cost with the finance partner. For controls, ask for the latest test result, not for the control description.

Watch for four recurring errors. Optimism bias: units rate their own controls as effective because they designed them; insist on operating evidence. Anchoring: participants copy last year's ratings; ask what changed and why the rating did not. Granularity drift: one risk is split into ten narrow risks while another covers a whole process; keep risks at a level where one owner can act. Missing change risk: new systems, providers and products create risks that historical losses do not show yet; ask explicitly about every change listed in section 1.

Record the reasoning in the rationale column in plain sentences. An auditor reading the file a year later should be able to see why each rating was chosen without attending the workshop.

4. Process inventory

5. Inherent risk assessment

Classify each risk using the seven Level 1 Basel operational risk event types: internal fraud; external fraud; employment practices and workplace safety; clients, products and business practices; damage to physical assets; business disruption and system failures; and execution, delivery and process management. Using the same taxonomy as the loss database lets the bank compare RCSA results with actual losses. The same Level 1 categories are used for regulatory loss data collection in the EU; check the current CRR3 provisions and EBA technical standards for the applicable taxonomy.

All seven Level 1 event types are represented. If a unit concludes that an event type is not material, record the reason in one line rather than omitting it, so reviewers can see it was considered.

6. Control inventory and effectiveness

Key controls are those the residual rating relies on. Record design and operating effectiveness separately; the evidence column must point to a test, monitoring report or event, not to an opinion. Detailed test steps and results belong in the Control Testing Workpaper (compliance/control-testing-workpaper) and the full control catalogue in the Risk and Control Matrix (compliance/risk-control-matrix).

7. Residual risk and appetite comparison

Operational appetite at unit level is derived from the Risk Appetite Statement (finance/risk-appetite-statement): the qualitative statements QS-06 and QS-07, the loss allocation under RAS-OPR-01, and the impact tolerance metric RAS-OPR-02. For the payments unit the operational risk function has translated these into the following residual rating appetite: risks linked to important business services or impact tolerances, Medium or lower; financial crime risks, Low; all other operational risks, Medium or lower.

Note on RSK-PAY-005: the score of 4 would normally map to Low, but the bank applies a floor of Medium to internal fraud risks with residual impact 4 or more while a detective control is only partially effective. Record any such override explicitly, with the rule that justifies it, so aggregation reports do not silently differ from the matrix.

Two risks are outside appetite (RSK-PAY-002 and RSK-PAY-005). Both require an action plan and a temporary risk acceptance signed by the authority defined in the operational risk policy until the action is complete.

8. Issues and action plans

Track actions in the bank's issue management system together with audit and KRI actions. When an action is closed, the second line checks the evidence and, where relevant, the control is retested before the residual rating is lowered.

9. KRI mapping

KRIs are defined in the KRI Framework Specification (finance/kri-framework-spec). The mapping below shows which indicators warn of each risk and their status at the data cut-off of 2026-09-30.

Every risk with an inherent rating of High or Very high has at least one KRI, except RSK-PAY-003, for which a new key control indicator is proposed above.

10. Loss events, incidents and external events

Loss and incident data challenge the self-assessment. If a risk rated Low produced a material loss, either the rating or the loss classification is wrong. Losses are recorded and classified in the Operational Loss Event Report (finance/operational-loss-event-report); ICT incidents classified as major under DORA are also reported under the bank's incident management process.

Net losses in the table total 450,000 + 65,000 + 212,500 + 885,000 = EUR 1,612,500, within the EUR 2.0 million allocation to the payments unit under RAS-OPR-01 (81% used by 2026-09-30, so the allocation would be exceeded at the same loss rate before year end: 1,612,500 / 9 x 12 = EUR 2,150,000). Each net figure equals gross less recoveries: 520,000 minus 70,000, 310,000 minus 245,000, 1,304,500 minus 1,092,000, and 1,020,000 minus 135,000. The operational risk function reported this run rate to the Executive Risk Committee with the September KRI pack. The full record of OLE-2026-014 is the worked example in the Operational Loss Event Report (finance/operational-loss-event-report).

External events reviewed: record relevant public loss events or supervisory publications from peers and state whether they reveal a gap. Example: a peer bank's outage caused by a failed cloud region migration led the unit to confirm that RSK-PAY-006 covers region-level failure as well as provider exit.

11. Operational resilience and third-party dependencies

The Basel Committee Principles for Operational Resilience (March 2021) group expectations under seven headings: governance; operational risk management; business continuity planning and testing; mapping of interconnections and interdependencies; third-party dependency management; incident management; and resilient ICT including cyber security. This section records the RCSA evidence for the headings that apply at unit level. Under DORA, the ICT risk management framework (Articles 5 to 16), ICT-related incident management and reporting (Articles 17 to 23) and the management of ICT third-party risk (Articles 28 to 30) set the legal requirements for EU financial entities; check the consolidated text and the related technical standards.

Keep the provider names, contract references and criticality assessments identical to the DORA Register of Information (compliance/dora-ict-third-party-register). Differences between the two are a reportable data issue. Where a third party supports a function the bank has assessed as critical or important, check that the contract includes the provisions the bank's ICT third-party policy requires, that the exit plan has been tested (CTL-PAY-009) and that concentration on a single provider has been assessed.

12. Second-line challenge and sign-off

The second line challenges the RCSA for completeness (all event types and processes considered), consistency (ratings in line with similar units and with loss and KRI data) and evidence (control ratings supported by tests). Unresolved disagreements are escalated to the Head of Operational Risk, who decides and records the decision.

Sign-off confirms that the unit head accepts the ratings and actions, that the second line has completed its challenge, and that the results have been loaded into the risk register and aggregated in the operational risk profile reported against the Risk Appetite Statement. The next RCSA is due in [12] months, or earlier after a trigger: a material loss or incident, a major change in systems or processes, a new product, a reorganisation, or a red KRI that remains red for two periods.

13. Glossary and references

13.1 Glossary

13.2 References

• Basel Committee on Banking Supervision, Revisions to the Principles for the Sound Management of Operational Risk (March 2021) and Principles for Operational Resilience (March 2021), cited by name only.
• Basel operational risk event type taxonomy (Level 1 categories), cited by name only.
• Regulation (EU) 2022/2554 (DORA), Articles 5 to 16, 17 to 23 and 28 to 30, applicable from 17 January 2025, EUR-Lex.
• Regulation (EU) No 575/2013 (CRR) as amended by Regulation (EU) 2024/1623 (CRR3), operational risk own funds and loss data provisions, EUR-Lex.
• European Banking Authority, Guidelines on internal governance under Directive 2013/36/EU, EBA/GL/2021/05.
• Risk Assessment Methodology (compliance/risk-methodology) for the general scoring method.

Standard and licence note

Structure aligned with the Basel Committee Revisions to the Principles for the Sound Management of Operational Risk (2021), the Basel Committee Principles for Operational Resilience (2021) and the Basel event type taxonomy, all cited by name only with no text reproduced. Based on public law where cited: Regulation (EU) 2022/2554 and Regulation (EU) No 575/2013 as amended (EUR-Lex). EBA guidelines are referenced with acknowledgement and no text is reproduced. All text, scales, risks, controls and figures are original and illustrative; they are not regulatory requirements. Fernhollow Bank and all figures are fictional. Check the current official version of each principle, guideline and regulation before use. Template licence: MIT.