KVKK & GDPR Compliance and Data Lifecycle Engineering
Starting from $7,500
(5 ratings) 1109 views
I move compliance out of the document layer and into the code: the retention period is a constant on the class rather than a line in a procedure, and a daily job enforces it. The masking rule is defined down to the minimum digest length, erasure is bound to a working function, and compliance texts are dated and audited.
SERVICE 5: KVKK & GDPR Compliance and Data Lifecycle Engineering
Compliance is usually mistaken for a documentation exercise: write the privacy notice, file the registration, put it in a folder. But the question asked in an audit is not what the text says — it is what the system actually does. If the notice claims 90 days of retention, that record must be gone on day 91, and a running piece of code, not a procedure document, has to guarantee it. I move compliance out of the document layer and into the code, so that every promise has a working mechanism behind it.
The work here is not filling in a template. It is binding, item by item, which data is collected and why, how long it is kept, who accesses it, how it is masked, and what is genuinely deleted when a deletion request arrives. Every number below was measured from code running in my own systems.
Data Lifecycle – High-Level Flow
| Collection Purpose limitation, data minimisation, explicit consent |
Processing Masking, hashing, access boundaries |
Retention Period pinned in code, automatic sweep |
Requests Access, rectification, erasure; 30-day response |
Evidence Audit trail, dated review cadence |
Why This Service?
Most compliance work is done to prepare for an audit day rather than for the system itself. The result is familiar: the documents are ready but the code knows nothing about them. By the time the gap is noticed, either data has leaked or an auditor has asked the question.
| Conventional Approach | My Approach |
|---|---|
| The retention period lives in a procedure document | The period is pinned in code and a daily job enforces it |
| Personal data is protected by saying "do not log it" | The masking rule is defined down to the digest length and is audited |
| Deletion requests are handled by hand over email | Deletion is a working function; the data classes it removes are countable |
| Compliance text is written once and forgotten | Review cadence is bound to policy; an overdue item fails the check |
| Anonymisation is done by "shortening" | Shortening is evaluated against collision risk; a minimum digest length is required |
| Compliance and product belong to separate teams | The rule is part of code review; a violation shows up during the build |
My Architectural Approach
1) Pinning Retention in Code
Writing "90 days" in a privacy notice is easy; making sure the record is genuinely gone on day 91 is a separate job. The retention period sits as a constant on the class, and a background job running once a day clears expired records with batched deletes.
The delete is deliberately done in batches; one giant DELETE can take a table lock and stall live traffic. The first sweep starts a while after application startup so it does not collide with deployment-time load.
2) Not Leaving Masking to Guesswork
Saying "do not log the national ID" is not enough; when it must be logged, how it is written has to be defined. The masking rule requires HMAC-SHA256 and a minimum 128-bit output.
Why is shortening forbidden? A 48-bit digest produces collisions across a set of millions because of the birthday paradox — two different people land on the same mask. That does not merely weaken anonymisation; it merges the wrong person's records. This is why the rule is written as a threshold rather than a preference.
3) Making Erasure a Working Function
When a data subject requests erasure, answering "your request has been received" is not enough; which data classes were removed has to be countable. Erasure is consolidated in a single function that walks the user's whole tree in order — profile, consent record, period-based rankings, submissions and the votes beneath them, invitations, identity record.
One exception is deliberate: purchase history is not deleted but converted into a trace record carrying no personal data. The reason is financial regulation; transaction records must be retained. The correct answer is not to ignore the record but to strip the identifier and detach it from the person.
4) Dating the Compliance Text
Compliance content written once and left alone ages quietly. The review policy binds every content item to a cadence class and pins files derived from KVKK and OWASP — because an external authority publishes updates — to a quarterly cycle. An item that does not match fails the automated check, so "forgetting to update" does not stay silent.
What I Deliver
| Area | What I Provide |
|---|---|
| Data inventory | Which personal data sits in which table, collected for what purpose, kept how long |
| Retention automation | Cleanup jobs with the period pinned in code, batched, and non-blocking for live traffic |
| Log masking | Defined masking and minimum digest length for identity, contact and payment fields |
| Data subject rights | Turning access, rectification and erasure flows into working functions |
| Notices and registration | Aligning texts with the system's real behaviour, versioning them, dating them |
| Children's data | Age gating, parental consent, and handling ad and purchase flows separately |
The Numbers Running in My Own Systems
The following are not examples but values measured from my own code. The most honest way to explain compliance is to show how you applied it to your own system.
| Component | Measure | What It Means |
|---|---|---|
| Retention period | 90 days / 5 tables | The period sits as a constant on the class, not in a procedure document |
| Cleanup job | 5,000-row batches / daily | Deletes without taking a table lock; the first sweep starts 30 minutes after startup |
| Masking threshold | minimum 128-bit digest | 48-bit truncation is forbidden; it collides at a scale of roughly 85 million |
| KVKK rule set | 8 rules / 30-day response | Requires a response within 30 days and one-way anonymisation |
| Review policy | 52 patterns / 6 cadence classes | KVKK and OWASP derived files are pinned quarterly; an unmatched item fails the check |
| Account deletion scope | 13 data classes | The single deliberate exception is purchase history: stripped of identity, kept as a trace |
| Visitor identifier | 32 hex characters | The day is part of the input, so the same address yields a different identifier tomorrow |
| Parental gate | 15-minute cache | A four-option check on the purchase entry; a wrong answer generates a new question |
Technologies I Use
ASP.NET Core background services, HMAC-SHA256 and salted hashing, structured logging with masking enrichers on Serilog, batched retention sweeps on MSSQL, server-side account deletion via the Firebase Admin SDK, the Google UMP consent flow, and automated date checks on rule files.
What I Deliberately Do Not Do
In compliance, an overstated promise is riskier than a missing one. The following are deliberate boundaries:
| Decision | Reasoning |
|---|---|
| Purchase history is not deleted | Financial regulation requires transaction records; the record is detached from identity, not ignored |
| Truncated digests are not used | A collision puts two people behind the same mask and breaks anonymisation |
| No legal opinion is given | This is an engineering service; interpreting legislation belongs to legal counsel |
| No "compliant" certificate is promised | KVKK is not a certification regime; what is delivered is demonstrable behaviour |
Project Deliverables
| Deliverable | Description |
|---|---|
| Personal data inventory | Data class, collection purpose, retention period and legal basis, table by table |
| Retention automation | Cleanup jobs that pin the period in code, run in batches and remain observable |
| Masking rule set | Which field is masked how, what the minimum digest length is, and how it is audited |
| Rights request flows | Access, rectification and erasure made to work end to end, with deadline tracking |
| Dated review cadence | Compliance content bound to a cadence class so overdue items surface in the check |
Who Is It For?
Teams that are not sure whether their privacy notice matches the system's behaviour; that suspect nobody is enforcing the retention period; that do not know whether personal data sits in their logs; that walk tables by hand when an erasure request arrives; that operate a product with child users; or that want to walk into an upcoming audit with evidence rather than paperwork.
Why Me?
I treat compliance as an engineering problem. Every number above was measured from code running in my own systems — the retention period, the masking threshold, the count of data classes erasure covers. If there is no working mechanism behind a promise, I do not write the promise.
This approach has a side effect: I audit my own texts too. When my site began keeping raw client information, the privacy notice did not say so; I noticed it, aligned the text with the system's real behaviour and raised its version. Compliance means the text changes when the system does.
Conclusion
Compliance is not a folder; it is the behaviour of the system. The moment what the text says diverges from what the code does, what you hold is not compliance but the appearance of it. The aim is for every promise to have a working mechanism behind it, so that when the audit arrives the answer is a measurement rather than a document.