24 Hours To Notify, 72 To Report: The UK Cyber Security And Resilience Bill, The Critical Third Parties Regime, And The Incident Pipeline UK Finance Teams Need Built Before Royal Assent

British technical regulation tends to arrive in layers rather than in one statute, which makes it easy to under-read. The Cyber Security and Resilience (Network and Information Systems) Bill is a case in point. On its own it updates the 2018 NIS regulations: it brings medium and large managed service providers into scope under the Information Commission, designates data centres as essential services in a new data infrastructure sector regulated by Ofcom, adds large load controllers and designated critical suppliers, requires incident notification within 24 hours and a full report within 72, lets regulators recover their costs, raises maximum penalties to GDPR-comparable levels, and gives the Secretary of State powers to direct regulators or entities against an imminent national security threat and to amend the regime by secondary legislation. It has cleared the Commons, had its Lords second reading on 14 July, and is at Report stage in the Lords.

Read with the financial-services layer underneath it, it is a different and larger thing. On 18 March 2026 the FCA, PRA and Bank of England opened a unified incident and third-party reporting portal with the same 24-hour and 72-hour clock, and 2026 is the first full year in which firms must meet steady-state operational resilience requirements with tested impact tolerances across important business services. HM Treasury holds a power under FSMA to designate major technology providers as Critical Third Parties, bringing them under direct supervision, and firms must now report structured information on their CTP dependencies. The Bill's factsheet says the NIS regime does not reach as far into banking and financial market infrastructure as NIS2 does - because the financial sector already has its own, stricter, sector regime. For an engineering team in a bank, broker or fintech, the practical effect is that the clocks are already running.

What 24 And 72 Hours Actually Require

The timelines look generous until you decompose them. Twenty-four hours from becoming aware of an incident to a notification means that detection, triage, classification against the regulator's materiality thresholds, an accountable decision and a submission through a specific portal all have to happen inside a working day - including on a Saturday. Seventy-two hours to a full report means the evidence for that report must already exist in a form that can be assembled, not reconstructed. Firms that treat this as a compliance-team task will miss the clock; firms that treat it as a pipeline will not.

1. 01Awareness has a timestamp, and it is contestable. The clock starts when the firm becomes aware. That means your detection tooling's first alert, not the moment a human read it. Log the alert time authoritatively; it is the number the regulator will ask about.
2. 02Classification has to be machine-assisted. Whether an incident crosses the threshold for notification depends on impact on important business services - which you have already mapped for operational resilience. Wire the map to the incident, so a detected event on a component produces a candidate classification automatically.
3. 03The notification is a structured artefact. The unified portal takes structured information. Generate it from your incident record rather than writing it in a hurry.
4. 04The 72-hour report needs the evidence you had at hour one. Timeline, affected services, third parties involved, containment actions, customer impact. If any of that lives only in Slack, it will not survive to hour 72 in a form you can submit.
5. 05Third-party incidents are your incidents. With over 40% of reported incidents involving a provider, your pipeline must ingest provider notifications on the same clock and map them to your own services - which is the CTP dependency data you are now required to hold anyway.

The Incident Pipeline, In Code

The pattern we build is a single incident record that accumulates evidence from the first alert, is classified against the resilience service map automatically, and can emit both the 24-hour notification and the 72-hour report from its own contents. It is unglamorous, and it is the difference between meeting the clock and explaining why you did not.

import { z } from "zod";

