Operational resilience: business impact analysis, business continuity plan and DORA

Answer first. Operational resilience is the ability to keep delivering important business services through disruption. You build it in four moves: identify important services and set impact tolerances, run a business impact analysis to fix recovery objectives and dependencies, write and exercise a continuity plan, and test severe but plausible scenarios. DORA, the PRA and the FCA each require all four.

What operational resilience is, and how it differs from business continuity and disaster recovery

The Basel Committee on Banking Supervision defines operational resilience as a bank's ability to deliver critical operations through disruption. The UK Prudential Regulation Authority (PRA) says in SS1/21 that it is the ability of firms, their groups and the financial sector as a whole to prevent, adapt to, respond to, recover from and learn from operational disruptions. Both definitions start from the service the customer or market receives, not from the plan the firm has written.

• Business continuity protects the organization's own activities. ISO 22301:2019 asks you to identify the activities behind your products and services, decide how quickly each must resume, and plan to resume them. The unit is the activity.
• Disaster recovery restores technology: systems, data and infrastructure, each with a recovery time and recovery point objective.
• Operational resilience asks which services would harm customers, markets or the system if they stopped, how much disruption is tolerable, and whether you can prove you would stay inside that limit in a severe but plausible scenario. The unit is the important business service, end to end, including what third parties do for you.

The three nest rather than compete. The PRA says in SS1/21 that operational risk management and business continuity planning belong in existing firm practices and should be referenced in the resilience self-assessment only where they directly pertain to the rules. For the distinction in depth, read Operational resilience vs business continuity and Incident management vs crisis management vs business continuity. This guide builds the program underneath all three.

The regulatory drivers: PRA, FCA, DORA, Basel and ISO 22301

Five instruments shape what a resilience program must contain. They overlap heavily. Build once against the union of their requirements, then map evidence back to each.

The regulatory drivers: PRA, FCA, DORA, Basel and ISO 22301

Instrument	Issuer and date	Who is in scope	Core requirement	Key dates
SS1/21 Operational resilience: Impact tolerances for important business services, with PS6/21	PRA, 29 March 2021; current version March 2022	UK banks, building societies, PRA-designated investment firms and CRR consolidation entities; UK Solvency II insurers, the Society of Lloyd's and its managing agents	Identify important business services, set impact tolerances, map resources, test severe but plausible scenarios, document a board-approved self-assessment	Rules effective 31 March 2022; able to remain within impact tolerances by 31 March 2025
PS21/3 Building operational resilience, rules in SYSC 15A	FCA, 29 March 2021	Banks, building societies, designated investment firms, insurers, Recognized Investment Exchanges, enhanced scope SM&CR firms, and payment and e-money institutions under the Payment Services Regulations 2017 or the Electronic Money Regulations 2011	The same four elements, framed around intolerable harm to consumers or risk to market integrity; written self-assessment retained six years	Rules in force 31 March 2022; remain within impact tolerances no later than 31 March 2025
Regulation (EU) 2022/2554 (DORA)	European Parliament and Council, 14 December 2022	21 categories of financial entity in Article 2(1), from credit institutions to crowdfunding service providers, plus ICT third-party service providers	ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, information sharing	Applies from 17 January 2025 (Article 64)
Principles for operational resilience	Basel Committee on Banking Supervision, 31 March 2021	Banks in Basel Committee member jurisdictions, through national supervisors	Seven principles: governance, operational risk management, business continuity planning and testing, mapping interconnections and interdependencies, third-party dependency management, incident management, and ICT including cyber security	Principles, not rules
ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements	International Organization for Standardization, 2019 (second edition)	Any organization; voluntary, certifiable	A business continuity management system with a BIA (clause 8.2.2), risk assessment (8.2.3), strategies (8.3), plans (8.4) and an exercise program (8.5)	No regulatory deadline

Two supporting documents matter for the BIA. ISO/TS 22317:2021 (second edition, November 2021) is ISO's guidance on running the BIA that ISO 22301 requires. NIST SP 800-34 Rev. 1 (May 2010, updated November 2010) holds the clearest published definitions of maximum tolerable downtime, recovery time objective and recovery point objective, and a three-step BIA method that works outside government.

