Privacy is often treated as a Legal or compliance problem. Understandable, given the legislation, contractual obligations and potential penalties involved.
But having worked across information security, privacy and governance in financial services, payments and technology businesses, I think this view is too narrow.
Some of the worst privacy problems I've encountered weren't caused by a lack of policies or legal advice. They arose because organisations didn't fully understand what they were doing with personal data, how their systems operated or who was responsible for making decisions.
And sometimes, the information was already there. It was simply sitting in different parts of the organisation.
Everyone has done their job. So who's looking at the whole picture?
Consider a typical SaaS procurement.
Procurement has negotiated the commercial terms. Legal has reviewed the data-processing agreement. Information Security has completed a supplier assessment. Privacy has considered the processing, while Architecture understands how the service integrates with existing systems.
The business owner has approved the investment.
Everyone has done their job.
So why do we sometimes discover, much later, that nobody understood the complete arrangement?
I've encountered this problem both internally and when working with suppliers.
Legal may have negotiated a contractual restriction that the technical team knows nothing about. Security may have identified a dependency that Procurement hasn't considered. The business may have enabled new functionality that changes how personal data is processed, without realising that the original privacy assessment is no longer accurate.
Each function can point to a completed assessment.
The problem is that nobody has connected the findings.
This sort of compartmentalisation is more than an administrative inconvenience. It creates genuine risk, particularly where legal obligations, technical controls and commercial commitments need to align.
I don't think the answer is automatically another committee, policy or risk register.
Quite often, we need to make the existing governance processes work properly before adding more.
A green assessment doesn't mean a green supplier
I'm increasingly sceptical of the comfort organisations derive from point-in-time assurance.
We perform an assessment. Review the evidence. Record the findings. Agree the outstanding actions.
Everything is satisfactory, and the supplier is approved.
That tells us something useful about the supplier at the time of the assessment.
It doesn't necessarily tell us much about the supplier today.
Six months later, the provider may have introduced additional subprocessors, changed its support arrangements, moved processing to another jurisdiction or added AI functionality.
Meanwhile, our own business may have started using the service for something entirely different.
Yet the original assessment remains on file, reassuringly marked as complete.
Annual assessments, audits and certifications certainly have their place. I've spent enough time working with ISO 27001 and SOC 2 to appreciate their value.
But we shouldn't mistake evidence of compliance at a particular point in time for assurance that the risk remains adequately managed.
I'd much rather see risk-based, near-continuous assurance.
That doesn't mean monitoring every supplier around the clock. It means understanding which changes matter, detecting or being informed of them, and having a reliable process for acting on them.
A change in data-processing location, a new subprocessor, a material incident or a significant change in the supplier's service should trigger appropriate scrutiny.
Waiting another twelve months simply because that's when the next review is scheduled doesn't strike me as particularly sensible.
Most organisations already have the necessary components: change management, procurement, supplier management, information security and privacy.
The challenge is connecting them.
The DPO isn't there to accept everybody else's risk
Another recurring problem is the confusion between advising on risk and owning it.
I've seen situations where a project encounters a difficult privacy issue and the question becomes, "Will the DPO approve it?"
That rather misses the point.
The DPO has responsibilities to advise, monitor compliance and provide independent challenge. It isn't supposed to become the convenient owner of every difficult data-processing decision.
The same applies to the CISO.
Legal Counsel should explain the legal position. Privacy should explain the data-protection implications. Security should assess the technical risks and controls. Procurement should understand the contractual obligations.
But the business remains accountable for the activity, and the organisation remains responsible for complying with the law.
It's also worth distinguishing genuine risk acceptance from an attempt to ignore a legal obligation.
Management can accept legitimate residual risk within its authority. It cannot simply sign off unlawful processing because the commercial deadline is approaching.
Good governance should make those boundaries clear.
It shouldn't provide a route for passing difficult decisions around the organisation until somebody finally agrees to sign a form.
Security by design, privacy by design. Or just good design.
I've long regarded security and privacy by design as essential rather than optional extras.
In fact, the principle applies to just about anything.
You wouldn't sensibly build a house and then decide afterwards where the plumbing, electrical services and insulation should go.
You could, of course. But it would be unnecessarily expensive, disruptive and almost certainly involve compromises.
Technology is no different.
When security and privacy are considered while a system is being designed, there's usually some flexibility.
We can change the architecture, reduce the information being processed, restrict access or select a supplier with a more appropriate operating model.
Once the system is built, the supplier is contracted and the business is dependent on the service, those options become much more difficult.
I've seen too many cases where the relevant specialists are brought in just before launch, when almost every meaningful decision has already been made.
Security and Privacy then get blamed for holding up delivery.
Perhaps the more useful question is why they weren't involved when their advice could have influenced the design.
Bolting on controls afterwards is sometimes unavoidable, but it nearly always introduces additional work, cost or compromise.
And occasionally, there's no practical way to correct the original design without rebuilding something substantial.
Data minimisation: are we collecting information simply because we can?
A rather good example of poor privacy design is something many people will recognise: applying for jobs.
Why do some employers insist on collecting full referee details before they've even shortlisted a candidate?
These are details about other people, being collected, stored and potentially shared with recruitment platforms before there's any realistic need to contact them.
Surely it would be more proportionate to request them later in the process?
Then there are the equality and diversity questionnaires.
I understand the legitimate reasons for monitoring recruitment outcomes and identifying discrimination. Those are worthwhile objectives.
But there's something decidedly odd about a supposedly voluntary disclosure section containing mandatory fields that prevent the applicant from proceeding.
To be fair, some systems provide a "prefer not to say" option, so mandatory completion of a field doesn't necessarily mean mandatory disclosure of sensitive information.
Even so, we should be asking whether the information needs to be collected at that stage, how it is separated from hiring decisions, how long it is retained and whether applicants understand what's happening to it.
And now we have automated screening and AI-assisted recruitment adding another dimension.
The point isn't that employers shouldn't collect personal data.
It's that too many business processes appear to have been designed around what the technology allows rather than what is genuinely necessary.
Data minimisation is not particularly complicated as a principle.
Applying it requires somebody to challenge the requirements before the process becomes established.
Good governance shouldn't need detective work
I don't think effective privacy governance requires an ever-expanding bureaucracy.
It requires the organisation to understand what information it processes, why it needs it, where it goes and who can access it.
It also requires Legal, Security, Privacy, Procurement and the business to share information rather than operate independently.
Most importantly, the picture needs to remain reasonably accurate as the organisation changes.
A signed contract, completed DPIA and approved supplier assessment are useful evidence.
They're not substitutes for understanding the actual processing.
And if we struggle to maintain that understanding within our own organisation, it becomes considerably more difficult when we start examining suppliers, their subcontractors and the other organisations they depend upon.
That's where the problem becomes rather more interesting.
In Part 2, I'll look at international data transfers, cascading contractual obligations and the potentially uncomfortable consequences when risk starts propagating through a supply chain.
Further reading and references
ICO — Guide to accountability and governance https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/
ICO — Data protection by design and by default https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/
ICO — Data Protection Impact Assessments (DPIAs) https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
UK Government — Questions that allow you to monitor diversity in your workforce https://www.gov.uk/government/publications/questions-that-allow-you-to-monitor-diversity-in-your-workforce
Personal commentary. Views are the author’s own.