Flow of the explanation in this lesson.
Operational resilience and DORA: staying open when things break
What you will learn
Your objective. By the end of this lesson, you will be able to explain operational resilience and dora: staying open when things break and apply it to a real banking scenario.
Why it matters. For a business analyst, operational resilience is a requirements discipline.
Chapter objective: Data protection, US anti-money-laundering law, and keeping payments running under stress
Key learning points
- Operational resilience
- Impact tolerances
- Critical third party designation
- Resilience testing under DORA
- UK Payment Systems Regulator
- Further reading and sources
Key terms
Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.
Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.
Break: A difference found during reconciliation between two records that should agree, such as a bank statement and a ledger.
Payment flow diagram showing Operational resilience and DORA: staying open when things break.
Practise this lesson
Exercise
Investigate the reconciliation break described in this lesson and find its root cause.
Use the three-way matching rule and the break categories in this lesson.
- What to do. Compare the instruction, the settlement record and the statement, name the break type, and state the corrective action.
Correct result. A break is found by matching amount, currency, date and reference across the three sources. The root cause is a timing difference, an amount difference, a missing entry, or a duplicate, and the corrective action follows the cause.
Why. Reconciliation is the last line of defence. A break that is not investigated is money that cannot be proved.
Check your understanding
Practice question
Which of the following best describes operational resilience and dora: staying open when things break?
Takeaway and next step
What to remember
For a business analyst, operational resilience is a requirements discipline.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "The US Bank Secrecy Act: the BSA framework behind every dollar payment".
Transcript and full text
Show transcript
Operational resilience is the requirement that a payment service keeps working, or recovers quickly, when something breaks. The European Digital Operational Resilience Act, Regulation (EU) 2022/2554, known as DORA, applies to banks, payment institutions, and the third party providers they depend on, from 17 January 2025. DORA does not ask for perfect uptime. It asks the firm to identify its important business services, to set an impact tolerance for each one, and to prove through testing that it can stay within that tolerance when a disruption happens. An important business service is a service whose disruption would cause harm to customers or to the financial system. For a payment firm the obvious ones are payment initiation, payment execution, and the receipt of incoming payments. Each one gets an impact tolerance, which is the maximum tolerable level of disruption, expressed as a time, a volume, or a number of affected customers. A typical tolerance for a retail payment service is that no more than a defined number of payments are delayed by more than a defined number of hours. The tolerance must be set by the board, not by the technology team. Third party risk is where DORA bites hardest. A payment firm that runs its payment hub on a cloud provider, or that uses a vendor for sanctions screening, must manage that provider as a risk, not as a purchase. DORA requires a register of all third party ICT providers, a risk assessment before signing, contractual clauses that give the firm audit and exit rights, and an exit plan that proves the firm can move the service to another provider. The European Supervisory Authorities can designate a third party provider as critical, and then supervise it directly. Incident reporting under DORA has hard deadlines. A major ICT related incident must be reported to the competent authority with an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month. A major incident is one that affects an important business service, affects a large number of customers, or causes a significant financial loss. The payment operations team must therefore be able to classify an incident within hours, not days, and the classification criteria must be written down before the incident happens. Testing is the part of DORA that most firms underestimate. DORA requires basic testing, such as vulnerability scanning and network security assessments, and advanced testing, such as threat-led penetration testing, for the most significant firms. Threat-led penetration testing is a live test in which a red team tries to break into the payment system using the tactics of a real attacker, while the blue team defends it. The test must be scoped to an important business service, and the results must go to the board with a remediation plan. The Bank of England and the Prudential Regulation Authority have their own operational resilience rules that run alongside DORA for UK firms. The PRA requires firms to identify important business services, set impact tolerances, and test them, and the Bank of England can require a firm to prove it can recover within its tolerance. The UK Payment Systems Regulator also has an interest, because a payment system that fails harms consumers directly. A firm operating in both the EU and the UK must satisfy both regimes, and the requirements are similar enough that one testing programme can cover both. For a business analyst, operational resilience is a requirements discipline. Every important business service needs a service definition, an impact tolerance, a dependency map, a test plan, and an incident classification procedure. The acceptance criteria must include a test where the primary payment hub fails and the service recovers within its tolerance, with the recovery time measured and recorded. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2022/2554 (DORA), Articles 5, 6, 19 and 28; PRA Supervisory Statement SS1/21 on operational resilience; Bank of England operational resilience policy; European Supervisory Authorities joint examination team guidance on threat-led penetration testing.
Operational resilience is the requirement that a payment service keeps working, or recovers quickly, when something breaks. The European Digital Operational Resilience Act, Regulation (EU) 2022/2554, known as DORA, applies to banks, payment institutions, and the third party providers they depend on, from 17 January 2025. DORA does not ask for perfect uptime. It asks the firm to identify its important business services, to set an impact tolerance for each one, and to prove through testing that it can stay within that tolerance when a disruption happens.
An important business service is a service whose disruption would cause harm to customers or to the financial system. For a payment firm the obvious ones are payment initiation, payment execution, and the receipt of incoming payments. Each one gets an impact tolerance, which is the maximum tolerable level of disruption, expressed as a time, a volume, or a number of affected customers. A typical tolerance for a retail payment service is that no more than a defined number of payments are delayed by more than a defined number of hours. The tolerance must be set by the board, not by the technology team.
Third party risk is where DORA bites hardest. A payment firm that runs its payment hub on a cloud provider, or that uses a vendor for sanctions screening, must manage that provider as a risk, not as a purchase. DORA requires a register of all third party ICT providers, a risk assessment before signing, contractual clauses that give the firm audit and exit rights, and an exit plan that proves the firm can move the service to another provider. The European Supervisory Authorities can designate a third party provider as critical, and then supervise it directly.
Incident reporting under DORA has hard deadlines. A major ICT related incident must be reported to the competent authority with an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month. A major incident is one that affects an important business service, affects a large number of customers, or causes a significant financial loss. The payment operations team must therefore be able to classify an incident within hours, not days, and the classification criteria must be written down before the incident happens.
Testing is the part of DORA that most firms underestimate. DORA requires basic testing, such as vulnerability scanning and network security assessments, and advanced testing, such as threat-led penetration testing, for the most significant firms. Threat-led penetration testing is a live test in which a red team tries to break into the payment system using the tactics of a real attacker, while the blue team defends it. The test must be scoped to an important business service, and the results must go to the board with a remediation plan.
The Bank of England and the Prudential Regulation Authority have their own operational resilience rules that run alongside DORA for UK firms. The PRA requires firms to identify important business services, set impact tolerances, and test them, and the Bank of England can require a firm to prove it can recover within its tolerance. The UK Payment Systems Regulator also has an interest, because a payment system that fails harms consumers directly. A firm operating in both the EU and the UK must satisfy both regimes, and the requirements are similar enough that one testing programme can cover both.
For a business analyst, operational resilience is a requirements discipline. Every important business service needs a service definition, an impact tolerance, a dependency map, a test plan, and an incident classification procedure. The acceptance criteria must include a test where the primary payment hub fails and the service recovers within its tolerance, with the recovery time measured and recorded. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2022/2554 (DORA), Articles 5, 6, 19 and 28; PRA Supervisory Statement SS1/21 on operational resilience; Bank of England operational resilience policy; European Supervisory Authorities joint examination team guidance on threat-led penetration testing.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.