What Happens When You Get a Data Breach in 2026

The breach response sequence begins with two questions that must be answered within the first hours of incident detection. The first is whether personal data is involved , and this question must be answered conservatively, treating ambiguous situations as personal data involvement until evidence clearly establishes otherwise. Personal data under GDPR Article 4 is any information relating to an identified or identifiable natural person, a definition broad enough to capture IP addresses, device identifiers, behavioral data, and pseudonymized data that can be re-identified when combined with other information the controller holds. The second question is whether the breach can be fully contained within 24 hours. This is not a question about whether containment can begin within 24 hours , it is a question about whether the threat can be fully neutralized and the attack vector closed within that window. If the answer is no, or if there is meaningful uncertainty, the correct path is immediate escalation to the DPO or legal counsel and initiation of the regulatory assessment track in parallel with ongoing technical containment.

Documentation must begin at the moment of detection, not at the moment the breach is fully understood. GDPR Article 33(5) requires controllers to document any personal data breaches, including the facts relating to the breach, its effects, and the remedial action taken , and this documentation obligation applies regardless of whether the breach ultimately meets the threshold for supervisory authority notification. ISO 27001:2022 Control 5.26 on response to information security incidents and Control 5.28 on collection of evidence provide the management system framework for building the documentation discipline that this regulatory obligation requires. Organizations that reconstruct their breach timeline after the fact from system logs and email threads rather than maintaining a contemporaneous incident log from the point of detection consistently produce notification documentation that contains internal inconsistencies , inconsistencies that supervisory authorities treat as indicators of inadequate incident response governance rather than as honest reconstruction artifacts.

The regulatory assessment phase activates when personal data involvement is confirmed and resolves into jurisdiction-specific notification obligations based on the population of affected data subjects. The EU resident question triggers GDPR Article 33 supervisory authority notification within 72 hours and, where the breach is likely to result in high risk to the rights and freedoms of natural persons under Article 34, direct notification to affected individuals without undue delay. The 72-hour clock is measured from awareness, and supervisory authorities have consistently interpreted awareness as the point at which the organization has sufficient information to know a breach affecting personal data has occurred , not the point at which the full scope is quantified. GDPR Recital 87 establishes that the controller should verify whether all appropriate technical protection measures were implemented and should use those measures to assess whether a notification to the supervisory authority is necessary, but this verification does not pause the notification timeline. Incomplete notifications submitted within 72 hours with a follow-up supplement as additional information becomes available are explicitly contemplated by Article 33(4) and are far preferable to complete notifications submitted after the deadline.

Thailand Personal Data Protection Act notification obligations run on the same 72-hour timeline as GDPR but are administered by the PDPC , the Personal Data Protection Committee , rather than by EU supervisory authorities. The Thailand PDPA, which reached full enforcement in June 2022, applies to any organization that collects, uses, or discloses personal data of data subjects located in Thailand, including organizations headquartered outside Thailand that process Thai resident data. The PDPA breach notification requirement under Section 37 requires the data controller to notify the PDPC within 72 hours of becoming aware of the breach unless the breach is unlikely to result in risk to the rights and freedoms of individuals , a risk threshold assessment that mirrors GDPR Article 33(1) language but is assessed independently by the PDPC under Thai law. For organizations operating across both EU and Thai data subject populations, the 72-hour notifications to the EU supervisory authority and the PDPC are separate filings with different content requirements, different notification portals, and different supervisory authority relationships , a dual-track notification process that must be coordinated simultaneously.

HIPAA breach notification obligations under 45 CFR Part 164 Subpart D apply when the breach affects protected health information , individually identifiable health information held by a HIPAA covered entity or business associate. The HIPAA notification timeline is structurally different from GDPR and PDPA: covered entities must notify HHS and affected individuals within 60 calendar days of discovery of the breach, with media notification required when more than 500 residents of a single state or jurisdiction are affected. Business associates must notify the covered entity within 60 days, with the covered entity notification clock to individuals running from the covered entity discovery date rather than the business associate discovery date. The HIPAA Breach Notification Rule distinguishes between breaches and security incidents that do not constitute breaches , specifically, the Rule provides that impermissible uses or disclosures of PHI are presumed to be breaches unless the covered entity or business associate demonstrates through a four-factor risk assessment that there is a low probability that the PHI has been compromised. That four-factor risk assessment , evaluating the nature and extent of PHI involved, the unauthorized person who used the PHI, whether the PHI was actually acquired or viewed, and the extent to which risk has been mitigated , must be documented as the basis for any decision not to provide HIPAA breach notification.

