"We Just Build the Software" Isn't a Privacy Strategy

There's an assumption that runs deep in the outsourced development world: privacy is the client's problem. You're not collecting the data, you're not running the business, so the obligations must sit with them. Right?

Not quite.

I work with software companies ranging from small dev shops to teams of a few thousand, and this assumption is one of the more expensive ones I see. The reality is that outsourced and white-label development companies carry more privacy obligations than most of their leadership teams realize. And by the time they find out, it usually involves a client contract review, a procurement questionnaire, or a regulator.

Let's unpack where those obligations actually come from.

Jurisdiction follows you, not just your clients.

Just because you're building for someone else doesn't mean the laws of where you operate stop applying to you. If you're based in Canada and you have employees, PIPEDA and provincial laws apply to you. Your employee data, your internal processes, your vendor relationships: all of it falls under that umbrella. If your clients are in the EU, you're operating as a data processor under GDPR, and that means you need a privacy program in place to hold up your end of those data processing agreements (DPAs). Jurisdictional legislation doesn't ask whose idea the product was, it asks who's touching the data.

You're responsible for how you handle what flows through you.

When client data lives in your development environments, sits in your databases during a project, or passes through your CI/CD pipelines, you're not just a passive conduit. You have obligations around how that data is handled, how long it's kept, and what you're allowed to do with it. And here's the thing: the answer to "can we use this for our own purposes?" is almost always no.

That means having policies. It means having controls. It means being able to demonstrate to a client, or their regulator, that the data processed on their behalf was handled appropriately. "We just build the software" doesn't satisfy a procurement team running a vendor risk assessment.

Your workforce is its own layer of complexity.

Outsourced dev teams often have people embedded at client sites, contractors working across multiple jurisdictions, and staff agreements that were drafted when the company was a fraction of its current size. The privacy and labor requirements around these arrangements are genuinely complicated. Subcontracting chains, data access controls, policy acknowledgment, device and network policies: these aren't nice-to-haves. They're the kind of gaps that surface at exactly the wrong moment, like during a client audit or an acquisition due diligence process.

The good news is that building a privacy program for an outsourced software company isn't the same as building one for an enterprise collecting consumer data at scale. It can be right-sized to where you are and structured around the workflows you already have. It just needs to actually exist.

If you're not sure where your obligations start and end, or you want to get ahead of the next client questionnaire rather than scrambling through it, reach out through rossgsaunders.com. This is a space I've spent a lot of time in, with dev companies from small teams to a couple of thousand people, and I'm happy to help you get clarity on what you actually need.