There is a version of a privacy program that looks very solid from the outside. Policies written and filed. Trainings completed. Assessments sent. Controls documented. From a distance, it reads as a mature, well-run program.
Then something tests it, a regulatory inquiry, a data incident, a fast-moving business decision that needs a quick privacy sign-off and the gaps that were not visible in the documentation become evident in practice.
In a previous Myna Partners webinar, Dave Cohen and Aaron Weller walked through the patterns they see most often when privacy programs look good on paper but struggle in execution. And more usefully, what programs that hold up under pressure are do differently, allowing them to succeed.
Why Is Treating Completion as the Goal a Trap?
One of the most common failure modes in privacy program management is the instinct to finish things. Policies get written and filed. Assessment forms get designed and sent. Training modules get completed and logged. And then, implicitly, the work feels done.
Aaron described this directly in the session: the work is never done. It is temporarily stable. The programs that run into trouble are the ones where the team reaches a point of completion and stops looking for what needs to change next. The regulatory environment moves. The business changes. Vendors update their tools. A program that was adequate six months ago may not be adequate now and if no one is looking, no one knows.
The practical response is not to build a program that never finishes anything. It’s to build a program that treats completion as a checkpoint, not an endpoint and builds in the habit of looking again.
What Happens When Policies Lack People and Processes Behind Them?
The second pattern is more structural. Privacy programs often invest heavily in documentation – policies, procedures, templates, forms, without connecting those documents to the specific people and processes responsible for executing them.
A policy that says data subject requests must be handled within thirty days is not a control. It becomes a control when there is a named person responsible for it, a process for tracking it, and a way to know when it is not happening. Without those elements, the policy is a statement of intent, not a mechanism for managing risk.
Aaron’s team operates with a clear principle: proof, not promises. The question is not whether the policy says the right thing. It is whether there is evidence that the policy is operating in practice. That distinction is what separates programs that hold up under scrutiny from programs that look solid until they are tested.
How Does Fragmented Ownership Undermine Privacy Program Execution?
Privacy does not sit in one place. It sits at the intersection of legal, IT, security, the business, and often procurement. Each of those functions has a piece of the picture. None of them has the whole thing.
The programs that execute well are the ones that have mapped this explicitly, who owns what, who hands off to whom, and what happens when something falls between functions. The ones that struggle are the ones where ownership is assumed rather than assigned, and where accountability drifts into the spaces between teams.
“Fragmented ownership — I don’t think it’s reasonable to expect privacy to fix that. That’s just the way businesses operate. It’s more about acknowledging that’s the truth and making sure the fragmentation doesn’t get in the way of delivering what you need to.”
— Aaron Weller, Leader of Privacy Innovation and Assurance, HP
The answer is not to restructure the organisation. It is to build relationships and clarity within the structure that exists. That means knowing who the relevant stakeholders are across functions, maintaining those relationships actively, and making sure that when something needs to move across a boundary, there is a clear path for it to do so.
And importantly, training team members to produce measurable results and documentable evidence of controls working, not checklists of tasks or activities that have been completed and forgotten.
What Goes Wrong When Assessments Go Out and Do Not Come Back?
The assessment process is one of the most consistent operational challenges in privacy program management. Assessments get designed carefully, sent out on schedule, and then, nothing, or are returned incomplete. A follow-up email goes out. Another one. And eventually the team is left waiting on information that may or may not arrive.
The programs that handle assessments well have made a few deliberate changes. They schedule actual live discovery sessions, often with third party support, rather than relying on email alone, a video call with the relevant team to walk through what is being asked for and why. They work hard to make the assessment itself as light a lift as possible, asking only for what is genuinely necessary and never asking for information that was already provided recently. And they treat the assessment process as a relationship-building exercise, not just an information-gathering one. Additionally, care is taken to schedule efficient discovery sessions where every single person on the call is necessary, and hopefully can answer questions for multiple systems or processes.
Aaron’s point about looking at assessments from the perspective of the person receiving them is worth taking seriously. If a team member who has nothing to do with privacy cannot understand what is being asked or why, that is a design problem and not a people problem.
What Are the Programs That Hold Up Under Pressure Doing Differently?
Privacy programs that perform well under pressure share a few consistent characteristics. They are built around outcomes, not activities, the measure of success is not assessments sent but risks closed. They have explicit ownership for every compliance activity, mapped and visible to everyone involved. They invest in relationships across functions before they need something from those functions. And they treat the assessment and remediation process as a continuous cycle, not a periodic project.
Perhaps most importantly, they have defined what done looks like and they have built the infrastructure to know when something is really completed, and, importantly, when it has come undone again.
That last point is where the real operational maturity sits. Not in the elegance of the policies, but in the ability to confirm, at any point, that the program is working the way it is supposed to.
Frequently Asked Questions
Why do privacy programs fail under pressure even when they look compliant?
The most common reason is that policies exist without the people and processes needed to execute them. A policy is not a control until there is a named owner, a tracking process, and a way to know when it is not happening. Programs that look solid in documentation often have not connected those documents to real operational accountability.
What does “proof not promises” mean in privacy program execution?
It means the measure of a privacy program is not whether the right policies are written, it is whether there is evidence those policies are operating in practice. Under scrutiny from a regulator or during an incident, documentation is not enough. What matters is whether the program can show that controls are working.
How does fragmented ownership affect privacy program execution?
Privacy sits at the intersection of legal, IT, security, and the business. When ownership is assumed rather than assigned, accountability drifts into the gaps between functions. The programs that execute well have mapped this explicitly, who owns what, who hands off to whom, and what happens when something falls between teams.
Why do privacy assessments often go unanswered?
Assessments that rely entirely on email often stall because the people receiving them do not understand what is being asked or why. The programs that handle this well schedule discovery sessions, make the assessment as light a lift as possible, and treat the process as a relationship building exercise, not just an information request.
What separates privacy programs that hold up under pressure from those that do not?
Programs that perform well under pressure are built around outcomes rather than activities, have explicit ownership for every compliance task, invest in cross functional relationships before they need them, and treat assessment and remediation as a continuous cycle. Most importantly, they have defined what done looks like and built the infrastructure to know when something has come undone again.
>> Also in this series: When Should You Bring in Outside Support for Your Privacy Program?
