How to Build 72-Hour Data Breach Notification Readiness

Short answer: Data breach notification is not a legal formality; it is an engineering capability. The 72-hour window for notifying Türkiye's data protection authority (KVKK) starts not when the breach happens, but when the data controller learns of it, and in practice the real problem is that learning takes weeks. Readiness rests on three pillars: 24/7 detection capability, a written and rehearsed response plan, and notification obligations built into supplier contracts. Without all three, the 72 hours run out before the first meeting is even scheduled.

Twelve notices in a single day: the anatomy of September 16

On September 16, 2026, KVKK published data breach notices for 12 companies in a single day. As reported by Turkish Minute, the number of affected individuals exceeded 10.2 million: Eve Kozmetik alone topped the list with 6,263,305 people, followed by Shaya at 2,298,726 and Deniz Deniz at 1,271,096. The exposed data included names, email addresses, phone numbers and, in some cases, home addresses and account authentication details.

The wave did not stop there. According to a compilation by Turkish lawyer Özgür Eralp, the number of companies filing notices reached 28 within the same week, with roughly 10.4 million individuals affected. The common denominator was striking: most of the breaches traced back to a vulnerability in a third-party software library used across multiple e-commerce platforms.

The episode confirmed once more that supply chain risk is no longer a theoretical topic in Türkiye. We covered that dimension earlier in our piece on supply chain security and KVKK liability. This article is about the other side of the coin: the clock that starts ticking once the breach is in.

The clock starts at discovery, not at the breach

KVKK's Board decision 2019/10 clarifies what the law's "as soon as possible" means: the data controller must notify the Board without delay and within 72 hours at the latest, counted from the moment it learns of the breach. Affected individuals must be informed within the shortest reasonable time, directly where contact details are known, or through channels such as the company website where they are not. The same decision requires every data controller to maintain a written data breach response plan and review it regularly.

The critical detail is this: the clock starts at discovery, but the time that actually gets lost is the period before discovery. The Samsonite Türkiye case from the September wave illustrates it well: the breach took place on August 15-19, yet the company only learned of it from its e-commerce infrastructure provider on September 10. That is roughly four weeks during which the attacker could do whatever they wanted with the data.

Even that is optimistic by global standards. According to IBM's 2026 Cost of a Data Breach report, identifying and containing a breach takes 247 days on average, and the global average cost per breach has climbed to 4.99 million dollars. The same report finds that organizations making extensive use of security AI and automation cut breach costs by about 1.93 million dollars and shorten the breach lifecycle by 65 days. Detection capability is an investment that converts directly into money.

Two regulators, two clocks: KVKK and Law 7545

Türkiye's Cybersecurity Law No. 7545, which entered into force in 2025, added a second notification track to the equation. According to an assessment of the law's status in 2026, organizations in scope must report vulnerabilities and cyber incidents to the Cybersecurity Directorate immediately, while a significant part of the procedures still awaits secondary legislation. The 2026 penalty for failing to meet reporting and security-measure obligations ranges from 1.25 million to 12.55 million Turkish lira.

The sanctions table on the KVKK side has been updated as well. With the 2026 revaluation rate applied, a data controller that violates its data security obligations faces administrative fines between 256,357 and 17,092,242 Turkish lira. In other words, in any incident involving personal data, the enterprise IT team must be able to answer to two separate regulators, in two separate formats, within the same 72-hour window.

The practical consequence: the notification process cannot be handed to the legal department as a single "compliance file." Which incident gets reported to which authority, at which threshold and with what content must be defined in advance, and the technical team must keep its logging, inventory and impact-analysis infrastructure ready to feed that definition.

What actually has to fit into 72 hours

Slice the window from a CTO's perspective and the picture sharpens. The first hours go to verifying and classifying the incident: is it a real breach, a false alarm, is personal data affected? Then comes scoping: which systems, which data categories, how many individuals? The KVKK notification form asks exactly these questions; it wants the timeline of discovery, containment and notification, the number of affected records, and the measures taken.

The good news is that decision 2019/10 allows information to be provided in stages: if the full picture is not clear within 72 hours, you can file with what you have and complete the rest later. The bad news is that this flexibility is worthless against an undetected breach. If your logs do not go back 30 days, if you cannot show which tables were accessed, you cannot fill in even the first stage of a staged notification.

The September wave carries a communication lesson too. In the Samsonite case, the data categories in KVKK's notice did not match the company's own statement to its customers; the regulator listed phone numbers and account authentication data, while the company mentioned only names and email addresses. Inconsistent communication can leave a more lasting dent in trust than the breach itself.

The readiness checklist: five building blocks

You build 72-hour capability in calm times, not on the day of the crisis. The minimum structure we see working in the field:

• 24/7 detection and response. Learning about a breach from third parties weeks later is the most expensive version of this process. Make monitoring continuous through a SOC or a managed MDR service; per Verizon's 2026 DBIR findings, 48 percent of breaches now involve a third party, and vulnerability exploitation became the number one entry vector at 31 percent, overtaking stolen credentials for the first time.
• A written, rehearsed response plan. Decision 2019/10 already mandates one; the difference shows when the plan is tested through tabletop exercises. See our comparison of paper plans versus real testing for why that distinction matters.
• Data inventory and log coverage. Impact analysis is impossible without knowing which personal data category lives in which system. Set log retention periods long enough to survive a realistic discovery delay.
• Notification clauses in supplier contracts. In the September wave, most companies learned of the breach not from their own systems but from their platform provider. If the contract does not specify a concrete notification deadline, a communication channel and a log-sharing obligation, your 72 hours are at your supplier's mercy.
• Pre-approved communication templates. Keep legally cleared drafts ready for the regulator filing, the customer announcement and the press statement. Debating wording mid-crisis is the most expensive way to lose time.

Three actions for Monday morning

You can start this week with three concrete tasks. First, a one-question test: "From the moment we learn of a breach to the regulator filing, who executes which step, in what order?" If the answer lives in one person's head, there is no plan. Second, pull the notification clauses from your e-commerce and SaaS supplier contracts and check whether they contain a deadline and a channel. Third, if it has not happened in the last 12 months, schedule a tabletop exercise built around a scenario involving personal data.

The most uncomfortable part of the September wave was that most of the affected companies ended up on the list not because of their own vulnerability, but because of a component everyone uses. Nobody knows which library the next wave will come from; but knowing when the clock will start that day, and who does what in the first 72 hours, is entirely within your control.