What must a DORA digital operational resilience strategy contain?
Article 6(8) of DORA requires a financial entity to hold a digital operational resilience strategy that sets its risk tolerance for ICT risk, analyses its impact tolerance for ICT disruptions, sets information security objectives with key performance indicators and key risk metrics, and explains its ICT reference architecture. The management body must approve the strategy, and that approval is one of the decisions the Regulation places on the board under Article 5(2). The strategy is the document that ties the rest of the ICT risk management framework to a stated appetite for disruption, so an assessor will read the other policies against it.
The depth of each element depends on the entity's size, business model and ICT footprint. A small payment institution with a single cloud platform will need fewer metrics and a shorter architecture description than a bank running many critical functions across several providers. Whatever the scale, the organization owns the strategy: it decides the tolerances, chooses the KPIs and signs off the architecture. An implementation partner can help document systems and collect the data behind the metrics, but it cannot set the risk appetite. An independent auditor or the competent authority then assesses whether the strategy is coherent and implemented.
Before drafting, confirm three things with your board and your supervisor's guidance: how risk tolerance will be expressed (quantitative or qualitative), which impact tolerances apply to each critical or important function, and whether your ICT reference architecture will be kept as a diagram, a configuration record or both. Also decide whether you will use the optional holistic multi-vendor strategy under Article 6(9), because that choice shapes the architecture section. Article 13 expects yearly reporting from senior ICT staff to the management body on progress, so define the KPIs now in a form that can be reported and traced over time.
How the strategy components connect to the rest of the framework
The Article 6(8) strategy is not a standalone paper. Each component sets a parameter or direction that other DORA documents must follow, and each produces evidence an assessor can trace. The cards below show what each component must contain and what to check before the management body approves it.
Risk tolerance approval
The strategy sets the risk tolerance level for ICT risk, and Article 3 of Delegated Regulation (EU) 2024/1774 requires the ICT risk management policy to provide for its approval. Check that the tolerance level is stated in terms the risk assessment can apply, and that the board approval date is recorded. Every accepted residual risk should be measured against this level.
Impact tolerance analysis
Article 6(8) requires the strategy to analyse impact tolerance for ICT disruptions, meaning how much disruption to critical business functions the entity can absorb. This analysis sets the recovery targets used in continuity plans and response and recovery testing. Check that each tolerance links to a named business function and to the scenarios tested later.
Security objectives and KPIs
The strategy sets information security objectives, each with key performance indicators and key risk metrics. Article 2 of Delegated Regulation (EU) 2024/1774 requires the ICT security policies to align with these objectives. Check that every objective has a measurable indicator, an owner and a reporting frequency, so progress can be shown to the board.
ICT reference architecture
The strategy must explain the ICT reference architecture, the high-level view of systems, connections and dependencies that supports the business. It is the bridge to the asset inventory and to the dependency maps used in third-party risk work. Check that the architecture names self-hosted and third-party components so reviewers can see where control responsibility sits.
Optional multi-vendor strategy
Article 6(9) allows, but does not require, a holistic ICT multi-vendor strategy covering reliance on ICT third-party providers. If adopted, it feeds the register of information and the exit planning work. Check whether the entity has decided to adopt it, and if not, that the reasoning is recorded and the concentration risk is still assessed.
Yearly progress report
Article 13 requires monitoring of how effectively the strategy is implemented, and senior ICT staff must report to the management body at least yearly. Lessons from threat-led testing and real incidents must feed back into the risk assessment. Check that the report compares results against the KPIs and tolerances set in the strategy, and records decisions the board took.
How the strategy is approved, implemented and reported each year
The strategy moves through a fixed sequence of drafting, challenge, board approval, monitoring and reporting. Each phase produces a named output that an assessor or supervisor can ask to see, and the cycle feeds lessons from tests and incidents back into the strategy.
Draft the strategy within the ICT function
The ICT function, usually led by the chief information officer or the head of ICT, drafts the digital operational resilience strategy. The draft sets the risk tolerance level for ICT risk, analyses impact tolerance for ICT disruptions, states information security objectives with key performance indicators and key risk metrics, and explains the ICT reference architecture. The output is a versioned draft with a named owner and the sources used for each target, such as the asset inventory and the latest risk assessment. The step is complete when every element Article 6(8) requires has a section in the draft.
Challenge the draft through risk and compliance
The risk management and compliance functions review the draft independently of the ICT team. They test whether the risk tolerance is consistent with the ICT risk assessment methodology, whether the impact tolerances match the business functions the entity has classified, and whether each KPI and risk metric can be measured with data the entity actually collects. Challenges are logged with the response and the change made. The output is a reviewed draft and a record of open points, which should be closed before the draft goes to the management body.
Obtain management body approval with a recorded date
The management body bears ultimate responsibility for ICT risk under Article 5(2), so it must approve the strategy and the ICT risk tolerance. The approval is recorded in board minutes or a formal resolution that states the date of approval and the version approved. The same date is referenced in the ICT security policies, which must state when the management body formally approved them under Article 2 of Delegated Regulation (EU) 2024/1774. The output is a signed approval record that an assessor can trace from the strategy to the policies.
Monitor implementation against the stated objectives
Once approved, the strategy becomes the reference for monitoring. Owners report on each information security objective, the KPIs and key risk metrics, and any deviation from the risk or impact tolerance. Monitoring under Article 13(4) checks how effectively the strategy is being implemented, so the entity should be able to show trend data rather than a single snapshot. The output is a periodic monitoring pack with the metric values, the owner of each gap and the action taken. Confirm the reporting frequency with your own governance calendar, as DORA sets no fixed interval for this internal monitoring.
Feed lessons from tests and incidents back
Article 13(3) requires lessons from threat-led penetration testing and from real ICT-related incidents to be fed continuously into the ICT risk assessment. Findings from resilience tests and post-incident reviews therefore change the threats, vulnerabilities and tolerances recorded in the strategy and the risk register. Where a finding shows that a KPI or tolerance was set wrongly, the strategy is updated and re-approved under the same route. The output is a documented link from each lesson to a risk assessment entry or a strategy change, which supervisors commonly ask to trace.
Prepare the yearly report from senior ICT staff
Under Article 13(5), senior ICT staff report to the management body at least yearly on the ICT risk and the progress of the strategy. The report draws on the monitoring pack, the test and incident lessons, and the status of open risk acceptances. It should state the objectives met and missed, the changes approved in the year, and the resources requested. The output is a written report addressed to the management body, with the board's receipt minuted. Ask your auditor or consultant how they expect the report to be structured, since DORA sets the frequency but not a template.
Re-approve the strategy on material change
The annual report is the trigger to decide whether the strategy still holds. If the business model, the ICT reference architecture, the critical functions or the risk tolerance have changed, the ICT function revises the draft and the cycle restarts from challenge to approval. If nothing material has changed, the management body records that the strategy was reviewed and confirmed. The output is either a new approved version with a new approval date or a minuted confirmation, so that the version in force is always clear to supervisors and auditors.
How the strategy scales for different entity types
Credit institutions, large investment firms and other sizeable entities are expected to build the strategy in full. The Article 6(8) elements apply without reduction: risk tolerance, impact tolerance, information security objectives with key performance indicators and key risk metrics, and the ICT reference architecture. The management body approves the strategy under Article 5(2), and senior ICT staff report progress to it at least yearly under Article 13.
- Full impact analysis: impact tolerances tied to the business functions and services recorded in the asset inventory.
- Measurable objectives: KPIs and key risk metrics with named owners, baselines and thresholds the board can review.
- Architecture depth: a reference architecture covering production, recovery sites, cloud platforms and third-party dependencies.
- Documented multi-vendor position: an explicit decision under Article 6(9), recorded even when the answer is a single provider model.
- Annual reporting cycle: progress reports that measure the strategy against its objectives each year.
Confirm with your competent authority how detailed it expects the architecture and metrics to be, and whether it tests the strategy during supervisory inspections.
Smaller entities still need a digital operational resilience strategy. Proportionality under Article 4, together with the simplified regime in Chapter II, changes how deep the strategy goes, while the core elements stay in place. A small firm can keep the document shorter, with fewer metrics, a simpler architecture view and a lighter review cycle. The management body still approves the strategy, and it still states risk tolerance and impact tolerance.
- Shorter document: fewer objectives and metrics, sized to the critical functions the firm actually runs.
- Simple architecture view: one current diagram of systems, hosting locations and key providers.
- Same approval step: management body sign-off with a dated version history.
- Lighter reporting: progress reported in the yearly cycle with a smaller set of indicators.
- Stated scope of simplification: a short note explaining which simplified-regime elements apply and why.
Ask your competent authority whether it accepts a short-form strategy and which elements it expects in every case, including the approval record and the risk tolerance statement.
Entities that depend heavily on ICT third-party providers need the strategy to show how that dependence is managed. This includes entities that rely on cloud platforms or on providers that may be designated as critical and overseen under Section II of Chapter V. For these firms, the optional multi-vendor strategy in Article 6(9) becomes a substantive design decision. The reference architecture must show where critical functions run and how the firm would move them if a provider failed. Contract and register work under Articles 28 to 30 should feed the strategy's risk metrics.
- Dependency map: each provider linked to the critical or important functions and to the architecture diagram.
- Concentration measures: metrics for reliance on a single provider, platform or hosting region.
- Exit and substitution: strategy statements tied to exit plans and to substitution options that have been assessed.
- Documented provider model: a recorded rationale for a single-provider or multi-provider design.
- Feedback loop: a defined route by which provider audits, reports and incidents update objectives and risk metrics.
Confirm with your competent authority how it expects concentration risk and exit planning to appear in the strategy, and check that your provider contracts give you the information the strategy requires.
DORA applies directly in every EU member state, but supervision sits with the national competent authority for each type of financial entity under Article 46. The ECB supervises credit institutions classified as significant. Authorities may publish guidance on how detailed the strategy should be, how often it is reviewed and what they request during supervisory reviews. Local expectations therefore shape how each element of the strategy is written, even though the Regulation sets the baseline.
- Identify the authority: confirm which national competent authority or the ECB supervises your entity type.
- Review published guidance: look for supervisory material on strategy content, metrics and review frequency.
- Ask about inspection evidence: find out which documents the authority requests during supervisory reviews.
- Align group strategies: check that group-level strategies meet the expectations of each local authority where the group operates.
Get written confirmation of your authority's expectations before you fix the scope and the evidence list, because changes after drafting cost more to make than changes before it.
What must exist before a supervisor or auditor reviews the strategy
Article 6(8) gives the strategy its content, and Article 5(2) gives the management body the duty to approve it. The checks below cover the records a supervisor or auditor will ask for first, and each one can be verified inside the organization before any outside reviewer arrives.
Dated management body approval record
The strategy and the ICT risk tolerance must be approved by the management body under Article 5(2), and the approval must be traceable to a specific meeting. Check that the minutes name the document version, record the date of approval, and show that the board discussed the content rather than noting it. The ICT security policies must also state the date of formal approval, as required by Article 2 of Delegated Regulation (EU) 2024/1774, so the two records should agree.
Risk tolerance and impact tolerance analysis
Article 6(8) requires the strategy to set the risk tolerance level for ICT risk and to analyse impact tolerance for ICT disruptions. The first is the amount of ICT risk the entity accepts, and the second is how long a disruption to a critical function can last before harm becomes unacceptable. Confirm that each tolerance links to named business functions and that the risk tolerance level is the one the ICT risk management policy requires the management body to approve.
Measurable KPIs with named owners
The strategy must set information security objectives with key performance indicators and key risk metrics. A KPI without a target, a data source and an accountable owner will not show whether the objective is met. For each indicator, record the measurement method, the reporting frequency, the owner and the threshold that triggers escalation to the management body, and confirm that the owner can produce the underlying data from existing systems.
Reference architecture matching the asset inventory
Article 6(8) requires the strategy to explain the ICT reference architecture. Reviewers will compare it against the asset inventory and the register of information, so any system, network zone, cloud account or self-hosted platform shown in one should appear in the other. Check for mismatches such as retired hosts still drawn in the diagram, or services in the inventory with no place in the architecture. Record the review date and the person who signed off the diagram.
Evidence of a prior progress review
Article 5(2) and Article 13(5) require monitoring of how effectively the strategy is implemented, and senior ICT staff must report to the management body at least yearly. Before a review, the organization should hold at least one progress report that compares the KPIs with their targets, lists the lessons taken from incidents and threat-led testing, and records decisions the board made in response. A strategy with no prior report shows that monitoring has not started, which is the gap reviewers look for first.
Who owns the strategy, who prepares evidence and who tests it
The management body of the financial entity carries ultimate responsibility for ICT risk under Article 5(2) of DORA. It approves the digital operational resilience strategy and the ICT risk tolerance, approves and periodically reviews the business continuity and response and recovery plans, and allocates budget for resilience, awareness and training. The strategy must be signed off by people who can be held to it. Senior ICT staff, such as the CISO or head of ICT risk, usually draft the strategy, set the KPIs and key risk metrics, and report progress to the management body at least yearly under Article 13.
- Approval: the management body formally approves the strategy and records the approval date, which the ICT security policies must also state under Article 2 of Delegated Regulation (EU) 2024/1774.
- Risk tolerance: the board sets the ICT risk tolerance level, and the risk management policy must provide for that approval.
- Ownership of KPIs: named executives own each information security objective and the metrics that show whether it is met.
- Annual reporting: senior ICT staff report progress on the strategy to the board at least yearly.
- Outsourcing limits: the entity may outsource verification of compliance under Article 6(10), but it stays fully responsible.
Check that the approval record names the approving body, the date and the version of the strategy, and that the board minutes show a real discussion of impact tolerance and not only a sign-off.
An implementation partner such as DeployOpen can help prepare the systems and evidence that the strategy depends on. For self-hosted open-source platforms, that work usually covers configuring the platforms inside the client's own infrastructure, instrumenting the metrics behind the information security KPIs, assembling evidence packs, and drafting documentation for the client's review. The partner has no authority to approve the strategy, set the risk tolerance or accept residual risk. Those decisions stay with the entity's governance bodies, and the partner's drafts become binding only after the entity adopts them.
- Systems preparation: configuring logging, monitoring and recovery capabilities so that the KPIs in the strategy can be measured.
- Documentation drafts: preparing a first version of the strategy sections on the ICT reference architecture and the objectives, for the entity to edit and adopt.
- KPI instrumentation: wiring metrics such as patch latency or recovery time into dashboards that the owners can review.
- Evidence packs: collecting configuration records, test outputs and review minutes in a form the entity and its assessor can trace.
- Scope limits: work is fixed-scope and agreed in writing, and the scope should state that approval and risk acceptance remain with the client.
Before engaging a partner, confirm in the written scope which documents the partner drafts, who signs them, and how the partner's work is kept separate from the management body's decisions.
Assessment comes from outside the entity. Competent authorities supervise DORA compliance under the powers in Article 50, and for credit institutions classified as significant, the ECB performs that role. Independent auditors may also assess an entity's controls for its own assurance purposes. Neither body approves the strategy on the entity's behalf. DORA sets no certification scheme, so no organization can obtain a DORA certificate in the sense used by ISO/IEC 27001. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7).
- Supervision: the national competent authority for each type of financial entity assesses compliance, using the powers in Article 50.
- Independent review: an auditor reviews the strategy, its KPIs and the evidence, and reports findings to the entity.
- No DORA certificate: any claim of DORA certification should be questioned, since the Regulation provides none.
- Threat-led testing attestation: the one attestation DORA provides for concerns threat-led penetration testing under Article 26(7).
- Separation: an auditor that helped build the evidence packs should be assessed for independence before relying on it.
Ask any reviewer to state in writing what they examined, what they did not examine, and whether they were involved in preparing the material they tested.
Questions buyers ask about the DORA resilience strategy
Does DORA require a standalone resilience strategy document?
No. Article 6(8) requires a digital operational resilience strategy with specific content, but it does not say the strategy must be a separate file. Entities can keep it as a standalone document or as a clearly identified section within the ICT risk management framework, as long as every required element is present, the management body approves it, and auditors and supervisors can find it. Many organizations keep it separate because the board approves it on its own cycle and the policies refer back to it. Whichever format you choose, give it a version number and an approval date, and confirm the structure with your competent authority or your auditor before drafting. The text of Article 6 sets out the required content.
How long does it take to draft a DORA resilience strategy?
DORA sets no fixed drafting period, so the time depends on the scope of the work. The main drivers are the size of the entity or group, how many business functions and ICT services need to be analysed, how much current documentation already exists, and how many people must agree on the risk tolerance and impact tolerance before the board sees the draft. Ask for a written schedule with milestones, a list of decision points where the board or CISO must sign off, and a review round before final approval. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so a scope that names the business functions, ICT services and reviewers included will give you a more reliable schedule than an estimate based on the document alone.
What does the board and the CISO need to contribute?
Under Article 5(2), the management body bears ultimate responsibility for ICT risk and must approve the digital operational resilience strategy and the ICT risk tolerance. The board therefore needs to set risk tolerance and impact tolerance for ICT disruptions in terms it can defend, and it must allocate budget for resilience, awareness and training. The CISO or senior ICT lead typically drafts the information security objectives, the key performance indicators, the key risk metrics and the ICT reference architecture. Article 13 also requires senior ICT staff to report on the strategy to the management body at least yearly, so the reporting cycle should be agreed before the first approval. Plan at least one board session for tolerance decisions and one for final approval, and record who attended and what was decided.
Can an internal team write the strategy without outside help?
Yes. DORA does not require an external firm to draft the strategy, and an internal team that knows the business functions, the ICT services and the architecture can write it. The work that most often stalls internal teams is the impact tolerance analysis, which needs input from business owners who can describe how long a disruption to each service can run before it causes unacceptable harm, and the ICT reference architecture, which needs current, accurate system documentation. A partner can help with either piece, or review a draft written in-house for completeness against Article 6(8). Whichever route you choose, make sure the people named as owners have the time and authority to finish their sections, because an unfinished tolerance analysis will hold up the whole approval.
What can an implementation partner sign for the strategy?
A partner can prepare drafts, document the architecture, define KPIs and risk metrics, organize evidence and help run the workshops. It cannot approve the strategy. Under Article 5(2), approval sits with the organization's management body, and the organization remains responsible for its controls. Article 6(10) allows verification of compliance to be outsourced, but the entity stays fully responsible for that work. Only an independent auditor, assessor or certification body issues reports or attestations, and DeployOpen prepares systems, controls and evidence for those assessments without issuing them. Ask any provider to put in writing which deliverables they prepare, which signatures remain with your staff and which reviews belong to an independent party.
How does the strategy relate to the required ICT policies?
The strategy sets the direction and the policies put it into practice, so the policies must trace back to it. Article 2 of Delegated Regulation (EU) 2024/1774 requires ICT security policies to be embedded in the ICT risk management framework, aligned with the information security objectives of the strategy, and to state the date the management body approved them. Article 3 of the same regulation requires the ICT risk management policy to provide for approval of the ICT risk tolerance level. In practice, write the strategy first or in parallel, then check each policy against its objectives and tolerance statements, and record the approval date on every policy. The sibling topic on required DORA policies and documents lists each policy and the elements it must contain.
How DeployOpen prepares the strategy evidence for your review
DeployOpen helps financial entities and their ICT providers prepare the evidence behind a digital operational resilience strategy. The management body owns the strategy and its approval, while DeployOpen prepares the systems, metrics and documentation that show how the strategy is put into practice. Independent assessors, not DeployOpen, judge whether the result meets DORA.
How we scope
- Scope is agreed in writing before work starts, listing the ICT systems, business functions and entities the strategy covers.
- The written scope names which strategy elements are in scope, such as tolerance levels, security objectives, KPIs and the reference architecture.
- Your organization confirms who owns each strategy section and who signs off on the management body approval record.
How we build
- We help draft the impact tolerance analysis and link it to the ICT systems that support critical business functions.
- We map security objectives to measurable KPIs and key risk metrics, and set up the systems that collect those measurements.
- We document the ICT reference architecture from the hosting, network and platform components that run your self-hosted open-source services.
How we hand over
- You receive the strategy documents, metric definitions, data sources and architecture diagrams in formats your teams can maintain.
- Each deliverable is traceable to the scope agreed at the start, so reviewers can follow how each section was produced.
- We walk the management body and control owners through the evidence so they can explain and defend it to supervisors.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Support can cover updating KPIs and risk metrics for the yearly progress report to the management body.
- Ask your independent auditor or assessor to confirm which evidence they expect before the review starts.
