Chapter 33: Cybersecurity Regulations — DORA, NIST, and Operational Resilience

7:45 AM

Maya Osei picked up her phone on the first ring.

"Maya." It was Amir, the CISO. "We have a ransomware incident. Payment processing is down. Customer-facing services are degraded. Detection was 3:14 AM. It's now — " she could hear him checking a clock "— 7:45."

Maya sat up in bed. "How contained?"

"Not. We've isolated the affected segment but we're still assessing scope. Estimated recovery: four to six hours."

Four to six hours. Maya was already doing the calculation. Verdant Bank's payment processing system had an impact tolerance of four hours under the Bank of England's PS21/3 framework — the maximum time it could be disrupted before regulatory breach. It was now four and a half hours since the attack began. If recovery was at the optimistic end — four hours from now — that was eight and a half hours total.

They were going to breach the tolerance.

"FCA notification status?" she asked.

"Not filed yet. I was waiting for — "

"File it now. PRIN 11 — material incident. I'll send you the template." Maya was already at her desk. "What about personal data?"

"Customer email addresses may be in the affected segment. We're assessing. Nothing confirmed yet on exfiltration."

UK GDPR. If personal data was involved, the ICO had to be notified within 72 hours. The clock started at awareness of the breach, not confirmation. And they were now aware.

"Amir, I need a list of affected systems in the next thirty minutes. I need to know if personal data is confirmed. And I need you to start the DORA major incident assessment — we have EU customers through the Dublin branch, which means DORA applies to that segment."

"Already on it."

"One more thing," she said. "The impact tolerance breach. We're going to breach it."

A pause. "I know."

"I need you to tell me when we breach four hours from detection. To the minute. I have to document it."

Maya Osei, thirty-two years old and in her first year as Chief Compliance Officer, ended the call and opened three regulatory notification templates simultaneously.

She had four hours of regulatory filing work ahead of her. The bank's CISO had recovery. She had documentation.

Section 1: The Cybersecurity-Compliance Intersection

For most of the past thirty years, cybersecurity was treated in financial institutions as an IT problem. The CISO owned the firewalls, the incident response plan, the penetration test schedule. The Chief Compliance Officer owned capital ratios, transaction monitoring, and regulatory reporting. The two functions intersected only occasionally — and rarely comfortably.

That division has collapsed. Not because IT and compliance have merged, but because regulators have moved cybersecurity from the domain of IT best practice to the domain of regulatory obligation. The EU's DORA imposes mandatory ICT risk management requirements with statutory legal force, enforceable by financial regulators. The FCA's operational resilience framework requires firms to set and test impact tolerances for their most important business services — including payment processing and client-facing platforms — and to document what happens when those tolerances are breached. The UK GDPR requires breach notification to the ICO within 72 hours of awareness. These are not IT obligations. They are compliance obligations with legal consequences for non-fulfillment.

The compliance professional's stake in cybersecurity now extends across four distinct domains:

First, notification obligations. A cyber incident triggers multiple regulatory notification obligations with different deadlines, different recipients, and different content requirements. Missing a deadline — or filing incomplete information — is a regulatory failure independent of the underlying incident.

Second, third-party risk. The most consequential cyber incidents in financial services are not attacks on the firm's own systems — they are attacks on the firm's technology vendors, cloud providers, and data processors. Every contractual relationship with an ICT provider carries embedded regulatory risk. DORA's Article 28 and Article 30 requirements make this explicit.

Third, data breach liability. A cyber incident that compromises personal data triggers data protection obligations that are entirely separate from the cyber incident itself. The ICO does not care why the data was breached — it cares whether notification was timely, whether affected individuals were informed where required, and whether the firm had adequate security in place under UK GDPR Article 32.

Fourth, operational resilience compliance. Impact tolerances are regulatory commitments. Breaching an impact tolerance — even if the underlying disruption was caused by a criminal attack — is a regulatory matter that must be documented, reported, and remediated.

This chapter examines the primary cybersecurity regulatory frameworks across the EU (DORA), the US (NIST), and the UK (FCA/PRA operational resilience), with particular attention to the incident response and notification obligations that transform a technical incident into a compliance event.

Section 2: DORA — Digital Operational Resilience Act

DORA — Regulation (EU) 2022/2554, effective January 17, 2025 — is the most comprehensive cybersecurity and operational resilience regulation in the financial services world. It applies directly and uniformly across all EU member states to financial entities, including credit institutions, investment firms, insurance undertakings, payment institutions, electronic money institutions, and crypto-asset service providers. It also applies, through a designation mechanism, to ICT third-party service providers that are deemed Critical Third-Party Providers (CTPPs).

ICT Risk Management (Articles 5–16)

DORA's ICT risk management requirement is not a checklist — it is a framework obligation. Financial entities must maintain an ICT risk management framework that:

