PDPL-Compliant Software Development: Core Principles

PDPL-compliant software collects only as much personal data as it needs. It also controls and logs who accesses which data, can delete data once its purpose is fulfilled, and informs users properly. Turkey's Personal Data Protection Law (PDPL, Law No. 6698) doesn't tell developers "write this code." However, the data controller can meet most of the obligations it sets only if the software is designed for them from the start.

Why does the PDPL matter for software development?

The obligations under the PDPL belong to the data controller, that is, the business that processes personal data using the software. However, what the software can do limits how well the business can meet them. For example, if software has no delete function, it can't delete data. If it doesn't keep access logs, it can't show who looked at what. And if every field is mandatory, it can't prevent unnecessary data collection.

That is why PDPL compliance is not a text you add after delivery; instead, it is a set of decisions you make at the design stage. Adding it later is both more expensive and riskier.

1. Data minimization: collect only what you need

Article 4 of the PDPL lists the general principles for processing personal data. These are lawfulness and fairness; accuracy and being up to date; specific, explicit and legitimate purposes; being relevant, limited and proportionate to the purpose; and retention only for as long as necessary.

In software, this means:

• Asking "why?" for every form field. Does a quote request form need a Turkish national ID number? Does anyone actually use the date of birth?
• Separating mandatory and optional fields. Make only the fields the job needs mandatory.
• Not showing more data on screen than necessary. The field team sees only what it needs for that job, not the customer's entire history.
• Keeping personal data out of logs and error reports. Teams often overlook application logs and error tracking tools as data sources.

2. Notice and explicit consent screens

Under Article 10 of the PDPL, when you collect data, you must tell the data subject several things. These are the identity of the data controller, the purpose of processing, to whom and for what purpose the data may be transferred, the method and legal basis of collection, and their rights. The Law calls this the privacy notice (aydınlatma).

Explicit consent (açık rıza), on the other hand, is something else. It is consent relating to a specific matter, based on information and given of one's own free will. You rely on it when none of the other processing conditions listed in the Law apply.

The Board's 2026 principle decision

The Personal Data Protection Board's principle decision No. 2026/347 of 18 February 2026 appeared in the Official Gazette today (24 March 2026) and took effect. Under the decision:

• You must prepare the privacy notice and the explicit consent text separately. Even when you show them on the same platform, you must present them under separate headings and in separate steps.
• You cannot make the privacy notice conditional on approval or acceptance; the decision considers setups such as "I have read and accept" unlawful. You may only collect confirmation that the user has read it.
• If processing relies on a legal basis other than explicit consent, give only the notice, and don't request explicit consent unnecessarily.

What this means for software design: avoid a single "I accept" box on a sign-up or form screen. Instead, use a link to the privacy notice (without a checkbox) and separate, unticked and optional choices for each purpose that genuinely requires explicit consent.

Earlier, in principle decision No. 2025/1072 (Official Gazette, 26 June 2025), the Board had already called for an end to one practice. That practice combined membership confirmation, permission for commercial messages and consent to personal data processing into a single step via an SMS verification code. In other words, the "one tap to agree to everything" design is now clearly risky.

3. Access control, logs and security

Article 12 of the PDPL requires the data controller to take all necessary technical and administrative measures to prevent unlawful processing and access. If someone else processes the data (for example, a software or hosting company), the data controller shares joint responsibility with them for these measures.

The most common ways software meets this:

• Role-based authorization: Each user sees and changes only the data needed for their job.
• Access and activity logs: Who looked at or changed which record, and when? These logs are the only way to understand what happened after an incident.
• Strong authentication: Two-step verification or passwordless sign-in methods. We explained passwordless sign-in in our post What Is a Passkey?.
• Encryption: Encrypting data in transit (HTTPS) and, where needed, at rest.
• Backups and restore testing: Apply the same security measures to backups. We covered our approach to backups in our post Website Backup.
• Verifying contact details: The Board's decision No. 2020/966 requires data controllers to take reasonable measures so that invoices and documents don't go to third parties because of incorrect contact details. For example, you can send a verification code or link to the phone number or email address.

