We Need to Talk: About IT Providers

The third-party risk nobody ordered, and got delivered anyway.

I co-founded an IT service provider and helped run it for years, competing against global corporations across more than a hundred projects. After that, I was, and still am, a CEO and board member on the other side of the table: the one receiving the proposal, signing it, and carrying the responsibility. So what I write here, I don’t write from the outside. I have held both roles, made the mistakes in the first one, and in the second sometimes had to clean up after exactly those mistakes myself, which was a good thing. Changing roles didn’t just change my perspective and my responsibility. Ever since, I have also seen the reality many companies are actually operating in.

It’s fundamentally easy to demand technology literacy from boards. I have done so myself, more than once, and I stand by it. But the demand is incomplete as long as it only addresses one side. Even a competent board can only decide as well as the groundwork it is given. And in many companies, that groundwork is supplied by an external provider who has their own commercial stake in the answer.

A Sequence I Have Seen in This Shape More Than Once

A business, a good hundred employees, infrastructure grown over the years. The person who built and, in places, jury-rigged the systems over the years leaves the company. Out of necessity, the company decides to outsource. The provider is expected to be cheap and to be able to do “everything.” Someone evaluates them, or someone just knows someone who knows someone. The collaboration starts well.

The seven-year-old firewall and the equally ageing servers get replaced. That’s overdue, it’s management debt from the past. But which components actually get used? Not necessarily the right ones. They’re the ones from the provider’s own portfolio. Whether the new firewall comes from vendor X or vendor Y rarely hinges on a technical requirement. It hinges on the partner programme, on purchasing terms, and on which certifications the provider’s own staff happen to hold. That doesn’t make the components bad. It just means they aren’t the result of a requirements analysis.

Then demand grows. Video conferencing, file shares, home office. The platforms used are the ones the provider knows. The local Exchange server gets migrated to the cloud, MS Teams goes live, and suddenly data sits in the cloud, locally, in Teams, and on the NAS. It then becomes apparent that, say, archiving is missing and mailboxes are getting flooded with spam. The provider has an answer ready immediately: a front-end email gateway. The product proposed is the one they know, and only that one, because they are not an email specialist, an archiving specialist, a data protection specialist, or a security specialist, and after a few teething problems it runs fine.

Two years later, the gateway vendor gets acquired, terms and the partner programme change, and a product switch follows. What gets replaced isn’t an architecture. What gets replaced is one product for a similar one. There is no comparison across several vendors or options, and the quote is unreadable for a non-technical reader: “ATP,” for instance, appears in it. That doesn’t refer to the Association of Tennis Professionals here. It means Advanced Threat Protection. The executive team sees three letters and a difference of thirty francs per user per year, which comes to three thousand francs for a hundred users. They go with the cheaper option, because IT costs are already seen as too high.

Then phishing emails keep getting through, and the question of why gets an answer that says everything about the relationship: with add-on module XY, including ATP, we could of course have caught those emails. If only the customer had known beforehand.

The Only Metric: It Runs

At this point, it’s worth asking what was ever actually measured across this whole chain. The answer is: function and availability, nothing else. No target architecture, no defined level of protection, no check on where exactly which problem was supposed to be addressed in the first place. And that is the real diagnosis here.

Because in the case described, the add-on module would have solved the one named problem. But the question isn’t whether to buy another licence. The question is where an attack path can be broken most effectively, at the gateway, the mail server, the firewall, or the endpoint. That’s first a question of use case, and therefore a question of architecture. Whoever doesn’t ask it buys modules, not security.

None of the individual decisions in this sequence was wrong on its own. And yet the outcome is unsatisfying, and a cybersecurity risk, because nobody actually decided on the end result. This company’s technology architecture emerged as a byproduct of procurement decisions and needs, spread out over years, each step plausibly justified on its own. That is the pattern I have seen across many companies, and it is more dangerous than any single bad purchase.

Why Providers Behave This Way

Fairness matters here, in both directions. This behaviour is rarely intentional. It follows an economic logic.

A provider with ten to twenty employees cannot be certified across half a dozen vendor ecosystems at once and know every product in full detail. Some of these products are, frankly, overloaded with features and complex enough that mastering even a single one properly is a real challenge. Partner programmes reward concentrating on one stack, not diversity. Recurring licence margins are predictable revenue, and therefore the backbone of the business model. A solid comparison across multiple products costs effort that nobody orders and nobody pays for, and it can make the provider’s own portfolio look worse. The result is portfolio logic instead of requirements logic. I have experienced these incentives myself, from the provider side, and I wouldn’t blame anyone personally for it.

