Let me paint you a picture that I see far too often in growing tech companies. You've got multiple products, multiple development teams, and they all have access to production data. DevOps has keys to everything. Support can see client information whenever they need it. Dev teams can pull production databases for debugging. Everyone's happy because they can move fast and fix things quickly.

Your privacy officer, however, is having a quiet panic attack in the corner.

One of the issues I see repeatedly when working with development teams and their CTOs is the way companies treat email. Most organizations have their email configured as a permanent archive, keeping messages for the duration of someone's employment and then indefinitely thereafter "just in case we need it later."

This approach seems prudent on the surface, but from a privacy perspective, it's a ticking time bomb.

Companies are increasingly relying on security evidence collection platforms for their SOC 2, ISO 27001, or GDPR compliance programs, assuming that if the tool says they're compliant, they must be covered. The reality is quite different, particularly for privacy.

These platforms are excellent at what they do: collecting digital evidence, tracking policies, monitoring systems, and creating audit trails. They'll plug into your cloud infrastructure, pull logs from your applications, and generate reports that auditors love to see. But here's the catch: they only see what's digital.

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.

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.