Privacy by Design: GDPR-Compliant Software Guide

Names, phone numbers, email addresses, IP addresses — almost every piece of software built today processes personal data. The GDPR and Turkey's KVKK require anyone processing such data to take appropriate technical and organisational measures. Some of those obligations are legal processes, but many are decided by how the software is designed.

This is not legal advice — always get a legal review. It covers the technical decisions a software team should make up front.

Privacy cannot be bolted on

The most expensive compliance mistake is treating it as something to "look at after launch". Discovering where personal data lives in a production system, rebuilding the permission model or adding deletion later costs many times more than designing it in. That is why our custom software projects handle the topics below during architecture.

1. Data inventory: what, and why?

Ask three questions for every field: Why is it needed? What is the legal basis? How long will it be kept? A field without answers should not be collected. Data minimisation is the cheapest security measure there is.

Technically, every personal-data field is flagged in the data model and listed in an inventory, so "which data do we hold about this person?" can be answered in minutes.

2. Authorisation: least privilege

A system where everyone sees every record is a risk even in the most trustworthy team. Design role-based access (who sees which screen) together with record-level access (who sees which customer's data). In enterprise software, this often mirrors the organisation chart.

3. Access logs: who looked at what, and when?

That is the first question in any suspected breach. Reads and changes to personal data should be recorded in a tamper-evident log.

4. Masking and encryption

In transit: all traffic over HTTPS
At rest: sensitive fields (ID numbers, health data) encrypted in the database
In logs: no emails, phone numbers or tokens in error logs
IP masking: analytics rarely needs the full IP address

5. Retention and automatic deletion

"How long do we keep it?" must be answered by a working mechanism — a scheduled job that anonymises or deletes expired records is far more reliable than manual clean-ups.

6. Data subject requests

People can ask for their data to be exported or erased. An admin function that finds, exports and deletes everything about one person turns days of work into minutes.

For consent-based processing such as marketing, store which text was accepted and when. When the notice changes, you must know which version each record agreed to. The forms on this site work this way: the version of the data protection notice is stored with each submission.

8. International transfers

Cloud services, email providers and AI APIs may move data abroad. Decide during architecture which data goes to which provider, and keep data in-country where required.

Common mistakes

Using real customer data in test environments
Writing personal data into error logs
Marking records "inactive" instead of actually deleting them
Giving everyone admin rights
Unencrypted backups with unknown access

Conclusion

Privacy compliance is not a checklist; it is a design decision built into the architecture. Done early it is cheap; retrofitted it often means rebuilding. We can review your existing system as part of software support.