If you operate in the UK and the EU, both regimes apply in parallel. The UK regime is service-led and technology-neutral; DORA is ICT-led and prescriptive about incidents, testing and contracts. A program built on important business services, with ICT dependencies mapped under each, satisfies both.

Important business services and impact tolerances

The UK regime rests on two definitions.

An important business service is, in SS1/21 paragraph 2.2, a service a firm provides which, if disrupted, could pose a risk to the firm's safety and soundness or, where the firm meets the relevant criteria, to the financial stability of the UK; for insurers, policyholder protection is added. The FCA's version in PS21/3 paragraph 2.2 is a service which, if disrupted, could cause intolerable harm to consumers or risk to market integrity. The FCA describes intolerable harm as harm from which consumers cannot easily recover, much more severe than inconvenience.

An impact tolerance is the maximum tolerable level of disruption to an important business service, measured by a length of time and any other relevant metric (SS1/21 paragraph 3.1), set at the point at which any further disruption would pose a risk to those objectives (paragraph 3.2). Three features of the PRA's guidance decide how you set one:

1. A time metric is mandatory (paragraph 3.6). Firms must also consider adding volume or value metrics, such as the number or value of transactions that can be interrupted for that period.
2. Assume the disruption has happened (paragraph 3.5). Set tolerances without considering cause or probability. A tolerance is not a risk appetite statement; Risk appetite vs risk tolerance vs impact tolerance explains why the three are different numbers.
3. Peak matters (paragraph 3.9). Tolerances apply at peak times as well as normal ones.

The PRA's working method (paragraph 3.7) is to assume the service is unavailable for a period, judge whether that poses a risk to the objectives, and lengthen the period until it does. Both regulators expect the list of important business services to be reviewed at least annually or sooner on significant change (SS1/21 paragraph 2.10; SYSC 15A.2.2R).

Two warnings. Internal services such as HR or payroll are not important business services on their own (paragraph 2.7); they appear in the mapping under the services that depend on them. And the list must be short enough for the board to prioritize and invest in each item (paragraph 2.9).

DORA's parallel concept is the critical or important function: one whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities (Article 3(22)). Firms in both regimes keep one register in which each important business service is tagged with the critical or important functions it contains.

How to run a business impact analysis, step by step

The BIA turns a list of services into recovery requirements. ISO 22301:2019 clause 8.2.2 requires it. DORA Article 11(5) requires financial entities to conduct one that assesses the potential impact of severe business disruptions by quantitative and qualitative criteria. The PRA and FCA do not use the term, but impact tolerances and mapping both depend on its outputs. The eight steps below combine the ISO/TS 22317:2021 process (clauses 5.2 to 5.8) with the NIST SP 800-34 Rev. 1 three-step method.

Step 1: Plan the BIA and agree the method (ISO/TS 22317 clauses 5.2 and 5.3). Name a BIA leader and activity owners, fix the scope, and agree impact types (financial, customer, regulatory, legal, reputational, operational), scoring criteria and time frames (for example 4 hours, 24 hours, 3 days, 1 week, 1 month) before collecting any data, so no department invents its own scale.

Step 2: Prioritize products and services with top management (clause 5.4). Start from what the organization delivers externally, not from departments. For a regulated firm the list should reconcile to the important business services register.

Step 3: Identify the activities that deliver each service (ISO 22301 clause 8.2.2; NIST step 1). Record each activity once, with an owner, even where several services share it.

Step 4: Assess impact over time (clause 8.2.2). Impact is a curve, not a score. A settlement activity may be tolerable at four hours and intolerable at 24. Score each activity at each time frame from Step 1.

Step 5: Set the time-based objectives. From the impact curve, derive the outputs in the table below, per activity, then roll up to the service. Where a service has an impact tolerance, the recovery times of the activities on its critical path must sum to less than it.

Step 6: Identify resources and dependencies (ISO/TS 22317 clause 5.6; NIST step 2). For each prioritized activity, list the roles and headcount, premises, applications, data, equipment, suppliers and internal dependencies needed to resume at the minimum acceptable level.

Step 7: Analyze, consolidate and resolve conflicts (clause 5.7; NIST step 3). Where two activities need the same scarce resource at once, decide the sequence now. Where an application's achievable recovery time exceeds the RTO of an activity that depends on it, log a gap as a finding for treatment.

