Insurers were inside a compromised network for 60 hours before the breach was detected — not by their own monitoring, but by a threat intelligence feed that found their data for sale. This post covers the four principal threat types, the DORA and NIS2 obligations, and the technology stack that reduces dwell time from 60 hours to 8.
The Alert Did Not Come from Inside. That Is the Problem.
The alert arrives at 06:47 on a Monday morning. It does not come from the insurer's own monitoring system. It comes from a third-party threat intelligence feed. The insurer's policyholder data is appearing on a dark web marketplace. Names. Addresses. Policy numbers. Bank account details for 34,000 direct debit customers.
The head of technology calls the CISO at 06:52. The CISO calls the CTO at 06:58. By 07:15, the incident response team is assembled. The forensic investigation begins. The breach was not from this morning. The attackers entered the network on Friday evening. They moved laterally through the claims management system to the policy administration database. They copied the data and left. Nobody noticed until the data appeared for sale.
The insurer has 72 hours under GDPR to notify the ICO. Finanstilsynet must also be notified under DORA Article 19. The CEO needs a press statement before 09:00. The board wants a briefing by 10:00. The claims portal is still running on the compromised infrastructure. Taking it down means stopping claims processing. Leaving it running means the attackers may still have access. The head of technology makes the call at 07:34. The claims portal goes offline.
The attackers were inside for 60 hours before they were discovered. Not by the insurer's own monitoring. By an external feed that noticed the data for sale.
Why Insurers Are High-Value Cyber Targets
Cyber risk insurance companies face is not a technology problem. It is a strategic operational threat. Three characteristics make insurers attractive targets. The data is valuable. The systems are critical. The attack surface is wide.
Policyholder data is among the most complete personal datasets available. It typically includes full name, date of birth, address, national insurance or identification number, bank account details, health information on life and health products, and claims history. This data has direct financial value for identity theft and fraud. It has secondary value as intelligence on high-net-worth individuals and commercial clients.
Insurance systems are operationally critical. A ransomware attack that encrypts a claims management system does not just create an IT problem. It stops claims handlers working. It freezes payment processing. It puts the insurer in breach of its service commitments to policyholders within hours. The operational pressure that critical system unavailability creates is exactly what ransomware attackers exploit to accelerate payment.
The attack surface is expanding. Most insurers connect to dozens of third-party technology providers: core system vendors, cloud providers, data providers, broker platforms, and payment processors. Each connection is a potential entry point. The 41% of insurance cyber incidents that originate in third-party supplier compromise reflects how thoroughly attackers have understood this.[2]
The Four Principal Cyber Threats Facing Insurers
Insurance cyber security professionals monitor four principal threat types. Each has a different attack vector, a different operational impact, and a different regulatory consequence.
| Threat type | Attack vector | Operational impact | Regulatory consequence |
|---|---|---|---|
| Ransomware | Phishing email; credential theft; unpatched vulnerability in claims or policy system | System encryption; claims processing halted; average outage 9 days; NOK 38 million ransom demand | DORA major incident notification; GDPR breach notification if personal data encrypted; FCA/Finanstilsynet supervisory engagement |
| Data exfiltration | Lateral movement from initial compromise to policy administration database; insider threat | Policyholder personal and financial data exfiltrated; sold on dark web; identity theft enabling downstream fraud | GDPR Articles 33–34: 72-hour supervisory notification; individual notification where high risk; ICO/Datatilsynet investigation |
| Supply chain compromise | Trusted vendor connection exploited; software supply chain attack via shared platform | Compromise reaches insurer through permitted connection; perimeter controls bypassed by design | DORA Article 28: third-party ICT risk assessment and contractual control obligations; DORA Article 30: exit provisions |
| Business email compromise | Executive impersonation; supplier invoice fraud; broker account takeover | Fraudulent payments authorised; premium diverted; claims payment intercepted | Financial crime reporting obligation; potential FCA/Finanstilsynet notification depending on materiality |
Ransomware is the highest-impact threat in operational terms. A nine-day claims system outage is not a cyber problem. It is a customer service crisis, a regulatory compliance failure, and a reputational event simultaneously. The ransom demand is not the full cost. The full cost includes the investigation, the remediation, the regulatory response, the customer remediation programme, and the reputational damage that affects renewal rates in subsequent quarters.
DORA Cyber Requirements for Insurers
ICT risk management framework (Articles 5–16)
DORA Articles 5 to 16 require a documented ICT risk management framework. For cyber risk, this means: a complete asset inventory covering all systems that process or store sensitive data, a threat and vulnerability assessment updated at minimum annually, documented security controls mapped to identified threats, and a testing programme that validates those controls. The framework must be approved at board level. The board must receive regular reporting on the cyber risk position. This is not a technology team deliverable. It is a governance document that the board owns and the technology team implements.[3]
Incident detection and reporting (Articles 17–23)
DORA Articles 17 to 23 establish the incident classification and reporting requirements. For cyber incidents, the 4-hour initial notification window to Finanstilsynet starts from classification, not from discovery. The breach in the opening scene was discovered at 06:47. Classification happened at approximately 07:30 after the forensic team confirmed the data had been exfiltrated. The 4-hour notification clock started at 07:30. Finanstilsynet notification was due by 11:30. Meeting this window requires the incident response process to be practised. Classification criteria must be documented in advance. The notification template must be prepared. The DORA reporting obligation cannot be assembled from scratch under the pressure of a live incident.[3]
Threat-led penetration testing (Articles 24–27)
DORA Article 26 requires significant financial institutions to conduct TLPT every three years. TLPT is not a standard penetration test. It uses real threat intelligence to simulate the tactics of actual threat actors against live production systems. Standard penetration testing finds known vulnerabilities. TLPT finds the attack paths that a motivated, intelligence-led adversary would actually use. The attacker who was inside the opening scene insurer's network for 60 hours used credential theft and lateral movement. A standard vulnerability scan would not have identified that as an active attack path.[3]
NIS2 Obligations for Insurers
NIS2 Directive, transposed into national law across the EU and EEA, classifies insurers as essential or important entities in most jurisdictions. Essential and important entities must implement risk management measures covering: network and information system security, incident handling, business continuity, supply chain security, and access control. They must report significant incidents to the national competent authority within 24 hours for early warning, 72 hours for the incident notification, and one month for the final report.
For Norwegian insurers, NIS2 was transposed into Norwegian law in 2024. Finanstilsynet oversees NIS2 compliance for financial sector entities. The NIS2 and DORA obligations overlap significantly for insurers. Where both apply, DORA takes precedence for ICT-specific requirements. Specific NIS2 implementation requirements for Norwegian insurers should be verified with qualified Norwegian legal counsel.[4]
The Insurance Cyber Resilience Technology Stack
Cyber threat insurance operations require a layered technology defence. No single tool addresses all threat vectors. The five layers work together to detect, contain, and respond to attacks.
| Technology layer | Function | What it detects | Limitation |
|---|---|---|---|
| Endpoint detection & response (EDR) | Monitors endpoint behaviour for malicious activity; contains compromised endpoints | Malware execution; credential theft; lateral movement from a compromised device | Covers endpoints only; network-level lateral movement between servers may not be visible |
| Network detection & response (NDR) | Monitors network traffic for anomalous patterns; identifies lateral movement between systems | East-west traffic anomalies; data staging prior to exfiltration; command-and-control communication | Encrypted traffic reduces visibility; requires tuning to the specific network baseline |
| Security information & event management (SIEM) | Aggregates and correlates security events across all systems; provides the single view for incident response | Multi-stage attack patterns that span endpoints, network, and applications; policy violations | Alert volume is high; false positive rate requires experienced analyst triage |
| Identity and access management (IAM) | Controls and monitors access to sensitive systems; enforces multi-factor authentication | Credential misuse; privilege escalation; unusual access patterns to policy or claims databases | Legitimate credentials used maliciously after theft are harder to detect without behavioural baselines |
| Threat intelligence feed | External monitoring of dark web and threat actor infrastructure for indicators of compromise | Exfiltrated data appearing for sale; credentials circulating on criminal forums; active campaigns targeting insurers | Detects after exfiltration has occurred; complements internal monitoring but does not prevent the breach |
The threat intelligence feed is the layer that detected the breach in the opening scene. The insurer's own monitoring missed the attacker for 60 hours. The external feed identified the data for sale at 06:47. This is the fundamental limitation of internal monitoring alone: it detects what happens inside the network. It does not detect what the attacker does with the data after it leaves. External threat intelligence covers both dimensions.
Third-Party Cyber Risk: The Hardest Problem
DORA insurance compliance requires insurers to assess, monitor, and contractually manage the cyber risk introduced by critical technology suppliers. This is technically and commercially challenging. Technically: insurers cannot directly assess the security posture of their suppliers' internal networks. They must rely on supplier-provided evidence: security certifications, penetration test summaries, and contractual commitments. Commercially: major cloud providers and core system vendors have standard contracts. DORA Article 30 gives insurers a regulatory basis for requiring exit provisions and portability. It does not guarantee the negotiating leverage to enforce bespoke security requirements.[3]
The practical approach is tiered. Critical suppliers that support the most sensitive systems receive the most intensive assessment: annual security questionnaire, third-party certification review, and contractual audit rights. Less critical suppliers receive periodic questionnaire assessment. All suppliers are monitored for publicly disclosed vulnerabilities and breaches that may affect the insurer.
Where Human Cyber Expertise Stays Essential
Technology detects. Humans respond. Threat hunting requires an experienced analyst who can interpret ambiguous signals. An EDR alert may indicate a genuine attack or a false positive from a legitimate administrative activity. A network anomaly may indicate lateral movement or a misconfigured application. Distinguishing between them requires judgement that automated tools cannot reliably provide.
Incident response leadership requires a human who can make rapid decisions under pressure: whether to take down the claims portal at 07:34, as in the opening scene; when to engage law enforcement; how to communicate with the board and the regulator simultaneously. Regulatory dialogue during a live incident requires a qualified compliance professional who understands both the technical facts and the regulatory obligations. The 4-hour DORA notification must be accurate. The GDPR 72-hour ICO notification must be complete. Getting these wrong under pressure creates a second compliance problem on top of the original incident.[3][5]
Frequently Asked Questions
We have cyber insurance — does that not transfer the risk?+
Cyber insurance transfers a portion of the financial cost of a cyber incident. It does not transfer the operational impact: a claims portal that is offline for nine days affects customers regardless of whether the insurer has cyber cover. It does not transfer the regulatory obligation: DORA and GDPR reporting requirements apply regardless of insurance cover. It does not transfer the reputational damage: the 34,000 customers whose bank account details were exfiltrated will consider whether to renew their policy regardless of the insurer's insurance position. Cyber insurance is a financial risk management tool. It is not an operational resilience strategy.[1][3]
What is the difference between DORA and NIS2 cyber obligations, and which takes precedence?+
DORA is a financial services-specific regulation covering ICT risk management, incident reporting, resilience testing, and third-party risk for financial institutions including insurers. NIS2 is a cross-sector directive covering network and information security for essential and important entities. Both apply to most EU and EEA insurers. Where they overlap, DORA takes precedence for financial sector entities by virtue of its lex specialis status. In practice: meet DORA requirements and you will largely satisfy NIS2. The NIS2 incident reporting timeline (24-hour early warning) is shorter than DORA's 4-hour major incident notification for some scenarios, so both timelines must be tracked.[3][4]
How do we reduce the dwell time of attackers inside our network?+
Dwell time is reduced by two capabilities: faster detection and network segmentation. Detection speed depends on monitoring coverage. Organisations with network detection and response tools covering all internal network segments detect lateral movement faster than organisations relying on perimeter controls alone. Network segmentation limits how far an attacker can move once inside: a breach of the customer portal should not provide access to the policy administration database. Threat intelligence feeds that monitor for indicators of compromise on external dark web forums detect data exfiltration after it occurs, but before the breach becomes public. Average dwell time with EDR and NDR deployed: 8 hours versus 60 hours without.[2]
What does a DORA-compliant cyber incident response process look like?+
A DORA-compliant cyber incident response process has five components. Documented classification criteria that define what constitutes a major ICT incident so the 4-hour notification clock can start from a defined trigger rather than from a subjective assessment. A pre-prepared initial notification template that can be completed with incident-specific details within the 4-hour window. A designated person accountable for regulatory notifications who is part of the incident response team from the first call. An established communication channel with Finanstilsynet or the FCA for incident notifications. A post-incident review process that produces the one-month final report required by DORA Article 23. This process must be rehearsed. Discovering it does not work during a live incident is not acceptable.[3]
How do we assess the cyber security posture of our critical third-party ICT suppliers?+
Start with a tiered assessment approach. Classify each supplier by the criticality of the function they support. Tier 1 suppliers — those supporting critical business services — receive an annual assessment covering: security certifications (ISO 27001, SOC 2 Type II), penetration test summary covering scope and conclusions, vulnerability management programme evidence, and incident response capability. Tier 2 suppliers receive a biennial questionnaire assessment. All suppliers are monitored for publicly disclosed breaches and vulnerabilities. The assessment results feed into the third-party ICT risk register that DORA Article 28 requires. Contractual audit rights should be negotiated at the point of initial contract, not requested during an incident.[3]
What are the GDPR notification obligations when policyholder data is breached?+
GDPR Article 33 requires notification to the supervisory authority (ICO in the UK; Datatilsynet in Norway) within 72 hours of becoming aware of a personal data breach, where the breach is likely to result in a risk to the rights and freedoms of individuals. Article 34 requires notification to the affected individuals where the breach is likely to result in a high risk to their rights and freedoms. The 34,000 customers whose bank account details were exfiltrated in the opening scene would likely meet both thresholds. The 72-hour clock starts from awareness — the point at which the organisation has sufficient certainty to determine that a breach has occurred. Specific Norwegian data protection requirements should be verified with qualified Norwegian legal counsel.[5]
This article provides general information only and does not constitute legal or regulatory advice. Cyber and operational resilience obligations under DORA Articles 5–44, NIS2, GDPR Articles 33–34, FCA SYSC, and Finanstilsynet guidance require case-specific legal assessment. Insurers should consult qualified legal and compliance counsel for guidance specific to their jurisdiction, technology architecture, and incident response programme design. NIS2 transposition requirements and Norwegian data protection obligations should be verified with qualified Norwegian legal counsel.
References
All statistics sourced from documented research and regulatory publications. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
Insurers were inside a compromised network for 60 hours before the breach was detected — not by their own monitoring, but by a threat intelligence feed that found their data for sale. This post covers the four principal threat types, the DORA and NIS2 obligations, and the technology stack that reduces dwell time from 60 hours to 8.
The Alert Did Not Come from Inside. That Is the Problem.
The alert arrives at 06:47 on a Monday morning. It does not come from the insurer's own monitoring system. It comes from a third-party threat intelligence feed. The insurer's policyholder data is appearing on a dark web marketplace. Names. Addresses. Policy numbers. Bank account details for 34,000 direct debit customers.
The head of technology calls the CISO at 06:52. The CISO calls the CTO at 06:58. By 07:15, the incident response team is assembled. The forensic investigation begins. The breach was not from this morning. The attackers entered the network on Friday evening. They moved laterally through the claims management system to the policy administration database. They copied the data and left. Nobody noticed until the data appeared for sale.
The insurer has 72 hours under GDPR to notify the ICO. Finanstilsynet must also be notified under DORA Article 19. The CEO needs a press statement before 09:00. The board wants a briefing by 10:00. The claims portal is still running on the compromised infrastructure. Taking it down means stopping claims processing. Leaving it running means the attackers may still have access. The head of technology makes the call at 07:34. The claims portal goes offline.
The attackers were inside for 60 hours before they were discovered. Not by the insurer's own monitoring. By an external feed that noticed the data for sale.
Why Insurers Are High-Value Cyber Targets
Cyber risk insurance companies face is not a technology problem. It is a strategic operational threat. Three characteristics make insurers attractive targets. The data is valuable. The systems are critical. The attack surface is wide.
Policyholder data is among the most complete personal datasets available. It typically includes full name, date of birth, address, national insurance or identification number, bank account details, health information on life and health products, and claims history. This data has direct financial value for identity theft and fraud. It has secondary value as intelligence on high-net-worth individuals and commercial clients.
Insurance systems are operationally critical. A ransomware attack that encrypts a claims management system does not just create an IT problem. It stops claims handlers working. It freezes payment processing. It puts the insurer in breach of its service commitments to policyholders within hours. The operational pressure that critical system unavailability creates is exactly what ransomware attackers exploit to accelerate payment.
The attack surface is expanding. Most insurers connect to dozens of third-party technology providers: core system vendors, cloud providers, data providers, broker platforms, and payment processors. Each connection is a potential entry point. The 41% of insurance cyber incidents that originate in third-party supplier compromise reflects how thoroughly attackers have understood this.[2]
The Four Principal Cyber Threats Facing Insurers
Insurance cyber security professionals monitor four principal threat types. Each has a different attack vector, a different operational impact, and a different regulatory consequence.
| Threat type | Attack vector | Operational impact | Regulatory consequence |
|---|---|---|---|
| Ransomware | Phishing email; credential theft; unpatched vulnerability in claims or policy system | System encryption; claims processing halted; average outage 9 days; NOK 38 million ransom demand | DORA major incident notification; GDPR breach notification if personal data encrypted; FCA/Finanstilsynet supervisory engagement |
| Data exfiltration | Lateral movement from initial compromise to policy administration database; insider threat | Policyholder personal and financial data exfiltrated; sold on dark web; identity theft enabling downstream fraud | GDPR Articles 33–34: 72-hour supervisory notification; individual notification where high risk; ICO/Datatilsynet investigation |
| Supply chain compromise | Trusted vendor connection exploited; software supply chain attack via shared platform | Compromise reaches insurer through permitted connection; perimeter controls bypassed by design | DORA Article 28: third-party ICT risk assessment and contractual control obligations; DORA Article 30: exit provisions |
| Business email compromise | Executive impersonation; supplier invoice fraud; broker account takeover | Fraudulent payments authorised; premium diverted; claims payment intercepted | Financial crime reporting obligation; potential FCA/Finanstilsynet notification depending on materiality |
Ransomware is the highest-impact threat in operational terms. A nine-day claims system outage is not a cyber problem. It is a customer service crisis, a regulatory compliance failure, and a reputational event simultaneously. The ransom demand is not the full cost. The full cost includes the investigation, the remediation, the regulatory response, the customer remediation programme, and the reputational damage that affects renewal rates in subsequent quarters.
DORA Cyber Requirements for Insurers
ICT risk management framework (Articles 5–16)
DORA Articles 5 to 16 require a documented ICT risk management framework. For cyber risk, this means: a complete asset inventory covering all systems that process or store sensitive data, a threat and vulnerability assessment updated at minimum annually, documented security controls mapped to identified threats, and a testing programme that validates those controls. The framework must be approved at board level. The board must receive regular reporting on the cyber risk position. This is not a technology team deliverable. It is a governance document that the board owns and the technology team implements.[3]
Incident detection and reporting (Articles 17–23)
DORA Articles 17 to 23 establish the incident classification and reporting requirements. For cyber incidents, the 4-hour initial notification window to Finanstilsynet starts from classification, not from discovery. The breach in the opening scene was discovered at 06:47. Classification happened at approximately 07:30 after the forensic team confirmed the data had been exfiltrated. The 4-hour notification clock started at 07:30. Finanstilsynet notification was due by 11:30. Meeting this window requires the incident response process to be practised. Classification criteria must be documented in advance. The notification template must be prepared. The DORA reporting obligation cannot be assembled from scratch under the pressure of a live incident.[3]
Threat-led penetration testing (Articles 24–27)
DORA Article 26 requires significant financial institutions to conduct TLPT every three years. TLPT is not a standard penetration test. It uses real threat intelligence to simulate the tactics of actual threat actors against live production systems. Standard penetration testing finds known vulnerabilities. TLPT finds the attack paths that a motivated, intelligence-led adversary would actually use. The attacker who was inside the opening scene insurer's network for 60 hours used credential theft and lateral movement. A standard vulnerability scan would not have identified that as an active attack path.[3]
NIS2 Obligations for Insurers
NIS2 Directive, transposed into national law across the EU and EEA, classifies insurers as essential or important entities in most jurisdictions. Essential and important entities must implement risk management measures covering: network and information system security, incident handling, business continuity, supply chain security, and access control. They must report significant incidents to the national competent authority within 24 hours for early warning, 72 hours for the incident notification, and one month for the final report.
For Norwegian insurers, NIS2 was transposed into Norwegian law in 2024. Finanstilsynet oversees NIS2 compliance for financial sector entities. The NIS2 and DORA obligations overlap significantly for insurers. Where both apply, DORA takes precedence for ICT-specific requirements. Specific NIS2 implementation requirements for Norwegian insurers should be verified with qualified Norwegian legal counsel.[4]
The Insurance Cyber Resilience Technology Stack
Cyber threat insurance operations require a layered technology defence. No single tool addresses all threat vectors. The five layers work together to detect, contain, and respond to attacks.
| Technology layer | Function | What it detects | Limitation |
|---|---|---|---|
| Endpoint detection & response (EDR) | Monitors endpoint behaviour for malicious activity; contains compromised endpoints | Malware execution; credential theft; lateral movement from a compromised device | Covers endpoints only; network-level lateral movement between servers may not be visible |
| Network detection & response (NDR) | Monitors network traffic for anomalous patterns; identifies lateral movement between systems | East-west traffic anomalies; data staging prior to exfiltration; command-and-control communication | Encrypted traffic reduces visibility; requires tuning to the specific network baseline |
| Security information & event management (SIEM) | Aggregates and correlates security events across all systems; provides the single view for incident response | Multi-stage attack patterns that span endpoints, network, and applications; policy violations | Alert volume is high; false positive rate requires experienced analyst triage |
| Identity and access management (IAM) | Controls and monitors access to sensitive systems; enforces multi-factor authentication | Credential misuse; privilege escalation; unusual access patterns to policy or claims databases | Legitimate credentials used maliciously after theft are harder to detect without behavioural baselines |
| Threat intelligence feed | External monitoring of dark web and threat actor infrastructure for indicators of compromise | Exfiltrated data appearing for sale; credentials circulating on criminal forums; active campaigns targeting insurers | Detects after exfiltration has occurred; complements internal monitoring but does not prevent the breach |
The threat intelligence feed is the layer that detected the breach in the opening scene. The insurer's own monitoring missed the attacker for 60 hours. The external feed identified the data for sale at 06:47. This is the fundamental limitation of internal monitoring alone: it detects what happens inside the network. It does not detect what the attacker does with the data after it leaves. External threat intelligence covers both dimensions.
Third-Party Cyber Risk: The Hardest Problem
DORA insurance compliance requires insurers to assess, monitor, and contractually manage the cyber risk introduced by critical technology suppliers. This is technically and commercially challenging. Technically: insurers cannot directly assess the security posture of their suppliers' internal networks. They must rely on supplier-provided evidence: security certifications, penetration test summaries, and contractual commitments. Commercially: major cloud providers and core system vendors have standard contracts. DORA Article 30 gives insurers a regulatory basis for requiring exit provisions and portability. It does not guarantee the negotiating leverage to enforce bespoke security requirements.[3]
The practical approach is tiered. Critical suppliers that support the most sensitive systems receive the most intensive assessment: annual security questionnaire, third-party certification review, and contractual audit rights. Less critical suppliers receive periodic questionnaire assessment. All suppliers are monitored for publicly disclosed vulnerabilities and breaches that may affect the insurer.
Where Human Cyber Expertise Stays Essential
Technology detects. Humans respond. Threat hunting requires an experienced analyst who can interpret ambiguous signals. An EDR alert may indicate a genuine attack or a false positive from a legitimate administrative activity. A network anomaly may indicate lateral movement or a misconfigured application. Distinguishing between them requires judgement that automated tools cannot reliably provide.
Incident response leadership requires a human who can make rapid decisions under pressure: whether to take down the claims portal at 07:34, as in the opening scene; when to engage law enforcement; how to communicate with the board and the regulator simultaneously. Regulatory dialogue during a live incident requires a qualified compliance professional who understands both the technical facts and the regulatory obligations. The 4-hour DORA notification must be accurate. The GDPR 72-hour ICO notification must be complete. Getting these wrong under pressure creates a second compliance problem on top of the original incident.[3][5]
Frequently Asked Questions
We have cyber insurance — does that not transfer the risk?+
Cyber insurance transfers a portion of the financial cost of a cyber incident. It does not transfer the operational impact: a claims portal that is offline for nine days affects customers regardless of whether the insurer has cyber cover. It does not transfer the regulatory obligation: DORA and GDPR reporting requirements apply regardless of insurance cover. It does not transfer the reputational damage: the 34,000 customers whose bank account details were exfiltrated will consider whether to renew their policy regardless of the insurer's insurance position. Cyber insurance is a financial risk management tool. It is not an operational resilience strategy.[1][3]
What is the difference between DORA and NIS2 cyber obligations, and which takes precedence?+
DORA is a financial services-specific regulation covering ICT risk management, incident reporting, resilience testing, and third-party risk for financial institutions including insurers. NIS2 is a cross-sector directive covering network and information security for essential and important entities. Both apply to most EU and EEA insurers. Where they overlap, DORA takes precedence for financial sector entities by virtue of its lex specialis status. In practice: meet DORA requirements and you will largely satisfy NIS2. The NIS2 incident reporting timeline (24-hour early warning) is shorter than DORA's 4-hour major incident notification for some scenarios, so both timelines must be tracked.[3][4]
How do we reduce the dwell time of attackers inside our network?+
Dwell time is reduced by two capabilities: faster detection and network segmentation. Detection speed depends on monitoring coverage. Organisations with network detection and response tools covering all internal network segments detect lateral movement faster than organisations relying on perimeter controls alone. Network segmentation limits how far an attacker can move once inside: a breach of the customer portal should not provide access to the policy administration database. Threat intelligence feeds that monitor for indicators of compromise on external dark web forums detect data exfiltration after it occurs, but before the breach becomes public. Average dwell time with EDR and NDR deployed: 8 hours versus 60 hours without.[2]
What does a DORA-compliant cyber incident response process look like?+
A DORA-compliant cyber incident response process has five components. Documented classification criteria that define what constitutes a major ICT incident so the 4-hour notification clock can start from a defined trigger rather than from a subjective assessment. A pre-prepared initial notification template that can be completed with incident-specific details within the 4-hour window. A designated person accountable for regulatory notifications who is part of the incident response team from the first call. An established communication channel with Finanstilsynet or the FCA for incident notifications. A post-incident review process that produces the one-month final report required by DORA Article 23. This process must be rehearsed. Discovering it does not work during a live incident is not acceptable.[3]
How do we assess the cyber security posture of our critical third-party ICT suppliers?+
Start with a tiered assessment approach. Classify each supplier by the criticality of the function they support. Tier 1 suppliers — those supporting critical business services — receive an annual assessment covering: security certifications (ISO 27001, SOC 2 Type II), penetration test summary covering scope and conclusions, vulnerability management programme evidence, and incident response capability. Tier 2 suppliers receive a biennial questionnaire assessment. All suppliers are monitored for publicly disclosed breaches and vulnerabilities. The assessment results feed into the third-party ICT risk register that DORA Article 28 requires. Contractual audit rights should be negotiated at the point of initial contract, not requested during an incident.[3]
What are the GDPR notification obligations when policyholder data is breached?+
GDPR Article 33 requires notification to the supervisory authority (ICO in the UK; Datatilsynet in Norway) within 72 hours of becoming aware of a personal data breach, where the breach is likely to result in a risk to the rights and freedoms of individuals. Article 34 requires notification to the affected individuals where the breach is likely to result in a high risk to their rights and freedoms. The 34,000 customers whose bank account details were exfiltrated in the opening scene would likely meet both thresholds. The 72-hour clock starts from awareness — the point at which the organisation has sufficient certainty to determine that a breach has occurred. Specific Norwegian data protection requirements should be verified with qualified Norwegian legal counsel.[5]
This article provides general information only and does not constitute legal or regulatory advice. Cyber and operational resilience obligations under DORA Articles 5–44, NIS2, GDPR Articles 33–34, FCA SYSC, and Finanstilsynet guidance require case-specific legal assessment. Insurers should consult qualified legal and compliance counsel for guidance specific to their jurisdiction, technology architecture, and incident response programme design. NIS2 transposition requirements and Norwegian data protection obligations should be verified with qualified Norwegian legal counsel.
References
All statistics sourced from documented research and regulatory publications. All currency figures in NOK. Links verified 2026. Click any citation to jump to its source.
Why cyber risk is now one of the biggest operational threats facing insurance companies.