Personal data breaches: keep the notification decision moving

A personal data breach creates two parallel jobs: contain the incident and decide what must be communicated. Neither should wait for the other to finish. Engineers may still be reconstructing access logs when the controller already has enough information to assess notification.

The practical challenge is keeping that decision moving without presenting assumptions as facts. A useful response process records awareness, produces a reliable minimum evidence set, assigns decision responsibility, and updates the assessment as findings change. From a CTO’s perspective, the essential deliverable is not a completed forensic investigation within 72 hours. It is a timely, defensible decision supported by technical evidence, with clear ownership of the remaining questions.

Recognize the breach before debating notification

A personal data breach is broader than stolen data. Article 4(12) GDPR covers a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.

Three dimensions matter:

One event can involve all three. Ransomware may interrupt access, corrupt records, and expose information. Restoring a backup addresses only part of that incident.

A misplaced email and a ransomware incident can therefore both require a documented assessment, even though the investigations look different. Conversely, an unsuccessful attack that did not compromise personal data is not automatically a personal data breach. It may still require security investigation and reporting under another regime.

Start by establishing whether personal data was affected, not whether anyone has complained or financial damage has occurred. Names, account identifiers, employee records, device identifiers, and combinations of seemingly ordinary information may be personal data. Pseudonymized records can remain personal data where people are still identifiable.

For availability incidents, examine consequences rather than using a fixed outage duration as a shortcut. Losing access to an appointment record during urgent treatment differs from briefly interrupting access to an archived newsletter list.

Establish awareness and name the decision owner

Under Article 33 GDPR, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms.

The clock does not automatically start when the underlying attack began. Equally, it does not wait for a final forensic report or executive approval. In supervisory guidance, awareness is understood as having a reasonable degree of certainty that a security incident has occurred and compromised personal data. An initial investigation can establish that certainty; it must not become a mechanism for postponing responsibility.

Keep three timestamps separate:

• Occurrence: when the incident happened, if known.
• Detection: when someone first observed or reported a possible incident.
• Awareness: when the organization had sufficient certainty that personal data was compromised.

Record the evidence supporting awareness. If a timestamp is disputed, retain the competing interpretations and their basis rather than quietly replacing the earlier entry. Internal escalation delays should be visible, not used to assume that awareness began only when privacy or leadership received the report.

Seventy-two hours means elapsed hours, including weekends and public holidays. It is an outer timing reference where feasible, not permission to wait if notification can be made sooner.

Assign an incident coordinator to maintain the timeline and outstanding questions. Technical leads establish facts; privacy expertise evaluates the consequences and legal requirements; an authorized controller representative owns the notification decision. Where a DPO is appointed, involve them promptly in their independent advisory and monitoring role. Do not make the DPO the owner of containment or assume that they replace controller accountability.

Name deputies. A process that depends on one executive’s availability is not a functioning out-of-hours process.

Produce a decision-ready evidence set in the first hours

Containment and evidence preservation must proceed together. Disconnecting a compromised endpoint may be appropriate, but wiping it before collecting relevant evidence can destroy the basis for assessing access and scope. Conversely, preserving every artifact is not a reason to leave an active disclosure uncontained.

The following is a practical response sequence, not a statutory timetable.

Stabilize the incident

Revoke exposed sessions or credentials, restrict unsafe permissions, isolate affected components where appropriate, and stop ongoing misdirected transfers. Record each action, its time, and its expected effect. Preserve relevant logs, configuration snapshots, message headers, and other volatile material before retention limits or recovery work remove them.

Restrict access to incident evidence. A breach investigation can itself create sensitive collections: identity documents, employee messages, authentication data, or lists of affected customers. Use an approved evidence location rather than forwarding raw records through a broad incident chat.

Build the minimum fact packet

Give privacy reviewers a short, structured account containing:

• What happened, and which observations confirm it.
• Affected systems, services, and responsible providers.
• Personal data categories and categories of affected people.
• Approximate numbers of people and records, with the counting method.
• Exposure period, known recipients, and possible access paths.
• Relevant protections, including encryption and key access.
• Known or plausible consequences for people.
• Measures already taken and the questions still unresolved.

Separate confirmed facts, supported estimates, and hypotheses. “No export event appears in the available audit log” is narrower than “no data was accessed.” State log coverage and retention gaps so reviewers understand what the evidence cannot establish.

Maintain a questions queue

Give each unresolved question an owner and a next review time. Prioritize questions capable of changing the decision: whether an exposed object contained personal data, whether an attacker accessed encryption keys, or whether unavailable records affected essential services.

Other questions, such as the precise initial exploitation technique, may matter greatly to remediation without being necessary for the first notification. Keeping those tracks separate prevents technical curiosity from delaying legal action.

A current system and data inventory makes this work faster. Data discovery for privacy provides the context needed to translate “storage service compromised” into identifiable data categories, processing purposes, and affected populations.

