Database Security and KVKK Technical Measures

Focusing on the database layer of legal compliance #

Turkey’s Personal Data Protection Law No. 6698 (KVKK) requires data controllers to take technical and organizational measures to safeguard personal data. In this context, we provide consulting and hands-on engineering support to implement the technical requirements at the database layer.

However, implementing technical database safeguards alone does not ensure overall corporate compliance. Data inventories, consent management, privacy notices, and internal administrative procedures must be completed in tandem by the data controller and legal counsel. In audits, technical questions expect answers directly from the database architecture. Organizations unprepared at the database layer risk non-compliance findings even if all administrative processes are fully established.

Implementing the four core technical controls in the database #

Encryption at rest (TDE) #

Standard MySQL Community Edition lacks the advanced keyring plugins needed to integrate with enterprise key management servers. Storing encryption keys in a local file on the database host largely defeats the security purpose of encryption. To build a robust TDE architecture that integrates with enterprise key managers (such as HashiCorp Vault), we recommend migrating to the open-source Percona Server for MySQL.

Similarly, standard PostgreSQL does not provide native TDE support. We deliver this capability via pg_tde, which operates as part of the Percona Server for PostgreSQL distribution rather than as an isolated plugin. Consequently, enterprise-grade disk encryption on both MySQL and PostgreSQL typically involves a controlled distribution migration. We manage these migrations on production systems with minimal risk and strict change-management discipline. Version upgrades are covered separately on our MySQL 8.4 migration page.

Audit logging #

To document every access to personal data stored in the database during KVKK audits, we establish a query-level audit logging infrastructure. This enables granular and filterable recording of which user accessed personal data, at what timestamp, and with which SQL query.

Because open-source audit plugins are not available in MySQL Community Edition, we configure Percona Server audit log for MySQL and pgaudit for PostgreSQL. Since query contents can themselves contain sensitive values, we also structure log retention policies, secure storage paths, and strict access controls as part of the same security architecture.

Data masking #

We address data masking along two fronts: on production databases and across non-production testing environments.

On production systems, we prevent sensitive personal data from being exposed in cleartext when queried by users or roles with restricted privileges (such as support personnel, analytics services, or reporting accounts). We configure appropriate masking models so that unmasked personal records remain visible only to privileged roles.

Simultaneously, we prevent real personal data from proliferating uncontrolled into development, QA, and staging environments. We configure Percona Server data masking functions for MySQL and PostgreSQL Anonymizer for PostgreSQL. This maintains realistic data distributions and test integrity without exposing production personal data.

Retention and destruction #

The Regulation on the Deletion, Destruction or Anonymization of Personal Data mandates periodic destruction policies for personal data that has reached the end of its retention period. In database engineering, the primary technical challenge is not executing a simple DELETE statement, but executing it without compromising relational data structure and integrity.

In high-throughput production databases where foreign key (FK) constraints are omitted for performance reasons, deleting a record from a parent table can leave orphaned personal data scattered across related tables. Organizations are then forced to develop custom relational archival and purging routines to clean records consistently across all dependent tables.

On MySQL systems, we solve the archiving and destruction of expired data using our open-source product GoArchive. GoArchive traverses relational dependencies to copy dependent rows to target storage, verifies data receipt, and safely removes them from source tables. This verification step forms the technical basis of the destruction record the Regulation requires. On PostgreSQL and MongoDB, we design retention and purging workflows utilizing native database tools and scheduled maintenance routines.

Technical measures on MongoDB installations #

MongoDB environments share the same requirements for encryption, audit logging, access controls, and data destruction. However, standard MongoDB Community Edition does not include native audit logging or encryption at rest. We deliver these security features through the open-source Percona Server for MongoDB distribution. Because it is fully compatible with standard MongoDB, no application-level code modifications are required.

We enforce access control following the principle of least privilege using role-based access. A common vulnerability we encounter in the field is applications connecting to MongoDB with administrative credentials. Without collection-level authorization, audit logs cannot distinguish individual operations. We also enforce TLS encryption across both inter-node replica communications and client connections to protect network traffic.

For retention and destruction, MongoDB’s document model offers operational advantages when related data is embedded inside a single document. Where data is distributed across collections via references, purging expired records consistently requires relational-style dependency planning.

Related services #

Security and recovery procedures differ based on the backup method in TDE-encrypted databases:

• Physical backups (XtraBackup, pgBackRest, pg_basebackup): Because raw disk blocks are copied directly, the backup files produced from a TDE-enabled database are automatically encrypted. However, to restore these backups, encryption keys (keyring) must be backed up securely and incorporated into your disaster recovery plan.
• Logical dumps (mysqldump, pg_dump, mydumper): Because data is retrieved via the SQL client layer, dump files are exported in cleartext. Therefore, logical backup files must be separately encrypted in transit and at rest, with strict storage access controls.

We design the backup and recovery plan for encrypted databases with this distinction in mind: Database Backup and Recovery

Encryption and audit logging configurations must be deployed consistently across all cluster nodes: High Availability and Cluster Solutions

We measure and monitor the performance impact of security extensions and audit logging: Performance Tuning and Monitoring