The real sore point sits elsewhere. There is not a single point in this sequence where an independent judgement gets made. Whoever recommends the solution sells it. Whoever sells it would have to question their own earlier decision if something goes wrong. That is not a knowledge problem. It is an incentive problem, and it doesn’t resolve itself just because everyone involved has good intentions.

Certificates don’t resolve it either. An ISO 27001 certification for the provider attests to their own management system, within a defined scope. It says nothing about whether the architecture they build for you actually fits your risk profile.

Where Governance Theory Hits Its Limit

At the end of this chain sits the board. The oversight duty under Art. 716a para. 1 no. 5 OR cannot be delegated, and neither can accountability for the organisation. The service can be outsourced; the accountability cannot. I have described that in detail elsewhere, and nothing changes there, even though I know that in practice people are often tempted to delegate exactly this responsibility.

But the practical consequence gets stated far too rarely. A board here is overseeing an environment it never decided to build, whose risks were never fully laid out for it, and whose assessment comes from the very party that profits from it. When something goes wrong, the hot potato gets passed back and forth between providers, and what’s left standing is the executive team and the board.

There is also an asymmetry that usually goes missing in the discussion of third-party risk. The provider’s liability is typically capped contractually, often excluding consequential damages entirely. Business interruption, data loss and reputational damage, meanwhile, sit entirely with the customer. The provider barely carries any of the economic risk of their own recommendation. That’s why I now treat these contracts as a leadership issue, not a procurement issue.

I therefore still stand by the demand for technology literacy on boards and in executive teams. It’s necessary, but not sufficient. Governance can manage an information asymmetry. It cannot remove it.

Where I Draw Finer Distinctions Today

This doesn’t need more checklists. It needs three decisions that belong on the executive team’s table and on the board’s agenda, and they belong there before the next quote arrives.

• Separate judgement from sales. For any decision above a defined materiality threshold, someone who has nothing to gain from the solution assesses the requirement. That could be an independent specialist, an advisory board, or a second provider with no shot at the contract. The extra effort looks like added cost at first. Mistakes not made are savings too, they just don’t show up on any invoice.
• Keep your own keys. Who owns the Microsoft tenant? Who holds the global admin accounts? Who owns the solutions that get built? Where does the documentation live, and who owns it? If the answers all point to the provider, the dependency is no longer a contract question. It’s a fact. These are five questions any board member without a technical background can ask, and the answers can be verified.
• Treat architecture as a decision, not an outcome. Who in the company knows where which data sits and which component covers which risk? If nobody can answer that question, the architecture wasn’t decided. It happened. The same goes for investment appraisal: neither the cheapest nor the most expensive option is automatically the right one. The right one is the one that pays off over its useful life once risk, process adjustments and operating costs are factored in. You pay the real price either way, just later, and rarely at list price.

And a word to providers, without malice. The most reliable partners I have worked with were not the ones with the broadest portfolio. They were the ones who said, unprompted, where their expertise ends, and recommended bringing someone else in for that part, or who at least admitted they would need to build the know-how first, at their own cost. That costs revenue in the short term, but it builds the kind of relationship in which a customer actually starts listening. Whoever builds an infrastructure and then needs a second provider to close the gaps it created has a business model, but not a lasting mandate.

Summary

The debate about technology literacy on boards only covers half the conversation. The other half is that many companies run their most critical infrastructure on the recommendation of a party whose portfolio, margin and certification status all shape that recommendation, and who carries barely any of the economic consequences. That is another third-party risk nobody consciously bought. It builds up quietly, out of individually defensible decisions.

The board cannot resolve this asymmetry through expertise alone. But it can decide that an independent assessment sits between recommendation and decision, that access to its own environment stays in-house, and that architecture is an agenda item, not a byproduct. None of these three decisions requires technical training. They require the willingness to have a quote explained for as long as it takes to actually understand it. That is not just the board’s right. It is part of its duty of care.

Governance and practice collide right here, and practice always wins. Which is exactly why it matters who is in the room when the decision gets made.