# DORA continuity and response plans for Norwegian firms

> What DORA makes you write down, what it makes you test, who has to approve it, and how often each of those has to happen.

Source: https://fmcybersecurity.com/en/insights/compliance/dora-continuity-and-response-plans/
Locale: English
Other locale: https://fmcybersecurity.com/insights/compliance/dora-beredskapsplaner/

## Metadata

- Date: 2026-07-28
- Author: johan-vorgaard
- Topic: compliance
- Format: guide

Here is what DORA asks for in ICT continuity and response planning: which documents have to exist, which of them have to be tested, and who signs.

DORA has applied across the EU since 17 January 2025 ([Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng), Article 64). Norway came in through the EEA. [Finanstilsynet](https://www.finanstilsynet.no/tema/dora/forordning-om-digital-operasjonell-motstandsdyktighet-i-finanssektoren-dora/) states that DORA was incorporated into the EEA Agreement on 20 February 2025, and that the Norwegian DORA act and the DORA regulation both entered into force on 1 July 2025. From that date, [most supervised firms left the scope of the old ICT regulation](https://www.finanstilsynet.no/nyhetsarkiv/nyheter/2025/ny-lov-om-digital-operasjonell-motstandsdyktighet-i-finanssektoren-dora-loven-trer-i-kraft-1.-juli) (IKT-forskriften) and came under DORA instead.

Continuity is where the old binder and the new rulebook part company. A pre-DORA plan usually models a data centre failure and a power cut. DORA asks what happens when your core banking provider goes insolvent, whether last year's test carried a cyber-attack scenario, and which board meeting approved the version you are holding.

## 1. Fix which regime you are in before you write anything

Two regimes govern continuity planning under DORA: the full ICT risk management framework, and a simplified framework for a defined set of smaller entities (DORA Article 16).

Write the classification down, name the provision you rely on, and file it with the plan. Finanstilsynet's [DORA Q&A](https://www.finanstilsynet.no/tema/dora/qa-dora/) notes that smaller firms, microenterprises among them, are exempt from several mandatory requirements. A microenterprise under DORA has fewer than 10 staff and turnover or a balance sheet at or below EUR 2 million (Article 3(60)). If you have not yet mapped scope at all, start with our [DORA checklist for Norwegian financial firms](/en/insights/compliance/dora-checklist-for-norwegian-financial-firms/) and come back here.

## 2. Run the business impact analysis first, then write the plan

The business impact analysis is the input to every other continuity document, not an appendix to it (DORA Article 11(5)).

List your critical or important functions. For each one, set a recovery time objective and a recovery point objective, and tie both to how the outage would hit the market and your customers (Article 12(6)). Then record which ICT assets carry the function and which of those assets sit at a third party. The analysis has to use quantitative and qualitative criteria and consider severe disruption scenarios, so a single availability percentage is not enough.

## 3. Write the ICT business continuity policy as a document of its own

DORA names the ICT business continuity policy as a separate deliverable inside the ICT risk management framework (Article 11(1)).

[Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) sets out what the policy contains: objectives drawn from the business impact analysis, scope and timeframe, criteria for activating and deactivating the plans, roles for implementation, how the ICT arrangements sit inside overall business continuity, the order recovery actions run in, and how the policy connects to crisis communication (Article 24). The same article gives central counterparties and central securities depositories a hard recovery target of no more than two hours for critical functions, and asks trading venues to resume trading within or close to two hours.

## 4. Build the response and recovery plans around a named scenario list

Response and recovery plans have to be written against specific disruption scenarios, not against a generic outage (Delegated Regulation (EU) 2024/1774, Article 26).

The scenario list is spelled out for you: cyber-attacks and switchovers between primary and redundant infrastructure, failure of an ICT third-party service provider including insolvency, loss of premises or a data centre, failure of the ICT assets a critical function depends on, staff unavailability, natural disasters and climate events, insider attacks, political instability, and widespread power outages. Each plan states its activation and deactivation conditions, the actions that protect availability and integrity, short-term and long-term recovery options, and what counts as success. Assign the roles by name in the document, and keep a copy readable when the network is down. For every firm other than a microenterprise, the response and recovery plans go through independent internal audit review (DORA Article 11(3)).

## 5. Get the board to approve the plans, then put the review date in the minutes

The management body approves, oversees and periodically reviews the ICT business continuity policy and the ICT response and recovery plans (DORA Article 5(2)).

Delegation does not work here. In the DORA reviews I have sat in, the finding that comes back most often on this article is a plan signed off by the CISO alone. Review the wider ICT risk management framework at least once a year, and again after any major ICT-related incident, after supervisory instructions, and after conclusions from resilience testing or audit (Article 6(5)). Minute the date, the version number and the decision, because the minute is the evidence.

## 6. Test at least once a year, and let the test fail

Continuity and response plans must be tested at least yearly, and again on any substantive change to ICT systems supporting critical or important functions (DORA Article 11(6)).

For firms other than microenterprises, the annual test has to include a cyber-attack scenario and a switchover between the primary infrastructure and redundant capacity, backups and redundant facilities. The delegated regulation adds more teeth: severe but plausible scenarios, failure of an ICT third-party provider, and a live challenge to the assumptions in the plan, including governance and crisis communication procedures (Article 25). Backup and restoration procedures carry their own periodic test (DORA Article 12(2)), and data restoration runs on systems physically and logically segregated from the source system (Article 12(3)). Document the results, the deficiencies you found and the remediation plan, and take all three to the management body. Resilience testing is a wider programme than this, and our companion piece on [DORA and recurring penetration testing](/en/insights/compliance/dora-and-recurring-penetration-testing/) covers the rest of it.

## 7. Keep the records that prove the plan ran

When a continuity plan is activated, keep readily accessible records of activities before and during the disruption (DORA Article 11(8)).

Three more obligations attach to the same evidence pile. Non-microenterprises appoint a crisis management function with written procedures for internal and external communication (Article 11(7)), and at least one person is tasked with implementing the communication strategy for ICT-related incidents (Article 14(3)). After a major incident, run a post-incident review and report what it found to the management body (Article 13(2)). And on request, non-microenterprises hand the supervisor an estimate of aggregated annual costs and losses from major incidents (Article 11(10)). If a monitoring service produces your incident timeline, name it in the plan; that is what our [managed detection and response](/en/services/mdr/) customers hand to their auditors. For the reporting clocks and supervisor-facing side of this, see [DORA audit and reporting requirements](/en/insights/compliance/dora-audit-and-reporting-requirements/).

## What a pre-DORA continuity plan usually misses

Five gaps show up again and again when a continuity binder written before July 2025 gets read against DORA:

- No named third-party failure scenario. Data centre loss is in there; provider insolvency almost never is.
- No cyber-attack scenario in the annual test, and no switchover to redundant capacity.
- A restore procedure that writes back onto the source system, rather than onto segregated systems.
- Recovery time objectives set for infrastructure, not for the critical or important functions the business runs on.
- Approval by IT rather than by the board, with no dated review cycle behind it.

If your documentation was built for ISO 27001, the structure carries over well. Annex A controls 5.29 and 5.30 already cover information security during disruption and ICT readiness for business continuity, and the [ISO 27001 checklist for Norwegian SMBs](/en/insights/compliance/iso-27001-checklist-for-norwegian-smbs/) walks that ground. What ISO 27001 does not give you is the scenario list, the yearly test floor or the board-approval trail. Those are the DORA additions. If your firm falls outside DORA but runs an essential service in Norway, the parallel duties sit in [the Digital Security Act](/en/insights/compliance/what-norways-digital-security-act-is/). Choosing where the evidence lives is a separate decision, and our note on [tooling for DORA compliance](/en/insights/compliance/tooling-for-dora-compliance/) works through it.

Operational stability in Norwegian finance held up last year. Finanstilsynet's [ROS 2026 analysis](https://www.finanstilsynet.no/nyhetsarkiv/nyheter/2026/risiko--og-sarbarhetsanalyse-ros-2026) records that operational stability and the availability of payment services in 2025 were satisfactory, while the digital threat level is assessed as high. Plans get tested by supervisors long before they get tested by an incident.

## Next step

Take last year's continuity test report and read it against DORA Article 11(6). If it has no cyber-attack scenario and no switchover, you have your first finding, and you have it before the supervisor does. Send Johan Vorgaard a message, or see how [our compliance team](/en/services/compliance/) works, and we will read the continuity policy and the response and recovery plans with you before they go to the board.

## FAQ

### How often does DORA require us to test the continuity and response plans?

At least once a year, and again on any substantive change to the ICT systems supporting critical or important functions (Article 11(6)). Backup and restoration procedures are tested periodically on their own track (Article 12(2)). If you are not a microenterprise, the yearly test has to include a cyber-attack scenario and a switchover to redundant capacity and backups.

### Does the board have to approve the plans, or is the policy enough?

Both. The management body approves, oversees and periodically reviews the ICT business continuity policy and the ICT response and recovery plans (Article 5(2)). Approving the policy and leaving the plans to IT does not meet the wording. Record the approval in the minutes with a version number.

### We already have a group business continuity plan. Do we need a separate ICT one?

You need ICT continuity arrangements that meet DORA on their own terms, and the regulation allows them to sit as a dedicated part of the overall business continuity policy. What matters is that the ICT-specific content is present and traceable: the business impact analysis, the scenario list, the activation criteria, the recovery objectives and the testing record. A group plan that mentions IT in one paragraph will not survive a review.

### Does DORA apply in Norway, and since when?

Yes for most firms under Finanstilsynet supervision. DORA applied in the EU from 17 January 2025, was incorporated into the EEA Agreement on 20 February 2025, and the Norwegian DORA act and DORA regulation entered into force on 1 July 2025. Confirm your own scope against Article 2 of the regulation and write the conclusion down.

### What changes if we use the simplified framework?

Less depth, not fewer documents. Firms under the simplified framework still need an ICT business continuity plan built on an analysis of severe disruption, approved by the management body, documented and reachable in an emergency, with recovery timelines, activation criteria, backup arrangements and communication procedures (Delegated Regulation (EU) 2024/1774, Article 39). Name the provision you rely on so the discussion does not restart at every supervisory cycle.

Drafted with AI assistance, reviewed and edited by Johan Vorgaard and the FM CyberSecurity editorial team.

---

For the full documentation index, see https://fmcybersecurity.com/llms.txt
For the complete corpus as a single document, see https://fmcybersecurity.com/llms-full.txt