In this new blog post, Arcanum Technical Director, Lawrie Abercrombie, provides an introduction to the Arcanum NIS Readiness Sprint: what it is, who it’s for and where the benefits lie for organisations looking to move quickly in assessing their resilience.
Most boards and security leaders, particularly those in the CNI sphere, now agree that cyber resilience matters. So in recent conversations around NIS readiness, I have found that the most difficult discussion is about whether they can confidently evidence that their organisation understands its critical services, dependencies, supplier exposure and the controls relied upon to keep those services operating during a cyber incident.
That question is becoming more urgent. The Cyber Security and Resilience Bill is expected to extend and strengthen the existing NIS framework, with greater emphasis on essential and digital service resilience, third-party dependency management, incident reporting and demonstrable cyber risk governance. For organisations that may be in scope, or that support organisations already in scope, now is the time to establish a defensible view of readiness rather than waiting for regulatory detail to force a rushed response.
This is where I see real value in a NIS Readiness Sprint. It is a short, structured assessment of an organisation’s current cyber resilience posture against the expectations associated with the NIS Regulations and the emerging Cyber Security and Resilience Bill. It is not a certification exercise and it should not be dressed up as a full audit. Its purpose is more direct i.e. to test whether governance, risk management, operational resilience and assurance arrangements are sufficiently clear, owned, implemented and evidenced.
A good sprint looks beyond policy statements. It examines: how critical services are defined; how dependencies are understood; how cyber risks are escalated; how supplier assurance is performed; how incidents would be reported and whether senior decision-makers receive management information that would withstand scrutiny. In operational technology environments, it should also consider the practical realities of legacy equipment, safety constraints, network segmentation, remote access and change control.
In our experience supporting organisations preparing for NIS assessments, CAF reviews and Defence Cyber Certification (DCC), which incidentally we’ve been doing a lot of recently, the biggest challenge is never a complete absence of security controls. Even on a recent very early stage project where we were part of the design team, the client had already specified networking equipment that incorporated some security functionality. The simple fact that they had brought us in as an NCSC Assured Consultancy meant they have “taken appropriate and proportionate” measures and that the advice they relied upon is “competent and credible”.
However, most jobs aren’t early stage so the OES we deal with have been operating for years and have invested in security technologies and processes. The link between early and late stage projects is that both generally lack a clear view of how what they are doing maps to regulatory obligations. We regularly encounter organisations that are doing many of the right things but cannot easily demonstrate this through evidence, governance records or structured risk management.
The organisations that benefit most are not only those already caught by the NIS Regulations. I would also include organisations that may be brought into scope as the regime develops and suppliers that provide services on which essential or digital service operators depend. That can include operators in energy, transport, health, drinking water and digital infrastructure, as well as managed service providers, cloud and data centre providers, OT suppliers, security service providers and other 3rd parties.
From a practical perspective, the sprint is particularly useful where boards, accountable executives, risk owners, CISOs, security managers, compliance leads or service owners need a clear assessment of exposure, control maturity and remediation priority. It gives them something tangible to work with e.g. a view of current risk, the evidence gaps that would matter in an assurance discussion and the decisions needed to move from intent to delivery.
One of the mistakes I have seen in regulatory readiness work is treating preparation as a legal interpretation exercise. Legal interpretation matters, but it does not keep a critical service running. The technical and operational questions are just as important: which systems support the service, who maintains them, what dependencies are hidden in supplier contracts, how quickly incidents can be detected and escalated and what evidence exists to show that risks are being actively managed.
A Readiness Sprint allows those questions to be addressed before pressure becomes acute. It separates controls that are already operating effectively from areas where accountability, design, implementation or evidence is insufficient. It also distinguishes quick evidence improvements from structural remediation that may require architecture change, contract variation, supplier engagement, technology investment or revised operating processes.
That distinction matters because a supplier delivering a critical component of an essential service does not have the same obligation or assurance burden as the operator of that service, but it may still represent a material dependency. A mature organisation with established governance, incident response and assurance functions needs a different assessment lens from a smaller specialist provider. The sprint should therefore be calibrated against service criticality, dependency, threat exposure, operational context and available evidence.
In my view, the output should be concise enough to be used by leadership, but detailed enough to support action by technical, risk and service teams. Typical outputs include:
- Readiness baseline: an assessment of current governance, risk, resilience and assurance arrangements against relevant NIS and Cyber Security and Resilience Bill themes.
- Gap analysis: identification of material weaknesses in accountability, risk treatment, supplier assurance, incident response, reporting, service continuity and supporting evidence.
- Readiness roadmap: a prioritised sequence of activity that distinguishes immediate evidence improvements, near-term control uplift and longer-term strategic remediation.
- Remediation plan: practical actions with proposed ownership, dependencies, sequencing and implementation considerations, enabling findings to be transferred into delivery governance.
- Executive insight: a concise view of regulatory exposure, residual risk, investment decisions and the consequences of delayed action.
The real value is not the document pack itself. It is the disciplined conversation the sprint creates between leadership, security, operations, service owners and suppliers. Done well, it gives the organisation a shared understanding of what is good enough, what is not yet evidenced and what must be remediated before regulatory scrutiny increases.
For organisations likely to be affected by the changing NIS regime, readiness should be treated as an assurance and resilience issue, not simply a compliance task. A NIS Readiness Sprint provides a controlled way to establish the current position, identify material gaps and start proportionate remediation while there is still time to plan properly.
If you would like to understand what NIS readiness means for your organisation, Arcanum can help you assess your current position, develop a technically grounded readiness roadmap and define an actionable remediation plan. Get in touch with the Arcanum team to find out more.