• Identifies and classifies ICT assets (hardware, software, data, ICT infrastructure) and their criticality
• Identifies and assesses ICT risks on a continuous basis
• Defines protection and prevention measures proportionate to identified risks
• Establishes detection capabilities for ICT anomalies and incidents
• Provides for response and recovery, including business continuity plans and backup strategies
• Includes ICT learning and evolving mechanisms — post-incident analysis and continuous improvement

Senior management accountability is explicit. DORA Article 5 requires the management body of the financial entity to define, approve, oversee, and be accountable for the ICT risk management framework. This is not delegable to the CISO alone. The management body must take specific training on ICT risk to enable it to perform this oversight function — and must devote "sufficient time" to ICT risk matters.

The documentation requirement is extensive: the ICT risk management framework, the asset register, the risk assessment methodology, the business continuity plan, and the crisis communication plan must all be documented and available to the competent authority on request.

ICT Incident Management and Reporting (Articles 17–23)

This is where DORA becomes most directly relevant to the compliance professional's daily work.

Classification of Incidents

DORA requires financial entities to classify ICT-related incidents as major or non-major using criteria specified in the accompanying Regulatory Technical Standards (RTS on major incident classification). The classification criteria include:

• The number of clients affected or potentially affected
• The duration of the incident
• The geographic spread of the incident
• The data loss involved (where data loss occurs)
• The criticality of affected services
• The economic impact
• Whether the incident has been assessed as a cyber attack (cyber attacks that qualify as major are automatically classified as major incidents)

Recurring incidents that individually do not qualify as major but, in aggregate, are significant may also qualify for the major incident classification.

The distinction between major and non-major incidents is consequential: major incidents trigger the full reporting timeline; non-major incidents are reported on an aggregated basis in the annual summary.

Reporting Timeline for Major ICT Incidents

DORA establishes a three-stage reporting timeline for major ICT incidents:

• Initial notification: Within 4 hours of the firm classifying the incident as major (and no later than 24 hours after the firm first detected the incident that it later classifies as major). Content: basic incident details, initial assessment, affected services, containment measures initiated.

• Intermediate report: Within 72 hours of the initial notification filing. Content: updated classification; current status; impact assessment; corrective actions taken; planned remediation.

• Final report: Within one month of the intermediate report (i.e., approximately 30 days from intermediate notification). Content: root cause analysis; full impact assessment; remediation measures implemented; lessons learned; changes to ICT risk management framework if any.

Who Receives DORA Notifications

Financial entities file DORA notifications with their National Competent Authority (NCA) — for example, BaFin in Germany, DNB in the Netherlands, the Central Bank of Ireland in Ireland, or the relevant NCA in the member state of authorization. Where the incident has cross-border significance, the NCA may share information with other EU competent authorities and with ENISA (the EU Agency for Cybersecurity). Where the incident affects payment systems, the ECB may also receive notification.

The Aggregated Reporting Obligation

Non-major incidents are not individually notified but are reported in an aggregated statistical return submitted annually to the NCA. This aggregate return provides regulators with systemic visibility into the volume and nature of minor incidents across the sector — which, in aggregate, may reveal patterns not visible from individual major incident reports.

Digital Operational Resilience Testing (Articles 24–27)

DORA distinguishes between basic testing (required for all financial entities) and advanced testing in the form of Threat-Led Penetration Testing (TLPT), required for significant financial entities.

Basic Testing

All financial entities must conduct basic digital operational resilience testing annually, covering: vulnerability assessments; open-source analysis; network security assessments; gap analyses; physical security reviews; and questionnaire-based assessments. These assessments must be conducted by appropriately qualified parties, which may be internal or external.

Threat-Led Penetration Testing (TLPT)

Significant financial entities — those designated by the NCA based on their systemic importance — must conduct TLPT at least every three years. TLPT is a controlled, intelligence-led simulation of a realistic cyber attack conducted by a certified red team. Key features:

