Most companies treat GDPR like a driver’s licence test. Study hard, pass once, get the certificate, and then move on with this one-off exercise. But complying to GDPR is not the same as passing a simple test.
Picture this: A letter from the Data Protection Authority lands on someone’s desk. The request doesn’t seem too complicated: “provide evidence of how the organisation has managed privacy over the past two years.” Easy enough, surely. Just pull the decision logs, DPIA outcomes, training records, vendor reviews, breach handling…
Then the real struggle begins. Privacy notice? Check! Cookie banner? Done! Beyond that, things fall apart. Nobody can produce evidence of anything happening consistently. The policies exist but there is no trail showing they were ever used. The DPO left eight months ago, and their replacement has been stitching things together from email threads ever since.
You guessed it. What was missing? A privacy programme!
What is a privacy programme?
A privacy programme is how an organisation runs privacy day to day. It covers governance, processes, controls, roles, documentation, and the culture around all of it. Put together, it makes privacy something the organisation actively does, not a folder of PDFs it owns.
It helps to be clear about what a privacy programme is not. It’s not a DPIA, a record of processing activities, or a policy overview. It is also not a remediation projects that ends when the last finding is closed.
The closest analogy is an information management system. A privacy programme is to GDPR what an ISMS is to ISO 27001:a management system to manage privacy within your organisation (not just documented)
Do we need a privacy programme?
We can offer four reasons to answer yes. The first two are legal, the second two are practical.
Accountability is a programme-level obligation.
Read Article 5(2) and Article 24 GDPR carefully. It does not ask you to be compliant. However, it does ask you to demonstrate compliance on an ongoing basis. That can’t be achieved through a single document, or even a wide array of them. It lives in how the organisation operates everyday.
Evidence of sustained management
When the Belgian DPA or a peer authority opens a file, they rarely care whether your privacy notice is elegant or well-written. They want decision logs, DPIA workflows, breach timelines, training records, and vendor reviews. Organisations without a programme tend to struggle here, because the evidence does not exist or cannot be produced in a usable form.
Ad hoc prevents scaling your company
One product, one controller, one processor, one country? Handling privacy questions as they copme might just about work. But add controllership, international transfers, a differentiated product portfolio, and AI systems, and the ad hoc modelbreaks down. It becomes a bake on growth, not a support for it.
AI Act convergence is coming.
Article 9 of the AI Act requires a “risk management system” for high-risk AI: This is a continuous iterative process running across the entire lifecycle of the AI system, with regular review and updates. This is structurally very close to what a mature privacy programme does. If you have one, extending it to AI is challenging but achievable. If you do not, you are building two governance models at the same time. Most organisations do not have the budget or the people for that.
What’s in a privacy programme?
At CRANIUM, we work with our very own framework (based on ISO 27701) to build a privacy programme. This framework rests on eight building blocks, with the programme itself as the ninth that ties them together. This could serve as your base as well:
- Awareness and communication. Think of training, privacy champions, role-specific guidance, internal messaging and more. An important part of awareness and communication is assigning people to own the programme to integrate it into your company culture.
- Record of processing activities. Your inventory of what data you process, why, on which legal basis, and where it ends up..
- Data subject rights. How access, deletion, objection and portability requests are handled. Ideally automatically and with a defined retention period.
- Relationship with external parties. Processor agreements, sub-processor flow-down, and vendor review before the contract goes live.
- International data transfers. Chapter V mechanics: SCCs, TIAs, BCRs.
- Data breach management. Detection, internal escalation, notification to the GBA/APD and to data subjects where required, and the post-incident review to keep improving your processes.
- Privacy by design and by default. Privacy embedded in how new processes, products and tools are built, rather than bolted on at the end.
- Technical and organisational measures. Every control (organisational, people, physical and technological) implemented to reduce, minimise and/or eradicate risks (not) implemented.
While a lot of companies will chase compliance, ‘evidence’ is often forgotten. “We have a policy” is then not sufficient when you are governing your data protection.
Evidence looks like this: a completed DPIA with a decision log attached, a data subject request handled on time with timestamps, a training record linked to a named employee, a vendor review signed off before the contract went live.
The good thing is that once your privacy programme is up and running, it should be smoother sailing from that point onwards. When people leave or priorities change, the programme remains steady and can be exercised regardless.
Are there any privacy frameworks out there?
You do not have to invent a privacy programme from scratch. Several frameworks give you a structure to start from. Four are worth looking into:
ISO/IEC 27701 is the international standard for a privacy information management system. It extends ISO 27001, so if you already have 27001 certified, 27701 is the most natural next step.
NIST Privacy Framework is outcome-oriented and risk-based. It is flexible, widely adopted in the United States, and maps cleanly onto existing security controls. A good choice for hybrid EU/US organisations.
AICPA GAPP (Generally Accepted Privacy Principles) is audit-friendly and built around principles that translate well to management reporting. Useful if your organisation is already audit heavy.
EDPB Guidelines 07/2020 on accountability are not a framework in the same sense, but they are the EU regulator baseline for what a good programme looks like.
Which one to pick? Follow your existing standards. An ISO 27001 organisation goes to 27701. A US-heavy footprint points to NIST. Audit-driven governance fits GAPP. A pure EU focus can lean on EDPB accountability guidance and borrow structure from one of the others.
Where do we start?
An organisation cannot do everything at once, nor will buying a tool blindly immediately solve all issues. This is why we recommend to starting with an honest and internal maturity assessment. What do you have in place? Strong points, weak points? Where to improve?
According to these findings, you can start to pinpoint your priorities. We recommend starting with the foundation:
- Record of processing activities
- Data subject rights
- Data breach management
- TOMs
Once these are running, you can build out the blocks that take longer to mature:
- Relationship with external parties (vendor due diligence, processor agreements)
- International data transfers
- Privacy by design and by default (DPIA methodology sits here, as does retention enforcement on the design side)
- Awareness and communication (basic training early, role-specific guidance and a champions network later)
Once the priorities are in place, you can start mapping them and determine a realistic schedule such as 12 to 18 months to move from ‘ad hoc’ to ‘programme-managed’.
Lastly, going beyond the formal privacy programme, is part of your company’s culture. How you and your colleagues react and adapt a programme is always unique and should be accounted for accordingly. How do you implement change in your organisation, who are the drivers, which processes require more care? These questions need to be answered before your programme can be adopted.
Conclusion, a trap?
The companies that run into trouble with privacy rarely fail on just a ‘single’ requirement. They fail because they treat privacy as a project, another box to check.Projects may end, however, privacy does not. On the contrary, the more a company grows, the more complex it becomes to manage it (and your customers, as well as regulators, demand it) e.g. AI systems, biometric data, cross-border flows, etc.
A privacy programme stops the scramble. Instead of reacting to each issue as it lands, you build a system that keeps pace with your growth and stays ahead of what regulators expect.
