Friday, 5:40 pm. A customer writes to the support team: while looking at their own order history they changed the number in the URL and saw someone else’s address, phone number and order contents. They’ve attached a screenshot.
The moment that message is read, a timer starts running for your company. 72 hours later — that is, Monday evening — you need to have notified Turkey’s Personal Data Protection Board (Kişisel Verileri Koruma Kurulu, “the Board”). You have a weekend ahead of you, you don’t know how long the vulnerability has existed, you don’t know how many people are affected, and you’re not sure whether your logs can tell you.
Breach response is not a skill you learn that Friday evening. This article covers how those 72 hours should go and — more importantly — what needs to be ready before that day arrives.
This article is for general information purposes only and does not constitute legal advice. In an actual breach, we recommend that you obtain legal support.
What Does the Law Say?
Article 12 of KVKK — Turkey’s Personal Data Protection Law No. 6698 — requires that where processed personal data is obtained by others through unlawful means, the data controller (veri sorumlusu) notify the data subject (ilgili kişi) and the Board of this as soon as possible. The Board made that wording concrete with its decision No. 2019/10 dated January 24, 2019:
- Notification to the Board is made without delay and within 72 hours at the latest from the moment the breach is learned of.
- Once the affected persons have been identified, the data subjects are also notified within the shortest reasonable time — directly if their contact details can be reached, and if not, through appropriate methods such as publishing on the website.
- If notification cannot be made within 72 hours, the reason for the delay is explained together with the notification.
- If all the information cannot be provided at the same time, notification in phases is possible.
- If the breach occurred at a data processor (veri işleyen), the data processor must notify the data controller without delay.
- The data controller must keep a record of breaches, their effects and the measures taken, and must prepare a response plan.
If a breach at a data controller established abroad affects people in Turkey, the same notification obligation applies.
When Does the Clock Start?
The period starts not when the breach occurred, but when it was learned of. That cuts both ways.
The good side: for a leak that began six months ago and that you noticed yesterday, the clock runs from yesterday.
The bad side: “learning” means the company learning, not the executive learning. That message landing in a support agent’s inbox, an odd log line a developer spotted, a warning email from a vendor — any one of these can start the clock. Information being passed around internally for three days is your problem, not the Board’s. That is why the first measure is organisational, not technical: everyone must know to whom, and through which channel, to report something suspicious.
A Breach Is Not Just “Getting Hacked”
A significant share of the breaches notified to the Board are not sophisticated attacks but ordinary mistakes:
- An email sent to the wrong recipient, or a bulk send done with CC instead of BCC
- An authorisation flaw — as in the example above, changing the number and seeing someone else’s record
- A storage bucket, backup file or admin panel left open to the internet
- The loss of an unencrypted laptop or phone
- A departing employee taking the customer list with them
- Ransomware — even if no data leaves, loss of availability is also a breach
- Access keys embedded in source code and pushed to a public repository
More than half of that list is preventable with basic engineering hygiene. On authorisation flaws specifically, see our web application security guide; this is one of the technical root causes that comes up most often in Board decisions.
The 72 Hours, Hour by Hour
Hours 0-4: Verify and contain
- Designate the incident lead and the core team (technical, legal, management, communications). Open a single communication channel.
- Start keeping a timeline. Who learned what, when, and what they did. This record is the backbone of both the notification and the investigation that follows.
- Verify the breach and stop the bleeding: close the vulnerability, revoke compromised credentials and keys, isolate the affected system.
- Do not destroy the evidence. Wiping and rebuilding the server is the most natural reflex and the most expensive mistake. Disk and memory images and log copies first; clean-up afterwards.
Hours 4-24: Determine the scope
The questions you need to answer are also the questions on the notification form:
- Which data categories were affected? Is there any special category data?
- How many people and how many records were affected?
- When did the breach start, and when did it end?
- Was the data only accessed, or was it copied, or altered?
- What is the root cause?
Your ability to answer these questions depends entirely on the logs you were keeping before the breach. If there are no access logs, or if they are deleted after 7 days, the honest answer to “how many people were affected?” becomes “we don’t know; we have to assume everyone was.”
Hours 24-48: Assess the risk, prepare the notification
Assess the possible consequences for the affected persons: identity theft, fraud, financial loss, reputational harm. This assessment is part of the notification to the Board, and it also determines what you will tell the data subjects.
Notification to the Board is made using the Personal Data Breach Notification Form on the website of the Personal Data Protection Authority (Kurum, “the Authority”). Even if you don’t have all the information, notify on time with what you have and complete it in phases. An incomplete but timely notification is always better than a complete but late one.
Hours 48-72: Notify
- Submit the notification to the Board.
- Prepare and send the notification to the data subjects. Under the Board’s decision No. 2019/271, this notification must be written in clear and plain language and must contain at a minimum: when the breach occurred, which data was affected, the possible consequences, the measures taken and the measures recommended, and the contact channels through which information can be obtained.
- Tell users the concrete things they can do: change your password, don’t trust messages of such-and-such a kind. “Your security is important to us” is not a measure.
After hour 72
Root cause analysis, permanent fixes, completing the breach record and — without fail — updating the response plan with what this experience taught you. The Board often asks for additional information and documents; your timeline comes in handy again here.
The Technical Groundwork That Makes 72 Hours Possible
Whether that weekend is manageable depends on engineering decisions made months earlier:
Centralised, immutable logs. Application, database and access logs should be collected in one place, stored in a way an attacker (or a malicious employee) cannot delete, and retained for a period measured in months.
A record of access to personal data. Not just “who logged in”, but “who viewed or exported which record, and when”. This is the log that answers the scope question.
Anomaly alerts. One account pulling 10,000 customer records in an hour, a bulk export at three in the morning, an admin login from an unusual country. Learning about the breach from your own alert rather than from a customer shrinks both the timeline and the damage.
A data map. An up-to-date inventory showing which personal data sits in which system. You should be able to answer “what was on this server?” in two minutes, not two days.
Encryption. A leak of data that was properly encrypted, and whose key was not compromised, seriously reduces the risk for the affected persons — and that feeds directly into your risk assessment and the Board’s assessment.
Tested backups. In a ransomware scenario, what matters is not that a backup exists but that restoring from it has been tried.
Key and password rotation. Can you change all API keys, database passwords and tokens within an hour? Most teams ask this question for the first time during a breach. For the infrastructure side, see our article on DevOps practices.
Data processor agreements. Do the contracts you have with your vendors state within how many hours they will notify you of a breach? If not, part of your 72 hours is not under your control.
Write the Plan, Then Test It
A response plan can be one page long: who decides, who gets informed, what happens in the first four hours, where the notification drafts live, who provides legal support. What matters is not its length but that it has been tested.
Run a two-hour tabletop exercise once a year: “Friday, 5:40 pm, this message came in. What do we do now?” In the first exercise almost every team discovers the same things: the logs don’t go back as far as assumed, nobody has ever opened the notification form before, and it isn’t clear who can be reached over the weekend. Learning these things in an exercise is cheap.
The Cost of Not Notifying
The administrative fine for breaching data security obligations is between 256,357 TL and 17,092,242 TL for 2026. There is a recurring pattern in Board decisions: as much as the breach itself, late notification, incomplete notification and failure to notify the data subjects at all are also sanctioned. Conversely, data controllers that act quickly and transparently and can document their measures are assessed in a noticeably better light.
As for concealing a breach, it almost never works: the data goes up for sale on a forum, an affected person files a complaint, or an employee talks. At that point you have both the breach and the failure to notify on your hands.
Are You Ready?
If you can give clear answers to these three questions today, you’re in good shape: Who reports a suspected breach, and to whom? Can you show who accessed a particular customer’s record in the last 90 days? When was your response plan last tested?
If the answers aren’t clear, the cheapest time to fix that is now. As part of our KVKK consulting, IWWOMI prepares the breach response plan, builds the logging and alerting infrastructure, and runs the exercise together with your team. If you’d like to talk through your current level of readiness, get in touch.
Sources: Board Decision No. 2019/10 on the Procedures and Principles of Personal Data Breach Notification · Board Decision No. 2019/271 on the minimum elements of the notification to be made to the data subject
