Leadership article
Mission Assurance Before Compliance
Start with the operation that must continue, then ask what evidence supports that confidence.
The management problem
A control can pass an audit while the service it protects remains fragile. For a maritime headquarters or a defence supplier, the useful question is operational: which decisions, communications and support activities must remain trustworthy when technology fails? Compliance provides evidence; mission assurance requires a demonstrated ability to continue.
A framework for decisions
NIST CSF 2.0 describes cybersecurity outcomes for managing risk; it is not a universal implementation checklist. Its Govern function gives governance an explicit place alongside the other functions. [1] Our recommendation is to start each review with one critical service, its accountable owner and its external dependencies.
Test the degraded operation
Choose a credible scenario: identity services unavailable during a time-sensitive deployment. Specify the minimum acceptable service, authorised fallback, recovery objective and person empowered to stop unsafe work. Exercise the fallback with operators. Record where credentials, suppliers or communications prevent it from working. These are editorial proposals, not additional NIST requirements.
Evidence for the next decision
Present the executive with the last tested recovery result, unresolved dependencies, remedial owner and deadline. NIST SP 800-61 Rev. 3 integrates incident response into wider risk management. [2] Apply that principle by feeding exercise findings back into investment decisions. A successful test supports a bounded claim; it cannot guarantee resilience against every incident.
Map the service, not just the equipment
Consider a hypothetical maritime operations centre. Its communications service may depend on identity, electrical power, time synchronisation, external connectivity and specialist maintenance. An inventory that lists only servers misses the relationships that determine whether a watch team can work. Map each dependency to a service owner and identify which failures share a common cause. Two alternative systems are not independent if both require the same unavailable identity provider.
Choose a defensible recovery objective
A recovery target should express a business or mission requirement, not simply the time an IT team hopes to achieve. Ask operators how long they can work with delayed information, which transactions must not be lost and how they will recognise an unsafe operating picture. Then compare those needs with demonstrated restoration capability. Where the gap cannot be closed immediately, record the restriction, responsible authority and compensating procedure.
Turn the exercise into an investment decision
Run a short exercise in which the normal administrator is unavailable and the primary communications channel cannot be trusted. Observe whether the team can locate instructions, obtain authority and validate restored information. Report the gap in operational terms: an additional shift without reliable data is more actionable than an unexplained technical score. Fund the dependency that limits recovery, assign a retest date and retain the evidence. An exercise is valuable when it changes a decision.
References
Cyber Policy Review · Editorial analysis. Original paraphrases; no verbatim quotations. Framework references do not imply certification or endorsement.
Publications