ICT Risk Reviews and Assurance

ICT risk reviews and assurance test whether the ICT risk management framework is accurate, complete, and effective for the services it covers. Review examines the risk picture, the protections, the detection, the response and recovery arrangements, and the governance around them, and asks whether they still match the service as it runs and whether they would work under disruption. Assurance provides independent challenge to that examination, so that the framework is not judged only by the people who built and maintain it.

Review and assurance are distinct from routine maintenance. Maintenance updates a document or a control. Review asks whether the document or control should exist in its current form at all, whether it covers the right service, and whether evidence supports the claim that it works. That challenge is what keeps a framework honest as technology, threat, and service change around it.

Review is triggered by change and by experience, as well as by routine. A significant change to a service, a system, or a supplier, a new threat, a new technical standard or guidance from the European Supervisory Authorities, an incident, a test result that contradicts an assumption, and an audit finding can each trigger review of the affected part of the framework. Routine review provides a backstop, ensuring that parts of the framework that have not been triggered by an event are still examined periodically.

The trigger determines the scope. An incident in one service triggers review of that service framework, and of any shared element that contributed to the incident, rather than a review of the entire framework at the same depth. A supplier change triggers review of the services that depend on that supplier. Scoping review by trigger keeps it focused and timely, while routine review provides a check so that slow drift, which produces no single trigger, is still caught.

Review is conducted by examining evidence against the service picture. Reviewers look at the service map, the risk assessment, the protection and detection arrangements, the response and recovery plans, and the records of tests and incidents, and they ask whether those elements cohere for a named service. They look for gaps between the documented framework and the service as it operates, for risks that have changed without a corresponding framework change, and for controls whose claimed effect is not supported by test or incident evidence.

Review also involves the people who run the service. A document review alone can miss the operational reality that staff know from daily work: a recovery step that is impractical, a detection alert that is routinely ignored, a supplier contact that no longer works. Conversations with service owners, technical teams, and responders surface those realities, and they turn review from a paper exercise into an examination of how the framework would perform under disruption.

Assurance adds independence and challenge. An independent reviewer, whether internal audit or an external party, brings a perspective that is not invested in the framework as built, and is therefore more likely to notice an optimistic assumption, a missing dependency, or a test that flattered the service. Assurance also brings a systematic approach, examining the framework against the regime and against good practice, rather than only against its own stated intentions.

Independence needs to be real, not formal. Assurance provided by a team that helped design the framework, or that reports to the same management as the framework owners, carries a conflict that limits its challenge value. The assurance arrangement therefore needs to show who provided it, what scope they covered, what access they had, and what findings they raised, including findings that were uncomfortable. Assurance that reports no findings, year after year, while services and threats change, deserves scepticism rather than comfort.

Findings are handled by ownership, action, and follow up. Each finding is assigned an owner, a response, and a point at which its closure will be checked. The response may be a change to protection, detection, recovery, or the risk picture, or it may be a reasoned decision that the finding does not require change, with the reasoning recorded. What matters is that the finding is not merely noted. A review that produces findings that are never acted on, or never checked, has consumed effort without improving resilience.

Review connects to testing because testing provides the evidence that review judges. A recovery test shows whether a recovery plan works for a service. An incident shows whether detection and response worked in reality. A penetration test or a resilience test shows whether protection holds under attack or disruption. Review examines that evidence critically, asking whether the test was realistic, whether it covered the service end to end, and whether its scope flattered the result by excluding the hardest parts.