This article accompanies Hour 7: Data Breach Response in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event A: Full-Day Regulatory Privacy Training.

At 17:42 on a Friday, a supplier emails your service desk. Its support platform has detected suspicious access. The supplier is still investigating. It cannot yet confirm whether customer records were viewed, downloaded or altered. It does know that your organisation's environment is "potentially in scope", and it promises a further update when the incident team has more facts.

That is the kind of breach scenario that tests a privacy programme properly. Not the neat version where every fact is known and the notification decision is obvious. The difficult version, where the DPO, legal, security and governance teams have to move quickly without pretending to know more than they do.

The 72-hour clock matters, but it is not the whole discipline. The organisation needs a decision log that can show what happened, when the controller became aware of a personal data breach, what remained unknown, what evidence was requested, why notification was or was not made, and how later updates were handled.

This article is general guidance, not legal advice. Breach notification decisions are fact-sensitive, especially where the incident involves suppliers, cloud systems, special category data, children, vulnerable people, financial information, cross-border processing or ongoing malicious activity.

The operational problem is incomplete facts

Most breach response failures do not start with bad faith. They start with an uncomfortable gap between the time available and the evidence available.

The supplier does not yet know whether the suspicious login was an attacker, a compromised admin account, a false positive or a legitimate support action. Security wants logs. Legal wants the contract and notification clause. The DPO wants to know what personal data is in the supplier system and whether the organisation is controller or processor for each dataset. Senior stakeholders want to know whether the regulator must be told. Communications wants to avoid saying anything that later proves wrong.

All of those needs are reasonable. None of them removes the need to triage.

For GDPR purposes, the first question is whether there has been a personal data breach: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That definition covers confidentiality, integrity and availability. It is not limited to a confirmed data download.

The second question is whether the breach is notifiable to the supervisory authority. Under GDPR, the controller must notify unless the personal data breach is unlikely to result in a risk to individuals' rights and freedoms. If the breach is likely to result in a high risk, affected individuals may also need to be informed without undue delay.

The third question is what the organisation can evidence. A confident answer without a record is not much use in a regulator, board, audit, insurance or complaint setting. The decision log is the bridge between fast operational action and accountable judgement.

What the 72-hour decision log is for

A 72-hour decision log is not just a form. It is a live evidence record for the notification decision.

It should show the difference between four things:

  • confirmed facts;
  • reasonable assumptions;
  • unknowns under investigation;
  • decisions made on the evidence available at the time.

That distinction matters because breach response is rarely linear. Early facts can change. A supplier may first say "no evidence of access" and later confirm that logs were incomplete. A security team may first see one affected account and later identify a wider permission issue. A processor may first report a platform incident and later narrow it to one support queue. The log should be able to absorb that movement without looking like the organisation changed its story casually.

The log also helps identify when the organisation became aware of the personal data breach for Article 33 purposes. A vague alert that a supplier is investigating suspicious activity may not be enough on its own. A later update confirming unauthorised access to a system containing personal data may be enough. The answer depends on the facts, and the record should explain the judgement.

A good log does not wait for perfect certainty. It records the working position, the evidence behind it and the next evidence needed.

Worked example: Friday supplier access alert

Assume the organisation is an Irish-established controller using a supplier to host a customer support platform. The platform contains customer names, email addresses, account numbers, support queries and some free-text attachments uploaded by customers. Some tickets may include financial hardship information or health-related comments because customers sometimes provide more context than the form requests.

The supplier acts as processor for the support platform. It uses a subprocessed cloud logging tool and provides security monitoring under the service agreement. The contract requires the supplier to notify suspected or actual personal data breaches without undue delay and to provide reasonable assistance with regulatory notifications.

The first facts are thin:

  • the supplier detected suspicious access to an admin account at 16:58 on Friday;
  • the supplier emailed the controller at 17:42;
  • the suspicious session may have accessed the support platform;
  • the supplier has not yet confirmed which tenant records, if any, were viewed;
  • the supplier has disabled the account and started log preservation;
  • a further update is expected within two hours.

