KVKK Technical Measures: Log and Access Record Checklist

This is an English adaptation of our Turkish article on KVKK technical measures, written for IT and compliance leads of foreign-owned companies that process personal data in Turkey. The official texts are in Turkish and are linked below; English terms are followed by the Turkish original in parentheses. This page is for information only and is not legal advice; consult your legal and information-security advisers on how the measures apply to your organisation.

Short answer

If your company processes personal data in Turkey (Türkiye), the Personal Data Protection Law No. 6698 (Kişisel Verilerin Korunması Kanunu, KVKK) applies to your Turkish entity. The parent company's nationality does not matter. This includes data about employees, customers and visitors; the entity typically acts as a data controller (veri sorumlusu). Article 12 obliges the controller to take "all necessary technical and administrative measures to ensure the appropriate level of security" to prevent unlawful processing of and unlawful access to personal data, and to ensure its preservation. The law does not list the measures one by one; the Personal Data Security Guide — Technical and Administrative Measures, April 2025 (Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler)), published by the Personal Data Protection Authority (Kişisel Verileri Koruma Kurumu), explains them.
In the Guide's table of technical measures, access security (authorisation matrix, authorisation control, user account management, encryption, current antivirus, firewalls) and logging/monitoring (access logs, log records, intrusion detection and prevention, penetration testing) sit side by side.
The Guide asks two things of logs: that records are kept ("regularly keeping records of all users' actions/transactions" — tüm kullanıcıların işlem hareketleri kaydı) and that records are looked at ("regularly checking security software messages, access control records and other reporting tools, and acting on the alerts from these systems").
In practice these two requirements are met by central log collection and monitoring (SIEM); Law 5651 access records are part of the same stream.

What are KVKK technical measures?

KVKK technical measures are the technical part of the "technical and administrative measures" that a data controller must take under Law No. 6698, art. 12/1. Their purpose is to prevent unlawful processing of and unlawful access to personal data and to ensure its preservation. The law does not enumerate them; the Authority's Personal Data Security Guide (April 2025), Table 4.1, lists the technical measure headings as: authorisation matrix (yetki matrisi), authorisation control, access logs, user account management, network security, application security, encryption, penetration testing, intrusion detection and prevention systems, log records, data masking, data loss prevention software, backup, firewalls, current antivirus systems, deletion/destruction/anonymisation, key management. This article focuses on the access security and log/monitoring subset.

For readers used to the GDPR: KVKK dates from 2016 (amended in 2024, notably on cross-border transfers) and is generally described as modelled on the EU's 1995 Data Protection Directive. It shares the basic vocabulary — controller (veri sorumlusu), processor (veri işleyen), data subject (ilgili kişi) — but it is not the GDPR; obligations, thresholds and procedures differ, and it applies independently of any GDPR compliance work done at group level.

What the law requires, what the Guide explains

KVKK art. 12/1 says the data controller must take all necessary technical and administrative measures to ensure the appropriate level of security in order to prevent unlawful processing of personal data, prevent unlawful access to personal data and ensure the preservation of personal data. Under art. 12/2, where a data processor (veri işleyen) is used, the controller and the processor are jointly responsible for security. Art. 12/3 adds that the controller must carry out or commission the necessary audits within its own organisation to ensure that the law's provisions are applied. Under art. 12/5, a breach must be notified to the data subjects (ilgili kişi) and to the Board (Kişisel Verileri Koruma Kurulu) as soon as possible. In its decision No. 2019/10 of 24 January 2019, the Board interpreted this as 72 hours for notifying the Board. Data subjects are informed within the shortest reasonable time once the affected persons are identified.

The Authority's Guide (April 2025) explains the measures under administrative (risk analysis, training, policies, data minimisation, processor relations) and technical (cyber security, monitoring, security of environments containing personal data, cloud, procurement/development, backup) headings and summarises the technical measures in Table 4.1. In the Guide's own words, "the view that full security can be achieved by using a single cyber-security product is not always correct"; the recommended approach is "applying a set of measures that are complementary in nature within a number of principles and are regularly checked".

