A weak programme usually shows up as poor asset visibility, unclear interdependencies, too many open connections, and no practical way to separate compromised systems from healthy ones. If teams cannot identify what must stay available during an incident, they will struggle to maintain operations under attack. NIS2 readiness depends on proving containment, not just writing policies.
How to tell a NIS2 readiness programme is failing in practice
A readiness programme is not working if it cannot show which services are truly critical, which dependencies keep them alive, and how containment will happen under pressure. In practice, the warning signs are usually operational rather than paper-based: weak asset visibility, unclear interdependencies, and no tested way to separate compromised systems from healthy ones.
The most useful test is whether the programme can support continuity decisions during an incident, not whether policies exist. If teams cannot prove what must stay available, what can be isolated, and what can be restored in sequence, the programme is not yet protecting critical services effectively.
What ineffective service protection looks like operationally
The clearest sign is a gap between declared criticality and real recovery confidence. Organisations often label services as important, but cannot trace the supporting applications, networks, data stores, third parties, and administrative paths that make those services work. That leaves recovery plans too abstract to guide live incident decisions.
Another common failure is over-reliance on perimeter or policy language. A programme may define controls, but still lack segmentation, isolation procedures, and exercised fallback paths. When an incident hits, the team discovers that “protecting” a service really means being able to contain blast radius, keep key dependencies online, and stop lateral impact from spreading.
Signals that readiness has not become resilience
Readiness stops being credible when it has not been exercised against realistic failure conditions. If teams have never tested isolation of a compromised zone, dependency shutdown, manual workaround, or restoration order, they do not know whether the service can survive a live attack or major outage.
Watch for these signs:
- Critical services are identified in documents, but not tied to owners, dependencies, and recovery objectives.
- Asset inventories miss shadow systems, shared platforms, or externally managed components.
- Segmentation exists on diagrams but not in enforceable network and access patterns.
- Incident playbooks do not say what gets isolated first or who can authorise the cutoff.
- Recovery testing validates restoration, but not containment, degraded operation, or inter-service dependencies.
If those conditions are present, the programme may be compliant on paper while still being fragile in operation.
Risk and Threat Considerations
Poor protection of critical services creates a double exposure: business disruption if the service fails, and wider spread if the compromise is not contained quickly. Attackers benefit when defenders cannot map dependencies or isolate affected systems, because that uncertainty slows response and increases the chance of lateral movement or repeat compromise.
Failure mechanism: Weak visibility, excessive connectivity, and untested separation controls prevent responders from containing the affected service, so a compromise propagates into adjacent systems or interrupts essential operations.
Impact: The organisation can lose the ability to maintain essential service availability, meet recovery objectives, and demonstrate effective operational resilience during a real incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Strategy | NIS2 readiness depends on knowing third-party and dependency exposure for critical services. |
| ID.AM-01 — Physical Devices and Systems are Inventoried | Poor asset visibility is a primary sign that critical services cannot be protected effectively. | |
| PR.AA-05 — Identity and Access Permissions are Managed | Excessive connections and weak separation often reflect unmanaged access paths into critical services. | |
| Recommendation — Map critical-service dependencies and require containment-ready supplier and service relationships. Maintain an accurate inventory of systems and assets supporting each critical service. Restrict and review access paths that could expand incident impact across critical services. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Service protection fails when component and dependency inventories are incomplete. |
| SC-7 — Boundary Protection | Containing compromised systems depends on enforceable separation and boundary controls. | |
| Recommendation — Keep a current inventory of components that support each essential service. Enforce boundaries that limit lateral spread between critical and non-critical systems. | ||
Practitioner Guidance
What to verify: Confirm that each critical service has a current dependency map, an owner, and a tested containment path. If the team cannot say which connections must remain open and which must be severed first, the programme is not ready for incident conditions.
What good looks like: The organisation can prove, through exercises or incidents, that it can isolate a compromised segment, keep priority services running in a constrained mode, and restore dependencies in the right order without guessing.
Common mistake: Treating policy completion as readiness. A written control set is useful only when it translates into observable containment, recovery sequencing, and decision authority under stress.
Practitioner takeaway: For NIS2, the real test is not whether critical services are named, but whether they can be protected, isolated, and sustained when the environment is actively failing.
Related resources from NHI Mgmt Group
- What are the signs that segmentation and visibility are not protecting critical assets effectively?
- What are the signs that a two-factor authentication programme is not protecting users effectively?
- Why does a risk-based approach matter more than blanket compliance when protecting critical infrastructure and cloud native environments?
- What are the signs that identity governance is not keeping pace with digital transformation in financial services?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
