Financial Services Incident Response: Clocks and Payments

A single cyber incident at a bank, payments firm or insurer can start five or more regulatory clocks at once, each with its own trigger, and the team that has to run them is also trying to keep payments flowing and stop customers being defrauded. The rules are each covered in depth elsewhere on this site. This guide is about running them together: one classification step that answers every regulator's question, a payments continuity playbook, and a customer harm workstream that starts on day one rather than after the forensic report. It covers US, EU and UK firms in banking, payments and insurance, and is written for incident commanders, CISOs, compliance and operational resilience leads.

Key takeaways

Build one classification step for every regime. DORA, the US 36-hour rule, NYDFS Part 500 and the UK regime each ask a slightly different question; answer them all in one meeting and record who decided and when.
Know which clocks run from determination. The US banking rule and NYDFS both start their clocks when the firm determines an incident has occurred, so the decision log is evidence.
Payments continuity is a separate workstream. Settlement deadlines, scheme rules and liquidity do not pause for forensics; give payments operations its own lead inside incident command.
Customer harm continues after containment. Stolen customer data fuels impersonation scams, as the Coinbase insider breach showed; warn customers and tighten verification early.
UK rules change on 18 March 2027. The FCA's PS26/2 replaces today's Principle 11 approach with defined thresholds, a 24-hour initial report expectation and a four-hour deadline for payment service providers.

The regulator clocks in one table

This table brings the main financial sector clocks together so the classification meeting can work through them in one pass. Each row is covered in detail in its own guide; confirm thresholds against the current rule text before relying on them.

Regime	Who	Trigger	First deadline	Follow-up
EU DORA major ICT-related incident	EU financial entities, including banks, payment institutions and insurers	Classification as major under RTS 2024/1772	Within 4 hours of classification, no later than 24 hours after awareness	Intermediate within 72 hours of the initial notification; final within one month of the latest intermediate report
US Computer-Security Incident Notification Rule	US banking organisations	Determination that a notification incident has occurred	As soon as possible, no later than 36 hours	None specified
US bank service provider notice	Bank service providers	Covered services disrupted, or likely to be, for four or more hours	As soon as possible, to the bank's designated contact	None specified
NYDFS 23 NYCRR 500.17	NYDFS-licensed covered entities	Determination that a Cybersecurity Incident has occurred	As promptly as possible, no later than 72 hours, via the DFS Portal	Extortion payment: notice within 24 hours, written explanation within 30 days
SEC Regulation S-P (amended 2024)	Broker-dealers, investment companies, registered advisers, transfer agents	Sensitive customer information accessed or used without authorisation, or reasonably likely to have been	Customer notice as soon as practicable, no later than 30 days after becoming aware	None specified
NAIC Model Law #668 (as enacted by states)	Insurance licensees	Determination that a cybersecurity event has occurred, where state triggers are met	No later than 72 hours to the commissioner (some states differ)	Continuing updates; consumer notice under state breach law
UK FCA and PRA, current approach	FCA and PRA regulated firms	Material incident (Principle 11, SUP 15.3; SUP 15.14 for payment service providers)	Contact supervisor or use the SUP 15 notification form	As the supervisor directs
UK FCA PS26/2, from 18 March 2027	Firms with Part 4A permission, payment service providers and others	Risk of intolerable consumer harm, safety and soundness, or market stability	As soon as practicable, at most 24 hours after determining a threshold is met; payment service providers within 4 hours of first detection	Enhanced firms: intermediate on significant change; final within 30 working days of resolution
UK GDPR personal data breach	Controllers	Notifiable personal data breach	ICO generally within 72 hours of becoming aware, where feasible	Phased information allowed

See the DORA Major ICT Incident Reporting Guide, US Bank Computer-Security Incident Notification Rule Guide, NYDFS Part 500 Guide and NAIC Insurance Data Security Model Law Guide. For the programme view of the same rules see the Banking Cybersecurity Programme Guide.

Running one classification step

Most late filings come from a classification that never formally happened, not from a missed calendar reminder. We recommend a standing classification call, convened within the first hour of any incident that touches customer data, payments or critical services.

Collect the facts every regime needs: services affected and since when, number and location of customers affected, data types touched, whether access was malicious and unauthorised, third parties involved, and any ransom demand.
Answer each regime's question explicitly: is it major under DORA, a notification incident under the US rule, a Cybersecurity Incident under Part 500, material under SUP 15, a notifiable personal data breach? Record yes, no or not yet, with reasons.
Timestamp the determination: the US banking and NYDFS clocks start at determination, and DORA starts at classification with a 24-hour backstop from awareness. Record the time, the decision makers and the evidence they had.
Assign an owner per filing: one person per regulator, working from pre-approved templates, with legal review built in.
Repeat on change: reconvene when scope changes. A "not yet" becomes a "yes" the moment data theft is confirmed or an outage passes a duration threshold.

Decision guidance, groups and single firms: a group with entities in several jurisdictions needs one group classification call plus a named local filer per legal entity, because a single incident may be major for an EU payment institution and immaterial for a US sister bank. A smaller single-entity firm can run the classification inside its incident bridge with the compliance officer present.

Payments continuity

Payments are where a technology incident becomes a liquidity, customer and systemic problem within hours. Treat continuity as its own workstream with its own lead.

Function	Incident risk	Continuity action (NHI Mgmt Group recommendation)
Payment initiation and channels	Online banking or API outage, fraudulent payment instructions	Fall back to staffed channels with call-back verification; raise fraud scoring thresholds on new payees
Interbank messaging and settlement	Compromised operator or messaging credentials, missed cut-offs	Suspend outbound messages from affected systems, use pre-agreed manual or alternative routes, reconcile every message sent during the window
Card issuing and acquiring	Authorisation outage, card data exposure	Stand-in processing rules agreed with the processor; notify the schemes and acquirer under their rules
Treasury and liquidity	Inability to see positions	Manual position reporting, early contact with the central bank or settlement agent
Third-party processors	Provider outage or compromise	Invoke contract notification and exit clauses; use the provider's four-hour disruption notice under the US rule where it applies