Step 8: Obtain top management approval and schedule the review (clause 5.8 and clause 6). ISO 22301 clause 8.2.1 requires review at planned intervals and on significant change. Annual review matches the PRA's minimum for services and mapping.

The BIA outputs

The BIA outputs

Output	Definition	Source	How to use it
Maximum tolerable period of disruption (MTPD)	The time frame within which the impacts of not resuming an activity would become unacceptable	ISO 22301:2019 clauses 3 and 8.2.2	The hard ceiling; everything else fits inside it
Maximum tolerable downtime (MTD)	The time a mission or business process can be disrupted without causing significant harm to the organization's mission	NIST SP 800-34 Rev. 1	The US term for the same ceiling; use one term consistently
Recovery time objective (RTO)	The maximum time a system resource can remain unavailable before there is an unacceptable impact on other resources, supported processes and the MTD	NIST SP 800-34 Rev. 1	Set per activity and per supporting system; NIST states the RTO must normally be shorter than the MTD
Recovery point objective (RPO)	The point in time to which data must be recovered after an outage	NIST SP 800-34 Rev. 1	Drives backup frequency and replication; a measure of tolerable data loss, not downtime
Minimum business continuity objective (MBCO)	The minimum level of services or products acceptable to achieve business objectives during a disruption	ISO 22301:2019 clause 3	Defines what "resumed" means, for example 40 per cent of volume for priority clients
Impact tolerance	The maximum tolerable level of disruption to an important business service, measured by time and other relevant metrics	PRA SS1/21 paragraph 3.1; FCA SYSC 15A.2.5R	The regulatory ceiling at service level
Dependencies	The people, processes, technology, facilities, information and third parties needed to resume each prioritized activity	ISO 22301:2019 clause 8.2.2; PRA SS1/21 paragraph 5.1; FCA SYSC 15A.4.1R	Input to mapping, to the plan's resource requirements and to third-party risk

Two rules hold across the standards. MTPD or MTD is set by the business and describes harm; RTO is set by the recovery team and describes a target. For how the BIA connects to the rest of a GRC data model, read Business impact analysis: building the map before the crisis. The glossary entry What is a business impact analysis (BIA)? gives the short definition.

Mapping people, processes, technology, facilities and third parties

Mapping is the regulatory name for documenting what the BIA found. The PRA (SS1/21 paragraph 5.1) and the FCA (SYSC 15A.4.1R) use the same words: firms must identify and document the people, processes, technology, facilities and information necessary to deliver each important business service. The PRA adds (paragraph 5.5) that firms must map resources whether or not a third party provides them, intragroup or external.

The PRA sets the depth in paragraph 5.4: map to the level of detail necessary to identify vulnerabilities and to test the ability to remain within impact tolerances. For each resource, ask the two questions in paragraph 5.2: is it fit for purpose, and what happens to the service if it becomes unavailable? If the map cannot answer the second, it is not deep enough.

A workable map has six layers under each important business service:

1. The service chain: the activities from taking on an obligation to delivering the outcome, with the parts critical to delivery marked (paragraph 2.8).
2. People: roles, minimum numbers, locations and non-substitutable skills.
3. Processes: the BIA activities, with RTO, RPO and MBCO.
4. Technology and information: applications, infrastructure, data stores and interfaces, each linked to the activity it supports and its achievable recovery time; the disaster recovery plan plugs in here.
5. Facilities: sites, data centers and work-area recovery locations, with capacity.
6. Third parties: suppliers, intragroup providers and, where material, their subcontractors. Paragraph 5.6 expects firms to understand reliance on sub-outsourcing. DORA's register of information (Article 28(3)) is the equivalent record.

Keep the map in linked records, not a diagram, so it can answer "which important business services depend on this data center?" the day after a fire. The PRA expects mapping to be updated at least annually or after significant change (paragraph 5.9). Operational resilience: connecting critical services, assets, vendors and response plans covers the data model.

Scenario testing against severe but plausible disruption

Testing is where the program proves, or fails to prove, that the tolerance holds. Both UK regulators require firms to test their ability to remain within impact tolerance for each important business service in a severe but plausible disruption (SYSC 15A.5.3R; SS1/21 paragraph 6.1). Chapter 6 of SS1/21 sets the design principles:

