Your organization has a privacy policy. You’ve done the training. So why does privacy keep falling through the cracks?
That’s the question we sat down to tackle in our first joint webinar with Digital Skills Agency. SkillsTX CEO Paul Collins and Digital Skills Agency Managing Director Daniel Merriott joined host Mary-Anne Merriott for a conversation that got straight to the point: privacy isn’t primarily a policy problem. It’s a capability problem — and most organizations can’t see that until something goes wrong.
Here’s a recap of the key themes from the session.
Watch the full webinar
1. Why privacy programs fail even with policies in place
The conversation opened with a deceptively simple question: why do privacy programs keep failing even when organizations have done everything ‘right’ on paper?
Daniel’s answer: people see privacy through the lens they’re most familiar with.
“If you’re an information security person, you see privacy as an information security problem. If you’re a data person or a legal person, you see it from that perspective.”
— Daniel Merriott, Digital Skills Agency
The result is that privacy becomes fragmented — handled in silos, bolted on at the end of projects, or left to one or two nominated experts who can’t possibly cover everything.
Paul framed it even more directly:
“Policy is a document. Capability lives in people. Training is a moment. Saying we have a policy and we’ve done the training is easy to count. Measuring how well you do privacy is much more difficult.”
— Paul Collins, SkillsTX
2. The capability blind spots leaders miss most often
Daniel identified two patterns that come up repeatedly:
- IT teams often have strong data management skills but limited focus on information management — the broader picture of how data is used, governed, and protected.
- Business teams tend to understand information management but lack depth on the data engineering side.
The gap between those two worlds is where privacy risk lives. And when organizations don’t have visibility into that gap, the signs only show up after the fact — in incidents, audit findings, or failed projects.
A useful diagnostic Daniel suggested: look at who conducts privacy impact assessments in your organization. If it’s one person, that’s a signal. Privacy impact assessments should involve people from different domains — technical, business, and legal — to bring different lenses to the same problem.
3. Privacy roles vs. privacy tasks — a critical distinction
One of the sharper distinctions in the conversation was between roles that exist specifically for privacy (Chief Privacy Officer, Data Protection Officer) and privacy tasks that should be embedded in roles across the organization.
Paul used the SFIA framework to illustrate: a software developer doesn’t need to be a privacy specialist, but they do need privacy as an attribute of their design skills. A tester doesn’t need a privacy title, but they should be testing with a privacy lens.
“It’s linking privacy into a DevOps role because you’re designing a software system — privacy needs to be designed in on day one.”
— Paul Collins, SkillsTX
Daniel put it this way: you can have all the right job titles at the top — a Chief Privacy Officer, a Data Protection Officer, a legal advisor — and still have privacy falling apart at the execution level if it isn’t embedded in how everyday work gets done.
4. What good skills visibility looks like
So what should leaders actually be able to see? Paul’s answer centered on transparency and specificity:
- Can you see privacy-related skills distributed across your organization — not just concentrated in one team?
- Are privacy expectations defined at a role level, not just at a policy level?
- Can you identify where you have one person covering something that should involve six?
Within SkillsTX, this kind of visibility is built into how roles are defined and measured. Organizations using the platform can run a privacy ‘slice’ through their workforce data and immediately see where the gaps are — before an incident surfaces them.
Paul also flagged something worth reflecting on: most skills platforms let managers see their people’s data. Fewer ask the follow-up question — who needs to see it, and why? Applying a privacy lens to your own skills data is itself a sign of maturity.
5. How SFIA helps map the gaps
Daniel explained how the SFIA framework brings structure to what can otherwise be a vague exercise. SFIA doesn’t just catalog skills — it defines what’s expected at each level, which makes it possible to measure actual behavior, not just stated knowledge.
Relevant SFIA skills in the privacy space include:
- Information and data compliance
- Information management
- Records management
- Data management
- Information security
SFIA also includes behavioral attributes — and one in particular stood out in the discussion: security, privacy, and ethics. This isn’t a skill. It’s a behavior expected of everyone in the organization, at every level — but what it looks like in practice changes depending on seniority and role.
“Having a loose or vague expectation of ‘you should generally follow privacy rules and laws’ doesn’t really tell people what to do or how to behave. Setting clear expectations is how you begin to hold people to account.”
— Daniel Merriott, Digital Skills Agency
6. What boards should be asking
The conversation wrapped up with a governance lens. What should boards and senior executives actually be asking to know they have real privacy capability — without getting into the weeds of every skills report?
Daniel’s suggested signals:
- Do we have the policies, and how do we know they’re actually being followed?
- Are we building privacy capability, or just assuming we have it?
- Is the improvement in skills translating into better business outcomes — fewer audit findings, privacy embedded in new projects by design?
Paul framed it from a risk angle: the board view is essentially a gap analysis. This is what our organization’s privacy capability should look like. Here’s where we actually are. What does closing that gap require?
“If you don’t know what you’re doing in the first place, you can be pretty damn sure you’re not doing it.”
— Paul Collins, SkillsTX
Key takeaways
- Privacy programs fail not because leaders don’t care, but because capability gaps are invisible — until they’re not.
- Having a policy and completing annual training is not the same as having privacy capability.
- Privacy needs to be embedded across roles, not siloed in a single team or title.
- SFIA provides a common language to define, measure, and track privacy capability across a workforce.
- Boards should be asking for evidence of capability, not just confirmation that policies exist.
One action you can take right now
We closed by asking both speakers for one concrete action a leader can take immediately.
Paul’s recommendation: get familiar with SFIA. It has well-defined skills around privacy and data protection, and gives you a common language to start assessing where you are. If you’re already using SFIA, start defining your requirements around privacy specifically.
Daniel’s: when you’re training people on privacy, focus on what you need them to do — not just what you need them to know. SFIA thinks about skills in terms of demonstrated capability, not knowledge held. Make sure your training does the same.
Watch on demand
[ Embed YouTube video here ]
Can’t watch right now? You can read the full transcript below.
Full transcript
Mary-Anne:
Welcome, everyone. Thanks for joining us today. We will be exploring privacy as a workforce capability problem, not just a policy or a training issue. We’ve all observed many times in our work that privacy initiatives rarely fail because leaders don’t care. They fail because capability blind spots tend to stay invisible until there’s an incident.
So today, we’ll cover three things: firstly, where privacy initiatives actually fail; secondly, what it means to build privacy as workforce capability; and finally, we’ll talk about what good skills visibility looks like and how SFIA and a skills platform can help with that.
My name is Mary-Anne. I’m the head of client success at the Digital Skills Agency, and I’ll be facilitating today’s discussion between Daniel Merriott, managing director at the Digital Skills Agency, and Paul Collins, CEO of SkillsTX.
Mary-Anne:
So tell me, just in one sentence each, what lens are you bringing to this privacy conversation today? Let’s start with you, Paul.
Paul:
The lens I’m going to bring is from a systems perspective. Privacy is a big deal wherever it is, but we’ve got to bring our solution to the market with a privacy lens. Any organization implementing systems needs to have that mindset around systems that work to the level you need as far as privacy and data protection’s concerned. So, a little bit techy.
Daniel:
I’ll take a workforce planning and capability perspective, but I also have a background in information security and some of the more technical aspects of privacy. So I’ll try and bring those in as best I can, too.
Mary-Anne:
Why do you think privacy programs tend to fail in practice even when organizations have policies and training behind it?
Daniel:
My experience has been that people tend to see the challenges from the domain they’re most familiar with. So if you’re an information security person, you see privacy as an information security problem. If you’re a data person or a legal person, you see it from that perspective.
And I think it’s important to note that privacy is not the same thing as security. It governs whether, why, and how you collect and use personal data. Information security is actually more concerned with governing how that data is protected.
Paul:
I sort of summarize it as: it’s someone else’s problem. We have documentation that describes it, and a little bit like quality control sometimes — “Someone else will look after that, I’ll just get on and do my things” — without really understanding that it’s really a cultural thing to some degree.
Mary-Anne:
What are the two or three blind spots you tend to see most often?
Daniel:
Generically, we see a lot of people leaders without the time to actually invest in managing their people and their professional development. That can have a real impact in terms of integrating good privacy practices into how the team works.
More specifically, IT teams tend to have good data management skills, but very few are focused on information management. And from the business side, they typically have a better understanding of information management, but not so good on the data management, data engineering side. So there are gaps that can be plugged by working better together.
Paul:
Policy is a document, capability lives in people. Training is a moment — we ticked a box, we did the training, job’s done. But no, that isn’t it. It’s got to be then applied and woven into the work you do. Saying we have a policy and we’ve done the training is easy to count. Measuring how well you do privacy is much more difficult.
Mary-Anne:
When an organization thinks it’s got itself covered on privacy, what are the signs that tell you they don’t actually have that capability?
Paul:
We start seeing incidents coming through. That’s the wrong time to measure it — that’s after the gate has been opened. The right approach is actually looking at how your roles are defined and whether you’re measuring your people against the expectation of a role and the privacy embedded within it. Documenting what privacy looks like in your organization at a role level.
Daniel:
Few organizations that aren’t large or have a specific requirement have jobs specifically targeted to privacy. So it’s usually an extra responsibility for a range of people. It can be seen in things like the distribution of skills. Are there one or two people with the skills for information management and information and data compliance, or is that spread across different teams? If you’re relying on just one or two people, that’s a good sign you’ve probably got the policies in place, probably written by those one or two people, but the implementation is perhaps lacking.
Mary-Anne:
How do leaders take that next step and create privacy as a proper workforce capability?
Daniel:
I’d go right back to: why do you care about privacy? Compliance is certainly one reason, and a very important one. But it can be something that enhances your brand reputation. It can be being a good corporate citizen and actually meeting your clients’ or customers’ expectations.
So if you can get to what’s the underlying reason why we as a business care, then get your senior leaders on board, and then actually take a look at what’s the capability we need. How much of that capability do you already have? What’s the gap? How do we build that? And then how do we change people’s work on an everyday basis so privacy becomes something that is routinely considered and factored into process decisions, design decisions, and so on.
Paul:
Quite often, we see the word ‘privacy’ within a job title rather than spread out across the organization as a component of many roles. If you look at it at a personal level — what would I want people to do with my data, who should be able to see it and why — and apply that when you’re involved in decisions around other people’s private data, then we’re starting to build the right mentality.
It’s putting specific roles whose job is to propagate privacy through other roles. They’ve got the authority and responsibility, but it doesn’t stay with them. It gets disseminated — linking privacy into a DevOps role, for example, because if you’re designing a software system, privacy needs to be designed in day one.
Mary-Anne:
Can you help us distinguish privacy roles that are focused on privacy from privacy tasks that are embedded in non-privacy roles?
Paul:
I can use the skills taxonomy to tease this out. Take a data protection officer — quite a lot of organizations have that role somewhere. Within it, there are very specific skills around being able to put policy together. That’s someone who is a specialist. We’re getting T-shaped roles.
When we drop that down into roles that don’t necessarily have an obvious privacy piece, it almost becomes what we call an attribute — a specialism against a particular skill. The example I was giving: someone doing software design or system design or programming with a privacy attribute. You’ve got your champion that really understands it. And then specifically somebody who’s got the skill of testing but with a privacy lens. That’s just a flavor of the skill. Some of our clients are actually in that space now, where privacy becomes part of the attribute of a skill.
Daniel:
That’s the difference between having accountable officers or senior execs and actually making it happen every single day. You can have your chief privacy officer, your data protection officer, your legal advisor. But then we have to have privacy by design — embedded into design practices, architectural standards, data management and data models, and business processes.
I was thinking about an example where I was working with a major retailer putting in a major change to how they handle credit cards. Some of the senior leaders couldn’t get their head around why they should care. But when I put it in terms of: if you lost all the records for your reward scheme, what’s that going to mean? Suddenly the marketing team said, “Whoa. That’s a major reputational issue. Our customers would never come back.” And then getting them behind how to embed change was really interesting.
We don’t just need the technical people involved. We also need people from the business who understand what privacy means for them. But those people also need to understand a little bit about design so they can work with the designers, too.
Mary-Anne:
What does good quality skills data look like for privacy? What’s the minimum you would want leaders to be able to see?
Paul:
Transparency is a big part of it. I’ve got an example of one of our customers right now who’s going through this — they’ve got a focus on privacy and they’re documenting the roles. So we can see those very clearly in the specialist skills. And it’s multi-domain. It isn’t like one person at the top covering everything — they’ll have privacy in different business units, but almost the same sort of title. Privacy where it relates to HR and employees, and privacy where it relates to customers or suppliers.
Those are defined using the skills in the SFIA framework. And then the next level down is having that propagation across pretty much all your organization — there’s a privacy lens. The role in itself might not appear to be a privacy role, but there’s a perspective within it. Whether you’re leading the test team, in program management or process design, that extra domain knowledge — what I call a skill attribute — against the skill.
There’s a skill called specialist advice. How many times is part of that that you’ve got the privacy lens? So if someone needs to know, you’re the person with the skill that can offer advice on privacy, data protection, whatever it might be. Does this organization have privacy running through their roles? That can be sliced and diced through the analytics. Yes or no.
Mary-Anne:
And how are leaders limited when they don’t have that kind of visibility?
Paul:
It’s almost a wish and a prayer, really. If you haven’t got it, you might have the capability, but you have nothing there to say you do. We live in a world of delta — these are the things we expect we should be doing compared to these are the things we can actually do. If you haven’t already set your to-be — what do we need people to be able to perform — then we can take that privacy slice through the data and say, “Wow, you really do have some blind spots. You’ve got one person who can do that thing. In your whole organization, you should have six.”
Mary-Anne:
How would you suggest that SFIA mapping helps highlight those capability blind spots more quickly than traditional approaches?
Daniel:
We have the skills already defined in SFIA. We actually have a skill specifically around information and data compliance. But for a long time, we’ve had skills like information management, data management, and information security skills. Those have been refined and updated with each version of SFIA to recognize that privacy is a dimension that people involved in security or information management or data management do need to be thinking about.
We’ve also now added behavioral attributes. One called security, privacy, and ethics — this is very much about making sure we have the protection of sensitive information, upholding privacy, demonstrating ethical conduct in how you work with your system, with your colleagues inside and outside the organization. That’s not a skill. That’s something we expect people at every level in the organization to embed. It looks different at different levels. But if you’ve got a leader who’s doing the bare bones basics of that, it’s going to have a knock-on impact in terms of how their team and the teams around them get to work.
Mary-Anne:
Once you’ve got that data and you’re tracking privacy capability over time, why is that useful to do over a period of time rather than as a one-off?
Paul:
It’s a right time, right place mentality. Having training ten months in advance of needing it is poor use of resources. Having that visibility of what we need people to do, with a privacy lens on it, allows you to deliver learning and development on a needs basis that can be immediately employed back in the workforce. And that is never ending — the ability to prioritize and deliver at the right time is just good use of time and money.
Daniel:
Showing the improvement over time is part of the justification for the training and effort that’s put into programs. If that’s not improving anything, that’s a very poor return on investment. I would also say capture business outcomes. Having the skills by themselves don’t give you the outcomes you’re looking for — they’re a leading indicator. So it’s a good sign you’re moving in the right direction, but you also need to couple that with: are you getting the business outcomes you’re looking for?
Measuring it based on incidents is pretty poor, but that’s base level zero. Actually checking: did we follow the process? Did we do the proactive things to make sure we have privacy embedded by design in our processes, in our tools? Checking for those proactively through internal audit would be a really good way to go.
Mary-Anne:
What would you recommend that boards and governance level executives should be asking for in terms of signals that they’ve got the right privacy capability?
Daniel:
Do we have the policies? Are they actually being followed? And how do we know they’re being followed — that’s a really good sign. I would also want to say: how do we make sure we’ve got this capability, and are we building it if we didn’t already have it? That should come out of some high-level reporting from the skills data.
I don’t want directors and board members really getting into the nitty-gritty of every last skill. But showing: hey, actually, we needed to improve in this domain, seven out of nine people have developed the skill the way they said, and those people are now involved in more of our programs of work. We have more trust in what they do. Oh, and actually, the internal audit results show that too. Those are really good signals.
Paul:
From the board side, it’s more the GRC view — looking for the improvements, but also doing the risk side: this is what we expect, this is what our organization should look like from a skills and privacy capability point of view. What is the gap? Because quite often that results in: now we need some resources, or we need to stand up a project to address it. Just almost a red, amber, green against skills that are privacy related as a gap analysis.
Mary-Anne:
What is one action a leader in this space can take right away to start reducing their privacy risk by improving their capability?
Paul:
I would give the Skills Framework for the Information Age a really good look at. It’s got some fantastic, well-defined skills around privacy and data protection. If you’re already using SFIA, start looking at or defining your requirements around privacy. A starting point would be to use a taxonomy that’s really got all you’d need within it.
Daniel:
100% behind what Paul said. Using a framework like SFIA that has a taxonomy and sets the expectations — that’s absolutely critically important.
I’d like to step one step backwards and just mention that SFIA thinks about skills in terms of what can you do, not what do you know. So when you’re training people to understand privacy, it’s not the understanding bit that’s the skill — it’s training them on what are they going to do with that new knowledge. Make sure you’re focusing your training on what we expect people to do, not just giving them knowledge. The knowledge is important, but let people know what you need them to do.
Mary-Anne:
That’s great. Thank you both. This has been a really good and insightful discussion on privacy and capability. Thank you to our viewers for joining us today. If you would like us to go deeper on a specific privacy challenge, send us your questions — this series is shaped by what leaders want to know.
About SkillsTX and Digital Skills Agency
This webinar is part of an ongoing series from SkillsTX and Digital Skills Agency on privacy and digital workforce capability.
SkillsTX is a skills intelligence platform built around the SFIA framework, helping organizations understand, measure, and build their digital workforce capability.
Digital Skills Agency works with organizations on workforce planning, capability development, and the people side of technology change.
