One Compromised System Rarely Stays One Compromised System

A business application stops working.

The server itself is fine. The network looks normal. Authentication is available. Then someone discovers that an external service used by the application is unavailable.

Suddenly the incident diagram gets bigger.

ENISA’s Threat Landscape 2026, published on 22 September and discussed in a dedicated webinar on 29 September, puts this problem near the centre of its analysis. ENISA says the growing interconnectedness of digital ecosystems is increasing exposure to cyber risk and continues to observe attacks targeting dependencies, including supply chain and third party relationships. ENISA

For workforce development, there’s a practical lesson here: cybersecurity professionals need to understand dependencies as well as assets.

An Asset List Doesn’t Show the Whole Risk

Knowing what systems an organization owns is useful.

Knowing what those systems rely on is different.

A customer portal might depend on an identity provider, DNS, cloud infrastructure, payment service, API, software library and managed service. Several other applications may rely on exactly the same components.

Compromise one shared dependency and the blast radius changes quickly.

Security teams therefore need skills to identify:

• Which external services support critical business functions
• Which applications share the same infrastructure or provider
• Where software and data originate
• Which dependencies have privileged access
• What happens if a dependency becomes unavailable
• Which alternative processes exist when a service fails
• Who owns the relationship when investigation or recovery is required

The last question has a habit of becoming surprisingly difficult at 2 a.m.

Incident Response Needs a Dependency View

Dependency knowledge changes how people investigate incidents.

Suppose unusual activity appears in three applications simultaneously. Looking at each application separately may produce three investigations. Knowing that all three depend on the same identity service immediately creates another hypothesis.

The same principle applies to recovery.

Restoring a server doesn’t restore a business process if a required external service remains unavailable. A technically healthy application may still be unusable because its authentication, API or data provider has failed.

ENISA reports that 73% of organizations targeted in the incidents it analysed were entities classified as essential or important under NIS2. Its analysis also says cyber dependencies can increase the scale and impact of incidents across interconnected infrastructure. ENISA

Cyber resilience therefore requires people who can reason across organizational boundaries.

Put Dependencies Into the Exercise

Training can make this capability visible.

Give learners a simulated organization containing several applications, shared infrastructure and external services. Provide the architecture, but don’t reveal every dependency.

Then trigger an incident at one supplier.

Participants must discover which services rely on it, determine what evidence is available, assess business impact and decide which teams or external parties need to be involved.

A more difficult version introduces a recovery decision that fixes one system while breaking another dependency.

This type of scenario fits practical learning at ITSEC Cyber & AI Academy, where cyber range exercises can connect technical investigation with architecture, incident response and operational decision making.

Security teams already ask, “What happened?”

The next useful question is often, “What else depends on it?”

Explore practical cybersecurity and AI training at ITSEC Cyber & AI Academy.

References: ENISA Threat Landscape 2026, 22 September 2026 · ENISA: How Dependencies Weaken Digital Resilience · ENISA Threat Landscape Webinar, 29 September 2026