• Test recovery, not prevention (paragraph 6.1). Tolerances assume the disruption has happened, so testing focuses on response and recovery arrangements.
• Source scenarios from real events (paragraph 6.2): previous incidents and near misses in the firm, across the sector and in other sectors and jurisdictions.
• Test the whole chain (paragraph 6.8), including the parts third parties perform.
• Vary severity (paragraph 6.9) by extending duration, widening the resources lost or combining events, and test some scenarios in which you expect to exceed tolerance (paragraph 6.12). A program in which every test passes was designed to pass.
• Keep a testing plan (paragraph 6.6; SYSC 15A.5.1R) with frequency proportionate to potential impact and to material change in the supporting resources.
• Do not cause the disruption (paragraph 6.7).

Record the assumptions, the result against tolerance, the vulnerabilities found and the remediation decided; paragraph 6.3 expects the self-assessment to document all of these. The FCA's lessons-learned rules (SYSC 15A.5.8R and 15A.5.9R) require firms to identify weaknesses after tests and incidents and act on them.

DORA adds a technology layer: a yearly test of every ICT system supporting a critical or important function (Article 24(6)); threat-led penetration testing at least every three years for entities their competent authority identifies (Article 26(1)); and yearly testing of the ICT business continuity plans and response and recovery plans (Article 11(6)). Put the three in one calendar so they reinforce rather than duplicate each other.

Operational resilience scenario testing sets out a twelve-stage method for an individual test and an evidence checklist.

Building the business continuity plan, section by section

The plan is the document a recovery team opens at 03:00. ISO 22301:2019 clause 8.4 requires business continuity plans and procedures; DORA Article 11 requires an ICT business continuity policy, response and recovery plans, crisis communication plans and records of activity during a disruption. Neither prescribes a format. The thirteen sections below are the ones the template follows, each a set of fields so the plan can be kept as records.

1. Plan control. Owner, approver, version, approval date, next review date, review trigger and distribution; the version history forms part of the six-year record SYSC 15A.6 requires.
2. Scope and services covered. The important business services, DORA critical or important functions and legal entities covered, linked to each service's record and impact tolerance.
3. Activation criteria and authority. Who may invoke the plan, on what triggers (loss of a site, loss of a named application beyond a defined period, an incident classified as major under DORA Article 18) and how invocation is communicated.
4. Roles and teams. Recovery team, crisis management team and the interface between them, with alternates and contact channels that do not depend on the failed systems.
5. Recovery priorities. The prioritized activities from the BIA in order, each with RTO, RPO, MBCO, MTPD and owner. This section changes when the BIA changes.
6. Recovery strategies and procedures. For each activity, the strategy (relocate, re-route, manual workaround, fail over) and the step-by-step procedure. ISO 22301 clause 8.3 calls these strategies and solutions.
7. Resource requirements. People by role and number, work-area seats, applications, data, equipment and suppliers needed to reach MBCO.
8. ICT response and recovery. The disaster recovery plan for each application and the backup and restoration arrangements DORA Article 12 requires, with achievable recovery time recorded against required RTO.
9. Third-party arrangements. Suppliers relied on during recovery, the contractual commitments that apply, and the exit plan DORA Article 28(8) requires for any provider supporting a critical or important function.
10. Communications. Internal notification chains, customer messaging, and regulatory notifications with their time limits (the DORA Article 19 reports; the communications strategy SYSC 15A.8 expects).
11. Loss scenarios. The severe but plausible scenarios the plan has been tested against, with dates and outcomes.
12. Return to normal. Stand-down criteria, reconciliation steps and the post-incident review that feeds lessons learned.
13. Appendices. Contact lists, site details and a glossary.

Store sections 4 to 9 as linked records, not text, so a change to a supplier's contract or an application's recovery time updates every plan that depends on it. The CSV template at the end of this guide is structured that way.

DORA: the five pillars and what each demands in practice

Regulation (EU) 2022/2554 applies from 17 January 2025 (Article 64) to the 21 categories of financial entity in Article 2(1). Its subject matter falls into five areas, each with a concrete deliverable.

