The Single Checkbox in Your App: What Changed in Turkey in March 2026

Since 24 March 2026, that single checkbox is exactly the structure the Turkish Data Protection Authority has pointed at. The issue is not who wrote your text. Even if the text is perfect, if there is only one box, the process itself is built wrong.

This guide gives you three things in order: what actually changed, what a correct sign-up screen looks like with templates you can copy, and a checklist that lets you compare your store declaration against what your app really does in about twenty minutes. No legal background needed.

To publish your app, Apple and Google required a privacy policy link. You added one. That part is right, because both stores require it.

But that document was written for the stores. The Turkish privacy notice, the aydınlatma metni under Article 10 of Law No. 6698, is a separate obligation. The two differ on every axis that matters:

• Who requires it. The privacy policy is required by Apple and Google; the privacy notice by KVKK Article 10.
• Who it addresses. The policy addresses the stores and the public; the notice addresses the person whose data you collect.
• When it appears. The policy sits on the store listing permanently; the notice must be given at the moment data is obtained.
• What it contains. The policy is free-form; the notice has specific mandatory elements.
• What it is for. One is a transparency statement, the other is an information duty.

The law lists what the notice must contain: the identity of the data controller, the purposes of processing, who the data may be transferred to and why, the method and legal basis of collection, and the individual's rights.

Timing is not free-form either. The implementing communiqué requires the notice to be given at the time the data is obtained. That means on the sign-up screen, at the moment of collection. A link on a store listing that a user can sign up without ever opening does not meet that moment.

The practical consequence: a well-drafted privacy policy can function as the KVKK notice if it contains every mandatory element and is presented at the point of collection. A typical store-facing privacy policy meets neither condition. In most apps, it does not qualify.

Principle Decision No. 2026/347, dated 18 February 2026, was published in the Official Gazette on 24 March 2026 and took effect on publication.

The Board's reasoning is blunt: presenting the consent text and the privacy notice intertwined is one of the most frequent violations found in the complaints reaching the Authority. This is not a theoretical refinement. It is the regulator naming the single most common mistake in the market.

The logic is simple once you see it. A privacy notice is information. It is not something to be approved. Explicit consent is a separate, freely given, specific expression of will. Merge them into one checkbox and it becomes impossible to say what the user actually agreed to.

The operative rules:

• If you rely on consent, you need two separate texts. The privacy notice and the consent text must be drafted separately, under different headings.
• They may sit on the same page, but each needs its own declaration. If both appear on one page, they must be under different headings, stacked, with a separate declaration collected for each.
• Never ask for approval of the privacy notice. You may only collect confirmation that it was read and understood. "I accept" or "I approve" must not be attached to the notice.
• If you are not relying on consent, do not present a consent text at all. This is the rule founders find counterintuitive. If your processing rests on another lawful basis, such as performance of a contract or a legal obligation, you satisfy the information duty only. Asking for consent you do not need is treated as a defect, because it obscures which lawful basis you are actually relying on. The instinct to collect consent just in case does not protect you. It creates the problem.
• Do not copy another company's texts. The texts must be specific to your actual processing, and vague or generic wording is called out.

The Board treats these as administrative and technical measures under Article 12 of the law, and has announced that action under Article 18 follows where non-compliance is established. Administrative fine amounts are revalued annually, so no figure is quoted here; check the current band on the Authority's own site.

One thing worth saying plainly, because this is not meant to alarm anyone: having a single checkbox does not automatically mean a fine. Outcomes depend on the specific facts, on complaints, and on review. The correct reading is narrower and more useful. Your flow is built wrong, and fixing it is a weekend of work.

Here is the concrete part. Compare these against your own screen.

Three problems: the notice and consent are merged into one box, "accept" is attached to the notice, and the user clears two legally distinct steps with a single action. The second variant has a merged heading and a merged approval, which is precisely the structure the Board flagged as bad practice.

Four things to notice. The notice box says "read and understood," not "accept." Consent boxes are separate, and separate per purpose. Nothing is pre-ticked. And withdrawal is stated.

If your app only processes what it needs to deliver the service, meaning the processing rests on performance of the contract, the screen is this simple. No consent box, because you are not relying on consent. Adding one to be safe is not helpful here. It is a defect.

Say you have fixed the sign-up screen. There is another layer, and it does not live in KVKK. It lives in the stores.

