What else stops? Understanding IT system and supplier dependencies

Most organisations can produce a list of their IT systems. Far fewer can answer a more important question:

What else stops when one of them goes down?

This is increasingly not just a useful question for IT operations. Understanding dependencies has become an explicit part of cybersecurity and operational resilience regulation.

In Norway, the Digitalsikkerhetsforskriften requires covered providers of essential services to document the importance of their network and information systems to the delivery of the service, as well as the extent to which the organisation depends on other organisations in order to function. Suppliers that can affect the security of those systems must also be followed up.

NIS2 takes the same direction at EU level. Supply-chain security is one of the required cybersecurity risk-management measures, and the Directive specifically addresses critical dependencies and potential single points of failure in supply chains.

For financial organisations, DORA goes further. It requires organisations to identify ICT-supported business functions and the assets supporting them, including their dependencies, and to map links and interdependencies between ICT assets. It also requires identification of processes dependent on ICT third-party service providers.

There is a good reason for this.

A system register tells you that a system exists. It may tell you who owns it, which supplier delivers it, what information it processes and how important somebody believes it is.

It does not necessarily tell you that seven other systems stop the moment it does.

And a supplier register does not necessarily tell you which of your five hundred suppliers is the one you genuinely cannot lose.

That information often exists somewhere in the organisation. The problem is that it exists in people's heads.

You discover it during an incident, a risk assessment, a due-diligence exercise or when somebody asks a seemingly simple question in a management meeting.

We built dependency analysis in Cyrigo to make those dependencies visible — and useful.

From a system register to a dependency map

Systems depend on other systems. A payroll system may depend on an identity provider for authentication, while a reporting system depends on several operational systems for data.

The important question is not simply whether systems are connected, but what happens when a dependency disappears. Some dependencies are essential: the system stops without them. Others allow it to continue with reduced functionality.

Capturing that distinction turns system dependency mapping into something useful for risk management, business continuity and operational resilience. The objective is not to produce a perfect architecture diagram. It is to understand how failures propagate through the organisation.

Finding hidden critical systems and single points of failure

Most organisations might already classify the importance or criticality of their IT systems. Dependency analysis adds another perspective: how much of the organisation actually depends on them?

The two do not always agree.

A seemingly ordinary infrastructure service may support several business-critical systems and processes without itself being classified as critical. Several important systems may also share the same underlying dependency, creating a single point of failure or concentration risk that is difficult to see from a traditional IT system register.

This makes it possible to identify where redundancy, alternative routes or degraded operation could materially improve resilience.

"Available" and "unavailable" are rarely the only options. A system might operate without an integration for several hours, use an alternative authentication method or temporarily fall back to a manual process.

The useful question becomes:

What could we change so that fewer things stop next time?

Which suppliers are actually critical?

The same principle applies to supplier risk management.

Contract value, data sensitivity and manually assigned supplier criticality are useful measures, but they do not answer:

What actually stops if this supplier disappears?

Combining supplier information with IT system dependencies provides a view of operational supplier dependency. A relatively small supplier may support systems that large parts of the organisation depend on, while a commercially important supplier may have relatively little operational impact.

This helps focus supplier assurance, continuity planning, exit strategies and efforts to reduce vendor lock-in where they matter most.

And the dependency chain does not necessarily stop with your direct supplier. Cloud providers, hosting companies, telecommunications providers and other subcontractors create third-party and nth-party dependencies.

There is an important difference between no dependency and no known dependency. If a supplier uses subcontractors but you do not know who they are, that is a gap in your supply-chain risk picture, not evidence that the dependency does not exist.

Dependencies can also reveal personal data flows

System dependencies can provide useful context for privacy and GDPR work.

A GDPR Article 30 record of processing activities describes the processing of personal data, but data rarely remains within one application. It moves between systems, integrations and suppliers.

Comparing processing activities with system relationships can therefore help identify undocumented systems, integrations and downstream data flows.

This does not replace the record of processing activities. It helps test whether the documented picture corresponds with the systems actually involved in processing personal data.

Dependency analysis is another perspective, not another risk score

Business criticality, cybersecurity risk, data sensitivity, financial exposure and operational dependency are different things. Dependency analysis should not collapse them into a single "true risk" score.

The value comes from comparing them.

If a system is classified as relatively unimportant while several critical services depend on it, that discrepancy deserves attention. The same applies to suppliers.

There is also an obvious limitation: you cannot analyse dependencies you have not mapped. Coverage and uncertainty therefore need to remain visible. A dependency analysis becomes more useful as knowledge of the IT environment improves.

From inventory to operational resilience

System and supplier registers answer an important question:

What do we have?

Dependency analysis adds the questions needed for risk management and operational resilience:

What depends on what? What happens when something fails? Where are our critical dependencies and single points of failure? And what can we change so that fewer things stop?

That is why we built dependency analysis into Cyrigo.

The purpose is not to create another diagram. It is to make better decisions about IT resilience, business continuity, supplier risk, supply-chain risk and security investment.

Because when an important system fails, knowing that it is important does not help much.

Knowing what else stops does.