Building KVKK-compliant software: a checklist from design to launch

Türkiye's Personal Data Protection Law No. 6698 (KVKK) applies to every organisation that processes personal data in Türkiye. From a contact form on a website to user accounts in a mobile app, most software touches personal data. In this post we share, as a checklist, how we build KVKK compliance into our own products and client projects from the start.

This article is for general information only and is not legal advice. We recommend working with a legal adviser for an assessment of your own project.

Privacy by design

The cheapest and most effective way to comply is to address it at the start of a project. Asking "why are we collecting this?" close to launch usually means rethinking the database, screens and integrations. So for every new feature we ask three questions up front:

• Which personal data does this feature really need?
• How long, and where, will this data be kept?
• Who will access it, and for what purpose?

1. Build a data inventory

You cannot comply without knowing which data is processed where, for what purpose and on which legal basis. On the software side, that means listing database tables, logs, data sent to third-party services and backups. The inventory is the foundation for every step that follows.

2. Data minimisation

The best-protected data is data you never collect. Does a form really need a date of birth, or is confirming that the user is over 18 enough? Is location needed continuously, or only at the moment of a transaction? Every field you collect brings a storage, protection and deletion burden.

3. Privacy notices and explicit consent

The duty to inform

Wherever personal data is collected, users must be told who the data controller is, why the data is processed, who it is shared with, how it is collected, the legal basis, and their rights under the law. This information must be easy to find and written in plain language.

When is explicit consent needed?

Explicit consent is the basis you rely on when none of the other legal grounds listed in the law apply. Where consent is used, it must be specific, informed and freely given. In software terms, that means avoiding pre-ticked boxes, not making consent a condition of the service, and making it easy to withdraw.

4. Technical and organisational measures

The law requires data controllers to take appropriate technical and organisational measures to keep data secure. In software projects the key measures are:

• Encryption: TLS on every connection, and encryption at rest for sensitive fields and backups.
• Access control: role-based permissions, least privilege and two-factor authentication for admin accounts.
• Logging: being able to see who accessed personal data and when, without the logs themselves holding unnecessary personal data.
• Password security: storing passwords with strong, salted hashing algorithms.
• Backups: encrypted, regular backups whose restores are tested.
• Secure development: code review, up-to-date dependencies and security testing.
• Test environments: using anonymised or synthetic data instead of real personal data in development and testing.

5. Retention and deletion

Personal data should be kept only as long as its purpose requires, then deleted, destroyed or anonymised. In software, that means defining retention periods and setting up scheduled jobs that clean up expired data automatically. A user's request to delete their account and data should be designed as part of the same process.

6. Cross-border transfers

Cloud services, email providers, analytics and crash reporting tools often mean data is transferred to servers abroad. Article 9 of KVKK, which governs cross-border transfers, was revised by an amendment in 2024. List clearly in your inventory which services send which data where, and confirm the transfer mechanism with your legal adviser. Hosting data in Türkiye where possible reduces this burden considerably.

7. Breach response

No system is risk-free; what matters is acting quickly and correctly when a breach happens. Under a decision of the Personal Data Protection Board, breaches must be reported to the Board as soon as possible and within 72 hours at the latest. To meet that deadline:

1. Set up monitoring and alerts that detect suspicious access.
2. Write down in advance who decides and who notifies.
3. Keep your data inventory current so you can quickly identify affected data and people.

8. Notes for mobile apps

• Ask for permissions such as location, camera or contacts only when needed, and explain why.
• Check what data third-party SDKs (analytics, ads, crash reporting) collect.
• Make sure the privacy declarations on Google Play and the App Store match how the app actually behaves.
• Publish an accessible privacy policy for every app; both stores require the link.

KVKK and GDPR

Projects serving users in the European Union or the United Kingdom may also fall under the GDPR (UK GDPR in the United Kingdom). The two share many core principles: purpose limitation, data minimisation, security and transparency. They differ, however, on points such as legal bases, notification duties and transfer rules. For products serving both markets, handling the requirements together from the start is more efficient than adapting twice later.

Clarify roles and responsibilities

Several parties touch personal data in a software project: the organisation that owns the product, the team that builds it, the hosting provider and integrated third-party services. Under KVKK you need to be clear about who is the data controller and who is the data processor, and govern the relationship by contract. For example, a software company that hosts and processes data on its client's behalf is usually a processor, acting on the client's instructions.

Plan for data subject requests in the system

The law gives individuals rights such as learning whether their data is processed and asking for it to be corrected or deleted. In systems where data is scattered, meeting these requests can take weeks. So the software should plan from the start for:

• Finding all data about a person through a single identifier
• Exporting data so people can see their own information
• Admin tools to delete or anonymise accounts and data
• Logging requests and the responses given

Cookies and analytics

Analytics and marketing cookies on websites often mean personal data is being processed. Good practice is to separate strictly necessary cookies (session, security) from analytics and marketing cookies, ask for consent for the non-essential ones, and not load those tools before consent is given. On this site too, Google Analytics only loads after the visitor consents.

Team culture

Even the best technical measures depend on how the team treats personal data. Limiting developers' direct access to production databases, letting support staff see only the data they need, and regular awareness training are organisational measures that complement the technical ones. Making "does this change collect new personal data?" a standard question in code review turns compliance into part of everyday work.

Pre-launch checklist

• Data inventory completed and up to date.
• Every form and screen collects only the data it needs.
• Privacy notices are available where data is collected; explicit consent, where needed, is separate and can be withdrawn.
• TLS, encryption at rest, role-based access and two-factor authentication enabled.
• Retention periods defined, and expired data cleaned up automatically.
• Cross-border transfers and their basis identified.
• Written breach response plan with named owners.
• Mobile app permissions and store privacy declarations reviewed.

Conclusion

KVKK compliance is not a one-off task but a habit that runs through the software's whole lifecycle. Done well, it increases user trust, limits the impact of potential breaches and makes it easier to enter new markets. If you want to build security and compliance into your project from the start, talk to our team.