Access security: what the Guide says

The Guide ties access to the principle of need to know: employees should be "granted access authorisation to the extent necessary for the work and duties they perform and for their authorities and responsibilities", and systems should be accessed with a username and password. Accordingly, controllers are advised to create an access authorisation and control matrix and to write and apply a separate access policy and procedure.

On passwords, the Guide recommends "combinations of upper- and lower-case letters, digits and symbols" instead of sequences related to personal information and easy to guess. It recommends two-factor authentication (iki kademeli kimlik doğrulama) for remote access, where needed, to personal data stored in the cloud (section 3.4); we recommend it for all remote access. Patch management and software updates, removal of unused software and services, up-to-date antivirus/antispam products, and — as "priority measures … against unauthorised access threats coming over the internet" — firewalls and gateways are listed in the same section as the password guidance (3.1).

In practice this maps to the following controls:

Measure in the Guide	What it means in practice	How it is evidenced
Authorisation matrix / authorisation control	Which role reaches which data; privileged accounts kept separate; a leaver's access is closed	Matrix document + periodic review of directory (Active Directory) group memberships
User account management	Personal accounts, no shared accounts, an inventory of service accounts	Account list, last-logon dates, record of disabled dormant accounts
Strong password; two-factor authentication for remote access to data stored in the cloud	Password policy; multi-factor authentication (MFA) on VPN, email and admin consoles	Policy settings, MFA records
Firewall, current antivirus, patching	Default deny, regular patching, current signatures	Rule-set review, patch report
Encryption	Encryption at rest and in transit; key management	Configuration records

The second and third columns are our recommendation, not wording from the Guide.

Log records and monitoring: what the Guide says

The Guide's section on "Monitoring Personal Data Security" notes that systems are exposed to attacks from inside and outside, that despite various indications this may go unnoticed for a long time, and that intervention may come late; to prevent this it asks for:

checking which software and services are running on the networks,
determining whether there is any intrusion or movement that should not exist on the networks,
"regularly keeping records of all users' actions/transactions (such as log records)",
reporting security problems as quickly as possible, and a formal reporting procedure for employees to report vulnerabilities in systems and services, or threats exploiting them.

It then adds: "regularly checking security software messages, access control records and other reporting tools, and acting on the alerts from these systems", regular vulnerability scanning and penetration testing against known vulnerabilities, and assessment according to the results.

In other words, the Guide expects logs to be reviewed, not just stored. "We keep records" is only half an answer; the other half is "we regularly review the records and act on alerts". The Guide gives no retention period for logs; the period is set in the personal data retention and destruction policy (saklama ve imha politikası) in proportion to the purpose. For internet access records under Law 5651, a company that gives staff or visitors internet access counts as a collective-use provider, and the period is two years. For collecting and retaining Law 5651 access records, see our 5651 logging service (in Turkish).

In practice the log-and-monitoring measure covers these sources: directory (logons, authorisation changes), server and application access records (who accessed what and when on systems that hold personal data), firewall and VPN records, endpoint security events. The Guide expects records to be checked regularly and alerts to be acted on. The usual technical way to meet that is to collect these records centrally, correlate them and route each alert to a named owner. Our article on a minimum SIEM and log architecture for KVKK describes the smallest set of components that does this for a small or mid-sized Turkish entity. You can run that collection, correlation and alerting in-house or use a managed SIEM service (in Turkish).

What logs are for at the moment of a breach

The Board's decision No. 2019/10 requires the Board to be notified within 72 hours of learning of the breach and asks that "information on data breaches, their effects and the measures taken be recorded" and kept ready for the Board's review. The answers to "which records were accessed, how many people are affected, since when?" are in the access and transaction logs. Without logs, or without monitoring, the breach is noticed late and its scope is written from guesswork.

Backup, processors and destruction

