A personal data breach is not only the capture of a database in a cyberattack. Depending on the circumstances, an email sent to the wrong recipient, an employee accessing records outside their authorisation, lost paperwork, a disclosed system password or personal data being unavailable when needed may also amount to a breach.

In such a situation, the legal assessment, notification deadlines and proper record-keeping are just as important as the technical measures taken in the first hours.

Is every security incident a personal data breach?

First, it must be determined whether the incident affects the confidentiality, integrity or availability of personal data. If the affected records contain no information relating to identified or identifiable natural persons, the incident may remain within a different information security process.

If there is a possibility that personal data has been unlawfully obtained, disclosed, altered, deleted or made inaccessible, the incident must be assessed under the Law on the Protection of Personal Data No. 6698 (KVKK).

The review should not be reduced to the question “Did the data leave the organisation?” The fact that an unauthorised person was able to view the data may create a risk even if it has not been established whether they copied it.

What should be done in the initial response?

Once a suspected breach becomes known, the priority is to prevent the damage from growing. Access to the relevant account may be restricted, compromised sessions may be closed, passwords and access keys may be renewed, an erroneous disclosure may be withdrawn or the affected system may be disconnected from the network.

The measure to be taken should be chosen so as to reduce the risk without unnecessarily halting business continuity. It is important that the response is coordinated with the participation of the technical team, legal, management and the relevant business units.

Digital evidence should be preserved

During the response, the integrity of system logs, emails, devices and other digital evidence must be preserved. Rebuilding the system quickly or clearing the logs may make it impossible to understand the scope of the incident later.

An incident log should be kept showing who carried out which action and at what date and time. Confirmed findings, technical assumptions and matters still under investigation should be kept separate from one another.

The role of the processing service provider

The incident may have occurred at a cloud service, a software company, a call centre or another data processor (veri işleyen). When the data processor detects the breach, it must inform the data controller (veri sorumlusu) without delay.

Agreeing in advance in the contract on the notification method, the contact persons and the technical information the data processor must provide reduces lost time. However, a contract with a service provider does not remove the data controller’s obligations arising from the law.

The scope and risk of the breach should be determined

For a sound assessment, answers to the following questions should be sought as soon as possible:

When did the incident begin, when did it end and when was it discovered?
Which systems and business processes were affected?
Which categories of personal data were involved in the breach?
Approximately how many people and how many records were affected?
Are special categories of personal data, financial information or passwords involved?
Is it known who may have accessed the data?
How likely is it that the data will be misused?
Is there a risk of identity theft, fraud or reputational damage?
Is the data encrypted, and are the encryption keys secure?
What measures were taken to contain the incident?

This assessment must be made in writing and with reasons. It is also important to record the grounds for the decision in cases where it is decided not to notify.

The 72-hour deadline for notifying the Board

Article 12(5) of Law No. 6698 provides that, if processed personal data is obtained by others through unlawful means, the data controller must notify the data subject (ilgili kişi) and the Personal Data Protection Board (Kişisel Verileri Koruma Kurulu) of the situation as soon as possible.

By its decision dated 24 January 2019 and numbered 2019/10, the Personal Data Protection Board interpreted the phrase “as soon as possible” as without delay and at the latest within 72 hours from the time the breach becomes known.

The period is calculated not from the time all details of the breach have been established but from the date on which the data controller became aware of the breach. If the review cannot be completed within 72 hours, notification can be made with the information available, and new information can be provided in stages through follow-up notifications.

If notification could not be made in time for a justified reason, the reasons for the delay must also be explained in the notification to the Board.

What information should be given to the Board?

Notification should be made using the current Data Breach Notification Form (Veri İhlali Bildirim Formu) and the notification channel published by the Personal Data Protection Authority (Kişisel Verileri Koruma Kurumu). As far as possible, the notification should include the following information:

The time the breach occurred, was detected and became known,
The source of the breach and how it occurred,
The categories of persons and personal data affected,
The approximate number of persons and records,
The likely consequences of the breach,
The measures taken or planned,
The method of notifying the data subjects,
The details of a contact person for the matter.

Data subjects must also be notified

Notifying the Board does not in itself fulfil the obligation to inform the persons affected by the breach. Once the affected persons have been identified, they should be notified within the shortest reasonable time.

If the data subject’s contact address is available, notification can be made directly. If contact details are not available, suitable methods such as publishing an announcement on the data controller’s website may be used.

The notification must be clear and understandable; a general statement such as “a cyber incident has occurred” is not enough. It should state when the breach occurred, which categories of data were affected, the likely consequences, the measures taken and what the person can do to reduce their own risk.

For example, if passwords were affected, it may be recommended that the person change the password, check other accounts where the same password is used and be careful about suspicious messages.

Records of the breach should be kept

The data controller must record information about personal data breaches that occur within its organisation, their effects and the measures taken, and keep this information available for review by the Board when required.

The incident log, technical reports, decisions taken, notifications made, information given to data subjects and corrective actions should be kept in an orderly file.

A root cause analysis should be carried out after the breach

Once the incident is closed, simply fixing the technical vulnerability is not enough. The reason why the breach occurred should be identified, and access rights, retention periods, the backup system, supplier contracts, employee training and the incident response plan should be reviewed.

If necessary, the personal data processing inventory, the retention and destruction policy, privacy notices and internal security procedures should be updated.

If the breach relates to banking, payment services, health, electronic communications or another regulated sector, there may be other notifications to be made to sector regulators or judicial authorities in addition to the KVKK notification.

Why is a response plan prepared in advance important?

Trying to allocate tasks for the first time within the seventy-two-hour period may lead to a significant loss of time and information. It is useful for organisations to define the tasks of the technical team, legal, management and communications units before an incident occurs.

The notification obligations of data processors, the decision and approval chain, the Board’s notification form, a draft notification to data subjects and an internal contact list should be prepared in advance. Testing the plan through exercises at regular intervals makes it possible to identify gaps more quickly in a real breach.

Conclusion

Managing a data breach is not just a matter of filling in a notification form. Stopping the incident, preserving evidence, analysing the scope and risk, informing the Board and data subjects in time and taking measures to prevent a recurrence are complementary stages.

Since every breach differs in the data, group of persons and systems it affects, the process should be carried out according to the features of the specific incident and without delay.

In a security incident, the deadlines and notification obligations should be assessed separately, taking into account the time the incident became known and its effects.

Data Breach Notification Process under KVKK