Legal and source review date: 27 September 2026. General information only; obligations and steps depend on the processing activity, corporate roles, data, people affected, systems, transfer route and law current for the matter.
1. Start with the processing facts
A global compliance review should begin with what the business actually does with personal data connected to Türkiye. Law No. 6698 covers personal data processed wholly or partly by automated means and non-automated processing that forms part of a filing system. The same activity must also satisfy the core principles of lawfulness and fairness, accuracy, specified purposes, proportionality and limited retention.
Corporate labels do not settle responsibility. The controller is the person that determines the purposes and means of processing, while a processor handles personal data on the controller’s behalf and authority. A Turkish subsidiary, overseas parent, shared-service company and cloud provider may therefore occupy different roles for different operations rather than one role across the entire group.
Map a legal condition to every processing purpose before choosing forms or contract clauses. Ordinary personal data require an Article 5 condition; special-category data require one of the current Article 6 conditions and the adequate measures determined by the Board. Collecting more data than the stated purpose requires, keeping inaccurate records or retaining information after its lawful need ends remains problematic even where a condition originally existed.
No single document closes the analysis. An information notice, explicit consent, VERBIS entry, vendor contract, standard-contract filing or breach notice deals with a defined obligation and evidence point. None proves by itself that every purpose, system, transfer, retention rule and security control complies or that the Board will reach a particular result.
2. Build one usable data map
A useful inventory follows the business process from collection to deletion. It should connect each activity to its purpose and legal condition, data-subject and data categories, recipients, foreign transfers, maximum retention period and technical and organisational measures. The map should also identify the system, business owner, Turkish entity or representative, relevant vendors and the record supporting each conclusion.
Information duties should be designed from that map. At collection, the controller or its authorised person must explain the controller and representative, processing purposes, recipients and transfer purposes, collection method and legal basis, and Article 11 rights. The duty applies whether the processing relies on consent or another legal condition, so a consent box cannot replace a complete and intelligible notice.
Consent should be used only where it is the correct legal condition and can be freely given, specific and informed. The information exercise and the request for consent are separate steps, and refusing consent should not be used to disguise processing that the business intends to carry out on another ground. A global privacy policy can provide context, but it may be too broad to explain a specific Turkish collection event.
Special-category data need their own column in the map. Current Article 6 lists the circumstances in which those data may be processed and requires the adequate measures determined by the Board. Health, biometric, genetic, criminal-conviction, trade-union and other listed categories should therefore be traced through access, transfer, vendor, retention and incident workflows rather than treated as an ordinary-data addendum.
Retention should be expressed as a rule with an owner and an event, not simply “as long as necessary”. When all processing conditions end, Article 7 and the disposal by-law require erasure, destruction or anonymisation, while other laws may require continued retention. Disposal operations, periodic cycles and exceptions should be documented so that a legal hold does not become indefinite storage by default.
3. Allocate vendor responsibility before signing
Article 12 places data-security duties on the controller and addresses processing carried out by another person on its behalf. The controller must take appropriate technical and organisational measures and conduct or arrange audits; processor involvement does not transfer away that responsibility. The processor also has relevant confidentiality and security duties, so the contract should reflect the real allocation without suggesting that one party has no statutory exposure.
Vendor diligence should be proportionate to the data and service. Examine access architecture, authentication, encryption, logging, segregation, backup, vulnerability and patch practice, staff access, physical controls, business continuity and incident history. The evidence may include policy excerpts, technical reports and remediation records, but a certificate or questionnaire should not substitute for examining material exceptions and the service actually purchased.
The service agreement should turn the operating model into enforceable instructions. Describe the purpose, duration, data and subject categories, authorised personnel, security measures, confidentiality, return or deletion, audit evidence, assistance with requests and incidents, and the consequences of changing the service. Instructions should be specific enough to test while still allowing controlled technical change.
Subprocessors need an accurate chain. In controller-to-processor and processor-to-processor transfer modules, subprocessor controls are not decorative annexes; the required authorisation and equivalent protections must match the service structure. The customer should know which entity performs which function, in which country, under whose instruction and how replacement or objection will be managed.
A contract cannot cure an unknown transfer. Remote support, global identity tools, telemetry, disaster recovery, content delivery, group reporting and administrator access may all create disclosures or access from abroad. The data map and vendor register should therefore be reconciled, and onward transfers should remain subject to Article 9 safeguards as well as Article 12 security and audit controls.
4. Choose the cross-border transfer route in order
Cross-border analysis has two layers. The underlying processing still needs an Article 5 or Article 6 condition, and the transfer must then fit Article 9. A business should first determine whether an adequacy decision covers the country, sector or international organisation, then consider an appropriate safeguard, and use the statutory incidental circumstances only where the earlier routes are unavailable and the specific conditions are met.
An adequacy decision is issued by the Board and published in the Official Gazette. It may concern a whole country, a sector in that country or an international organisation, and the Law provides for assessment at least every four years. A vendor’s description of a destination as safe, European or internationally certified is not an adequacy decision under Turkish law.
Where adequacy is absent, Article 9 provides several appropriate safeguards. These include a qualifying arrangement between relevant public or public-status bodies with Board approval, Board-approved binding corporate rules, the Board’s standard contract, and a written undertaking with Board approval. Each route has its own eligibility, content and timing rather than serving as alternative names for the same filing.
Incidental circumstances are a narrow third tier. They operate only without an adequacy decision and where an appropriate safeguard cannot be provided, and the particular transfer must meet one of the statutory cases. A repetitive cloud, payroll, support or group-reporting architecture should not be relabelled “incidental” merely because obtaining a durable safeguard requires more work.
The analysis continues after the first recipient. Article 9 applies safeguards to onward transfers, and it separately regulates transfers capable of seriously harming Türkiye or the data subject. The transfer record should therefore show further recipients and access locations, and should identify any matter requiring the specified institutional opinion and Board approval rather than assuming that an initial contract covers every downstream disclosure.
5. Select and file the Turkish standard contract
Türkiye has four official standard-contract modules. They cover controller to controller, controller to processor, processor to processor and processor to controller transfers. Select the module from the exporter’s and importer’s roles for that transfer; a group company can be a controller for one purpose and a processor for another, so corporate affiliation alone does not answer the choice.
The annexes are the factual centre of the contract. They should accurately describe the categories of personal data and data subjects, purposes, legal basis, frequency, retention, recipients, security measures, special-category measures and any onward transfer or subprocessor structure required by the selected module. Generic phrases that could describe any vendor weaken the link between the official text and the real transfer.
The Authority’s filing guidance also addresses execution. The parties or properly authorised representatives must sign, evidence of representative authority should accompany the filing, and both parties must sign the Turkish contract text even where another-language version is executed. Commercial schedules should be checked for conflicts rather than silently overriding the official clauses.
The controller or processor must notify the signed standard contract to the Authority within five business days after signature. The file should record the signing date, signatories, authority evidence, module, final annexes, notification date and receipt. This calendar should be built into procurement because waiting until service activation may leave a transfer operating before its documentation is ready.
Turkish standard contracts and EU GDPR standard contractual clauses arise under different legal frameworks. An EU SCC package may contain useful operational material, but it does not replace role selection, Turkish text, annex completion and notification under Article 9 and the Turkish transfer by-law. The two regimes should be coordinated where both apply, with separate evidence of compliance under each.
6. Use BCRs and approval routes for the right architecture
Binding corporate rules can serve as an appropriate safeguard for transfers within a group of undertakings engaged in joint economic activity. They must be legally binding and provide enforceable rights, governance, training, complaint, audit and cooperation arrangements required by the transfer by-law. Transfers under that route may start only after the Board approves the rules.
The Authority announced in 2026 that it approved one binding corporate rules application. That confirms the mechanism is operational, but the approval belongs to that applicant and its approved framework. It does not create adequacy for a country, automatic approval for another group or permission to omit transfer mapping while an application is pending.
A written undertaking is a distinct route. It must contain provisions providing the required protection and receive Board approval before the transfer begins. It should be evaluated against the number of parties, direction of transfers, likely changes and need for repeated group or vendor transfers rather than selected only because its title sounds familiar.
Public institutions and organisations, international organisations and qualifying professional bodies may use the public-body arrangement described in Article 9 and the by-law, again with Board approval. That route is not a general option for ordinary private vendor relationships. The parties and instrument must fall within the provision before drafting begins.
Whichever safeguard is chosen, the supporting work remains. The business must identify the processing condition, recipients and destinations, provide enforceable rights, set security and special-category measures, control onward transfers and keep the arrangement current. Approval or filing does not freeze the factual architecture; new systems, acquisitions, subprocessors and destinations can require reassessment.
7. Decide the VERBIS position from current facts
Article 16 establishes a Data Controllers Registry and permits the Board to provide exemptions. The registry by-law and published decisions must therefore be applied to the organisation’s establishment, activities and current facts. It is unsafe to say that every foreign business processing information about people in Türkiye must register, just as it is unsafe to assume that a small or specialised operation is exempt without checking the current decision.
For a controller not established in Türkiye that falls within the registry framework, the by-law provides for a controller representative in Türkiye. The representative performs defined registry and communication functions and should have documented authority, access to accurate information and an escalation route to the controller. Appointment does not transfer the controller’s substantive KVKK duties to the representative.
The registry submission draws from the processing inventory. It includes the controller and representative, purposes, data-subject and data categories, recipients, transfers abroad, security measures and maximum retention periods. If the business map says one thing while the registry and notices say another, the inconsistency is itself a governance warning.
Accuracy requires maintenance after registration. Corporate changes, new processing purposes, systems, recipient groups, destinations, retention and representative details should be assessed against the by-law’s update duties. Responsibility for monitoring changes should be placed with named functions rather than left to an annual form-filling exercise detached from procurement and product decisions.
Registration is a transparency and governance obligation, not a compliance certificate. A complete VERBIS entry cannot validate an unlawful processing ground, vague notice, weak security, incorrect transfer mechanism or excessive retention. Conversely, an exemption from registration removes only that duty and does not remove the other obligations in Law No. 6698.
8. Run the 72-hour breach clock correctly
Article 12(5) addresses personal data obtained by others through unlawful means. It requires communication to the data subject and notification to the Board within the shortest time. Board Decision 2019/10 supplies the operating standards, so the incident plan should use the statutory event and decision rather than importing a foreign threshold without checking the Turkish facts.
For the Board, the decision interprets “the shortest time” as without delay and no later than 72 hours after the controller becomes aware of the breach. If the deadline is missed, the reasons for delay should be explained with the notification. Awareness time must therefore be recorded as a legal fact, with the source and decision-maker, rather than reconstructed after the investigation.
Affected-person communication follows a separate standard. After affected people are identified, they should be informed within the shortest reasonable period; direct communication should be used where contact information is available and an appropriate method may be used where it is not. The content should help people understand the event and protective steps without speculation or unsupported reassurance.
A controller does not need to pretend that every fact is known at the first filing. Decision 2019/10 allows available information to be supplied in stages without delay where it cannot be provided at once. The response team should distinguish confirmed facts, reasonable assessments and open questions, and should preserve each submitted version and the basis for later changes.
Every breach, its effects and the measures taken should be documented, and the controller should maintain a periodically reviewed response plan. Decision 2019/10 also addresses a controller established abroad where affected people reside in Türkiye and benefit from products or services provided in Türkiye. Those conditions should be applied to the actual event rather than turned into a statement that every global incident is automatically reportable in Türkiye.
9. Coordinate legal, security and vendor response
The first response objective is to protect people and reliable evidence. Contain unauthorised access, preserve relevant logs and system images, secure credentials, isolate compromised paths and keep a record of decisions. Legal review should proceed with security and operations so that privilege, preservation and notification analysis do not delay urgent protective measures.
Vendor escalation should be fast enough for the controller’s clock. Contracts and playbooks should identify who reports, what minimum facts are provided, how evidence is preserved, how the customer obtains updates, and who contacts subprocessors. A processor’s promise to investigate does not relieve the controller from assessing awareness, scope and Turkish notification duties.
Build the assessment around known facts. Record affected systems, data and people, the likely consequences, destinations, special-category data, security protections, containment and remediation, together with the time each fact became known. Where the investigation is incomplete, submit available information in stages rather than waiting for a polished root-cause report beyond the deadline.
Communication should be controlled without becoming evasive. Board filings, affected-person notices, customer updates and public statements should remain factual, intelligible and consistent with the current investigation. Keep decision logs, drafts and approvals so the organisation can explain why a conclusion was made and how it changed when new evidence emerged.
Notification is one response step. Filing within 72 hours does not prove that pre-incident security was adequate, prevent the Board from investigating, or eliminate claims, contractual consequences and operational loss. Equally, a serious technical event is not automatically a Turkish personal-data breach; the statutory event, affected data and connection to Türkiye still require reasoned analysis.
10. Handle data-subject requests across systems
Article 11 rights include learning whether data are processed, obtaining information about processing and transfers, seeking correction or qualifying deletion, objecting to certain results produced solely through automated analysis, and claiming compensation for damage arising from unlawful processing. A request may engage several rights at once, so it should be read by substance rather than routed solely by the subject line.
The request is made to the controller under Article 13 and should be concluded as soon as possible and no later than thirty days. An accepted request must be implemented; a refusal should be explained with reasons and communicated through the permitted method. Internal service targets should leave time for legal review and delivery rather than equalling the statutory maximum.
The request communiqué recognises written and specified electronic channels and identifies the information a request should contain. The intake process should preserve the receipt date, channel, identity evidence, scope, searches, decisions and response. Identity checks should be proportionate so that responding to a privacy request does not become a new collection of excessive personal data.
Article 14 complaint timing is tied to the controller response and request date, and the controller route generally must be exhausted before a complaint to the Board. This makes a missing or vague response consequential. The file should show what was searched, what was withheld and why, which corrections or deletion actions were completed, and what was communicated to recipients where the Law requires it.
Global systems need one coordinated search process. Turkish data may sit in a local CRM, overseas support tool, archived mailbox, cloud backup and vendor platform under different retention rules. The controller should be able to instruct processors, collect reliable results, apply lawful exceptions and issue a reasoned answer without losing the Turkish timetable.
11. Turn compliance into an operating plan
Assign a named owner to each row of the processing inventory. The operating plan should connect notices, legal conditions, consent where used, vendor controls, security measures, transfer mechanisms, retention and request handling to source documents and review dates. This creates a traceable file when a product, acquisition or vendor changes the facts.
Maintain a separate transfer register for operational control. Record exporter and importer roles, destination and access location, purpose, data and subject categories, transfer route, module or approval, signing authority, notification date, onward recipients and reassessment triggers. Link the register to procurement and change management so a new subprocessor cannot appear only in an annual privacy review.
Retention controls should cover production systems, archives, collaboration tools and backups. Define the event starting the period, method of erasure, destruction or anonymisation, responsible function, evidence retained and any legal hold. A backup design may affect when data become inaccessible in ordinary use, but it should not become an unexplained exception to the disposal programme.
Testing should cover real paths. Sample a notice against a live data flow, trace a vendor’s subprocessors, exercise a data-subject request across systems, and run a breach scenario that records awareness and prepares staged facts for the Board. Findings should have owners and closure evidence rather than being copied into the next assessment.
KVKK compliance changes with law, Board decisions, exemptions, systems, recipients and incidents. The sources in this guide were reviewed on 27 September 2026, but the exact mechanism and current text should be checked again before implementation or filing. No responsible plan can guarantee approval, non-enforcement, a fixed response time or a result detached from the organisation’s facts.
12. Frequently asked questions and official sources
Frequently asked questions
No blanket answer is reliable. Article 16, the Registry by-law, the controller’s establishment and activities, and current Board exemptions must be applied to the facts. Registration or exemption affects the Registry duty and does not decide every other KVKK obligation.
They do not replace the applicable Turkish mechanism. Türkiye has four role-specific modules under Article 9 and the transfer by-law, and the Turkish contract must be completed and notified within five business days after signature. Where both regimes apply, keep coordinated but separate evidence for each.
Decision 2019/10 ties the period to the controller becoming aware of the breach and requires notification without delay and no later than 72 hours. Record the awareness time and reasons for any delay. Communication with identified affected people follows its separate shortest-reasonable-period standard.
Not where waiting would cause the statutory notification period to be missed. Available information may be supplied in stages without delay when the full picture cannot be provided at once. Preserve confirmed facts, open questions, submitted versions and the basis for updates.
No single certificate or contract answers the statutory questions. The controller should map roles and transfers, examine material security evidence, include operational duties and subprocessor controls, and retain audit and incident-response capability. The appropriate depth depends on the service, data and risks.
No. Filing addresses one Article 9 step; module selection, annex accuracy, security and onward transfers remain reviewable. A filing cannot guarantee that the Authority will accept the wider processing arrangement or refrain from enforcement.
Official sources
- Personal Data Protection Law No. 6698
- Transfer of Personal Data Abroad By-Law
- Controller-to-controller standard contract
- Controller-to-processor standard contract
- Processor-to-processor standard contract
- Processor-to-controller standard contract
- Authority announcement on standard-contract filing
- Data Controllers Registry By-Law
- Data security obligations
- Board Decision No. 2019/10 on breach notification
- Erasure, destruction and anonymisation by-law
- Data-subject request communiqué
