What “compliance” means in code

Compliance is not a checkbox; it is a set of behaviors the system must exhibit on demand. The questions that matter in code are: what personal data do you collect, where does it live, who can read it, how long does it stay, how can a user export or delete it, what happens when something goes wrong?

The data inventory

• Every field that contains personal data, tagged in your schema
• Every external service that receives any of it (payment, email, analytics, CRM)
• Every region where it is stored, including backups
• The legal basis for processing each field (consent, contract, legitimate interest, etc.)

Without this inventory, no other checklist item can be answered honestly.

Consent

• Granular consent records — what was consented to, when, on which version of the policy
• Cookie consent that defaults to “off” for non-essential categories
• Withdrawal flow that is as easy to use as the consent flow
• Per-jurisdiction default behavior — GDPR for EU, KVKK for Turkey, soft defaults elsewhere

Subject access

• Export — a tested flow that produces a machine-readable export of a user’s personal data
• Deletion — a tested flow that removes the user’s data from primary stores, backups (within a defined window) and downstream services
• Rectification — a way for users to correct their data without going through support
• Response time targets (GDPR: 1 month; KVKK: 30 days, similar in practice)

Retention

• Documented retention windows for each data category
• Automated purging at end-of-retention, not “we will get to it”
• Soft-delete vs hard-delete distinction with retention applied to both
• Backup retention disclosed in the privacy policy and the DPA

Breach response

• Detection — observability tuned to surface anomalous data access
• Containment — playbooks for revoking access, rotating credentials, isolating affected services
• Notification timelines — GDPR: 72 hours; KVKK: similar in practice, no fixed regulatory deadline but expectations have tightened
• Customer-facing communication templates pre-drafted, not improvised under pressure

KVKK-specific notes

• Data localization expectations have shifted — newer guidance pushes toward Turkish-resident storage for certain categories
• Cross-border transfer requires explicit safeguards or consent
• The data controller (VERBİS) registration requirement applies to many SaaS operators with Turkish establishments
• The penalties have grown — recent enforcement actions are large enough to take seriously

What we hold as practice

Every engagement T-Square runs operates under a KVKK and GDPR-aligned Data Processing Addendum. The engineering work to support it — schema tagging, export and deletion flows, consent records, breach playbooks — is part of the architecture, not a bolt-on. Adding it after launch is expensive; building it in is not.

Frequently asked questions

Does GDPR compliance automatically mean KVKK compliance?

Largely yes, with caveats. KVKK was modeled on the pre-2018 EU data protection directive, not the GDPR itself, and Turkish data localization expectations have shifted. Treat KVKK as a separate jurisdictional review even after you are GDPR-compliant.

What is a Data Processing Addendum?

A DPA is the contract between a controller (typically your customer) and a processor (typically your SaaS) that defines how personal data is processed, what protections apply, where data is stored, and what happens on subject access or deletion requests. It is a hard requirement for enterprise B2B deals in regulated industries.

Working on something similar?

T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.