I have walked into many organisations and found their privacy champions sitting through the same training as the compliance team. It is well-intentioned, but it is a recipe for glazed eyes and forgotten lessons by the time everyone gets back to their desks.
If you are running a hub-and-spokes model with privacy champions embedded in different teams, you cannot train them as though they are compliance managers. They are not. They are developers, support staff, marketers, or operations folks who have an additional responsibility to be your eyes and ears for privacy matters. Their day-to-day work looks nothing like what happens in a compliance office, and your training needs to reflect that reality.
The Disconnect
Picture this: you have a developer who needs to understand privacy by design principles, sitting through an hour-long session on data subject access requests and how to log them into your ticketing system. Meanwhile, your support team member who actually handles those requests daily is learning about HR practices they will never use.
Neither of them will retain what they have learned, because it is not relevant to what they do. And if it is not in their KPIs or directly tied to their role, it is simply not going to be top of mind when they are under pressure to deliver their actual work.
Making It Relevant
Role-based training works because it meets people where they are. Your developers need to know how to handle personal data in code, how to implement data minimisation, and what secure deletion looks like in practice. They do not need to become experts in responding to regulatory inquiries.
Your support team needs to understand what constitutes personal data when they are on a call, what information they should and should not be collecting in tickets, and how to recognise when a request is actually a data subject request. They do not need deep dives into database encryption standards.
Your marketing team needs to grasp consent requirements, legitimate interests, and what makes a privacy notice actually compliant. They do not need to understand the technical implementation of pseudonymisation.
Each role has specific touchpoints with privacy and security in their daily work. That is where your training needs to focus.
The KPI Reality
People are measured on what they deliver in their primary role. A developer is measured on features shipped and bugs fixed. A support agent is measured on tickets closed and customer satisfaction. If you pile on compliance training that feels disconnected from these metrics, you are fighting a losing battle for their attention.
But when you show a developer how privacy-aware code prevents production incidents and reduces technical debt, or when you show a support agent how proper data handling prevents escalations and improves customer trust, you are speaking their language. You are not adding to their workload. You are helping them do their job better.
Getting It Right
The best privacy and security training programs are built around actual scenarios from each team's work. Use real examples, anonymised of course, of where things went right or wrong. Walk through the decisions people will actually face, not theoretical situations they will never encounter.
Keep sessions short and targeted. Thirty minutes of highly relevant training beats two hours of general concepts every time. And make it ongoing, not a once-a-year checkbox exercise. Privacy and security should be woven into regular team meetings, sprint retrospectives, and project planning.
If you are struggling to design these training programs or your current approach is falling flat, reach out. I work with development teams and their leadership to build training that actually sticks because it is built around what people do, not what we wish they would remember.