Most organizations treat data protection as a document exercise. A privacy policy gets written, a consent banner goes up, a folder of PDFs is filed — and everyone assumes the box is ticked.

Then a data subject asks to see everything you hold on them, or to have it deleted, and the real state of things becomes clear: nobody knows where all the personal data actually lives.

At DZDSoft, data security is one of the services we're asked for most, and the pattern is almost always the same. The policy is fine. The system underneath it isn't. Here's how we think about closing that gap.

Personal data hides in more places than anyone expects

The privacy policy describes the tidy version: a CRM, an HR system, a customer database. The reality is messier. Personal data accumulates in:

• Spreadsheets on individual laptops and shared drives.
• Email inboxes and attachments, indefinitely.
• Database backups that outlive the records they copied.
• Application logs, analytics events, and support tickets.
• Old systems nobody has decommissioned but everyone still trusts.

This is the shadow data problem, and it's why data discovery — knowing what you hold and where — is the first real step of any serious compliance effort. You cannot protect, delete, or report on data you can't locate.

The three hard problems: discovery, deletion, archival

Strip away the legal language and both KVKK and GDPR demand three concrete technical capabilities. Everything else is built on these.

The uncomfortable truth is that most organizations can describe all three and execute none of them reliably. Describing them is policy work. Executing them is engineering — and that's the part that's usually missing.

KVKK and GDPR: the same spine, different details

For organizations operating in Turkey and the EU — which describes most of our clients — the good news is that KVKK (Law 6698) and GDPR share the same backbone. Build for one properly and you're most of the way to the other.

They diverge in the specifics: KVKK has its own registry obligations (VERBİS), its own rules on explicit consent (açık rıza) and cross-border transfer, and its own supervisory authority. GDPR carries heavier maximum penalties and a more developed body of guidance. But the underlying engineering — inventory, lawful basis, retention, access control, breach response — is one system, not two.

That's why we build for the stricter requirement on each axis rather than maintaining parallel compliance programs. One well-engineered data layer, configured to satisfy whichever rule is tighter, is cheaper and safer than two half-maintained ones.

Building it into the system

Data protection that survives an audit isn't a feature you add at the end. It's a set of properties designed into how data is stored and moved from the start — data protection by design, in the regulation's own words. In practice:

• Data mapping that stays current, so the inventory reflects reality rather than last year's org chart.
• Retention rules attached to data at creation, so archival and deletion happen automatically, not by memory.
• Access control — least privilege, real authentication (SSO/LDAP where it fits), so only the right people reach the right records.
• An audit trail that records who accessed what, turning "we think we're compliant" into "here's the log."
• Encryption at rest and in transit, and pseudonymization where the raw identity isn't needed.

None of this is exotic. It's disciplined engineering applied to a problem most teams have only addressed on paper.

When you need a data security project

Not every organization needs a full engagement. You probably do when:

If two or more of those are true, the gap between your policy and your systems is a liability waiting for a request, an audit, or a breach to expose it.

How we approach it

We treat compliance as a data engineering problem, because that's what it is. Our work on a data security engagement is discovery first — mapping where personal data actually lives — then building the mechanisms that make discovery, deletion and retention automatic and provable. We're engineers, not a law firm: we don't write your legal opinion, we build the system that lets your legal position actually hold.

The same discipline we bring to façade software and custom development applies here. A compliance claim you can't demonstrate in the system isn't compliance — it's a hope. Our job is to turn it into a property of the software.