The trust problem

When you use a VPN, you don’t remove trust from the equation. You move it. Instead of trusting your ISP, you’re trusting the VPN provider. The traffic still goes somewhere, someone still has access to it, and the question of whether that someone will do something with it is still entirely a question of trust.

That’s a useful frame for thinking about a lot more than VPNs.

Every service you use, every platform you depend on, every piece of software that touches your data; all of it involves a trust decision. Usually an implicit one, made at the moment of signing up, buried in terms nobody reads, based on a vague sense that the company seems reputable and the alternative is doing without something convenient.

Not irrational, but it’s worth being honest that it’s what’s happening.

Trust in this context isn’t just about whether a company is trustworthy.

It’s about incentives. What does the company actually benefit from? What are they optimised for? What happens when your interests and their interests diverge, and they will diverge, at some point, because they always do.

A company offering free email isn’t doing it out of generosity. A platform that lets you store unlimited photos isn’t doing it because storage is cheap enough not to matter. A productivity suite bundled into an operating system isn’t there because the OS vendor thought you might find it useful. There are business models underneath all of these, and the business model is the thing that tells you what’s actually being optimised for.

Sometimes that’s fine, the incentives are roughly aligned with yours. The company makes money when you’re happy, so keeping you happy is genuinely in their interest. But sometimes the incentives are more subtle. The free service that funds itself through advertising needs your attention and your data more than it needs you to be satisfied. The platform that benefits from lock-in has a reason to make leaving difficult that has nothing to do with your experience of using it.

Understanding the business model is the first step to understanding the trust relationship.

There’s a specific version of this that comes up constantly in IT.

SaaS tools. Every team has accumulated them; the project management platform, the communication tool, the documentation system, the monitoring dashboard, the dozen other things that crept in over the years because someone needed something and this was the easiest solution. Each one made sense at the time. Each one involved, implicitly, a decision to trust a third party with some category of information about how your organisation works.

Individually, that’s usually fine. Collectively, it’s a sprawling web of trust relationships that nobody sat down and audited, with data scattered across services that have their own retention policies, their own security practices, their own terms that can change, their own acquisition risk. The information about how your team works, what you’re building, who’s talking to whom — a significant amount of it lives somewhere outside your control.

Most organisations accept this because the alternative is painful and the risk feels abstract until it isn’t.

The thing about trust is that it only becomes visible when it breaks.

The service goes down and you realise how dependent on it you’d become. The price increases and you discover how hard it is to leave. The company gets acquired and the new owner has different priorities. The terms change and something you relied on stops working the way it did. The breach happens and data you’d forgotten you’d shared turns out to have been sitting somewhere you didn’t think about.

None of these things are unusual. They happen constantly, to services of every size and reputation. The question isn’t whether they’ll happen but what you’ve done to limit the impact when they do.

Which is a question most people, and most organisations, haven’t really answered, because the trust was implicit in the first place.

This isn’t an argument for trusting nothing.

That’s not a workable position. Every useful thing you do with technology involves depending on something you didn’t build and can’t fully audit. The question isn’t how to eliminate trust from the equation, you can’t. It is about how to make the trust decisions consciously rather than by default.

What does this service actually know about me or my organisation? What’s the business model, and what does that tell me about how my data is being used? What happens if this service disappears tomorrow, how painful is that, and have I done anything to reduce that pain? Is there a version of this where I own more of the relationship?

Those aren’t questions with obvious answers. Sometimes the right answer is still the convenient managed service, because the alternative costs more than the risk is worth. But there’s a difference between reaching that conclusion after thinking it through and just never having thought about it.

Working in IT means you have the context to think it through.

You understand what it means for data to live somewhere. You know what APIs do and what access they grant. You’ve thought about dependencies and failure modes and what happens when something you relied on stops working. You have, professionally, opinions about these things.

The trust problem isn’t that people are making bad decisions. It’s that most of the decisions aren’t being made at all. The defaults got set, the services got used, the trust got extended, and nobody quite noticed it happening.

Noticing it is most of the work.

The rest is just deciding, with that in mind, where you actually want to put your trust.

And why.