/** The regulator's clock starts at awareness. Record it once, authoritatively. */
export const Incident = z.object({
  id: z.string(),
  awareAt: z.string().datetime(),          // first authoritative alert, NOT first human read
  source: z.enum(["detection", "third_party_notice", "customer", "internal"]),
  thirdParty: z.object({ name: z.string(), isDesignatedCTP: z.boolean() }).optional(),

  // Populated automatically from the operational-resilience service map.
  affectedComponents: z.array(z.string()),
  affectedImportantBusinessServices: z.array(z.object({
    service: z.string(),
    impactTolerance: z.string(),           // e.g. "restore within 2h, max 4h"
    toleranceBreachedAt: z.string().datetime().nullable(),
  })),

  classification: z.object({
    notifiable: z.boolean(),
    reasons: z.array(z.string()),          // machine-readable, stable codes
    decidedBy: z.string(),                 // accountable person, SMF where applicable
    decidedAt: z.string().datetime(),
  }).nullable(),

  // Evidence accrues from hour one; nothing here is reconstructed at hour 72.
  timeline: z.array(z.object({ at: z.string().datetime(), event: z.string(), evidenceRef: z.string() })),
  containment: z.array(z.object({ at: z.string().datetime(), action: z.string(), by: z.string() })),
  customerImpact: z.object({ estimatedAffected: z.number().int(), channels: z.array(z.string()) }).nullable(),

  regulatory: z.object({
    notificationDueAt: z.string().datetime(),  // awareAt + 24h
    fullReportDueAt: z.string().datetime(),    // awareAt + 72h
    notificationSubmittedAt: z.string().datetime().nullable(),
    fullReportSubmittedAt: z.string().datetime().nullable(),
    portalReference: z.string().nullable(),
  }),
});
export type Incident = z.infer<typeof Incident>;

/** Deterministic candidate classification from the service map. A human decides; this drafts. */
export function draftClassification(inc: Incident, thresholds: MaterialityThresholds) {
  const reasons: string[] = [];
  for (const s of inc.affectedImportantBusinessServices) {
    if (s.toleranceBreachedAt) reasons.push("IMPACT_TOLERANCE_BREACHED:" + s.service);
  }
  if (inc.thirdParty?.isDesignatedCTP) reasons.push("DESIGNATED_CTP_INVOLVED");
  if ((inc.customerImpact?.estimatedAffected ?? 0) >= thresholds.customers) reasons.push("CUSTOMER_IMPACT_THRESHOLD");
  if (inc.source === "third_party_notice") reasons.push("THIRD_PARTY_ORIGIN");
  return { notifiable: reasons.length > 0, reasons };
}

/** The 24-hour artefact, generated - never typed - from the record. */
export function buildNotification(inc: Incident) {
  return {
    firmIncidentRef: inc.id,
    awareAt: inc.awareAt,
    summary: inc.timeline.slice(0, 5).map((t) => t.at + " " + t.event).join("; "),
    servicesAffected: inc.affectedImportantBusinessServices.map((s) => s.service),
    thirdParty: inc.thirdParty ?? null,
    containmentSoFar: inc.containment.map((c) => c.action),
    classificationReasons: inc.classification?.reasons ?? [],
    accountable: inc.classification?.decidedBy ?? null,
  };
}

The CTP Dependency Map Is The Same Map

The structured CTP dependency information firms must now report is not a separate exercise from incident response; it is the same graph read in the other direction. The operational-resilience service map says which components support which important business services. The dependency map says which providers supply which components. Join them and a provider notification - a cloud region degraded, a market-data feed down, an identity provider impaired - produces the affected services, the impact tolerances and the candidate classification automatically. Firms that hold these as two spreadsheets in two teams will discover during a provider incident that neither is current.

• Model providers as nodes with a designated-CTP flag, and keep the flag current as HM Treasury designates. A designated provider's incident is presumptively reportable.
• Record concentration explicitly: which important business services have a single provider with no tested fallback. This is what the PRA's steady-state expectations and the Bank's July financial stability commentary on AI-provider dependence both point at.
• Test the provider-outage path on a calendar, with the incident pipeline running. The point of impact tolerances is that they are tested, and a provider failure is the scenario most likely to be real.
• AI providers are third parties. A model-gateway outage that halts a customer-facing journey is an incident against an important business service, and the model vendor belongs on the dependency map like any other supplier.

The British Case, And Its Limits