Assess harm to people, not just impact on the business

The Article 33 exception is that risk to rights and freedoms is unlikely. It is not a rule that only large breaches, special-category data, or proven harm must be reported.

Assess both the likelihood and severity of possible consequences. A small disclosure can be serious, while a larger incident may have effective protections that materially reduce risk. Document why the circumstances support the conclusion.

Consider these dimensions together:

Encryption requires technical scrutiny. A disk encrypted at rest does not necessarily protect information accessed through a compromised application account. Establish the encryption layer, key separation, attacker permissions, and whether usable plaintext was available. The same reasoning applies to hashed credentials: their protection depends on the method and circumstances, not the label “hashed.” See encryption and key management.

A recipient’s deletion confirmation can be relevant, especially for an accidental disclosure to a known, cooperative recipient. It is not universal proof that risk disappeared. Consider whether the content was viewed, copied, forwarded, or accessible through another channel.

Avoid turning a numerical risk score into an automatic legal conclusion. A scoring matrix can make reasoning consistent, but reviewers still need to explain the actual consequences and uncertainties. Business downtime, revenue loss, and reputational damage to the organization belong in operational incident management; they do not substitute for assessing effects on individuals.

Reassess when new facts arrive. Discovering sensitive attachments or attacker access to keys can change an initially reasonable non-notification decision.

Make two separate communication decisions

Notification to the authority and communication to affected people have different thresholds. Record both decisions explicitly, including when neither is required.

Notify with what is known

Article 33 requires the notification to describe the nature of the breach, including, where possible, the categories and approximate numbers of affected people and records. It must also provide a DPO or other contact, describe likely consequences, and describe measures taken or proposed, including mitigation where appropriate.

Do not wait for exact counts if reliable estimates and clear qualifications are available. Article 33(4) allows information to be supplied in phases where it cannot be provided at the same time, without undue further delay. Keep a submission copy, receipt, reference number, and a list of promised updates.

If notification is later than 72 hours, provide reasons for the delay. Missing the deadline does not remove the obligation. Explain the actual chronology rather than offering a generic statement that the investigation was complex.

Confirm the competent authority and reporting channel early, particularly for cross-border processing. Do not assume that the authority in the server’s location is the correct recipient.

Communicate when high risk is likely

Article 34 GDPR requires clear and plain-language communication to affected people without undue delay where high risk is likely. Its content includes the nature of the breach, contact details, likely consequences, and relevant measures.

Explain what people can do: for example, change an affected password, reject suspicious payment instructions, or use a verified support channel. Do not imply that precautionary advice transfers responsibility to them.

Article 34 includes exceptions for effective measures rendering data unintelligible to unauthorized people, subsequent measures ensuring high risk is no longer likely to materialize, and disproportionate effort. The last requires public communication or a similarly effective measure; it is not permission to remain silent. The authority may require communication or assess whether an exception applies.

Handle processor incidents without losing control of the assessment

A processor must inform the controller without undue delay after becoming aware of a personal data breach. It should not wait for its own conclusion that supervisory notification is necessary. The controller’s assessment must not be replaced by a supplier’s “low risk” label.

Request evidence relevant to your processing: affected tenant or account, data categories, exposure period, access evidence, protections, containment, and unresolved questions. A provider-wide incident statement may not establish which of your records were affected.

Vendor delay does not mechanically consume a controller’s 72-hour period before the controller becomes aware. It can nevertheless delay protective action, obscure the chronology, and raise questions about compliance with processor duties. Record when the supplier detected the incident, established awareness, and informed you.

As a practical contractual recommendation, specify operational contacts, rapid initial notice, minimum information, continuing updates, and assistance with investigation and communications. These arrangements should support, not replace, the Article 28 requirements.

Where your organization is both a processor for customers and a controller for employee data, make separate role-based decisions. A shared technical incident can require customer notices in one capacity and supervisory assessment in another.

Keep a decision trail that survives the incident

Article 33(5) requires documentation of personal data breaches, including their facts, effects, and remedial action, enabling the supervisory authority to verify compliance. This includes breaches that were not notified.

A useful incident record contains:

• Incident identifier, scope, coordinator, and processing role.
• Occurrence, detection, awareness, and escalation timestamps.
• Evidence references and the limits of available telemetry.
• Risk assessment, reviewer, decision owner, and decision times.
• Separate authority-notification and individual-communication conclusions.
• Submitted communications, acknowledgments, and subsequent updates.
• Containment, recovery, and preventive actions with owners.
• Closure review and reasons for any remaining uncertainty.

For non-notification, write the reasoning, not merely “below threshold.” Identify the facts supporting why risk was unlikely and what evidence would trigger reassessment.

Preserve successive assessments. An early conclusion can have been reasonable on the available evidence even if later findings change it. Overwriting the earlier version hides that chronology.