Do not restore payment systems on a compromised identity plane: rotate operator, HSM administrator and API credentials before reconnecting. See the Payment HSMs guide and the Payment API keys beyond Stripe guide.
Ransom and sanctions: NYDFS requires notice within 24 hours of an extortion payment and a written explanation within 30 days covering the reasons, alternatives considered and sanctions diligence. See the Ransomware Payments and Sanctions Guide.

Customer harm workstream

The harm customers suffer often comes after the incident is technically contained. PS26/2 makes consumer harm one of the three UK reporting thresholds from March 2027, and asks payment service providers to consider the characteristics of their own customers when applying it.

Assume impersonation follows data theft: in the Coinbase insider breach, customer balances, histories and ID images were used to make scam calls convincing, and Coinbase committed to reimburse customers who lost funds as a direct result.
Warn customers in plain words: tell them what was taken, that you will never ask them to move money to a "safe account", and how to verify a call.
Add friction for affected accounts: step-up verification for payee changes, contact detail changes and large transfers on flagged accounts. See the Account Takeover Response Playbook and the Authorised Push Payment (APP) Fraud Guide.
Staff the contact centre: brief agents, publish a status page and prepare scripts before notices go out.
Route crime reports correctly: in the UK, suspected fraud is reported to Report Fraud (reportfraud.police.uk, 0300 123 2040; in Scotland, Police Scotland on 101). The FCA page also points to the NCSC for cyber incidents.
Track redress decisions: record each reimbursement decision and its basis so later complaints and regulator questions can be answered consistently.

Where identity fits

Financial incidents frequently run through identities that sit outside the core IAM programme: outsourced support agents, payment operators, service accounts on messaging gateways and API keys held by fintech partners.

Support and outsourced staff: scope what each agent can see, mask sensitive fields and alert on bulk lookups unrelated to open tickets, as the Coinbase lessons set out.
Payment operators: require phishing-resistant MFA and dual control for release, and log operator sessions separately.
Machine identities: inventory service accounts and API keys on payment and data flows, and rotate them as part of eradication. See the Financial Services Identity Security Guide.

Implementing the combined process

Map regimes to entities: list every legal entity, its regulators and its clocks. Keep the list in the incident runbook, not only in compliance systems.
Write one classification worksheet: one page with each regime's question, the evidence needed and the deadline that follows a yes.
Pre-approve templates: DORA Annex I fields, NYDFS portal fields, US regulator email, UK SUP 15 form and, from March 2027, the new FCA report fields.
Bind third parties: require providers to notify a named contact quickly, with the information your filings need.
Exercise twice a year: include a cross-border incident, a payments outage over four hours and a data theft followed by customer scams. Test the rollback from manual payments to normal processing.
Prepare for PS26/2: before 18 March 2027 decide whether each UK entity is a standard or enhanced reporting firm and rehearse the 24-hour and four-hour deadlines.

Detection and measurement

Time from detection to classification: per incident, with the determination time recorded.
Filings on time: percentage of regulatory notices submitted within their deadline, target 100 percent.
Payments backlog: value and number of payments delayed past cut-off during the incident.
Customer fraud after the incident: scam losses on affected accounts in the 90 days after notice, against a baseline.
Credential rotation before reconnection: percentage of operator, service and API credentials rotated on affected systems.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev 5	Rule
Executing the plan with third parties	RS.MA-01	IR-4, IR-8	DORA Art. 17; NYDFS 500.16
Regulator and customer notification	RS.CO-02, RS.CO-03	IR-6	DORA Art. 19; NYDFS 500.17; 12 CFR 53.3; Reg S-P
Payments continuity	RC.RP-01	CP-2, CP-10	DORA Art. 11
Recovery communication	RC.CO-03	IR-6	PS26/2 intermediate and final reports
Credential reset during eradication	RC.RP-01	IA-5, AC-6	NYDFS 500.7

Common failure patterns

No recorded determination: the team acts on an incident for days without formally deciding it is notifiable, then cannot show when the clock started.
One regulator at a time: filings are drafted sequentially, so later ones miss their deadline.
Payments restored on the old credentials: operators reconnect before operator and service accounts are rotated.
Customers warned too late: scam calls start before the notice letter arrives.
Outsourced access outside scope: contractor support staff can read far more than their tickets require, as in the Coinbase insider breach.
Using today's UK rules after March 2027: runbooks still say "contact your supervisor" when a 24-hour or four-hour report is required.

Practitioner checklist

List every legal entity with its regulators, triggers and deadlines in the incident runbook.
Run one classification call per incident and record each regime's answer, the time and the decision makers.
Keep pre-approved templates for DORA, NYDFS, US regulators, SUP 15 and PS26/2.
Give payments continuity its own lead and manual fallback procedures with reconciliation.
Rotate payment operator, HSM, service and API credentials before reconnecting systems.
Start the customer harm workstream on day one: warnings, verification, contact centre scripts and redress log.
Check sanctions and NYDFS extortion payment duties before any ransom decision.
Rehearse the UK PS26/2 deadlines before 18 March 2027.

Standards and references

Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · Banking Cybersecurity Programme Guide · Threat Actors Targeting Financial Services Guide · Incident Response Guide · Legal Privilege in Incident Response Guide. This guide summarises financial sector incident reporting rules and is not legal advice.

Financial Services Incident Response Guide: Regulator Clocks, Payments Continuity and Customer Harm