The unknowns are more important than the labels:

  • whether the session was unauthorised;
  • whether the session accessed the controller's tenant;
  • whether personal data was viewed, exported, altered or deleted;
  • whether attachments were accessible;
  • whether special category or high-impact data was included in affected tickets;
  • whether the supplier's logs are complete;
  • whether any subprocessors are affected;
  • whether the incident is contained.

At this point, the organisation should not decide "no breach" simply because the supplier has not yet confirmed access. It should open the breach decision log, treat the matter as a suspected supplier security incident involving possible personal data, and start evidence collection.

Building the timeline from awareness to decision

The timeline below shows how the log might develop. It is not a template for every incident, but it shows the level of discipline a DPO or privacy team should expect.

Time Position Evidence recorded Decision or next action
Friday 17:42 Supplier reports suspicious admin access and says controller tenant may be in scope. Supplier email, incident reference, sender, time received, affected service, initial containment statement. Open suspected breach log. Notify internal incident lead, DPO, legal and security. Request written update and log preservation.
Friday 18:10 Internal team confirms the supplier hosts customer support tickets containing personal data. Processing record, supplier contract, data map, support platform description, known data categories. Treat as possible personal data breach. Identify controller and processor roles. Check escalation route.
Friday 19:05 Supplier confirms the admin account was used from an unusual IP address and MFA prompt was accepted. Tenant access is still under review. Supplier update, identity logs requested, MFA record requested, account disablement evidence requested. Continue investigation. Record that unauthorised access is plausible but tenant-level personal data access is not yet confirmed.
Friday 20:20 Supplier confirms the account accessed the controller's tenant dashboard for 11 minutes. It cannot yet confirm which tickets were opened. Supplier update, access timestamp, affected tenant, disabled account confirmation, log export requested. Controller reaches working awareness that a security incident has affected a system containing personal data. Start 72-hour notification assessment from this point unless later evidence changes the awareness analysis.
Friday 21:00 Internal review identifies affected platform data categories and possible risk factors. Data map, ticket field list, attachment policy, sample ticket categories, vulnerable customer flag review. Record likely personal data categories. Ask supplier whether attachments, exports and search results were accessible.
Saturday 09:30 Supplier says no bulk export event is visible, but individual ticket views are still being reconstructed. Logs cover dashboard views and ticket opens but not all attachment previews. Supplier technical note, log coverage explanation, missing evidence statement. Record uncertainty. Do not rely on "no export" as proof that no access occurred. Prepare notification working draft in case threshold is met.
Saturday 14:15 Security confirms no internal systems are affected. Supplier confirms two tickets were opened. One included financial hardship details. Security note, supplier ticket IDs, data category review, affected individual count, customer vulnerability assessment. Risk to individuals is possible. DPO and legal recommend preparing supervisory authority notification unless further evidence makes risk unlikely.
Sunday 10:00 Supplier provides partial log export and confirms no attachments were downloaded. It cannot confirm whether ticket text was read. Log export, supplier explanation, support ticket content review, no-download evidence. Record facts and limits. Assess whether confidentiality risk remains despite containment.
Monday 11:30 Organisation completes notification assessment. Two individuals affected, one ticket contains potentially sensitive financial hardship information, no evidence of onward disclosure, but unauthorised access to ticket text cannot be ruled out. Risk assessment, DPO advice, legal note, supplier evidence pack, draft regulator notification. Decide to notify supervisory authority because the breach is not clearly unlikely to result in risk. Do not yet notify individuals unless high-risk threshold is met; keep under review.
Monday 15:45 Notification submitted with incomplete forensic detail and commitment to update. Submitted notification, regulator reference, copy of notification, unresolved questions, update owner and due date. Schedule follow-up update when supplier completes log reconstruction. Update senior incident report.

This example is deliberately modest. The affected population is small, and there is no confirmed bulk export. Even so, the decision is not casual. The issue is unauthorised access to identifiable customer support records, including at least one ticket with more sensitive context. The controller cannot prove that the ticket text was not read. The supplier can prove some containment steps and can rule out some forms of export, but the evidence is incomplete.