• The red team is certified by the relevant NCA or by a recognized certification body
• The scope covers critical ICT systems and processes (the "crown jewels")
• The intelligence phase identifies likely threat actors and their tactics, techniques, and procedures (TTPs) relevant to the firm
• The attack simulation tests both technical defenses and human responses
• Results are shared with the NCA and with the TIBER-EU framework (the EU's threat intelligence-based ethical red teaming standard, which TLPT is built on)

Firms that participate in TLPT under DORA can share test results with multiple NCAs, avoiding the need to conduct separate tests for each EU jurisdiction in which they operate — a significant practical benefit for multi-jurisdictional EU firms.

Third-Party ICT Risk (Articles 28–44)

Chapter 27 of this textbook covers DORA's third-party ICT risk management requirements in detail. Key points for this chapter: DORA requires financial entities to maintain a register of all ICT third-party service providers; to assess the ICT risk of all providers and classify them by criticality; and to include specific contractual provisions (specified in Article 30) in agreements with ICT providers. Critical Third-Party Providers designated by the joint ESAs are subject to direct oversight by the ESAs — a novel form of regulation that reaches beyond the financial entity itself to its supply chain.

Section 3: NIST Cybersecurity Framework (CSF 2.0)

In the United States, the National Institute of Standards and Technology's Cybersecurity Framework (CSF) is the primary reference standard for cybersecurity governance across sectors, including financial services. The CSF is voluntary at the federal level — it is not statute — but it is referenced in regulatory guidance from OCC, FDIC, Federal Reserve, and the FFIEC, and it forms the basis of the FFIEC Cybersecurity Assessment Tool (CAT), which examiners use to assess financial institution cybersecurity programs.

Six Core Functions

NIST CSF 2.0 (published February 2024) expanded the original five functions to six:

GOVERN (new in CSF 2.0): Establishes the cybersecurity risk management strategy, policies, and roles within the organization. The Govern function is the overarching context within which all other functions operate. Key activities: organizational cybersecurity policy; cybersecurity risk management strategy; roles and responsibilities definition; supply chain risk management governance; and oversight of cybersecurity activities. This addition reflects the recognition that cybersecurity is a governance matter, not merely a technical one.

IDENTIFY: Develops the organizational understanding to manage cybersecurity risk. Key activities: asset management (hardware and software inventory); business environment understanding; risk assessment; risk management strategy.

PROTECT: Implements safeguards to ensure delivery of critical services. Key activities: access control; awareness and training; data security; information protection processes; maintenance; protective technologies.

DETECT: Develops and implements activities to identify cybersecurity events. Key activities: anomalies and events detection; security continuous monitoring; detection processes.

RESPOND: Develops and implements activities to take action regarding a detected cybersecurity event. Key activities: response planning; communications; analysis; mitigation; improvements.

RECOVER: Develops and implements activities to maintain plans for resilience and to restore any capabilities or services impaired by a cybersecurity event. Key activities: recovery planning; improvements; communications.

Implementation Tiers

CSF 2.0 defines four implementation tiers that describe the degree to which an organization's cybersecurity risk management practices are mature:

• Tier 1 (Partial): Risk management practices are not formalized; cybersecurity activities are performed on an ad hoc basis.
• Tier 2 (Risk Informed): Risk management practices are approved by management but not organizationally mandated; coordination between organizational units is inconsistent.
• Tier 3 (Repeatable): Risk management practices are formally approved and expressed as policy; organizational understanding of cybersecurity risk is consistent.
• Tier 4 (Adaptive): Cybersecurity practices are continuously improved based on lessons learned and predictive indicators.

Regulators do not mandate a specific tier — the appropriate tier depends on the firm's size, complexity, and risk profile. However, examination feedback consistently indicates that most supervised financial institutions should be operating at Tier 3 minimum, with significant institutions expected to demonstrate Tier 4 practices in their most critical domains.

CSF Profiles and the Gap Analysis Approach

The CSF Profile concept is the practical mechanism for using NIST CSF as a compliance tool. A Current Profile describes the firm's current state against each CSF category and subcategory. A Target Profile describes the desired state. The gap between Current and Target profiles generates an implementation roadmap.

For US financial services firms, the FFIEC Cybersecurity Assessment Tool (CAT) operationalizes this approach: it maps CSF activities to FFIEC examination criteria and produces an inherent risk level and maturity level assessment that examiners review during safety and soundness examinations.

Mapping NIST CSF to DORA

Despite their different legal status, NIST CSF and DORA share significant conceptual overlap:

The conceptual overlap means that firms building DORA-compliant frameworks can draw on NIST CSF documentation and methodology. The critical difference is legal: DORA is statutory with mandatory incident reporting timelines and testing requirements; NIST CSF is voluntary with no inherent notification obligations or mandatory testing frequency.

Section 4: UK Operational Resilience Framework

The UK's operational resilience framework, established in the FCA and PRA's Policy Statement PS21/3 (March 2021, with full compliance required by March 2025), takes a distinctive approach to cybersecurity within a broader resilience context.

Important Business Services and Impact Tolerances

The UK framework centers on Important Business Services (IBS) — the services that, if disrupted, would cause intolerable harm to consumers, market functioning, or financial stability. Firms must identify their IBS and set an impact tolerance for each: the maximum tolerable disruption to that service, expressed in time.

A payment processing service, for example, might have an impact tolerance of four hours — the maximum time that payment processing can be offline before harm to customers and market functioning becomes intolerable. A retail banking app might have an impact tolerance of two hours. These are firm-specific regulatory commitments that must be documented and shared with the PRA and FCA.

The cyber relevance is direct: a ransomware attack that takes down payment processing for five hours breaches the impact tolerance. The breach is not merely a technology failure — it is a regulatory event that must be documented and potentially notified to the regulator. The FCA and PRA expect firms to be able to demonstrate, through scenario testing, that they can remain within impact tolerances during severe but plausible disruption scenarios — including cyber attack scenarios.

CBEST — Threat-Led Penetration Testing

CBEST is the Bank of England's framework for threat-led penetration testing for major UK banks, insurers, and financial market infrastructure. It is the UK equivalent of DORA's TLPT requirement. Key features:

• CBEST is overseen by the Bank of England and conducted with the involvement of GCHQ's National Cyber Security Centre (NCSC)
• Participation is required for firms designated as systemically important; CBEST participation is coordinated with the Bank of England
• The threat intelligence phase involves classified intelligence about threats specific to the firm and sector
• CBEST results are shared with the Bank of England under strict confidentiality

CBEST differs from DORA TLPT in several respects: CBEST is UK-specific and coordinated with NCSC; DORA TLPT uses the TIBER-EU framework. CBEST results are not formally recognized under DORA, meaning UK-EU firms may need to conduct separate TLPT exercises for EU DORA compliance.

FCA Cyber Reporting Obligations

Under FCA Principle 11, firms must deal with the FCA in an open and cooperative way and must disclose appropriately anything relating to the firm of which the FCA would reasonably expect notice. A material cyber incident — one that affects the firm's ability to deliver services, affects customer data, or poses systemic risk — falls clearly within PRIN 11.

The FCA does not prescribe a specific cyber incident notification format (unlike DORA's RTS), but its supervisory expectations are well established through Dear CEO letters and supervisory guidance: notification should occur as soon as the firm becomes aware that an incident is material, typically within hours — not days.

NCSC Support for Regulated Firms

The National Cyber Security Centre (NCSC) provides government cyber security support available to UK-regulated financial institutions. Key programs:

• Active Cyber Defence (ACD): Free services including Mail Check (email security), Web Check (website security), and DNS sinkholing. Available to regulated financial institutions.
• Cyber Essentials Certification: A government-backed scheme certifying basic cybersecurity controls. NCSC encourages regulated firms to achieve certification as a baseline.
• Early Warning: A threat intelligence service notifying organizations about cyberattacks targeting their networks.

Section 5: Incident Response and Notification — A Compliance Workflow

Understanding the regulatory notification obligations triggered by a cyber incident requires a timeline-based workflow. The following reconstruction of a typical ransomware incident at a UK-based firm with EU operations illustrates the obligations and their sequencing.

Hour 0 — Detection (3:14 AM) IT systems detect anomalous encryption activity consistent with ransomware. Automated alerts fire. The on-call IT team is paged.

Hour 0–0.5 (3:14 AM – 3:44 AM) IT on-call team isolates affected network segments. Preliminary assessment: payment processing systems affected; customer-facing banking app degraded; corporate email unaffected. No confirmation yet on personal data exfiltration. CISO is notified.

Hour 0.5 (3:44 AM) CISO assesses: impact to payment processing ongoing; estimated recovery 4–6 hours. Internal escalation to CCO and CEO per the firm's incident escalation policy. CCO (Maya) is called at 7:45 AM. [Note: In this scenario, the internal escalation did not reach Maya until hour 4.5 — this is itself a process failure identified in the post-incident review.]

Hour 4 — FCA Notification DORA initial notification threshold: 4 hours from classification as major incident (or 24 hours from first detection, whichever is earlier). FCA PRIN 11 notification should occur as soon as the incident is assessed as material. Maya files the FCA major incident notification at approximately hour 5 (7:45 AM + 1 hour for preparation). This is late relative to FCA expectations — addressed in the post-incident review.

DORA assessment for EU operations (Dublin branch): payment services affected, customer count exceeds 10,000 — the incident qualifies as a major DORA incident. DORA initial notification filed to the Central Bank of Ireland. [Under DORA, the initial notification deadline is 4 hours after major incident classification — not 4 hours after detection.]

Hour 24 Internal crisis management team convenes. Customer communications team drafts service disruption notification for customers affected by payment processing outage (operational notification — not a GDPR breach notification, as no personal data exfiltration has been confirmed at this point).

Hour 72 IT forensics team confirms: customer email addresses from the payment system database were accessed by the attacker. Exfiltration not confirmed, but access is confirmed. Under UK GDPR, this is a personal data breach. The ICO 72-hour notification clock began running at hour 0 (the firm became aware of potential personal data involvement at hour 0, even if access was not confirmed until hour 72).

The GDPR breach notification to the ICO is filed at hour 72 — exactly on deadline. This is noted by the ICO; in its subsequent letter, it requests explanation of why the notification was filed at the last possible moment rather than earlier.

The DORA intermediate report is filed to the Central Bank of Ireland at hour 72, as required.

Day 30 The DORA final report is filed, containing: root cause analysis (the attack exploited an unpatched vulnerability in a third-party VPN appliance — a supply chain risk); full impact assessment (12,400 customers affected by payment processing outage; 8,200 customer email addresses accessed); remediation measures (patch applied; VPN supplier replaced; additional monitoring deployed); and lessons learned.

Section 6: Python Implementation — Cyber Incident Management

The following implementation models the regulatory notification obligations that arise from a cyber incident and provides real-time tracking of deadlines.

from __future__ import annotations
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from enum import Enum
from typing import Optional
import json


class IncidentSeverity(Enum):
    CRITICAL = "Critical"    # DORA major incident threshold met
    HIGH = "High"
    MEDIUM = "Medium"
    LOW = "Low"


class NotificationType(Enum):
    INTERNAL_ESCALATION = "Internal Escalation"
    FCA_MAJOR_INCIDENT = "FCA Major Incident Notification"
    DORA_INITIAL = "DORA Initial Notification (NCAs)"
    ICO_GDPR_BREACH = "ICO Data Breach Notification (GDPR 72h)"
    DORA_INTERMEDIATE = "DORA Intermediate Report (72h)"
    CUSTOMER_NOTIFICATION = "Customer Notification"
    DORA_FINAL = "DORA Final Report (30 days)"


@dataclass
class IncidentNotificationObligation:
    notification_type: NotificationType
    deadline_hours: Optional[float]    # hours after incident detection; None = conditional
    deadline_days: Optional[int]       # days; for longer deadlines
    regulator: str
    condition: str                     # When this obligation is triggered
    completed: bool = False
    completed_at: Optional[datetime] = None
    notes: str = ""

    def is_overdue(self, detection_time: datetime) -> bool:
        now = datetime.utcnow()
        if self.completed:
            return False
        if self.deadline_hours is not None:
            deadline = detection_time + timedelta(hours=self.deadline_hours)
            return now > deadline
        if self.deadline_days is not None:
            deadline = detection_time + timedelta(days=self.deadline_days)
            return now > deadline
        return False

    def time_remaining(self, detection_time: datetime) -> str:
        now = datetime.utcnow()
        if self.completed:
            completed_str = (
                self.completed_at.strftime("%H:%M UTC") if self.completed_at else "unknown time"
            )
            return f"COMPLETED at {completed_str}"
        if self.deadline_hours is not None:
            deadline = detection_time + timedelta(hours=self.deadline_hours)
        elif self.deadline_days is not None:
            deadline = detection_time + timedelta(days=self.deadline_days)
        else:
            return "Conditional — assess applicability"

        remaining = deadline - now
        total_seconds = remaining.total_seconds()
        if total_seconds < 0:
            overdue_h = abs(total_seconds) / 3600
            return f"OVERDUE by {overdue_h:.1f}h"
        hours = total_seconds / 3600
        if hours < 1:
            return f"{int(total_seconds // 60)} minutes remaining"
        return f"{hours:.1f} hours remaining"

    def mark_complete(self, notes: str = "") -> None:
        self.completed = True
        self.completed_at = datetime.utcnow()
        self.notes = notes


@dataclass
class CyberIncident:
    """Cyber incident record for regulatory notification tracking."""
    incident_id: str
    detection_time: datetime
    description: str
    severity: IncidentSeverity
    systems_affected: list[str]
    personal_data_affected: bool
    personal_data_records_estimate: int
    payment_services_affected: bool
    estimated_customer_count: int
    attack_type: str      # "ransomware", "DDoS", "phishing", "supply_chain"

    notifications: list[IncidentNotificationObligation] = field(default_factory=list)
    root_cause: str = ""
    resolution_time: Optional[datetime] = None

    def is_dora_major(self) -> bool:
        """
        Simplified DORA major incident assessment.
        Full criteria in RTS on major incident classification (DORA Article 18).
        A major incident requires at least one of the following:
        - Critical severity
        - >10,000 customers affected
        - Payment services affected
        - Personal data of significant volume involved
        """
        return (
            self.severity == IncidentSeverity.CRITICAL
            or self.estimated_customer_count > 10_000
            or self.payment_services_affected
            or (self.personal_data_affected and self.personal_data_records_estimate > 5_000)
        )

    def add_standard_notifications(
        self,
        dora_applicable: bool = True,
        uk_fca_applicable: bool = True,
        uk_gdpr_applicable: bool = True,
    ) -> None:
        """Add standard notification obligations based on incident characteristics."""
        self.notifications = []

        # Internal escalation — always, within 30 minutes
        self.notifications.append(IncidentNotificationObligation(
            notification_type=NotificationType.INTERNAL_ESCALATION,
            deadline_hours=0.5,
            deadline_days=None,
            regulator="CISO / CRO / CCO / CEO",
            condition="Always — all incidents",
        ))

        # FCA PRIN 11 — material operational incidents
        if uk_fca_applicable and self.severity in (
            IncidentSeverity.CRITICAL, IncidentSeverity.HIGH
        ):
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.FCA_MAJOR_INCIDENT,
                deadline_hours=4.0,
                deadline_days=None,
                regulator="FCA",
                condition="Material incident affecting operations or customers (FCA PRIN 11)",
            ))

        # DORA notifications — EU operations
        if dora_applicable and self.is_dora_major():
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.DORA_INITIAL,
                deadline_hours=4.0,
                deadline_days=None,
                regulator="National Competent Authority (NCA)",
                condition="DORA major incident — initial notification within 4h of classification",
            ))
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.DORA_INTERMEDIATE,
                deadline_hours=72.0,
                deadline_days=None,
                regulator="National Competent Authority (NCA)",
                condition="DORA major incident — intermediate report within 72h of initial notification",
            ))
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.DORA_FINAL,
                deadline_hours=None,
                deadline_days=30,
                regulator="National Competent Authority (NCA)",
                condition="DORA major incident — final report within 1 month of intermediate report",
            ))

        # ICO GDPR breach notification
        if uk_gdpr_applicable and self.personal_data_affected:
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.ICO_GDPR_BREACH,
                deadline_hours=72.0,
                deadline_days=None,
                regulator="ICO (or relevant DPA for EU operations)",
                condition=(
                    "Personal data breach where likely risk to data subjects — "
                    "notify ICO within 72h of becoming aware"
                ),
            ))

        # Customer notification — large-scale incidents
        if self.estimated_customer_count > 1_000 or (
            self.personal_data_affected and self.personal_data_records_estimate > 1_000
        ):
            self.notifications.append(IncidentNotificationObligation(
                notification_type=NotificationType.CUSTOMER_NOTIFICATION,
                deadline_hours=None,
                deadline_days=None,
                regulator="Affected Customers",
                condition=(
                    "Where high risk to personal data (GDPR Article 34) or "
                    "where payment services impacted and customer awareness required"
                ),
            ))

    def notification_dashboard(self) -> list[dict]:
        """Return notification obligations with current deadline status."""
        now = datetime.utcnow()
        dashboard = []
        for n in self.notifications:
            if n.deadline_hours is not None:
                deadline_str = f"{n.deadline_hours:.0f}h from detection"
                abs_deadline = self.detection_time + timedelta(hours=n.deadline_hours)
            elif n.deadline_days is not None:
                deadline_str = f"{n.deadline_days} days from intermediate report"
                abs_deadline = self.detection_time + timedelta(days=n.deadline_days)
            else:
                deadline_str = "Conditional"
                abs_deadline = None

            if n.completed:
                status = "COMPLETED"
            elif abs_deadline and now > abs_deadline:
                status = "OVERDUE"
            elif abs_deadline and (abs_deadline - now).total_seconds() < 3600:
                status = "URGENT"
            else:
                status = "PENDING"

            dashboard.append({
                "notification": n.notification_type.value,
                "regulator": n.regulator,
                "deadline": deadline_str,
                "time_remaining": n.time_remaining(self.detection_time),
                "status": status,
                "condition": n.condition,
                "notes": n.notes,
            })
        return dashboard

    def overdue_notifications(self) -> list[IncidentNotificationObligation]:
        """Return a sorted list of overdue notification obligations."""
        overdue = [
            n for n in self.notifications
            if n.is_overdue(self.detection_time)
        ]
        # Sort by how overdue they are — most overdue first
        def overdue_seconds(n: IncidentNotificationObligation) -> float:
            now = datetime.utcnow()
            if n.deadline_hours is not None:
                deadline = self.detection_time + timedelta(hours=n.deadline_hours)
            elif n.deadline_days is not None:
                deadline = self.detection_time + timedelta(days=n.deadline_days)
            else:
                return 0.0
            return (now - deadline).total_seconds()

        return sorted(overdue, key=overdue_seconds, reverse=True)

    def print_dashboard(self) -> None:
        print(f"\n{'='*70}")
        print(f"  CYBER INCIDENT NOTIFICATION DASHBOARD")
        print(f"  Incident: {self.incident_id}")
        print(f"  Attack Type: {self.attack_type.upper()}")
        print(f"  Severity: {self.severity.value}")
        print(f"  DORA Major Incident: {'YES' if self.is_dora_major() else 'NO'}")
        print(f"  Detection Time: {self.detection_time.strftime('%Y-%m-%d %H:%M UTC')}")
        print(f"{'='*70}")
        dashboard = self.notification_dashboard()
        for item in dashboard:
            status_symbol = {
                "COMPLETED": "[OK]",
                "OVERDUE": "[!!]",
                "URGENT": "[!]",
                "PENDING": "[ ]",
            }.get(item["status"], "[ ]")
            print(f"\n  {status_symbol} {item['notification']}")
            print(f"     Regulator: {item['regulator']}")
            print(f"     Deadline:  {item['deadline']}")
            print(f"     Status:    {item['status']} — {item['time_remaining']}")
            if item["notes"]:
                print(f"     Notes:     {item['notes']}")