If a data breach occurs

If others obtain data unlawfully, the Law requires you to notify the data subject and the Board "as soon as possible." In its decision No. 2019/10, the Board interpreted this period as 72 hours at the latest from the moment the data controller learns of the breach. To support this, software needs to keep records that let you quickly establish the scope of the breach (which data, which people).

4. Deletion, destruction and anonymization

Under Article 7 of the PDPL, the reasons for processing may cease to exist even when the processing itself was lawful. In that case, you must delete, destroy or anonymize the personal data, either on the controller's own initiative or at the data subject's request.

In software, this means:

• Defining retention periods by data type,
• A mechanism that finds and processes records whose retention period has expired,
• An admin screen that can carry out deletion requests,
• Considering the copies left in backups and connected systems (email service, SMS provider),
• Using truly anonymous data (data that can't be linked to a person) for reporting.

Similarly, app stores set this requirement for mobile apps: apps that let users create an account must also let them delete that account from within the app.

5. Third-party services and transfers abroad

Modern software rarely runs on its own: cloud servers, email delivery services, SMS and WhatsApp providers, analytics and error tracking tools. If their servers are abroad, this may be a transfer of personal data abroad. We explained the cloud concept in What Is Cloud Computing? and integrations in What Is API Integration?.

Law No. 7499, which appeared in the Official Gazette on 12 March 2024, rewrote Article 9 of the PDPL; the amendment took effect on 1 June 2024. Under a transitional provision, businesses could still rely on explicit-consent transfers under the old rules alongside the new rules until 1 September 2024. Under the new rules, if one of the processing conditions in Article 5 or 6 of the Law applies, you can transfer data in one of these ways:

1. Adequacy decision: A decision by the Board covering the relevant country, sector or international organization.
2. Appropriate safeguards (if there is no adequacy decision): a standard contract announced by the Board, approved binding corporate rules, an agreement between public institutions, or a written undertaking with the Board's permission. You must notify the Authority of a standard contract within 5 business days of signing.
3. Incidental transfer: If none of the above apply, only in incidental (non-recurring) cases and in the limited situations the Law lists. One example is the explicit consent of a person who knows the risks.

A practical step in a software project: list every third-party service you use, where it processes the data and which transfer mechanism you rely on. This list then becomes the basis for both the privacy notice and the contracts.

A short checklist for development teams

• [ ] Have you documented the purpose of every form field, and are there any unnecessary fields?
• [ ] Are the notice and explicit consent screens separate; are the explicit consent options optional and unticked?
• [ ] Have you defined roles and permissions, and do you keep access logs?
• [ ] Is there personal data in the application logs and error reports?
• [ ] Are there retention periods and a deletion mechanism?
• [ ] Do you encrypt backups, and have you tested a restore?
• [ ] Do you have a list of third-party services and the countries where they process data?
• [ ] Is there enough information to quickly identify the affected records in case of a breach?

Our experience

We developed AquaCRM, one of our digital products, as a platform that water treatment service companies use on a subscription basis. We built it so that each subscribing company works in its own isolated data space. That way, one company's customer and device data never appears on another company's screen. Features in AquaCRM such as WhatsApp/SMS templates and automatic notifications also require message types and permissions to be part of the design.

On our own website, we built a plugin-free cookie consent banner compatible with Google Consent Mode v2. In our projects, we don't leave PDPL requirements until after delivery. Instead, we define data fields, roles and third-party services together with the client at the scoping stage. The business's legal advisor is responsible for the content of the legal texts; we make sure the software presents these texts correctly and can carry out the required actions.

Frequently asked questions

Conclusion

PDPL-compliant software collects little data, restricts and logs access, can delete data on time and informs users correctly. Recent rules, such as separating the privacy notice from explicit consent and the rules on transfers abroad, make it even more important to make these decisions at the design stage.

Planning PDPL-compliant software

If you are planning new software or want to review your current system, take a look at our Software and Digital Solutions page or get in touch with us.