Data Breach Notification: Timelines, Evidence, and Response Plan

A data breach is not only an IT problem. Once personal data is involved, the incident becomes a legal, regulatory, contractual, operational, and reputational event. The same incident may require forensic work, regulator notification, customer notice, employee communication, law enforcement review, vendor coordination, cyber-insurance notice, and board reporting.

This guide belongs to the Kurums Law department and its Data Privacy and KVKK pillar. It explains how businesses should prepare for and manage personal data breaches under GDPR, KVKK, and related privacy regimes. It is written for legal teams, compliance officers, security leaders, executives, HR teams, and anyone responsible for incident escalation.

What is a data breach?

A data breach is a security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. The breach does not need to involve hackers. A misdirected email, lost laptop, exposed cloud bucket, rogue employee, ransomware attack, deleted HR file, or unauthorized vendor export can all qualify.

Privacy law looks at the effect on personal data, not only the technical cause. A system outage can be a breach if it affects availability of personal data in a way that risks individuals. Unauthorized alteration can be serious even if no data was stolen. A breach response plan must therefore cover confidentiality, integrity, and availability.

What should happen in the first 24 hours?

The first 24 hours should focus on escalation, containment, evidence preservation, preliminary classification, and notification deadline analysis. The company does not need perfect facts immediately, but it does need a disciplined process.

1. Activate the incident team – legal, security, IT, privacy, communications, business owner, and vendor manager.
2. Contain the incident – revoke access, isolate systems, disable exposed links, rotate credentials, or pause integrations.
3. Preserve evidence – logs, access records, emails, tickets, screenshots, configuration records, and forensic images where needed.
4. Identify affected data – categories, volume, sensitivity, jurisdictions, and affected individuals.
5. Classify legal roles – controller, processor, service provider, employer, customer, vendor, or joint controller.
6. Start deadline tracking – regulator, customer, insurer, and contractual notice windows.

How do you assess whether notification is required?

Notification analysis turns on risk: what data was affected, who was affected, what harm could result, whether data was protected, and whether the exposure was contained. Different laws use different thresholds and timelines, but the same facts usually matter.

What are GDPR and KVKK breach notification duties?

Under GDPR, controllers generally must notify the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal data breach that is likely to result in risk to individuals. If the breach is likely to result in high risk, affected individuals may also need notice.

KVKK has its own breach notification practice and authority expectations. Companies processing Turkish personal data should assess Turkish notification duties separately rather than assuming a GDPR analysis is enough. Multinational incidents may require parallel notifications in multiple jurisdictions, customer notices under DPAs, and insurer notice under cyber policies.

What should a breach response plan include?

A useful breach response plan assigns roles, defines escalation triggers, creates decision templates, maps notification duties, and integrates legal review with technical response. It should be short enough to use in a real crisis but detailed enough to prevent improvisation.

• Incident severity levels and examples.
• Contact list for legal, privacy, security, IT, communications, HR, procurement, and leadership.
• Evidence preservation checklist.
• Risk assessment template.
• Regulator and individual notification decision tree.
• Customer and vendor notification obligations.
• Cyber insurance notice procedure.
• Approved communications process.
• Post-incident remediation and lessons-learned process.

How should processors and vendors handle breaches?

Processors should notify controllers promptly after becoming aware of a personal data breach and provide enough detail for the controller to assess legal duties. This is why breach clauses in data processing agreements matter. A vague vendor notice can cost the controller precious time.

Vendor incident contracts should address timing, content, cooperation, evidence, updates, root cause analysis, remediation, customer communications, and allocation of costs. Customers should also know which vendors hold sensitive or large datasets so they can prioritize incident escalation.

How should breach communications be managed?

Breach communications should be accurate, coordinated, legally reviewed, and tailored to the audience. A regulator notice, customer notice, employee message, press statement, and internal executive update do not serve the same purpose. The regulator needs facts, risk assessment, and remediation. Affected individuals need understandable guidance about what happened and what they should do. Customers need contractual and operational impact information. Employees need escalation discipline and clear instructions.

The most damaging communication errors are speculation, blame before facts are known, inconsistent numbers, overpromising remediation, and sending notices before legal privilege and evidence preservation have been considered. Communications should use approved fact statements, version control, and a single owner. If the company later updates its understanding, the update should explain what changed and why.

What happens after notification?

The breach response is not complete when notices are sent. The company must remediate root causes, monitor for misuse, answer follow-up questions, handle data subject requests, support customers, update regulators if required, and document lessons learned. The post-incident phase is where companies either reduce future risk or repeat the same failure.

A post-incident review should identify technical causes, process gaps, vendor failures, delayed escalations, unclear ownership, missing logs, weak access controls, and training failures. The output should be a remediation plan with owners and deadlines. Common remediation actions include multi-factor authentication, privilege review, encryption, data minimization, retention cleanup, vendor contract updates, monitoring improvements, and tabletop training.

How should breach readiness be tested?

Breach readiness should be tested through tabletop exercises that simulate realistic incidents. A useful scenario includes incomplete facts, vendor delays, executive pressure, unclear data categories, and conflicting notification deadlines. The test should force the team to practice escalation, containment, evidence preservation, notification analysis, communications approval, and customer response.

After the exercise, update the response plan based on what failed. If no one knew who owned regulator notice, if vendor contracts had no emergency contact, or if logs could not identify affected users, the test has done its job. The purpose is not to perform perfectly; it is to discover weaknesses before a real incident.

Common breach response mistakes

The most common breach mistakes are procedural rather than technical. Companies wait too long to escalate, let IT remediate before preserving evidence, fail to identify legal roles, notify customers with incomplete or inconsistent facts, or treat a vendor incident as someone else’s problem. Another common failure is not involving communications early enough, which leads to rushed notices written under pressure.

A disciplined company keeps one source of truth for the timeline, one approved fact set, one legal owner for notification analysis, and one communications owner for external language. This does not slow the response. It prevents the confusion that creates regulatory and reputational damage after the technical issue has already been contained.

How do contracts and insurance affect breach response?

Many breach deadlines come from contracts and insurance policies, not only privacy statutes. A customer DPA may require notice within 24 or 48 hours. A SaaS agreement may require cooperation, root cause reports, or customer-specific remediation. A cyber insurance policy may require immediate carrier notice and approved forensic vendors before certain costs are covered.

The incident team should therefore review customer contracts, vendor contracts, cyber policies, employment obligations, and sector rules at the same time as GDPR or KVKK notification duties. Missing a contractual notice can create a commercial dispute even when regulator notification is not required.

Keep these notice obligations in the breach playbook, not buried in contract folders.

Frequently Asked Questions