15 posts into “Beyond Legal”: what's been covered so far
Fifteen posts in, Beyond Legal has explored why effective data protection (and AI governance) is less about legal interpretation and more about building real organisational capability across risk, engineering, operations, governance, communication, and measurement.
When I started writing my Beyond Legal series of blog posts, I wanted to challenge a default setting in our field: data protection is often treated as a legal topic, owned by legal professionals, solved with legal artefacts.
Of course, the laws themselves matter a huge amount. But succeeded in data protection isn’t just about legal interpretation. It also requires companies to fully understand how personal data is *actually processed *in their unique context, make sound decisions under uncertainty, and operationalise controls across their systems.
Now that I’ve published 15 posts, here’s a brief summary of what’s I’ve covered so far, organised by themes rather than in chronological order, because the point of the series isn’t “yet another GDPR explainer”. It’s a journey involving recognising and building the needed capabilities.
1. The real problem isn’t that the GDPR is hard. It’s that the job is bigger than “legal”
This past year there’s been a lot of commentary in data protection highlighting frustrations around “GDPR complexity” often blaming the regulation itself, rather than looking inwards questioning whether companies have the needed capabilities.
Posts:
Core takeaway: when we frame data protection as primarily legal, we over-invest in legal outputs and under-invest in delivery capability.
2. Risk competence is not optional, it’s the operating system
Data protection work is risk work so a functioning and effective risk management system needs to be at the heart of a data protection leader’s work. But risk often gets reduced to vague language (“low risk”, “medium risk”) without shared methods, shared definitions, or decision discipline. The result is inconsistent and subjective decisions, a false sense of being in control, and either blanket blocking (“no!”) or rubber-stamping.
Posts:
Core takeaway: if you want data protection (and AI governance) to be credible, you need to be able to analyse and communicate risk in a way that stands up outside the legal function.
3. Governance isn’t a pile of documents. It’s coordination.
Another theme: “governance” is widely misunderstood. Too often, it becomes a synonym for policies, templates, committees, and reporting. But governance is the practical reality of who decides, based on what, with which controls, and with what feedback loop.
Posts:
Beyond legal #5: Get to know your data management and data governance colleagues
Beyond legal #7: You can’t protect what you are not aware of
Core takeaway: you can’t govern what you can’t see. Awareness of data, flows, systems, and ownership is a precondition for meaningful protection.
4. If you don’t show up in engineering, you’re not in control.
This is where “beyond legal” becomes concrete and involves visiting the trenches, or engine room. If privacy or data protection considerations are not embedded into how products and systems are built and changed, it will always be late, reactive, and labour-intensive…and expensive.
Posts:
Core takeaway:** **scalable data protection is engineered. The most effective controls are designed and built into systems and delivery processes, not bolted on afterwards.
5. Training and measurement
A lot of companies can prove they did something (training delivered, DPIAs completed, RoPA entries updated). Fewer can show that the something mattered: improved behaviour, fewer incidents, better design decisions, reduced rework, improved time-to-safe-release.
Posts:
Core takeaway: if you want behavioural change, you need communication that competes for attention and metrics that reflect actual impact.
6. When incidents happen, operations beats legal theatre.
Personal data breach response is the ultimate test of whether your “governance” is real and effective. In the moment, what matters is coordination, clarity, and rehearsed operational capability, not beautifully written policies.
Post:
Core takeaway:** **legal advice is essential, but it can’t substitute for operational readiness.
7. Third parties: contracts don’t create trust, practices do.
Vendor risk and third-party data protection is often approached by prioritising signatures on documents. But signatures don’t operate controls. Ongoing assurance does - and that requires relationships, transparency, and governance mechanisms that work after onboarding.
Post:
Core takeaway: third-party governance is a living system, not a one-off legal transaction.
8 RoPA, business analysis, and “data sovereignty” debates.
Two later posts push into a broader category. Our tools and concepts often fail when they’re trivialised or detached from the reality of daily operations.
A RoPA that doesn’t reflect how processing actually takes place is a paper tiger and a wasted investment. Understanding and living up to Data sovereignty requirements is complex and involves a huge amount of hard work of trade-offs, assessing risk, and system design.
Posts:
Core takeaway:** **good governance needs working models that reflect reality, and leaders who can navigate trade-offs.
What’s still to come?
More posts will follow, continuing to map the competences needed for modern data protection and AI governance leadership, and to challenge the idea that data protection and privacy is primarily a job for lawyers. If you’ve been reading any of my posts, I would love to hear:
Which theme has been most relevant to your work?
Where is the biggest capability gap in your company right now (risk, engineering, operations, measurement, governance)?
What should the next set of posts explore?