Set access and retention arrangements deliberately. Article 33 does not provide a universal retention period for breach records. Choose a justified schedule considering accountability, applicable obligations, and data minimization. Where possible, retain evidence references rather than duplicating extensive personal datasets.

Notification is not immunity from scrutiny. Authorities may request clarification and examine security measures or other obligations. Equally, avoid treating notification as a reason to postpone containment while waiting for regulatory instructions.

Worked example: an exposed recruitment export

This example is illustrative; its times and numbers are assumptions, not reported results.

Assume an organization discovers on Friday at 16:00 that a recruitment export may be accessible through a public storage link. The file contains 240 applicants’ names, contact details, application notes, and some attachments. At 16:20, an engineer confirms unauthenticated access and verifies that the file contains personal data. The coordinator records 16:20 as the supported awareness point. The 72-hour reference point is Monday at 16:20, although notification must still proceed without undue delay.

By 16:35, the team has removed public access and preserved configuration history and available access logs. Those logs cover only part of the exposure period. The team cannot responsibly conclude that nobody accessed the file.

The first assessment identifies possible targeted phishing and disclosure of confidential employment intentions. Attachment contents remain uncertain. Privacy reviewers and the decision owner conclude that risk is not unlikely, so supervisory notification is required. They separately assess whether high risk is likely; the number of applicants alone does not answer that question.

The initial notification describes the confirmed exposure, approximate scope, incomplete log coverage, known consequences, and containment. It states that attachment review is ongoing and identifies the person responsible for supplying updates.

On Saturday, review finds that a subset of attachments contains health information. The team revisits the high-risk assessment and determines that communication is required for that affected group. Messages describe the relevant exposure and practical precautions without revealing other applicants’ information.

The completed record preserves both assessments, the supporting evidence, submission receipts, and corrective tasks. Follow-up includes export approval controls, public-access prevention, appropriate logging, and testing that recruitment files are no longer publicly reachable.

The lesson is operational: uncertain attachment contents did not prevent an initial notification, and later findings changed the individual-communication decision without invalidating the earlier evidence-based assessment.

Track other reporting duties on the same timeline

The same incident may trigger GDPR, contractual, sector-specific, and cybersecurity reporting. Use one factual chronology but separate obligation assessments, recipients, owners, and deadlines.

NIS2 Article 23 addresses significant incidents for covered entities, whether or not personal data is involved. Its EU reporting structure includes a 24-hour early warning, a 72-hour incident notification, and generally a final report within one month of the notification. NIS2 is implemented through national law: check applicability, national procedures, and relevant sector rules rather than assuming every organization has these duties.

For covered financial entities, DORA can provide sector-specific requirements. Do not duplicate reporting automatically or treat one submission as satisfying every regime.

Contractual customer notice may also be required even where supervisory notification is not. Maintain a reporting matrix identifying the source, trigger, recipient, accountable owner, submission route, and evidence of completion for each applicable obligation.

Prepare the handoffs before the next incident

A practical readiness test is a Friday-afternoon exercise using a misdirected email, compromised provider, or ransomware scenario. Ask participants to produce the actual first fact packet and decision record, not simply describe the policy.

Check whether the team can:

• Reach the coordinator, privacy adviser, decision owner, and deputies.
• Identify relevant data and providers from existing inventories.
• Preserve logs before restoration or retention limits remove them.
• Access the correct authority reporting channel.
• Draft a phased notification with clearly marked unknowns.
• Communicate securely with customers and affected people.
• Record a non-notification decision and schedule reassessment.

Where an answer depends on finding an unknown person or recovering inaccessible credentials, create a readiness task. CISO and DPO responsibilities should be clear enough that technical fact-finding and independent privacy advice can proceed together.

Secani can support the reviewable compliance record around this work. Model the affected systems and providers as target objects, connect evidence to relevant requirements and decisions, and assign owners to follow-up tasks. Its connected evidence and review workflows support source links, comments, approvals, and timestamps. Treat AI-assisted summaries as drafts requiring human review; keep containment and forensic investigation in operational systems and link their evidence into the decision trail.

Questions that arise during response

Can we wait for a deletion confirmation before deciding?

Seek it promptly, but continue the assessment in parallel. Its significance depends on the recipient, content, and possible onward access. An unanswered request is not evidence that exposure has ended.

What if the reporting portal is unavailable?

Record attempts and seek the authority’s published alternative contact route. Preserve the information ready for submission and explain any resulting delay. A technical submission problem should not stop assessment or necessary communication to people.

When can the incident be closed?

Operational recovery and privacy closure are separate milestones. Confirm that required notices and updates are complete, residual questions have an owner, and corrective actions remain tracked. As a practical next step, test one recent non-notified case against the record checklist: if another reviewer cannot reconstruct the decision, improve the handoff before the next incident.