The GDPR is an accountability regulation. Article 5(2) requires the controller to demonstrate compliance, not merely to achieve it. That distinction changes the deliverable: the output of privacy work is evidence that survives a supervisory question, a customer audit, or a subject complaint — not a policy set that has never been tested against the processing it describes.
Four activities carry a programme. Establishing the factual position through records of processing under Article 30, data-flow mapping, and supplier inventory. Deciding, through risk assessment and impact assessments under Article 35. Building, through data protection by design and by default under Article 25. Operating, through subject requests, breach notification inside the 72-hour window in Article 33, and processor oversight under Article 28.
The engineering half is where programmes usually fail. Controls that exist only in a document break the first time a team ships a feature, because Article 25 requires the measures to be implemented in the processing itself: defaults, minimisation, retention, access, and logging as built, not as described. Each of those is a decision a reviewer can verify in code.
In Poland the supervisory authority is the President of the Personal Data Protection Office, applying the GDPR alongside the Personal Data Protection Act of 10 May 2018. Evidence assembled for privacy purposes also carries into ISO 27001 control A.5.34 on privacy and protection of PII, and into NIS 2 obligations where the same systems are in scope, which is the argument for building it once rather than per audit.