1. ICT risk management (Chapter II, Articles 5 to 16). The management body bears ultimate responsibility for ICT risk, sets and approves the digital operational resilience strategy and approves the policy on ICT third-party services (Article 5(2)); its members must keep their knowledge current through regular training (Article 5(4)). The framework must be documented and reviewed at least once a year and after major incidents (Article 6(5)). Deliverables: the approved strategy, the framework document, an ICT asset inventory linked to the functions it supports, the ICT business continuity policy and response and recovery plans of Article 11, the backup policies of Article 12, and the BIA of Article 11(5).

2. ICT-related incident management, classification and reporting (Chapter III, Articles 17 to 23). An incident management process (Article 17), a classification method (Article 18, with criteria and thresholds in Commission Delegated Regulation (EU) 2024/1772) and reporting of major incidents (Article 19). The time limits are in Commission Delegated Regulation (EU) 2025/301 Article 5: the initial notification within four hours of classifying the incident as major and no later than 24 hours from becoming aware of it; the intermediate report within 72 hours of the initial notification, even if nothing has changed; the final report no later than one month after the intermediate report or its latest update. Templates are in Commission Implementing Regulation (EU) 2025/302; both instruments were published in the Official Journal on 20 February 2025 and entered into force on 12 March 2025. Article 19(3) requires entities to inform clients of a major incident without undue delay, and Article 11(10) lets a competent authority ask for an estimate of the aggregated annual costs and losses caused by major incidents.

3. Digital operational resilience testing (Chapter IV, Articles 24 to 27). A proportionate testing program, with tests at least yearly on all ICT systems and applications supporting critical or important functions (Article 24(6)) and, for entities identified by their competent authority, threat-led penetration testing at least every three years (Article 26(1)). Deliverable: a test calendar with results, findings and remediation per system.

4. ICT third-party risk management (Chapter V, Articles 28 to 44). Covered in the next section; the deliverables are the strategy, the register of information, pre-contract assessments, compliant contracts and exit plans.

5. Information-sharing arrangements (Chapter VI, Article 45). Sharing cyber threat intelligence is voluntary, but an entity that joins an arrangement must notify its competent authority when membership is validated and when it ends.

DORA and connected GRC shows how the DORA records link; the EU DORA framework page holds the official resources and the mappings to ISO 22301, ISO 27001 and NIS2.

Third-party and concentration risk

Every instrument in this guide treats third parties as part of the firm. The PRA quotes SS2/21 in SS1/21 paragraph 5.7: firms that outsource remain fully accountable. DORA Article 28(1) says financial entities remain fully responsible for all obligations under the regulation, and turns the principle into four working obligations.

The register of information. Article 28(3) requires a register of all contractual arrangements for ICT services at entity, sub-consolidated and consolidated level, distinguishing those that support critical or important functions, and a report at least yearly to the competent authority on new arrangements, provider categories, arrangement types and the services and functions provided. The templates are in Commission Implementing Regulation (EU) 2024/2956, published in the Official Journal on 2 December 2024.

Pre-contract assessment. Article 28(4) requires the entity to assess whether an arrangement supports a critical or important function, identify all relevant risks including ICT concentration risk, and carry out due diligence. Article 29 sets the concentration test: does contracting with a provider that is not easily substitutable, or holding multiple arrangements with the same or closely connected providers, create a dependency that could endanger a critical or important function? Article 3(29) defines ICT concentration risk in those terms. Article 29 also covers long or complex subcontracting chains that could impair monitoring or supervision.

Contract terms. Article 30(2) lists what every ICT service contract must contain: a complete description of the services, the locations where they are provided and data processed, data protection and recovery provisions, service levels, incident assistance, cooperation with authorities, termination rights and participation in security awareness training. Article 30(3) adds, for critical or important functions, performance targets, notice of material developments, business continuity and security obligations, participation in the entity's TLPT, unrestricted access and audit rights for the entity and its supervisors, and exit strategies with transition periods.

Exit. Article 28(8) requires comprehensive, documented and tested exit plans for services supporting critical or important functions.

