DORA came into force in January 2025. It requires EU and EEA insurers to define impact tolerances, detect and report major incidents within four hours, test recovery capability annually, and manage third-party ICT risk systematically. This post explains the five DORA obligations, the technology that supports each one, and what the difference looks like between detecting a failure at 02:45 versus 03:14.
The Batch Failed at 03:00. The Alert Arrived at 03:14. DORA Requires Four Hours from Classification.
The alert arrives at 03:14 on a Tuesday morning. The on-call engineer picks it up immediately. The policy administration system is unresponsive. The claims portal is returning a 503 error. The direct debit batch that runs at 03:00 has not completed. 4,200 customers are due to have payments taken before 09:00. The engineer calls the incident response team. The head of technology joins the call at 03:22. The CTO is notified at 03:25. Nobody knows yet whether this is a hardware failure, a software fault, or something more serious.
The claims portal serves 1,800 active claims. Handlers start their shifts at 08:00. If the portal is not restored by then, claims activity stops completely. The direct debit failure will generate customer complaints by mid-morning. Some customers will assume their policy has lapsed. The contact centre also runs on the same infrastructure. By 03:30, the incident response playbook is open. The team is working the problem. But the business impact clock started at 03:00. It has already been running for 30 minutes.
DORA Article 17 requires Finanstilsynet to be notified of a major ICT incident within four hours of classification. The team does not yet know if this qualifies.
What DORA Requires from Insurers
DORA establishes five categories of obligation for EU and EEA insurers. Each has a specific technology dimension. The impact tolerance statement is the starting point for everything else: it requires the insurer to define, for each critical business service, the maximum tolerable downtime and the maximum tolerable data loss — and then demonstrate that the technology recovery architecture can meet those tolerances.
| DORA requirement | Articles | What it means in practice | Technology contribution |
|---|---|---|---|
| ICT risk management framework | Arts. 5–16 | Documented framework covering identification, protection, detection, response, and recovery for all ICT systems | Automated asset inventory; continuous risk monitoring; real-time control gap detection |
| Impact tolerance statements | Art. 24 | Define the maximum tolerable downtime and data loss for each critical business service; board approval required; tested annually | Automated service availability monitoring; threshold alerting before tolerance is breached |
| Incident classification and reporting | Arts. 17–23 | Classify ICT incidents by severity; report major incidents to Finanstilsynet within defined timelines (initial: 4 hours; intermediate: 72 hours; final: 1 month) | Automated incident classification; report generation from incident log; deadline tracking |
| Digital operational resilience testing | Arts. 24–27 | Annual basic testing for all firms; threat-led penetration testing (TLPT) every 3 years for significant firms | Automated vulnerability scanning; testing schedule management; results documentation |
| Third-party ICT risk management | Arts. 28–44 | Due diligence on critical ICT suppliers; contractual resilience requirements; concentration risk assessment; exit strategy | Third-party monitoring dashboards; supplier resilience scoring; contract compliance tracking |
Technology for Impact Tolerance Monitoring
Automated service availability monitoring is the primary technology tool for impact tolerance compliance. It measures the availability of each critical service continuously, compares actual availability against the defined tolerance threshold, and alerts the operations team when availability approaches the threshold before the tolerance is breached.
A service that degrades gradually does not trigger human attention the way a sudden outage does. An API that begins returning slow responses at 02:00 and becomes fully unresponsive by 03:00 may have been in breach of its response time tolerance for an hour before the full outage was noticed. Automated monitoring catches the degradation at 02:00, not the failure at 03:00. The alert at 03:14 in the opening scene is this system working — but imperfectly. With better threshold alerting configured for early degradation signals, detection could have been at 02:45.
Incident Detection, Classification, and DORA Reporting
Automated incident classification
DORA Article 18 requires insurers to classify ICT incidents by the number of customers affected, the duration, the geographic spread, the data integrity impact, and the criticality of the affected services. This classification determines whether the incident is major (requiring regulatory notification) or minor (requiring internal logging only). Manual incident classification under pressure is unreliable: the on-call team at 03:14 is simultaneously trying to restore service and assess regulatory obligation. Automated classification tools apply the DORA criteria to the available incident data and produce a classification recommendation within minutes. The qualified person reviews and confirms the recommendation. The 4-hour notification clock starts from classification — faster classification means more time for the initial notification to be accurate.[2]
DORA incident reporting automation
DORA requires three reports for major incidents: the initial notification to Finanstilsynet within 4 hours, the intermediate report within 72 hours, and the final report within one month. Each report requires the timeline of events, the systems affected, the customer impact, the root cause assessment, and the remediation actions taken. Automated incident reporting tools build the report from the incident management log as the incident progresses — the timeline captured automatically, system impact data drawn from the monitoring platform, customer impact figures pulled from affected service metrics. The compliance team reviews and signs off the draft rather than compiling it from scratch.
Business Continuity Technology: Recovery Objectives by Service
The recovery time objective (RTO) and recovery point objective (RPO) for each critical service must be achievable in practice. Technology architecture decisions determine whether they are. The manual fallback column matters: DORA does not require insurers to guarantee zero downtime. It requires them to define what they can tolerate and demonstrate they can recover within that tolerance — including that manual fallback was operational during the outage.
| Critical service | Impact tolerance (typical) | Recovery technology | Manual fallback |
|---|---|---|---|
| Claims portal | 4 hours maximum downtime | Active-active cloud deployment; automatic failover | Paper-based FNOL intake; manual triage queue |
| Policy administration | 8 hours maximum downtime | Hot standby instance; automated promotion on primary failure | Read-only access mode; transactions queued for replay |
| Direct debit processing | 24 hours maximum downtime; no data loss | Transaction replay from immutable log; shadow processing | Manual payment run from last verified extract |
| Underwriting APIs | 2 hours maximum downtime | Load-balanced API gateway; geographic redundancy | Manual referral process; offline rate tables |
| Regulatory reporting pipeline | 48 hours maximum downtime | Replicated data hub; point-in-time recovery | Prior-period data held in read-only archive |
Third-Party ICT Risk Under DORA Articles 28 to 44
Most insurers depend on third-party technology suppliers for critical operations. Cloud providers, core system vendors, data providers, and payment processors all fall within DORA's third-party ICT risk framework if they support critical or important functions. DORA Article 28 requires insurers to maintain a register of all third-party ICT suppliers, conduct due diligence before contracting, monitor ongoing resilience, and include contractual terms covering availability commitments, incident notification, and exit rights.
DORA Article 29 requires concentration risk assessment. An insurer that runs its policy administration, claims management, and financial reporting on the same cloud provider has a concentration risk that must be documented and mitigated — contractually, architecturally, or both. Third-party resilience monitoring technology connects to supplier APIs and status feeds, tracks availability against contractual commitments in real time, and produces the evidence base for the annual third-party risk review that DORA requires.
For Norwegian insurers, many mid-size carriers run core systems through Nordic regional cloud providers. DORA's third-party ICT risk requirements apply to these providers in the same way they apply to major global cloud providers. The concentration risk assessment must cover the specific Nordic supplier landscape. Specific DORA implementation requirements, Finanstilsynet supervisory expectations, and EEA Agreement timelines should be verified with qualified Norwegian legal counsel.[3]
Frequently Asked Questions
We have a business continuity plan — does DORA require anything additional?+
Yes, materially. A business continuity plan addresses what the business does when systems fail. DORA addresses why systems fail, how quickly failures are detected, how incidents are classified and reported to regulators, how recovery capability is tested, and how third-party suppliers are monitored and managed. DORA also requires specific documentation: impact tolerance statements, an ICT risk management framework, a register of third-party ICT suppliers, and annual testing results. A BCP that has not been updated to address these DORA-specific requirements is not compliant.[2]
What is the DORA major incident classification threshold and how does it affect our notification obligation?+
DORA Article 18 defines major incidents by reference to five criteria: the number of clients affected, the duration of the disruption, the geographic spread, the economic impact, and the criticality of the affected services. An incident affecting more than a defined number of customers, lasting more than a defined period, or affecting a critical service is likely to meet the major incident threshold. The exact thresholds are set in regulatory technical standards published by EIOPA. When a major incident is classified, the initial notification to Finanstilsynet must be made within 4 hours. Missing this window is itself a DORA breach. Specific thresholds should be verified against the published RTS.[2]
What does a DORA-compliant impact tolerance statement need to contain?+
A DORA-compliant impact tolerance statement must define, for each critical business service: the maximum tolerable period of disruption (recovery time objective), the maximum tolerable data loss (recovery point objective), the quantitative and qualitative impact of a disruption beyond the tolerance, and the assumptions underlying the tolerance definition. The statement must be approved at board level, reviewed annually, and updated when the service changes materially. It must be tested: the recovery capability must be demonstrated to meet the tolerance in a test environment at least annually.[2][3]
How do we identify which of our ICT suppliers are in scope for DORA third-party risk requirements?+
DORA Article 28 applies to ICT third-party service providers that support critical or important functions. Start with the functions identified in the impact tolerance statements: the suppliers supporting those functions are in scope. Extend the assessment to suppliers whose failure would affect multiple critical functions simultaneously. Cloud providers, core system vendors, data providers, and payment processors are the most common in-scope categories for insurers. The register must be maintained and updated annually.[2]
What is threat-led penetration testing (TLPT) under DORA and which insurers must do it?+
TLPT is a structured cyber resilience test that simulates the tactics, techniques, and procedures of real-world threat actors against the insurer's live production environment. DORA Article 26 requires significant financial institutions to conduct TLPT every three years. Finanstilsynet, in coordination with EIOPA, determines which insurers meet the significance threshold. TLPT must be conducted by qualified external testers, cover critical systems, and be coordinated with third-party ICT providers that support those systems. The results must be documented and shared with Finanstilsynet.[2]
How do we build the business case for DORA compliance technology investment?+
The business case has three components. The cost of non-compliance: DORA fines of up to 1% of global daily turnover per day of breach, plus the reputational and regulatory relationship cost of a public enforcement action. The cost of incidents without resilience technology: at NOK 2.1 million per hour of downtime, a 4-hour outage costs NOK 8.4 million before recovery costs. The cost of manual compliance: the resource cost of manual incident classification, manual report preparation, and manual third-party monitoring versus the technology alternative. Most DORA compliance technology investments recover their cost within the first year from incident cost avoidance alone.[1][2]
This article provides general information only and does not constitute legal or regulatory advice. DORA obligations, Finanstilsynet implementation requirements under the EEA Agreement, and the specific regulatory technical standards published by EIOPA require case-specific legal assessment. Insurers should consult qualified legal and technology counsel for guidance specific to their jurisdiction and ICT infrastructure.
References
All statistics sourced from documented deployments and third-party research organisations. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
DORA came into force in January 2025. It requires EU and EEA insurers to define impact tolerances, detect and report major incidents within four hours, test recovery capability annually, and manage third-party ICT risk systematically. This post explains the five DORA obligations, the technology that supports each one, and what the difference looks like between detecting a failure at 02:45 versus 03:14.
The Batch Failed at 03:00. The Alert Arrived at 03:14. DORA Requires Four Hours from Classification.
The alert arrives at 03:14 on a Tuesday morning. The on-call engineer picks it up immediately. The policy administration system is unresponsive. The claims portal is returning a 503 error. The direct debit batch that runs at 03:00 has not completed. 4,200 customers are due to have payments taken before 09:00. The engineer calls the incident response team. The head of technology joins the call at 03:22. The CTO is notified at 03:25. Nobody knows yet whether this is a hardware failure, a software fault, or something more serious.
The claims portal serves 1,800 active claims. Handlers start their shifts at 08:00. If the portal is not restored by then, claims activity stops completely. The direct debit failure will generate customer complaints by mid-morning. Some customers will assume their policy has lapsed. The contact centre also runs on the same infrastructure. By 03:30, the incident response playbook is open. The team is working the problem. But the business impact clock started at 03:00. It has already been running for 30 minutes.
DORA Article 17 requires Finanstilsynet to be notified of a major ICT incident within four hours of classification. The team does not yet know if this qualifies.
What DORA Requires from Insurers
DORA establishes five categories of obligation for EU and EEA insurers. Each has a specific technology dimension. The impact tolerance statement is the starting point for everything else: it requires the insurer to define, for each critical business service, the maximum tolerable downtime and the maximum tolerable data loss — and then demonstrate that the technology recovery architecture can meet those tolerances.
| DORA requirement | Articles | What it means in practice | Technology contribution |
|---|---|---|---|
| ICT risk management framework | Arts. 5–16 | Documented framework covering identification, protection, detection, response, and recovery for all ICT systems | Automated asset inventory; continuous risk monitoring; real-time control gap detection |
| Impact tolerance statements | Art. 24 | Define the maximum tolerable downtime and data loss for each critical business service; board approval required; tested annually | Automated service availability monitoring; threshold alerting before tolerance is breached |
| Incident classification and reporting | Arts. 17–23 | Classify ICT incidents by severity; report major incidents to Finanstilsynet within defined timelines (initial: 4 hours; intermediate: 72 hours; final: 1 month) | Automated incident classification; report generation from incident log; deadline tracking |
| Digital operational resilience testing | Arts. 24–27 | Annual basic testing for all firms; threat-led penetration testing (TLPT) every 3 years for significant firms | Automated vulnerability scanning; testing schedule management; results documentation |
| Third-party ICT risk management | Arts. 28–44 | Due diligence on critical ICT suppliers; contractual resilience requirements; concentration risk assessment; exit strategy | Third-party monitoring dashboards; supplier resilience scoring; contract compliance tracking |
Technology for Impact Tolerance Monitoring
Automated service availability monitoring is the primary technology tool for impact tolerance compliance. It measures the availability of each critical service continuously, compares actual availability against the defined tolerance threshold, and alerts the operations team when availability approaches the threshold before the tolerance is breached.
A service that degrades gradually does not trigger human attention the way a sudden outage does. An API that begins returning slow responses at 02:00 and becomes fully unresponsive by 03:00 may have been in breach of its response time tolerance for an hour before the full outage was noticed. Automated monitoring catches the degradation at 02:00, not the failure at 03:00. The alert at 03:14 in the opening scene is this system working — but imperfectly. With better threshold alerting configured for early degradation signals, detection could have been at 02:45.
Incident Detection, Classification, and DORA Reporting
Automated incident classification
DORA Article 18 requires insurers to classify ICT incidents by the number of customers affected, the duration, the geographic spread, the data integrity impact, and the criticality of the affected services. This classification determines whether the incident is major (requiring regulatory notification) or minor (requiring internal logging only). Manual incident classification under pressure is unreliable: the on-call team at 03:14 is simultaneously trying to restore service and assess regulatory obligation. Automated classification tools apply the DORA criteria to the available incident data and produce a classification recommendation within minutes. The qualified person reviews and confirms the recommendation. The 4-hour notification clock starts from classification — faster classification means more time for the initial notification to be accurate.[2]
DORA incident reporting automation
DORA requires three reports for major incidents: the initial notification to Finanstilsynet within 4 hours, the intermediate report within 72 hours, and the final report within one month. Each report requires the timeline of events, the systems affected, the customer impact, the root cause assessment, and the remediation actions taken. Automated incident reporting tools build the report from the incident management log as the incident progresses — the timeline captured automatically, system impact data drawn from the monitoring platform, customer impact figures pulled from affected service metrics. The compliance team reviews and signs off the draft rather than compiling it from scratch.
Business Continuity Technology: Recovery Objectives by Service
The recovery time objective (RTO) and recovery point objective (RPO) for each critical service must be achievable in practice. Technology architecture decisions determine whether they are. The manual fallback column matters: DORA does not require insurers to guarantee zero downtime. It requires them to define what they can tolerate and demonstrate they can recover within that tolerance — including that manual fallback was operational during the outage.
| Critical service | Impact tolerance (typical) | Recovery technology | Manual fallback |
|---|---|---|---|
| Claims portal | 4 hours maximum downtime | Active-active cloud deployment; automatic failover | Paper-based FNOL intake; manual triage queue |
| Policy administration | 8 hours maximum downtime | Hot standby instance; automated promotion on primary failure | Read-only access mode; transactions queued for replay |
| Direct debit processing | 24 hours maximum downtime; no data loss | Transaction replay from immutable log; shadow processing | Manual payment run from last verified extract |
| Underwriting APIs | 2 hours maximum downtime | Load-balanced API gateway; geographic redundancy | Manual referral process; offline rate tables |
| Regulatory reporting pipeline | 48 hours maximum downtime | Replicated data hub; point-in-time recovery | Prior-period data held in read-only archive |
Third-Party ICT Risk Under DORA Articles 28 to 44
Most insurers depend on third-party technology suppliers for critical operations. Cloud providers, core system vendors, data providers, and payment processors all fall within DORA's third-party ICT risk framework if they support critical or important functions. DORA Article 28 requires insurers to maintain a register of all third-party ICT suppliers, conduct due diligence before contracting, monitor ongoing resilience, and include contractual terms covering availability commitments, incident notification, and exit rights.
DORA Article 29 requires concentration risk assessment. An insurer that runs its policy administration, claims management, and financial reporting on the same cloud provider has a concentration risk that must be documented and mitigated — contractually, architecturally, or both. Third-party resilience monitoring technology connects to supplier APIs and status feeds, tracks availability against contractual commitments in real time, and produces the evidence base for the annual third-party risk review that DORA requires.
For Norwegian insurers, many mid-size carriers run core systems through Nordic regional cloud providers. DORA's third-party ICT risk requirements apply to these providers in the same way they apply to major global cloud providers. The concentration risk assessment must cover the specific Nordic supplier landscape. Specific DORA implementation requirements, Finanstilsynet supervisory expectations, and EEA Agreement timelines should be verified with qualified Norwegian legal counsel.[3]
Frequently Asked Questions
We have a business continuity plan — does DORA require anything additional?+
Yes, materially. A business continuity plan addresses what the business does when systems fail. DORA addresses why systems fail, how quickly failures are detected, how incidents are classified and reported to regulators, how recovery capability is tested, and how third-party suppliers are monitored and managed. DORA also requires specific documentation: impact tolerance statements, an ICT risk management framework, a register of third-party ICT suppliers, and annual testing results. A BCP that has not been updated to address these DORA-specific requirements is not compliant.[2]
What is the DORA major incident classification threshold and how does it affect our notification obligation?+
DORA Article 18 defines major incidents by reference to five criteria: the number of clients affected, the duration of the disruption, the geographic spread, the economic impact, and the criticality of the affected services. An incident affecting more than a defined number of customers, lasting more than a defined period, or affecting a critical service is likely to meet the major incident threshold. The exact thresholds are set in regulatory technical standards published by EIOPA. When a major incident is classified, the initial notification to Finanstilsynet must be made within 4 hours. Missing this window is itself a DORA breach. Specific thresholds should be verified against the published RTS.[2]
What does a DORA-compliant impact tolerance statement need to contain?+
A DORA-compliant impact tolerance statement must define, for each critical business service: the maximum tolerable period of disruption (recovery time objective), the maximum tolerable data loss (recovery point objective), the quantitative and qualitative impact of a disruption beyond the tolerance, and the assumptions underlying the tolerance definition. The statement must be approved at board level, reviewed annually, and updated when the service changes materially. It must be tested: the recovery capability must be demonstrated to meet the tolerance in a test environment at least annually.[2][3]
How do we identify which of our ICT suppliers are in scope for DORA third-party risk requirements?+
DORA Article 28 applies to ICT third-party service providers that support critical or important functions. Start with the functions identified in the impact tolerance statements: the suppliers supporting those functions are in scope. Extend the assessment to suppliers whose failure would affect multiple critical functions simultaneously. Cloud providers, core system vendors, data providers, and payment processors are the most common in-scope categories for insurers. The register must be maintained and updated annually.[2]
What is threat-led penetration testing (TLPT) under DORA and which insurers must do it?+
TLPT is a structured cyber resilience test that simulates the tactics, techniques, and procedures of real-world threat actors against the insurer's live production environment. DORA Article 26 requires significant financial institutions to conduct TLPT every three years. Finanstilsynet, in coordination with EIOPA, determines which insurers meet the significance threshold. TLPT must be conducted by qualified external testers, cover critical systems, and be coordinated with third-party ICT providers that support those systems. The results must be documented and shared with Finanstilsynet.[2]
How do we build the business case for DORA compliance technology investment?+
The business case has three components. The cost of non-compliance: DORA fines of up to 1% of global daily turnover per day of breach, plus the reputational and regulatory relationship cost of a public enforcement action. The cost of incidents without resilience technology: at NOK 2.1 million per hour of downtime, a 4-hour outage costs NOK 8.4 million before recovery costs. The cost of manual compliance: the resource cost of manual incident classification, manual report preparation, and manual third-party monitoring versus the technology alternative. Most DORA compliance technology investments recover their cost within the first year from incident cost avoidance alone.[1][2]
This article provides general information only and does not constitute legal or regulatory advice. DORA obligations, Finanstilsynet implementation requirements under the EEA Agreement, and the specific regulatory technical standards published by EIOPA require case-specific legal assessment. Insurers should consult qualified legal and technology counsel for guidance specific to their jurisdiction and ICT infrastructure.
References
All statistics sourced from documented deployments and third-party research organisations. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
How insurers are using technology to keep their systems running even when things go wrong