KVKK and GDPR Compliant Software Development: Checklist from Architecture to Testing

The protection of personal data is often seen strictly as the domain of the legal department; a privacy notice is written, a clause is added to the contract, and the job is considered done. However, most principles required by regulations must find their counterpart in the architecture of the software. This article translates the common principles of the 6698 KVKK in Turkey, the Personal Data Protection Law in the TRNC, and the GDPR in the EU into a software team's checklist. Expert support must always be obtained for legal evaluation; what is described here is the technical side.

1. Data inventory: which fields contain personal data?

For every table and column in the database schema, information must be maintained answering whether it is personal data, sensitive data, for what purpose it is processed, and how long it is retained. This inventory is the foundation of VERBİS-like registration obligations and data-subject requests. Practical method: column comments within the schema and a separate data dictionary table.

comment on column employees.national_id is 'personal data; purpose: payroll; retention: employment relation + legal period';
comment on column employees.health_note is 'sensitive data; purpose: workplace physician; access: health role only';

2. Purpose limitation and data minimization

Adding fields to a form just "in case they might be needed" is the most common starting point for regulatory non-compliance. Every field must have a purpose; fields without a purpose should not be collected. Sensitive fields such as location, photos, and biometrics require a separate justification and separate access control.

3. Retention period and automated deletion

The retention period must be defined in the system, not just in a document. Automated anonymization or deletion jobs are set up for records whose retention period has expired; the deletion process is planned to include copies in backups as well (consistent with the backup retention period).

4. Access control: at the database level

The reliable implementation of the principle "only authorized personnel have access" is enforcing the rule at the data level. With PostgreSQL Row Level Security, every query is filtered according to the user's authorization scope; an error in the application code does not expose unauthorized data. Administrative access must be time-bound and justified.

5. Encryption: in transit and at rest

• TLS is mandatory in transit; legacy protocols and cipher suites are disabled.
• Encryption at disk or database level at rest; additional column-level encryption can be evaluated for sensitive fields.
• Passwords are never stored in plaintext; they are stored using modern and slow hashing algorithms (such as Argon2 or bcrypt).
• Key management: keys are kept in a separate secrets management service, not in the code or database.

6. Logging and audit trail

Who accessed personal data, when, and for what purpose must be recorded. However, logs also contain personal data: unnecessary data (such as full national ID numbers) must not be included in log contents, and the logs must have their own defined retention periods and access permissions.

Compliance is a behavior, not just a document: the system collects data only as much as needed, retains it only as long as needed, shows it only to the right people, and logs its actions.

7. Technical preparation for data-subject rights

When requests for access, rectification, erasure, and portability are received, the system must be able to fulfill them within a reasonable timeframe. For this, all data belonging to an individual must be located across tables (inventory), an export function must exist, and an anonymization path must be defined for cases where erasure requests conflict with legal retention obligations (such as accounting records).

8. Third parties and data transfer

SMS, email, payment, mapping, and analytics services are all data processors. For each of them, a contract, the location of data processing, and a list of transmitted fields must be maintained. International data transfers may be subject to additional conditions according to regulations; therefore, the server location of the service is a legal decision, not just a technical one.

9. Secure development practices

OWASP Top 10 and OWASP ASVS cover application vulnerabilities that are the source of most personal data breaches: broken access control, injection, insecure design, security misconfiguration. Code reviews, dependency scanning, and automated testing of authorization policies ensure regular auditing of these items.

10. Test and demo data

Copying real personal data into testing environments is a common and risky habit. Test environments must work with synthetic or anonymized data; this also eliminates unnecessary access by the development team.

Summary checklist

1. Data inventory and column-based classification
2. No fields without a purpose
3. Retention periods defined in the system, automated deletion/anonymization
4. Database-level access control
5. Encryption in transit and at rest, secure password storage
6. Audit logs (with their own retention rules)
7. Export and deletion paths for data-subject requests
8. Third-party inventory and transfer assessment
9. OWASP-based secure development
10. Anonymized test data

Consent and privacy notices: how they appear in the UI

Where the legal basis is "explicit consent," the consent record must be kept in the system: when it was obtained, with which text, for which purpose, through which channel, and when it was withdrawn if applicable. Privacy notices must be version-controlled, and the version seen by the user must be logged. Pre-checked checkboxes, consent bundled with mandatory fields, and "by continuing you are deemed to have accepted" patterns may invalidate consent; UI design must be reviewed with legal counsel.

Minimization in data transport and integrations

Integrations are often built with a "send all records" mentality. However, the SMS service should only receive the phone number and message, and accounting should only receive the amount and cost center. The list of fields sent for each integration must be documented; this list forms the technical appendix of the data processor agreement. API responses should also not return unnecessary fields: if an ID number is not needed for a list screen, the API must not provide it.

Logging example: avoiding writing more than necessary

// Bad: logs personal data
logger.info('Employee updated', { employee });

// Good: only ID and changed field names
logger.info('Employee updated', { employee_id: employee.id, fields: ['phone', 'address'], actor: user.id });

Writing the entire request body into error logs is a common source of data leaks; sensitive fields must be masked before logging.

Data protection impact assessment: when is it needed?

The GDPR requires a Data Protection Impact Assessment (DPIA) for high-risk processing activities (systematic monitoring, sensitive data, large-scale profiling); in KVKK, a similar risk-focused approach is seen in Board decisions and guidelines. For the software team, this means conducting a risk assessment with the legal team before design begins on projects involving location tracking, biometrics, or AI-based decision support. The assessment directly impacts architectural decisions (which data will not be collected, after what period it will be deleted).

International transfers: where is the server?

Cloud services, email providers, and analytics tools may process data in other countries. In Turkey, KVKK subjects international transfers to specific conditions; GDPR also has mechanisms such as adequacy decisions or standard contractual clauses for transfers to third countries. The concrete takeaway for the software team: the data processing location of every external service must be recorded in the inventory, and a location change (such as a provider changing regions) must be treated as a change event.

Preparation for breach notification

In the event of a breach, it must be possible to determine which data was affected within hours. To achieve this: table-based data classification, queryable access logs, and the ability to extract the list of affected individuals. This preparation looks like technical debt; at the moment of an incident, it is the most valuable asset.

Compliance is continuous, not a one-time event

Every new feature can bring a new data field, a new integration, or a new report. The checklist should be applied not just once at the beginning of the project, but through a short review with every release: "Does this release collect new personal data? Does it send data to a new external service? Is the retention period defined?" Three questions are sufficient for most releases.

In Cy Logic systems that process personal data (HR, time tracking, CRM, portals), this checklist is an input to the design phase, not a form filled out at the end of the project.