I've sat through loads of security training sessions over the years. Phishing awareness, password hygiene, secure coding practices—you name it, I've seen it, or delivered it. And if you're pursuing SOC 2 or ISO 27001 certification, your team has probably been through the same gauntlet. But here's what's been bugging me: where's the privacy training?

To be blunt: I'm getting grumpy about absolutism in privacy consulting. This post was spurred on by a LinkedIn post I saw this week by a privacy lawyer, one that seemed particularly green but equally vocal!

You know the type. The consultant or lawyer who proclaims that "consent MUST be done this way" or "fair processing obligations are absolute" without any consideration for the nuances of your actual business. They speak in certainties, as if privacy law exists in a vacuum, completely divorced from the messy reality of implementation.

I've lost count of how many conversations I've had with CTOs and dev leads that go something like this: "We know we need to address privacy, but we're still early stage. We'll get to it once we have more resources." And I get it, privacy programs can feel overwhelming, especially when you're knee-deep in product development with a lean team.

Here's the thing though: waiting until you're bigger isn't just risky from a regulatory perspective, it's expensive. Retrofitting privacy into an established product is like trying to rewire a house while everyone's still living in it. Possible? Sure. Pleasant? Absolutely not.

I ask this question frequently: "What's your privacy maturity looking like?"

The answer I get back, say eight times out of ten, is some variation of: "Oh, we're good on that front. We've got ISO 27001" or "We're SOC 2 compliant." And then there's a pause, as if that settles the matter entirely.

Here's the rub: it doesn't.

I've witnessed this scenario more times than I'd care to count: a promising startup or growing SME proudly tells me they've "sorted their cybersecurity" by engaging a managed security provider. They've ticked the box, satisfied their investors or clients, and moved on to focus on what they do best—building great software.

If you've been in software development for more than a few days, you've encountered technical debt. You know the drill: those quick fixes that were supposed to be temporary, the "we'll come back to this later" comments in the code, and the mounting pile of refactoring tasks that never quite make it to the top of the sprint planning board. What starts as a manageable issue slowly compounds until you're drowning in a codebase that's held together with digital duct tape and prayer.

The frequency that I hear "what security obligations?" or "what data processing requirements?" from CTOs is astounding, particularly for companies that are business-to-business (B2B) or serving European and Canadian markets. This leads me to think that technical leaders in these organizations are not prepared for a very large and very public compliance gap in their businesses.