A different fact pattern could lead to a different decision. If logs showed only access to an empty admin screen with no personal data, notification might not be required. If the affected tickets contained identity documents, children's data, medical details or credentials, individual notification might be needed. If the supplier could not provide credible logs, the uncertainty itself would become part of the risk assessment.

Facts, assumptions and unknowns

The decision log should make it easy for a reviewer to see what kind of statement each entry is.

A fact is supported by evidence. For example: "The supplier disabled the affected admin account at 17:12 and provided the audit event." Or: "The platform contains customer names, email addresses and support ticket text."

An assumption is a working judgement that has not yet been fully proved. For example: "The incident is currently limited to the supplier platform." Or: "Bulk export appears unlikely based on the log fields available." Assumptions can be useful, but they should be labelled and tested.

An unknown is a question still open. For example: "It is not yet known whether attachments were previewed." Or: "The supplier has not confirmed whether subprocessors were affected." Unknowns should have owners and target dates. Otherwise they become quiet gaps.

This separation reduces two common problems. The first is false reassurance, where the organisation writes "no evidence of access" as if it means "evidence of no access". The second is uncontrolled escalation, where every uncertainty is treated as proof of worst-case harm. The better discipline is to state the uncertainty and decide what it does to the risk assessment.

Processor and controller evidence

Supplier incidents need particular care because the controller's legal accountability and the processor's technical evidence sit in different places.

The controller should preserve the contract, data processing agreement, breach notification clause, subprocessors list, data map, service description, support tickets, incident correspondence and internal decision record. It should also record who within the controller had authority to make the notification decision and who was responsible for regulator contact.

The processor should provide prompt, usable evidence. In a scenario like this, that should usually include:

  • time of processor detection and time of controller notification;
  • affected service, tenant, environment and accounts;
  • initial access vector where known;
  • containment actions and timestamps;
  • log coverage and any known log gaps;
  • data categories and record categories potentially exposed;
  • number of affected records or a method for estimating them;
  • export, download, view, alteration and deletion evidence;
  • subprocessor involvement;
  • next update timetable.

The controller should be careful not to outsource its notification decision to the supplier. A supplier can provide evidence and recommendations, but the controller must assess the risk to individuals, decide whether supervisory authority notification is required, decide whether affected individuals must be informed, and maintain the Article 33 record.

Where the organisation is itself a processor for another controller, the discipline changes. It should notify the controller without undue delay, provide the evidence available, avoid making unauthorised statements to individuals or regulators unless the contract or law requires it, and keep its own record of what it reported and when.

Phased updates are better than late certainty

Regulator guidance recognises that complex incidents may not be fully understood within 72 hours. That does not mean the organisation can wait for a final forensic report before deciding whether to notify.

If notification is required but some information is missing, the organisation should provide the information it has, explain the limits clearly and update without undue further delay. A phased notification should not be vague by habit. It should say what is known, what is under investigation, who is responsible for the next evidence, and when the regulator can expect an update.

For the Friday supplier scenario, a phased notification might explain that the supplier has confirmed unauthorised access to the controller's tenant, that two tickets are currently known to have been opened, that no bulk export has been identified, that attachment preview evidence remains under review, and that the controller will provide an update when the supplier completes log reconstruction.

The same discipline applies if the initial decision is not to notify. The log should explain why the breach was assessed as unlikely to result in risk, what evidence supported that view and what would trigger review. If new evidence later changes the position, the organisation should reopen the notification assessment and record why the decision changed.

Practical checks for the DPO and privacy team

