Cybersecurity incident response for regulated firms
A cybersecurity incident affecting a regulated firm triggers a complex set of notification obligations that must be managed simultaneously and at speed. The FCA's SUP 15 requires firms to notify the regulator of any matter of which it would reasonably expect notice, including significant operational incidents — and the FCA's guidance on what is 'significant' sets a low threshold. The ICO's UK GDPR breach notification rules require notification within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals' rights and freedoms. For firms operating under DORA's requirements for their EU entities, the four-hour initial notification timeline for major ICT incidents adds a further urgent obligation. Managing all three regulatory timelines simultaneously, while also dealing with the incident itself, requires advance preparation.
Incident classification is the first step in any response, and the quality of initial classification determines whether the response process runs correctly. Firms should have a written incident classification framework that defines what constitutes a significant operational incident for FCA purposes, what constitutes a reportable personal data breach for ICO purposes, and (for DORA entities) what constitutes a major ICT-related incident for DORA purposes. The thresholds are different for each regime: a ransomware attack that encrypts a server but is contained within hours may not require FCA or ICO notification, but the same attack extending to customer-facing systems almost certainly would. Having pre-agreed classification criteria — and designated individuals with authority to make and document classification decisions — prevents delay and inconsistency in the first critical hours of an incident.
The first responder designation is critical. Who picks up the phone at 2am when a SOC alert comes through? Who has the authority to invoke the incident response plan, contact the regulator, engage external forensic support, and communicate with the board? Many firms have an incident response plan that is technically comprehensive but organisationally incomplete — it describes what should happen without identifying by name who is responsible for each step, and without providing the contact details, escalation paths, and decision authorities needed to implement it under pressure. An annual tabletop exercise that tests the plan with the actual named individuals is the most effective way to identify these gaps.
Regulatory notifications should be made promptly and honestly, even where the full facts are not yet known. The FCA and ICO both accept that notifications at early stages of an incident will contain incomplete information — what they expect is a credible initial notification, followed by updates as the picture develops, and a final notification once the incident is fully understood and remediated. A firm that delays notification while waiting to understand the full scope of an incident will almost invariably have a worse regulatory relationship than one that notifies promptly and communicates transparently throughout the response. Legal privilege over internal investigation communications should be sought early, as the privilege position can affect what is included in notifications and what is disclosable.
Post-incident review and lessons learned
Every significant cyber incident should be followed by a structured post-incident review that documents what happened, what the root cause was, what the response achieved and where it fell short, and what changes to controls or processes are warranted. This review should be presented to the board (or a board committee with appropriate technical understanding) and should be reflected in an updated risk register and, where appropriate, in a revised operational resilience self-assessment. Regulators expect firms to learn from incidents — a second incident of the same type within a short period is a significant supervisory concern.