We are a London firm and we will make the argument plainly. Britain has chosen a regime that is proportionate, sectoral and concentration-aware: the financial sector keeps its own supervisors, the CTP regime aims supervision at the handful of providers whose failure would matter systemically, and the Bill fills the gaps around it - managed service providers, data centres, critical suppliers - without imposing a single continental template on everything. The NCSC's count of four nationally significant attacks a week, £1.17bn of annual fraud losses and 40% of FCA-reported incidents involving a third party are the reasons this is urgent; the design is the reason it is workable. For a firm that has already built the resilience map and the incident pipeline, the UK regime is the easiest major jurisdiction in which to demonstrate compliance, because it asks for evidence of outcomes rather than adherence to a checklist.

The honest limits: the Bill's most important content - the scope expansions, the reporting duties - arrives through secondary legislation after Royal Assent, so the detail will move; the estimated cost of under £150m a year is a government estimate and firms should budget above it; and a proportionate, judgement-based regime is harder for a mid-sized firm without a resilience function than a prescriptive one would be. Layered regulation rewards the prepared and punishes the improvising, and the preparation is the pipeline.

What To Build Before Royal Assent

1. 01One incident record, accruing evidence from the first alert, with the regulatory clocks computed at awareness and on the pager.
2. 02Automatic candidate classification from the resilience service map, with an accountable human decision recorded.
3. 03Notification and report generated from the record, in the portal's structure, never written fresh.
4. 04A single provider graph that serves both CTP dependency reporting and incident impact analysis, with designated-CTP flags and concentration marked.
5. 05Ingestion of third-party notices onto the same clock, including from AI and model providers.
6. 06A calendar of provider-outage tests that exercise the pipeline end to end, because the 24-hour clock is not the moment to discover the portal login has expired.

The Bottom Line

The Cyber Security and Resilience Bill - through the Commons, past its Lords second reading on 14 July and at Report stage - is the visible top of a regime whose financial-services layer is already live: a unified FCA, PRA and Bank of England portal since 18 March with a 24-hour notification and 72-hour report clock, steady-state operational resilience with tested impact tolerances, and HM Treasury's power to designate Critical Third Parties in a sector where more than 40% of reported incidents involve a provider. Britain kept its own proportionate, sectoral, concentration-aware shape rather than adopting NIS2's, and for a prepared firm that is a genuine advantage. Prepared means a single incident record that accumulates evidence from awareness, deadlines on the pager, classification drafted from the resilience map, artefacts generated rather than written, and one provider graph serving both dependency reporting and impact analysis. That is the resilience engineering we build for UK financial firms in London, and the regime rewards exactly the firms that build it before they need it.

References & Further Reading

• GOV.UK - Cyber Security and Resilience (Network and Information Systems) Bill: summary of the Bill (factsheet). gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/summary-of-the-bill
• Stanga - UK Cyber Security and Resilience Bill 2026: what MSPs must build (Bill status and scope). stanga.net/en/blog/uk-cyber-security-resilience-bill-2026
• BCLP - Cyber resilience in financial services: navigating rising risks and the 2026 regulatory shift (unified portal, CTP regime, 40% third-party figure). bclplaw.com/en-US/events-insights-news/cyber-resilience-in-financial-services-navigating-rising-risks-and-the-2026-regulatory-shift.html
• Mayer Brown - United Kingdom proposes changes in the Cyber Security and Resilience Bill to the NIS regulations, with key differences to NIS2. mayerbrown.com/en/insights/publications/2026/03/united-kingdom-proposes-changes-in-the-cyber-security-and-resilience-bill-to-the-nis-regulations-with-key-differences-to-nis2
• Financier Worldwide - Landmark reform: the UK Cyber Security and Resilience Bill. financierworldwide.com/landmark-reform-the-uk-cyber-security-and-resilience-bill
• Bank of England - Financial Stability Report, July 2026 (AI-provider concentration and cyber risk). bankofengland.co.uk/financial-stability-report/2026/july-2026

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information