Google Play has the Data safety form. The App Store has App Privacy. These are declarations. You fill them in, and the store takes your word for it.

Google's own developer documentation is explicit: you must reflect data collection and sharing carried out by any third-party libraries or SDKs in your app's Data safety form. Google goes further and tells developers to treat any data an SDK collects from inside their app as if they had collected it directly. Responsibility for complete and accurate declarations sits with you alone. Apple's framing is the same in substance: you are asked to identify all data that you or your third-party partners collect, and third-party partners expressly include analytics tools, advertising networks and SDKs.

Here is what that means in practice. A typical app carries:

• An analytics SDK: screen views, session length, device identifiers.
• A crash reporting SDK: error logs, device model, operating system, sometimes user ID.
• An ad network SDK: advertising ID, device data, sometimes location.
• A push notification service: device token, usage signals.
• A payments or subscription SDK: purchase history, email.

You wrote none of that code. Your declaration covers all of it anyway.

An inaccurate declaration does not stay on the data protection side. On the store side it can lead to rejection or removal of the app. That is an available sanction, not an automatic outcome. But note the asymmetry: regulatory risk arrives on a delay, store risk arrives at your next release.

If you have read this far you are probably wondering where to start. The answer is one table.

To write the privacy notice you need to know what data you process, for what purpose, on what legal basis. To fill in the store form you need to know what each SDK collects. Both have the same input: a data inventory.

You write the texts from the inventory. You cannot write the inventory from the texts. That is the sequence.

A clarification so this is not overstated: the formal obligation to maintain a personal data processing inventory is tied to controllers subject to VERBİS registration. A small developer may fall within the exemption, which covers controllers whose main activity is not processing special categories of data, with fewer than fifty employees and an annual balance sheet not exceeding one hundred million Turkish lira. But being exempt from VERBİS does not exempt you from KVKK; your substantive obligations continue unchanged. The inventory is recommended here not as a legal requirement but as the practical precondition for everything else.

Do not leave the last column empty. Most analytics and crash SDKs send data to servers outside Turkey, and cross-border transfer is a separate regime under KVKK. It is not this guide's subject, but it has to be visible in the inventory, because you cannot manage what you cannot see.

Sit down and work through these honestly. You cannot complete Parts 1 and 3 correctly without doing Part 2 first. The order matters.

I am a solo developer. Does all of this really apply to me?

KVKK does not scale its application to company size. If you process the personal data of people in Turkey, you are a data controller. What changes with size are add-on obligations like VERBİS registration. The good news: for a small app, the inventory rarely runs past ten rows.

My company is incorporated abroad. Am I still in scope?

If you process data of people in Turkey, you are within the law's scope. Where your entity is incorporated does not by itself take you out of it.

Users never read the notice anyway. Why does it matter?

The duty is not to make people read. It is to present the information at the right moment, in an understandable form. Them not reading does not remove your responsibility, but not presenting it breaches the duty outright.

If I remove the consent box, can I still process the data?

Usually yes, and that is the point. In most apps the core processing already rests on performance of the contract and needs no consent. Consent is only needed for additional purposes such as marketing, personalisation or commercial analytics. Identifying the correct legal basis is both more robust and easier than collecting consent you do not need.

Can I just use a template?

The Board specifically warns against using another controller's texts verbatim. A template can be a starting point, but it has to be rewritten around your actual data flows. Once the inventory exists, the text largely writes itself.

The sequence: build the inventory, assign legal bases, write the texts from the inventory, split the sign-up screen in two, then reconcile the store declaration against the inventory.

For a small app this is a weekend. It grows if you postpone it, because every new SDK and every new feature adds another row.

One box on your sign-up screen, or two? If the answer is one, you know exactly where to start.

Sources: Law No. 6698 on the Protection of Personal Data, Articles 5, 6, 10, 12 and 18. Communiqué on the Procedures and Principles to be Followed in Fulfilling the Obligation to Inform, Article 5. Personal Data Protection Board Principle Decision No. 2026/347 of 18 February 2026, Official Gazette of 24 March 2026, No. 33203, and the Authority's related public announcement. VERBİS exemption criteria per Board decision No. 2023/1154 of 6 July 2023. Google Play Console Help, Data safety section and SDK requirements pages. Apple App Store Connect, App Privacy Details.

This guide is general information, not legal advice. Your app needs its own assessment.