How to Review a Processor Breach-Notification Clock in a DPA

Tove, Ops at a 23-person UK B2B SaaS, is about to treat “notify… without undue delay after becoming aware” as Art 33 covered. Knowing how to review a processor breach-notification clock in a dpa is a 20-minute hunt: 72 hours starts when you are aware → pin 24 or 48 hours → define awareness / suspicion / phases → lock first-notice contents → cascade to sub-processors → keep / tighten / escalate.

September 2026. English law; courts of England and Wales. The packet — the exact file set that will govern the vendor — is a support/CRM data processing agreement (DPA): a contract that sets processor duties when a vendor processes personal data for you as controller. Clause 9.2: without undue delay after becoming aware; no fixed hours; notice only after a “confirmed” incident; first notice = “a summary”; sub-processors get commercially reasonable efforts. Sales Slack: “Art 33 covered.” Customer PII staged. Go-live Friday.

“Without undue delay” is the statutory floor — not a stopwatch that protects your 72-hour Information Commissioner’s Office (ICO) window. UK GDPR Article 33 (live 2026-09-26) gives the processor no statutory 24- or 48-hour number. ICO processor guidance (live 2026-09-26): most controllers expect immediate notice and may contract for it. The hidden risk is a soft clock that burns your 72 hours before usable facts arrive.

Disclaimer: Checkory provides AI support, not legal advice. Consult a qualified lawyer for binding decisions.

How do you confirm the 72-hour regulator clock starts only when you are aware?

Yes. Article 33(1)’s 72-hour ICO clock is your duty after you become aware — not free investigation time for the vendor. Do: circle any processor “72 hours” that mirrors your regulator window. Don’t: treat “Art 33 covered” Slack as proof the clocks align.

In practice, ICO breach guidance (live 2026-09-26) says the processor informs you without undue delay; you then decide whether to notify the ICO within 72 hours of your awareness. ZwillGen (colour, live 2026-09-26): you are generally regarded as aware once the processor informs you — so a late first call compresses your remaining hours. Typical mistake: copying “72 hours” into the processor clause because it “matches GDPR.” If the fight is the whole DPA, see the data processing agreement checklist. Stay on this clock.

Why does “without undue delay” alone fail — when to pin 24 or 48 hours?

Yes — pin a hard cap. Do: require notice without undue delay and in any event within 24 hours of awareness (48 at the outside). Don’t: accept a 72-hour vendor-to-customer deadline that mirrors your ICO window.

For example, LearnTPRM (22 September 2026) flags fixed 72-hour vendor clocks as potentially too slow and warns against waiting for a full investigation. ContractKen (market colour): commercial windows often sit at 24–48 hours — drafting practice, not a second statute. Circle Tove’s undue-delay-only line. Log “undue delay alone — fail.” UK GDPR does not mandate a 24-hour contract term; you negotiate the cap because your ICO clock is fixed.

Which awareness, suspicion, and phased-update rules belong in the clause?

Define the trigger so “confirmed” cannot stall the first call. Do: treat awareness as a reasonable degree of certainty that personal data may have been compromised, and let suspected breaches start notice. Don’t: wait for full forensics or a vendor materiality decision.

EDPB Guidelines 9/2022 (guidance colour, live 2026-09-26) describe awareness as reasonable certainty that a security incident compromised personal data, say the processor need not finish a risk assessment before notifying you, and recommend prompt notice with details in phases — there is no explicit processor hour limit beyond undue delay. See EDPB Guidelines 9/2022. Article 33(4) colour allows phased information. Tove’s “confirmed” gate is the stall — demand suspicion triggers notice; forensics ride in updates. Log “wait-for-full-forensics — fail.”

What does the first notice need to contain before go-live?

More than “a summary.” Do: list nature; categories and approximate numbers of data subjects and records where possible; a contact point; likely consequences; measures taken or proposed, including containment. Don’t: accept “reasonable detail” with no fields.

Those fields track Article 33(3) colour on legislation.gov.uk Article 33 — paraphrase only. ICO contract guidance (live 2026-09-26): the Art 28 contract must say the processor assists with notifying breaches to the ICO and, where relevant, individuals. Allow “to the extent known” plus dated updates. Circle “a summary.” Log “summary-only — fail.”

Review the sub-processor cascade and named emergency channels

The breach often sits one layer down. Do: flow down the same or tighter clock to every sub-processor, keep the prime processor responsible, and name a 24/7 emergency email and phone on the schedule. Don’t: accept “commercially reasonable efforts” with no named inbox.

ICO Art 28 colour expects sub-processor authorisation and breach-assistance language. If a hosting sub discovers the incident on Monday and “reasonable efforts” reach you on Thursday, your 72 hours are already injured. For example, demand: sub notifies processor within 24 hours; processor notifies you within the prime clock; contacts are tested. This is not the UK IDTA versus UK Addendum fight and not a residency pin — stay on whether the cascade can wake Tove before Friday’s staged PII becomes a silent incident.

When to keep, tighten the clock, or escalate?

Keep only if hours, awareness, first-notice contents, and cascade already pass. Tighten undue delay into 24/48 hours, ban confirmation-only gates, list Art 33(3)-style fields, and harden the cascade. Escalate — pause Friday go-live or escalate to counsel — if soft clock + confirmation gate + summary-only + soft cascade remain as a package.

Success bar: a one-page log plus one Friday pause sentence (circle “without undue delay after becoming aware” and “a summary”). Workflow: 72h starts on you → pin 24/48h → awareness / suspicion / phases → first-notice contents → sub-processor cascade → keep / tighten / escalate. Optional: upload the same PDF to document analysis for a first-pass — first machine pass extracting clauses before a human reads every page — then a named human opens Clause 9.2. Verify every High flag — high-severity item a named human still opens. Escalate to counsel — a qualified lawyer, not the chatbot. Never treat the paper as ready to countersign.