How should organisations balance compliance and resilience under new cyber rules?

Why Compliance Is the Floor, Not the Finish Line

New cyber rules usually improve baseline hygiene by forcing reporting, accountability, and response discipline. But compliance only becomes resilience when the organisation can absorb an incident without losing control of critical services. The practical question is not whether the paperwork is complete, but whether the control set still works when a system is isolated, degraded, or under active attack.

That distinction matters because compliance often optimises for evidence of control, while resilience optimises for continuity under stress. A control can be formally present yet fail under blast-radius pressure, especially if recovery assumes shared infrastructure, single points of administration, or delayed containment decisions.

Compliance is therefore best treated as the minimum operating standard for governance, not the design goal for incident survival. A mature programme aligns reporting, escalation, and accountability with architecture that can segment, fail over, or shut down narrowly instead of forcing a full enterprise pause.

What Balancing the Two Looks Like in Practice

The balance starts with mapping each obligation to a real operational outcome. If a rule requires incident reporting, ask who can produce the evidence quickly; if it requires response plans, ask whether those plans assume unavailable systems; if it requires accountability, ask which team can actually isolate affected assets and authorize service restoration.

Good practice is to build controls that satisfy the regulator and still work during compromise. That usually means containment paths, tested recovery runbooks, clear ownership for shutdown decisions, and pre-agreed criteria for when safety or continuity takes priority over perfect service availability.

For CISA Secure by Design, the useful lesson is that resilient design should reduce how much has to be explained after an incident because less of the environment is exposed in the first place. Where organisations operate in cloud-heavy estates, the Cloud Controls Matrix is often helpful for translating governance expectations into cloud control domains that can be assessed operationally.

Where the subject is operational resilience in regulated sectors, DORA is a useful example of why incident reporting and third-party risk cannot be separated from continuity planning. The same logic applies beyond finance: if the business cannot keep essential functions running while responding, compliance has not yet produced resilience.

Where Compliance and Resilience Usually Pull Apart

The most common failure is treating reporting readiness as equivalent to recovery readiness. Teams can meet notification deadlines and still be unable to contain the incident, because the systems that produce logs, approvals, and dashboards are the same systems that are compromised or unavailable.

Another frequent weakness is over-centralisation. Central identity, central logging, central backup, and central administration all improve efficiency, but they also create correlated failure modes if they are not segmented and protected. If compromise of one control plane can halt containment, the organisation has a resilience gap even when audit evidence looks strong.

Policy can also drift away from architecture. A rule may require rapid response, but if access to isolation tooling, break-glass credentials, or recovery authorities is too broad or too slow to use, the organisation will default to delay. That is when compliance becomes documentation of intended behaviour rather than proof of survivable design.

Risk and Threat Considerations

Cyber rules can create a false sense of security when organisations equate attestable process with defensive strength. The real risk is that an incident still spreads, persists, or forces shutdown because the environment was never built to contain failure under pressure.

Failure mechanism: Control evidence, reporting workflows, and escalation plans may exist, but if segmentation, recovery, and administrative separation are weak, an attacker or outage can bypass the intended response path and expand impact before containment takes effect.

Impact: The organisation may satisfy formal obligations while still suffering prolonged service loss, wider data exposure, or a recovery process that is too slow to protect critical operations.

Practitioner Guidance

What to prioritise: Start by identifying the few services whose loss would make compliance irrelevant in practice, then verify that they can be isolated, monitored, and restored independently of the rest of the environment.

What to verify: Test whether your incident plan still works when the primary logging, identity, or admin path is unavailable; if it does not, the plan is not yet resilient enough to trust.

Decision rule: If a control helps you pass an audit but cannot be executed during an active incident, treat it as governance support, not resilience evidence.

Practitioner takeaway: The strongest programmes do not choose between compliance and resilience, they use compliance to prove that resilience can be executed under stress, not just described on paper.

Related resources from NHI Mgmt Group

• What breaks when organisations treat cyber resilience rules as a one-time compliance exercise?
• How should gambling operators govern crypto wallets under new compliance rules?
• How should organisations prepare for Cyber Resilience Act compliance in product teams?
• How should organisations control source-code access under the Cyber Resilience Act?