# ── Demonstration: Verdant Bank Ransomware Incident ───────────────────────

# Simulate the incident as detected at 3:14 AM
# We use a fixed detection time for demonstration purposes
detection_time = datetime(2026, 2, 17, 3, 14, 0)  # 03:14 UTC

verdant_incident = CyberIncident(
    incident_id="VB-2026-001",
    detection_time=detection_time,
    description=(
        "Ransomware attack targeting payment processing systems. "
        "Encryption detected across payment processing segment. "
        "Customer-facing banking app degraded. "
        "Attack vector: unpatched third-party VPN appliance."
    ),
    severity=IncidentSeverity.CRITICAL,
    systems_affected=[
        "Payment Processing Platform",
        "Customer Banking App (degraded)",
        "Core Banking System (partial)",
    ],
    personal_data_affected=True,
    personal_data_records_estimate=8200,  # customer email addresses accessed
    payment_services_affected=True,
    estimated_customer_count=12400,
    attack_type="ransomware",
)

# Add notifications based on Verdant's regulatory context
# UK-regulated firm with EU operations (Dublin branch — DORA applicable)
verdant_incident.add_standard_notifications(
    dora_applicable=True,
    uk_fca_applicable=True,
    uk_gdpr_applicable=True,
)

# Simulate: FCA notification was filed at 07:45 AM + 1 hour (08:45)
# That is 5.5 hours after detection — after the 4-hour deadline
fca_notif = next(
    n for n in verdant_incident.notifications
    if n.notification_type == NotificationType.FCA_MAJOR_INCIDENT
)
# In the simulation we don't mark it complete to show the overdue state

