As a fractional privacy engineer working with development teams, I often get called in after the fact. A feature has been built, it's ready to ship, and suddenly someone realizes there might be a privacy problem. The scramble that follows is never fun for anyone involved.

The good news is that there are clear red flags that should signal to your team that it's time to loop in privacy expertise. If you catch these early, you can save yourself from costly redesigns, delayed releases, or worse: regulatory complaints and fines.

A few days ago I attended the OWASP Toronto chapter, where agentic AI took centre stage from a security perspective. It confirmed something I'd been sitting with for weeks, and honestly, it wasn't comfortable.

Every relationship has a moment where someone needs to say it out loud. The dev team and the privacy office have been growing apart for a while now, and agentic AI just accelerated things considerably. The privacy office is still setting ground rules for the first date, and the development team has already moved in together, redecorated, bought a hot-tub, and is halfway through building an extension.

I spend a lot of time talking to development teams about implementing privacy requirements. It's necessary work, but here's what I've learned: by the time privacy lands on a developer's desk, you've already missed half the opportunities to get it right.

Privacy isn't a coding problem. It's a product problem.

If you're leading product management, design, or research teams, privacy is just as much your responsibility as it is your developers'. The difference is that when you get it right early, you save your team from the nightmare of retrofitting privacy into a product that was never designed for it.

I talk to a lot of founders and early-stage CTOs who just flake out when they hear about privacy compliance. They've read about GDPR fines, watched competitors scramble with incident response, and now they're convinced they either need a bulletproof privacy program before they can even ship their MVP, or nothing at all. The result in both cases? Paralysis.

Here's what I wish all founders were told: you don't need to implement every privacy requirement under the sun on day one. Privacy compliance isn't an all-or-nothing game.

When I'm working with development teams on privacy compliance, there's a persistent assumption that seems to pop up : "We've got a Master Services Agreement with our supplier, so we're covered for data protection."

Not quite.

As much as I love a hub-and-spokes model, I've walked into many organizations and found their privacy champions sitting through the same training as the compliance team. It's well-intentioned, sure, but it's also a recipe for glazed eyes and forgotten lessons by the time everyone gets back to their desks.

There's an old saying in IT circles that has caused more headaches than it has solved: "If it ain't broke, don't fix it." On the surface, this seems like sound advice. Why tinker with systems that are humming along nicely? Why risk introducing new issues when everything is stable?

The problem is that this philosophy, while comfortable, can quietly transform from prudent caution into outright negligence.

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.