Your vendor register isn't a crisis plan

Imagine an ordinary Tuesday. It’s 09:14. An employee calls IT and says they can’t get into the case management system. Two minutes later, another call. Then five more. Within fifteen minutes it’s clear that nobody can log in — not into the case system, not into email, not into finance. Everything is “up”. But the login at your identity provider isn’t responding.

What do you do now?

If the answer is “we pull out the vendor register and see who we have a contract with” — then you’re starting from the same position as most organisations in Sweden today. And it isn’t enough.

The register tells you what you have. Not what’s happening.

Almost every organisation has a vendor register. Names, contracts, classification, last review. It looks tidy and well-kept, and it’s often required by NIS2 and the Cybersecurity Act.

But a register is a list. It’s organised around who you have a contract with, not around what actually has to work for the business to deliver.

And that gap is where the problem lives. Because when something happens, the question is rarely “who do we have a contract with?”. The question is:

• Which decisions can we not make right now?
• Which services to citizens, customers or patients are no longer working?
• How long do we have before there are real consequences?
• Who in our organisation decides what — and with what mandate?

A register doesn’t answer those questions. A dependency map does.

What “breaking” actually means

When leadership teams talk about disruptions, many instinctively think of a server crashing or a data centre burning down. It happens, but it isn’t the common case.

The common case is less dramatic — and more treacherous:

• Login stops working. Everything is “up”, but nobody can get in. Email, case management, finance: all unreachable because they share the same identity service.
• A certificate expires. Two systems stop trusting each other. The integration goes silent. Nobody notices until someone wonders why the invoices aren’t arriving.
• A SaaS vendor freezes the account in the middle of a contract dispute or after a missed payment. The technology works perfectly. You just no longer have the right to use it.
• Support doesn’t respond. Not within the SLA, not in the first hour, not in the third. The contract says one thing. Reality says another.
• Sub-suppliers you didn’t know existed run into trouble. Your SaaS vendor uses another SaaS that uses a cloud service that is currently degraded. You have a contract with one. Reality has five.

None of this is in the vendor register. It has to be mapped separately.

The dependency map — from list to capability

A dependency map isn’t a document. It’s a model of the business where each important capability — making planning decisions, paying salaries, admitting patients — is connected to the systems, suppliers and people that must work for the capability to exist.

It does four things a register cannot:

1. It shows what actually stops working. When the identity service is down, knowing that Microsoft is the vendor isn’t enough. You need to know that 340 employees can’t make decisions, that three statutory response times are running, and that your public e-services are still accepting cases that nobody can handle.

2. It points out who decides what. A serious disruption rarely triggers a single decision. It triggers ten. Should the e-service be closed to the public? Should manual procedures be activated? Should citizens be informed? Who has the mandate to decide what, and who’s the backup if that person is on holiday? This has to be clear before the crisis, not during it.

3. It gives a realistic picture of endurance. “How long can we cope?” is the question leadership always asks. Without a map, the answer is a guess. With a map, the answer is concrete: finance can manage two business days because invoices can wait, but payroll has a hard deadline on Friday. That changes the priority completely.

4. It sharpens escalation. The difference between “your service is performing poorly” and “your disruption is blocking 340 employees from making statutory decisions and we have response deadlines running” is enormous. The first is a support ticket. The second moves you to the top of the vendor’s priority queue.

What NIS2 and the Cybersecurity Act actually require

There’s a common misunderstanding here. NIS2 and the Cybersecurity Act require you to have your suppliers under control: contracts, classification, review. That’s vendor management.

They don’t require dependency mapping explicitly. But they do require you to be able to handle incidents, maintain continuity and report impact on essential services within short timeframes. That isn’t possible without knowing what actually stops working when a supplier goes silent.

In other words: the vendor register meets the letter of the law. The dependency map meets the spirit. That’s what keeps you from going blank when something really hits.

Where do you start?

The simple answer: don’t start with the technology. Start with the business.

List your five to ten most important capabilities. Not systems — capabilities. “Make decisions on planning applications.” “Pay salaries on time.” “Admit emergency patients.” For each capability, ask three questions:

1. Which systems, services and suppliers must work for this capability to exist?
2. What do we do if each of them is unavailable for six hours? For 24 hours? For three days?
3. Who in our organisation decides what in each scenario — and who is the backup?

This isn’t technical work. It’s leadership work. IT can help with the mapping, but the prioritisation and the decision-making mandates belong to the business.

When it’s time to bring in help

For many organisations, this is the work that constantly gets pushed forward. Not because nobody knows it’s needed, but because the day-to-day is full of other priorities. And the expertise to lead the work often doesn’t exist in-house.

That’s exactly where VER&IT comes in. With our CISO-as-a-Service, you get an experienced security leader who runs the dependency mapping with your leadership team. No new hire required. And with SecuraPilot, our information security platform, the register, dependencies, continuity plans and incident handling are gathered in one place, so the map doesn’t end up as a PDF ageing in a folder.

The result isn’t more documents. It’s that leadership, the next time the alarm goes off, actually knows what’s happening, and what to do about it.

A vendor register gives you a list of names. A dependency map gives you a plan.

Want to see what a dependency map would look like in your organisation? Get in touch with VER&IT — the first conversation is on us.