# Print the full dashboard as it would look at 07:45 AM (4.5 hours after detection)
print("VERDANT BANK — RANSOMWARE INCIDENT NOTIFICATION STATUS (as at 07:45 UTC)")
print(f"Time since detection: 4h 31m")
print(f"DORA Major Incident: {verdant_incident.is_dora_major()}")
verdant_incident.print_dashboard()

print("\n\nOVERDUE NOTIFICATIONS:")
print("-" * 50)
overdue = verdant_incident.overdue_notifications()
# Note: in a live run, overdue status depends on current time vs detection_time
# For demonstration, we show the structure
if overdue:
    for n in overdue:
        print(f"  OVERDUE: {n.notification_type.value} — {n.regulator}")
else:
    print("  No notifications currently overdue (run in real-time to see live status)")

print("\n\nSUMMARY:")
print(f"  Total notification obligations: {len(verdant_incident.notifications)}")
print(f"  Personal data breach: YES — {verdant_incident.personal_data_records_estimate:,} records")
print(f"  Payment services affected: YES — {verdant_incident.estimated_customer_count:,} customers")

When run at 07:45 AM (4 hours and 31 minutes after detection), the dashboard reveals that the internal escalation deadline has passed — Maya was not notified until 4.5 hours after detection, a process failure. The FCA notification is overdue by 31 minutes. The DORA initial notification deadline is also past. Three notifications need immediate filing. The GDPR ICO notification has 67.5 hours remaining. The dashboard provides Maya with the precise regulatory status that she needs to triage her morning.

