UU PDP: Translating the Law Into Technical Controls

UU No. 27/2022 sets out obligations for data controllers and processors, but like most privacy legislation it stops short of prescribing technical implementation. Engineering teams are then asked to “comply” without a control specification. This is the mapping we use to bridge that gap.

Obligation: lawful basis and consent records

Technically, this means every collection point needs a persisted record of which consent version was accepted, when, and by which subject identifier. Consent state must be queryable at the time of processing, not just stored for audit.

Implement consent as a service with versioned policy documents, and require processing systems to check it rather than trusting an application-level flag.

Obligation: data subject rights

Access, correction, and erasure requests require the ability to locate every copy of a subject’s data. In most environments this fails not because of the primary database but because of analytics warehouses, log aggregation, backups, and CSV exports on staff endpoints.

Build a data inventory that records where personal data flows, and implement erasure as a coordinated workflow across every listed system rather than a single delete statement.

Obligation: security of processing

This is where offensive testing directly supports compliance. Encryption at rest and in transit, least-privilege access, and segmentation are the baseline. Demonstrating that these controls actually hold under attack requires testing them, and the resulting report is exactly the evidence a supervisory authority expects.

Obligation: breach notification within 72 hours

Notification is a detection problem before it is a legal one. Without logging that lets you determine which records were accessed and when, you cannot make an accurate notification, and inaccurate notification carries its own consequences.

Ensure that any system holding personal data produces access logs with subject-level granularity, retained long enough to reconstruct an incident timeline.

Obligation: processor accountability

Every vendor processing personal data on your behalf needs a written agreement with defined security requirements, and you need a mechanism to verify those requirements. In practice this means annual assessment for high-risk processors and contractual right-to-audit clauses that you actually exercise.

Getting started

Begin with the data inventory. Almost every other obligation depends on knowing where personal data lives, and organisations that skip this step end up rebuilding their entire compliance programme once the first data subject request arrives.