The checklist should support judgement, not replace it. In supplier incidents with incomplete facts, the DPO or privacy team should normally test the following points:

  • What is the earliest report, and when did the controller become aware that personal data was affected or likely affected?
  • What personal data is in the relevant system, including free-text fields and attachments that may contain unexpected information?
  • Which individuals are affected or potentially affected, and are any children, vulnerable people, employees, complainants or special-category contexts involved?
  • Is the organisation controller, joint controller or processor for each affected dataset?
  • What has the supplier actually evidenced, rather than asserted?
  • Are logs complete enough to support the proposed conclusion?
  • Has the incident affected confidentiality, integrity, availability or more than one of those?
  • What containment has happened, and what residual risk remains after containment?
  • Is notification to the supervisory authority required because risk to individuals cannot be ruled out as unlikely?
  • Is communication to affected individuals required because high risk is likely, or because individuals need advice to protect themselves?
  • What internal or external stakeholders must be informed, including senior leadership, insurer, law enforcement, sector regulator or cyber authority where relevant?
  • What follow-up evidence, remediation and lessons learned actions have owners and due dates?

The most important point is not that every question has a final answer in the first hour. It is that every material question is visible, owned and connected to the notification decision.

Concrete evidence record

After the incident, the breach file should be capable of standing on its own. A reviewer should not need to reconstruct the decision from scattered emails and memory.

The record should normally include:

Evidence item Why it matters
Initial report and awareness timeline Shows when the incident was first reported, when it became a suspected personal data breach and when the notification clock was assessed to start.
Controller / processor role note Shows who had the legal notification duty and what assistance the processor owed.
Data category and individual category assessment Shows the basis for risk assessment, including sensitivity and affected population.
Supplier evidence pack Supports the factual position on access, containment, logs, export, affected records and remaining gaps.
Facts / assumptions / unknowns log Prevents premature certainty and shows how uncertainty was managed.
Risk assessment and notification decision Records why the organisation notified, did not notify, or used phased notification.
DPO, legal and security input Shows governance quality and challenge, not just operational activity.
Regulator notification and updates Preserves the submitted notification, reference number, phased updates and contact point.
Individual communication assessment Shows whether the high-risk threshold was considered and what decision was made.
Remedial action and lessons learned log Shows containment, root cause review, control improvements and follow-up ownership.

This record is useful even when the incident is not notifiable. The DPC guidance specifically expects organisations to keep internal records even where they determine there is no risk to affected individuals. The EDPB also links breach documentation to accountability and recommends documenting the reasoning for decisions, especially where a breach is not notified.

What this means for governance

A breach triage process should make decisions faster without making them thinner.

That means preparing before the Friday email arrives. Supplier contracts should require rapid breach reporting and usable evidence. Data maps should identify what is in key systems, not just the name of the platform. Incident plans should name who opens the breach log, who contacts the supplier, who preserves technical evidence, who advises on notification and who signs off regulator contact. Staff should know that a supplier's "we are investigating" message is not something to leave in an inbox until Monday.

Senior stakeholders also need the right briefing shape. A useful update is short and evidence-led: what happened, what is known, what remains unknown, whether the 72-hour assessment has started, what decision is due by when, and what support the incident team needs. That is more useful than either panic or premature comfort.

For CPD purposes, the skill is not memorising the 72-hour rule. It is being able to run a defensible triage process while the facts are still developing. A DPO or privacy lead should be able to slow down the wrong kind of certainty, speed up evidence collection, and help the controller make a clear notification decision on time.

The best decision log tells a simple story: we saw the issue, we separated facts from assumptions, we asked for the right evidence, we assessed risk to individuals, we notified or did not notify for recorded reasons, and we updated the position when the evidence changed.

This article is intended to support the learning covered in Hour 7 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event A: Full-Day Regulatory Privacy Training.

Sources

Publication verification notes:

  • DPC source re-checked on 2026-06-25. The page states the 72-hour breach notification expectation, high-risk communication to individuals, DPC breach form route, update process and internal record expectation.
  • ICO source re-checked on 2026-06-25. The page states that the guidance is under review following the Data (Use and Access) Act coming into law on 19 June 2025, and emphasises early reporting with later updates where information is incomplete.
  • EDPB source re-checked on 2026-06-25. The page identifies Guidelines 9/2022 as the final version and links to the version 2.0 PDF covering awareness, phased notification, risk assessment and record keeping.
  • EUR-Lex source should be re-opened before publication for final verification of Article 33 and Article 34 wording in the publication browser.