Section 7: Building Cyber Resilience — The Compliance Perspective

The compliance professional's role in cyber resilience is not the CISO's role. The CISO owns the technology defense — the firewalls, the endpoint detection, the penetration test schedule, the incident response playbook. The CCO owns the regulatory dimension: the notification obligations; the documentation of impact tolerance performance; the third-party contract provisions; the Board's ICT literacy.

The Cyber Risk Register

A compliance-owned cyber risk register maps cyber risks to their regulatory consequences. It does not duplicate the IT risk register — it translates IT risk into regulatory language. A ransomware risk that the IT risk register describes as "probability: medium; impact: high" becomes, in the compliance risk register, "ransomware affecting payment processing would trigger: FCA PRIN 11 notification; DORA initial notification (if EU operations affected); GDPR ICO notification if personal data affected; potential impact tolerance breach under PS21/3." This translation enables the Board to understand cyber risk in regulatory terms and to make resource allocation decisions accordingly.

Third-Party Cyber Risk

The most consequential cyber incidents in financial services are supply chain attacks — attacks on the firm's technology vendors, cloud providers, or data processors. The SolarWinds attack (2020), the MOVEit vulnerability (2023), and numerous other incidents illustrate the pattern: the firm's own systems are not directly attacked; the attacker compromises a trusted third party and uses that access to reach the firm's data or systems.