PCI DSS breach response obligations activate when payment card data is confirmed or suspected to be in scope of the breach , and the PCI DSS response track operates on a faster timeline than any of the regulatory notification frameworks. PCI DSS Requirement 12.10.5 mandates that the incident response plan include alerts from security monitoring systems and escalation procedures, but the card brand response obligation is contractual rather than regulatory , it flows from the merchant or service provider agreement with the acquiring bank, which incorporates card brand operating regulations by reference. Visa and Mastercard operating regulations require merchants to notify their acquiring bank immediately upon confirmation or reasonable suspicion of a compromise of cardholder data, and the acquirer is responsible for notifying the card brands. The practical consequence is that PCI DSS breach response operates on an hours timeline, not a days timeline , the acquirer notification obligation is effectively immediate, which means the forensic investigator engagement and card brand notification must be initiated before the GDPR 72-hour clock has expired in many breach scenarios.

PCI DSS v4.0.1 Requirement 12.10.4 requires that incident response personnel receive training at least once every 12 months, and Requirement 12.10.6 requires that the incident response plan be modified and evolved to incorporate lessons from previous incidents and industry developments. The forensic investigation requirement , engaging a PCI Forensic Investigator from the PCI SSC approved PFI list , applies when card brands determine that a forensic investigation is necessary, which in practice means any confirmed or suspected account data compromise triggers PFI engagement. PFI engagements are conducted under card brand rules rather than client direction, and the PFI report is delivered to the card brands rather than exclusively to the breached entity , a structural feature of PCI forensic investigation that many organizations discover for the first time during an actual breach. Organizations that have pre-selected a PFI and established the engagement parameters before a breach occurs are significantly better positioned than those who begin PFI selection under breach conditions, because PFI capacity is limited and response times are contractually defined for organizations with pre-established relationships.

The decision to notify affected individuals directly , as distinct from notifying regulatory authorities , is determined by a harm probability assessment that each regulatory framework structures differently. Under GDPR Article 34, individual notification is required when the breach is likely to result in high risk to the rights and freedoms of natural persons. The Article 29 Working Party guidance, now maintained by the European Data Protection Board through Guidelines 9/2022 on personal data breach notification, identifies factors that elevate breach risk to the high risk threshold: the nature of the personal data involved, including special category data under Article 9 such as health data, biometric data, racial or ethnic origin data, and political opinions; the volume of affected records; the ease of identification of individuals from the compromised data; the severity of consequences including financial harm, reputational damage, discrimination risk, and physical harm; and whether the data has been accessed by unauthorized parties with the capacity and apparent intent to misuse it.

When the regulatory assessment determines that individual notification is not required , because the breach does not meet the high risk threshold, or because the data was encrypted with keys not compromised in the breach, or because the HIPAA four-factor risk assessment concludes low probability of PHI compromise , the decision not to notify must be documented with the specific rationale that supports it. This documentation is not optional governance hygiene: it is the evidentiary record that demonstrates the organization applied the required regulatory analysis rather than simply choosing not to notify. GDPR Article 33(5) documentation obligations apply to breaches that do not meet the notification threshold as well as those that do, and the EDPB has been explicit in enforcement decisions that undocumented decisions not to notify are treated as evidence of inadequate breach response governance rather than as legitimate exercise of the regulatory exception. The documented decision not to notify , with a completed risk assessment, identified rationale, and approval by the DPO or legal counsel , is as important a compliance artifact as the notification itself.

The post-breach requirements sequence , root cause analysis, evidence preservation, control remediation, incident response plan update, and staff retraining , represents the compliance obligations that determine whether a breach is genuinely closed or merely contained. Root cause analysis is not optional following a significant breach: GDPR Article 32 requires that controllers implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, and a breach that is not followed by documented root cause analysis and remediation provides supervisory authorities with evidence that the controller failed to maintain appropriate security rather than that the controller experienced an unavoidable incident. NIST SP 800-61 Rev 2, the Computer Security Incident Handling Guide, provides the methodological framework for root cause analysis that most compliance practitioners reference, and the root cause documentation produced under this framework serves as both the internal remediation driver and the regulatory evidence that the organization has addressed the vulnerability that enabled the breach.

Evidence preservation must be initiated before remediation begins , a sequencing requirement that creates practical tension in breach response because the instinct of technical teams is to remediate the vulnerability as quickly as possible. Forensic evidence that is overwritten during remediation is unrecoverable, and its absence can prevent both the root cause analysis from reaching accurate conclusions and the organization from establishing facts that limit regulatory liability. ISO 27001:2022 Control 5.28 on collection of evidence and NIST SP 800-86, the Guide to Integrating Forensic Techniques into Incident Response, provide the procedural framework for evidence preservation that must be completed before system restoration begins. Staff retraining as a post-breach requirement is not a generic cybersecurity awareness refresher , it is targeted retraining on the specific control failure or human behavior that the root cause analysis identified as a contributing factor, documented in a way that demonstrates the organization addressed the human element of the breach rather than treating it as purely a technical failure.