Above the entity, Article 31 lets the European Supervisory Authorities designate critical ICT third-party service providers and oversee them directly; the entity's own obligations for that provider remain. For firms outside DORA, SS2/21 chapters 5 to 10 set out the PRA's due diligence and contractual expectations (SS1/21 paragraph 6.13). Third-party risk management and Critical vendor management cover the vendor lifecycle.

Governance and board reporting

Regulators have put the board in the loop by rule.

• The PRA requires the board to approve and regularly review the important business services, the impact tolerances and the written self-assessment, including the scenario analyses (SS1/21 paragraph 7.1).
• The FCA requires the governing body to approve and regularly review the self-assessment (SYSC 15A.7.1R). It is not submitted but must be available on request (PS21/3 paragraph 6.3), and each version is retained for at least six years (SYSC 15A.6).
• DORA gives the management body ultimate responsibility for ICT risk, requires it to approve the strategy and the third-party policy, and requires regular training (Article 5).
• Basel Principle 1 is governance. The Committee's executive summary describes tolerance for disruption as the level of disruption from any type of operational risk a bank is willing to accept given a range of severe but plausible scenarios.

The self-assessment ties this together for UK firms. SS1/21 paragraph 8.3 lists its contents: the important business services and why each was identified; the impact tolerances and why each was set where it was; the mapping approach and how it found vulnerabilities and supported testing; the scenario testing with assumptions and results; the vulnerabilities and remediation; and lessons learned. For the board pack, four measures answer the questions directors must ask:

1. For each important business service: the impact tolerance, the date and result of the last scenario test, and whether the firm can currently remain within it.
2. Open vulnerabilities from mapping and testing, by service, with age and owner.
3. Concentration: which critical or important functions depend on a single provider, and whether a tested exit plan exists.
4. Incident performance: major incidents in the period, time to classify, and whether each DORA report met its deadline.

Board GRC reporting checklist gives a structure for the pack.

Common mistakes

Listing processes as services. The PRA warns against internal services (SS1/21 paragraph 2.7) and expects a proportionate list (paragraph 2.9). A list built bottom-up from the BIA activity inventory produces dozens of "services" no board can prioritize.

Setting the tolerance at the RTO. RTO is what the recovery team believes it can achieve; the impact tolerance is the point at which harm becomes intolerable. If the two are equal, the tolerance has been reverse-engineered from capability or the firm has no headroom. Derive them independently, then compare.

Treating the BIA as an annual survey. A questionnaire without a shared impact scale and time frames produces scores that cannot be compared and objectives no one owns.

Only testing scenarios you can pass. The PRA expects tests in which the firm anticipates exceeding tolerance (paragraph 6.12). A program with no failures has not found the vulnerabilities the regulator expects you to find.

Running DORA as a separate project. The ICT framework, incident process, tests, register and contracts describe the same services and providers as the UK program; run them as one.

Leaving incident cost fields empty. DORA Article 11(10) lets a competent authority ask for the aggregated annual costs and losses of major incidents. Without a cost field the estimate is reconstructed from memory.

How SmartSuite does this

SmartSuite's Operational Resilience & Business Continuity suite holds the records this guide describes as one linked data model.

• Business Impact Analysis (BIA) runs the eight steps above: process inventory, impact assessment against agreed criteria and time frames, RTO and RPO per process, dependency mapping to systems, people and third parties, scenario analysis, approval workflows and dashboards of criticality and recovery priority.
• Operational Resilience holds the important business services register with impact tolerances, the six-layer dependency map, the scenario testing program with results and evidence, recovery playbooks, and dashboards showing whether each service can remain within tolerance.
• Crisis Management coordinates the executive response when a plan is invoked: crisis events, playbooks, escalation and notification rules, and a decision and action log that becomes the evidence record.
• Incident Management captures and classifies incidents, runs the response workflow and root cause analysis, and links each incident to the services, vendors and controls involved, which is the basis for DORA Article 19 reporting and the Article 11(10) cost estimate.

The suite maps to the EU DORA and ISO 22301 framework pages, so evidence collected once can be presented against either. Connected GRC for business continuity leaders describes a first ninety days.

Frequently asked questions

What is the difference between a business impact analysis and a risk assessment?