Backup. The Guide calls for data-backup strategies against ransomware; backups should be accessible only to the system administrator, and it sets the rule that "backups of data sets must be kept off the network".
Data processor. If IT services are outsourced (including log collection and monitoring), a written contract with the processor is advised, with a clause that the processor acts only on the controller's instructions and in line with the legislation, and complies with the retention and destruction policy. Under art. 12/2 of the law, responsibility for security is joint. For a foreign-owned company this also covers the group's own shared services abroad. A group SOC or log platform that processes personal data of the Turkish entity's employees, customers or visitors is typically a processor relationship to be documented. Its location also brings KVKK's cross-border transfer (yurt dışına aktarım) rules into play.
Destruction. The personal data retention and destruction policy sets "the maximum period necessary for the purpose for which they are processed"; expired records (logs included) are deleted, destroyed or anonymised.

Implementation checklist

Write the access authorisation and control matrix; compare directory groups with the matrix (quarterly).
Remove shared accounts; keep privileged accounts separate; run the leaver procedure.
Password policy + two-factor authentication on remote access.
Patch calendar; close unused services; antivirus/antispam current.
Collect the access and transaction logs of systems holding personal data centrally; add directory, firewall, VPN and endpoint records.
Assign an alert owner: who receives the alert, on which channel, within what time; keep a record of regular reviews.
Set a vulnerability-scanning and penetration-testing cadence; track findings to closure.
Keep backups off the network and test restores periodically.
Put processor contracts (including the log/monitoring provider and group shared services) in writing; know where the data is held.
Cover log records in the retention and destruction policy; destroy expired ones.

How voosec supports this

SIEM (Guide: regular checks of records and action on alerts): central, encrypted collection of logs from firewalls, servers and endpoints; detection and alerting through correlation rules. You follow the alerts in the console yourself (Visibility) or our 24/7 SOC team does (Managed SOC).
DomainGuard (Guide: the audit side of the authorisation-matrix and account-management measures): Active Directory and domain security auditing; detection of privileged accounts and weak configurations.
LogVault · 5651: tamper-evident, signed and timestamped retention of Law 5651 records over encrypted transport (add-on, scoped per device) — see Turkey's Law 5651 logging rules.
Data processing (Guide: the data-processor section): data is kept on infrastructure in Türkiye; customer data is separated by row-level security (RLS); the roles under KVKK are defined in a data processing agreement.

Frequently asked questions

Does KVKK make logging mandatory?

The law does not list the measures one by one; it says "all necessary technical and administrative measures". The Board's Guide counts regularly keeping transaction records and checking those records among the technical measures. Not keeping logs is therefore a hard position to defend under the measures obligation; the final assessment depends on your organisation's processing activities and your legal adviser.

Our group already complies with the GDPR. Does that cover KVKK?

Not automatically. GDPR work gives you a head start on principles and documentation, but KVKK is a separate law with its own controllers' registry (VERBİS), notification and transfer rules; the technical measures in the Guide must be assessed for the Turkish entity's systems.

How long should we keep the logs?

The Guide gives no period; you are expected to set one in your retention and destruction policy in proportion to the purpose. For internet access records under Law 5651, the period is two years; a company that gives staff or visitors internet access is a collective-use provider. Our article on KVKK log retention and integrity explains how to set and document a retention period for each log source, when expired logs must be destroyed and how to show that records were not altered after they were written.

Is it KVKK-compliant to obtain access logs from an external service?

Yes, as long as the data-processor rules are followed: written contract, processing on instruction, security measures, retention-and-destruction compliance and knowledge of where the data is held; if the provider or its infrastructure is outside Turkey, KVKK's cross-border transfer rules (art. 9) apply as well. Under art. 12/2 responsibility is shared, not transferred.

Sources

The official texts are in Turkish (mevzuat.gov.tr and kvkk.gov.tr). English translations in this article are unofficial.

This article is for general information and does not constitute legal advice. The official texts are in Turkish; where this page and the official text differ, the official text prevails.