DORA's Article 28 requirements address this directly. Financial entities must: maintain a register of all ICT third-party service providers; categorize them by criticality; conduct risk assessments before engagement; include DORA-mandated contractual provisions (Article 30) in agreements with providers; and monitor provider performance and concentration risk.

The compliance implication: vendor contracts must include provisions on incident notification (the vendor must notify the financial entity of incidents affecting the firm's data or systems within specified timeframes); audit rights; data security requirements; business continuity obligations; and exit provisions. Contracts that predate DORA must be reviewed and, where necessary, renegotiated to include these provisions. This is a significant contractual remediation exercise for firms with large vendor portfolios.

Cyber Insurance and Compliance

Cyber insurance is increasingly available to financial institutions and can cover costs including forensic investigation, notification, business interruption, and ransom payments (subject to legal advice). Cyber insurance does not substitute for regulatory compliance. An insurer may cover the cost of filing a GDPR breach notification, but it cannot prevent the ICO from investigating whether adequate security measures were in place under GDPR Article 32 and whether the notification was timely. Regulatory penalties and enforcement actions are generally excluded from cyber insurance coverage. The Board should understand this clearly: insurance mitigates financial loss; it does not mitigate regulatory risk.

Board Cyber Literacy

DORA explicitly requires the management body of financial entities to maintain specific knowledge and skills on ICT risk sufficient to enable them to understand and assess ICT risk and its impact on the firm's operations. This is an enforceable requirement, not a governance aspiration. The FCA and PRA similarly expect Boards to be able to challenge management on cyber risk — to ask meaningful questions about testing results, incident response readiness, and third-party concentration risk.

The compliance team's role is to ensure that Board reporting on cyber risk is meaningful: not technical dashboards that Board members cannot interpret, but compliance-language summaries that translate technical risk into regulatory and business consequence. A report that says "98.3% uptime achieved" tells the Board little. A report that says "Payment processing availability was 98.3% against a 4-hour impact tolerance — we were within tolerance in all months except March, when an unplanned maintenance event caused a 4h 22m outage, which we reported to the FCA as a tolerance breach" tells the Board exactly what it needs to know.

Closing Vignette: 72 Hours Later

Seventy-two hours after the ransomware attack began, Maya Osei sat at the same desk where she had spent the worst Tuesday morning of her professional life. On her screen: four filed notifications, three acknowledgment receipts, and the draft DORA intermediate report that would be submitted to the Central Bank of Ireland before midnight.

The payment system had recovered at 07:01 AM — three hours and forty-seven minutes after detection. Thirteen minutes inside the four-hour impact tolerance. The forensics team had identified the entry point: an unpatched vulnerability in a third-party VPN appliance. The attacker had been in the network for eleven days before deploying the ransomware payload.

"We made it," Amir said, appearing in her doorway. He meant the tolerance. He was carrying two coffees.

Maya took one. "We need to run a lessons-learned exercise. Why did the attack get through? Why did it take four and a half hours from detection to notification to me? We were thirteen minutes from breaching our impact tolerance." She paused. "That's not a comfortable margin."

"I'll schedule the post-incident review."

"Schedule two." She turned back to her screen. "One for technology. One for our notification process." She gestured at the four filed notifications. "The FCA notification was thirty-one minutes late. The DORA notification was thirty-eight minutes late. My internal escalation was four and a half hours late. The notification process almost failed too." She pulled up the timeline on her second screen. "If the tolerance had been three hours instead of four, we would have breached it. If personal data exfiltration had been confirmed at hour two instead of hour seventy-two, we would have missed the ICO deadline."

Amir was quiet.

"The technology lesson," Maya said, "is about the VPN appliance patch cycle. That's yours." She closed the tab. "The notification lesson is about what happens in the first two hours of an incident. That's mine." She picked up the legal pad on which she had written, at 7:45 AM, the words FCA, DORA, ICO, tolerance. "We had the right framework. We nearly didn't have the right speed."

She set the pad down and opened the lessons-learned template.

The process had not failed. But thirteen minutes was a much smaller margin than it should have been.

Summary

Cybersecurity is no longer a matter for IT professionals alone — it is a compliance obligation with regulatory consequences that fall squarely on the Chief Compliance Officer and the management body. DORA's four pillars — ICT risk management, incident management and reporting, digital operational resilience testing, and third-party ICT risk — create a comprehensive statutory framework for EU financial entities that has no direct equivalent in US federal law but shares conceptual foundations with NIST CSF. The UK's operational resilience framework, centered on Important Business Services and impact tolerances, addresses cyber resilience through a regulatory commitment model enforced through scenario testing.

A cyber incident triggers multiple simultaneous regulatory notification obligations with different deadlines, different recipients, and different content requirements. The 4-hour DORA initial notification deadline, the 72-hour GDPR breach notification to the ICO, and the FCA's PRIN 11 material incident notification must all be managed concurrently during an active incident response. Systematic pre-planning — documented notification workflows, pre-cleared templates, and practice exercises — is the only reliable way to meet these obligations under the pressure of a live incident.

Third-party ICT risk is the source of the most consequential cyber incidents in financial services. DORA's contractual requirements for ICT third-party providers, the designation of Critical Third-Party Providers, and the concentration risk monitoring obligation reflect regulators' recognition that supply chain attacks have become the primary attack vector. The compliance professional's role is to ensure that vendor contracts, monitoring processes, and incident response workflows address the third-party dimension as thoroughly as they address direct attack scenarios.

The thirteen-minute margin at Verdant Bank was not a success. It was a warning.