The BIA measures the consequences of an activity stopping, over time, regardless of cause, and produces recovery objectives and dependencies. The risk assessment identifies what could cause the stoppage and how likely it is, and decides which risks to treat. ISO 22301:2019 keeps them as separate clauses, 8.2.2 and 8.2.3, and the PRA sets impact tolerances without regard to cause or probability.

Do I need an impact tolerance for every process in the BIA?

No. Impact tolerances belong to important business services, which the PRA expects to be a short list the board can prioritize. Processes and activities carry RTO, RPO and MBCO from the BIA. The activity recovery times along a service's critical path must fit inside the service's impact tolerance, which is how the two levels connect.

Does DORA require a business impact analysis?

Yes. Article 11(5) requires financial entities to conduct a business impact analysis of their exposure to severe business disruptions, assessing potential impact by quantitative and qualitative criteria and taking into account the criticality of business functions, support processes, third-party dependencies and information assets. The results feed the ICT business continuity policy and the response and recovery plans that Article 11 also requires.

How fast must a major ICT-related incident be reported under DORA?

Commission Delegated Regulation (EU) 2025/301 Article 5 sets three deadlines: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it; an intermediate report within 72 hours of the initial notification; and a final report no later than one month after the intermediate report. The classification criteria are in Delegated Regulation (EU) 2024/1772.

Sources

1. Prudential Regulation Authority, SS1/21 Operational resilience: Impact tolerances for important business services, March 2022 version (effective 31 March 2022). https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/operational-resilience-impact-tolerances-for-important-business-services-ss
2. Prudential Regulation Authority, PS6/21 Operational resilience: Impact tolerances for important business services, March 2021 (sets the 31 March 2025 date). https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/policy-statement/2021/march/ps621.pdf
3. Financial Conduct Authority, PS21/3 Building operational resilience: Feedback to CP19/32 and final rules, 29 March 2021. https://www.fca.org.uk/publication/policy/ps21-3-operational-resilience.pdf
4. Financial Conduct Authority Handbook, SYSC 15A Operational resilience. https://www.handbook.fca.org.uk/handbook/SYSC/15A/?view=chapter
5. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
6. Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 (content and time limits for major ICT-related incident reports), Official Journal 20 February 2025. https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng
7. Commission Implementing Regulation (EU) 2025/302 of 23 October 2024 (standard forms and templates for incident reporting), Official Journal 20 February 2025. https://www.regulationtomorrow.com/2025/02/further-dora-delegated-acts-published-in-oj/
8. Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 (criteria for the classification of ICT-related incidents). https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng
9. Commission Implementing Regulation (EU) 2024/2956 (standard templates for the register of information), Official Journal 2 December 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402956
10. European Securities and Markets Authority, DORA Incident Reporting – Operational Instructions, 16 September 2026. https://www.esma.europa.eu/sites/default/files/2026-09/DORA_Incident_reporting_-_Operational_instructions.pdf
11. Basel Committee on Banking Supervision, Principles for operational resilience, 31 March 2021. https://www.bis.org/bcbs/publ/d516.htm
12. Bank for International Settlements, Financial Stability Institute, Principles for operational resilience – Executive Summary, 29 September 2022. https://bis.org/fsi/fsisummaries/op_resilience.htm
13. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements. https://www.iso.org/standard/75106.html
14. ISO/TS 22317:2021 Security and resilience — Business continuity management systems — Guidelines for business impact analysis, second edition, November 2021. https://www.iso.org/standard/79000.html
15. National Institute of Standards and Technology, SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems, May 2010, updated November 2010. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

Template: business continuity plan

The companion file business-continuity-plan-template.csv lists the thirteen plan sections above as 81 fields, one row per field: section, field name, field type (text, date, person, link to another record, single select, number, duration), whether it is required, example content for a mid-size payment institution, and the source each field traces to (ISO 22301 clause, DORA article, SS1/21 paragraph or SYSC rule).

Load it as records, not as a printed form. Fields typed as links point at records that already exist in a resilience data model: important business services, prioritized activities, applications, sites, people and third-party arrangements. Loaded that way, a change to an application's achievable recovery time or a supplier's contract updates every plan that depends on it, and the plan's version history joins the six-year evidence trail the FCA requires. If you use the template as a standalone document, complete the linked fields as text and set a review date no more than twelve months out.