IT Risk

IT Risk Assessment: Getting from a Risk Register Entry to a Tested Control

Many IT risk registers are lists of worries with colours attached. They are reviewed quarterly, the colours rarely change, and nobody can say which control is supposed to address which entry or whether that control has ever been tested. An IT risk assessment that is worth the effort produces a chain: a risk written so that it can be tested, the control that is relied on to address it, a test designed for that control, a result, and a finding that tells someone what to do first.

This article walks a single fictional entry through that chain, including what to do when the evidence is insufficient, and ends with how a bounded engagement is scoped so the work stays proportionate.

By: AuditPartners
Added: 2 October 2026
Reading time: 10 min
Status: Educational guide

Frameworks and vocabulary

Two NIST publications supply the vocabulary used here. NIST SP 800-30 Rev. 1 describes risk assessment in terms of threat sources, threat events, vulnerabilities, likelihood and impact, and is explicit that the output should inform decisions, not sit in a document. NIST CSF 2.0 organises cybersecurity outcomes into six functions, Govern, Identify, Protect, Detect, Respond and Recover, and is a convenient way to check that a risk register covers more than preventive controls. For testing, NIST SP 800-53A Rev. 5 gives the examine, interview and test methods that distinguish self-reported from inspected from tested evidence.

None of these is a compliance requirement in itself. They are reference points; the criteria for any engagement are the ones agreed with the organisation. If the organisation runs an ISO/IEC 27001:2022 management system, its own risk methodology is the criterion and the standard's requirement for risk assessment and treatment applies, paraphrased rather than quoted here because the text is licensed.

Step 1: write a risk that can be tested

A risk statement is testable when it names an asset, a threat event, a consequence and a current rating with a stated basis. "Cloud security risk: High" fails all four. The rewrite below is the fictional entry we will follow.

Fictional example

Risk R-17 at a fictional logistics company

Orrin Freight, a fictional 600-person logistics company, runs its dispatch platform in a public cloud. Original register entry: "Cloud misconfiguration — High." Rewritten: R-17. Threat event: an engineer or automated pipeline grants public or over-broad access to a storage bucket holding shipment manifests (customer names, addresses, contents). Vulnerability: storage policies are set per project by engineers without a guardrail. Consequence: disclosure of customer personal data and contract terms; regulatory notification; contract penalties. Likelihood: moderate, basis: two near-misses in the last year caught by an engineer by chance. Impact: high, basis: 2.1 million manifest records in the buckets. Risk owner: Head of Platform. The company and figures are invented.

The rewrite already changed the conversation: 'two near-misses caught by chance' means the organisation has no detective control it can point to, which the next step makes explicit.

Step 2: map the controls relied on

For each risk, list the controls management relies on to reduce likelihood or impact, who owns each, and what kind of control it is. Checking the list against the CSF 2.0 functions is a quick way to see whether the organisation is relying on prevention alone.

Controls relied on for R-17, as stated by management before testing
Control	Type	CSF 2.0 function	Owner	Management's description (self-reported)
C-17.1 Organisation policy blocks public bucket access	Preventive, automated	Protect	Head of Platform	"An org-level policy prevents public access on all projects."
C-17.2 Infrastructure-as-code review	Preventive, manual	Protect	Platform Lead	"All storage changes go through pull-request review."
C-17.3 Daily configuration scan with alerting	Detective, automated	Detect	Security Engineer	"A posture tool scans daily and pages on public buckets."
C-17.4 Data classification and bucket inventory	Governance	Identify / Govern	Data Protection Lead	"We know which buckets hold personal data."
C-17.5 Incident runbook for data exposure	Corrective	Respond / Recover	Security Manager	"There is a runbook and we have exercised it."

Everything in the last column is self-reported at this stage. The purpose of step 3 is to replace it with inspected and tested evidence.

Step 3: design a test per control

A test design states the method, the population, the sample and the pass condition. A single attempt can demonstrate an automated preventive control's behaviour at that point, not its operation throughout a period. Inspection of reliable operating records can support operating effectiveness; manual controls need evidence across the period, and detective controls need both a configuration check and evidence that alerts were acted on. The sample sizes, test periods and pass conditions below are illustrative, selected by risk, scope and the organisation's criteria, not universal requirements. All public-exposure or permission-denial exercises are performed only in an approved isolated sandbox with synthetic data and recovery controls, never on production buckets or unrelated real data.

Test design for the R-17 controls
Control	Method	Population and sample	Pass condition
C-17.1 Org policy	Examine policy configuration; test by attempting to set a public ACL on a synthetic-data bucket only in an approved isolated sandbox replicating each project type, with recovery controls.	All projects in the organisation (policy inheritance); one sandbox attempt per project type.	Policy present and enforced at the organisation node with no exempted projects; sandbox attempt denied.
C-17.2 IaC review	Examine repository protection; examine a sample of merged storage changes for an independent approver.	All merged changes touching storage modules in the last 12 months (population from the repository); sample 25.	Branch protection requires review; every sampled change has an approver other than the author before merge.
C-17.3 Daily scan	Inspect scanner configuration, schedule, run records and alert history; test/re-perform detection by injecting a public synthetic-data bucket only in an approved isolated sandbox with recovery controls, and time the alert.	All scan runs and alerts in the last 90 days; one sandbox injected test.	Reliable records show daily scans with no gaps over 90 days; the sandbox injected bucket alerts within the documented window and reaches an on-call person.
C-17.4 Classification	Examine the bucket inventory; reconcile to the cloud provider's full bucket list.	All buckets in the organisation.	Every bucket holding personal data is in the inventory with a classification and owner.
C-17.5 Runbook	Examine the runbook and the record of the last exercise; interview participants.	Exercises in the last 24 months.	Runbook current; exercised at least once in the period with documented lessons and completed actions.

Step 4: results, including insufficient evidence

Three outcomes are possible for each test: the control operated, the control did not operate (an exception), or the evidence was insufficient to tell. The third is the one most often mishandled. Insufficient evidence is not a pass by default, and it is not a finding of failure either; it is a finding that the control cannot be relied on until evidence exists.

R-17 test results
Control	Result	Evidence basis	Note
C-17.1 Org policy	Exception	Inspected + tested	Policy enforced at the organisation node, but two legacy projects are exempted for a vendor integration; a public ACL attempt succeeded in an approved isolated sandbox replica of one exempted project, using synthetic data and recovery controls.
C-17.2 IaC review	Operated, with one exception	Inspected	24 of 25 sampled changes had an independent approver; one was merged by an administrator bypass during an incident.
C-17.3 Daily scan	Failed injected test + insufficient historical evidence	Inspected + tested (test/re-performance)	Inspection found scanner configuration and an alert rule, but run records and alert history were retained for only 30 days; 60 of the last 90 daily runs cannot be evidenced. In the approved isolated sandbox with synthetic data and recovery controls, the injected bucket produced no alert within four hours; the on-call rotation for the alert channel was empty.
C-17.4 Classification	Exception	Inspected	Inventory lists 38 buckets; the provider reports 51. Seven of the 13 unlisted buckets contain manifest exports created by a reporting pipeline.
C-17.5 Runbook	Insufficient evidence	Self-reported	Runbook exists (document). Management states it was exercised in 2025; no record of the exercise, participants or actions could be produced.

Step 5: one prioritised finding, not five equal ones

Five results do not deserve five equal findings. Prioritise by what most changes the residual risk and what can be fixed fastest. For R-17, inspected project exemptions and a successful public-access attempt in an isolated sandbox replica (C-17.1), combined with failed sandbox detection and insufficient historical evidence (C-17.3), indicate a potential exposure path without demonstrated effective detection, in buckets partly missing from the inventory (C-17.4). No production bucket was exposed by the exercise.

Fictional example

Priority finding for R-17

Condition. Two organisation projects are exempted from the preventive policy; a public ACL attempt succeeded in a sandbox replica of one. The daily scan failed to alert on the sandbox injected bucket within four hours, has no on-call recipient, and lacks records for 60 of the 90 days; seven buckets containing manifest exports are absent from the data inventory. All public-exposure exercises used only an approved isolated sandbox with synthetic data and recovery controls. Criteria. Orrin Freight's cloud security standard (no public storage; detective alerting within one hour; all personal-data stores classified). Cause. Policy exemptions granted for a vendor integration in 2024 were never reviewed; the alert channel's rotation lapsed when a team was reorganised; the reporting pipeline creates buckets outside the inventory process. Consequence. A misconfiguration in the exempted projects could expose customer personal data without demonstrated effective detection. Recommendation, in order: (1) within one week, assign an on-call recipient to the alert and re-run the injected test only in the approved isolated sandbox with synthetic data and recovery controls; retain reliable operating records; (2) within 30 days, remove or scope the two exemptions to the specific vendor resources; (3) within 60 days, add pipeline-created buckets to the inventory process and classify the seven. Owner. Head of Platform, with the Security Manager for (1). Rating. High until (1) and (2) are verified. Evidence. Policy export, sandbox ACL test record, scanner configuration, retained run records and alert history export, sandbox injected-test timeline, inventory reconciliation; all retained in the working papers.

The remaining results (the review bypass in C-17.2 and the unevidenced runbook exercise in C-17.5) become lower-priority findings with their own owners and dates. The register entry for R-17 is updated with the tested residual rating and the date it was tested, which is the single change that turns the register from a list of worries into a record someone can rely on.

Keeping the engagement bounded

The chain above was worked for one risk. A proportionate engagement does not attempt it for every register entry. In our IT Audit & Technology Risk work a bounded engagement typically agrees: the register entries in scope (often the top five to ten by rating, plus any the sponsor is unsure about), the period, which controls will be tested rather than inspected, and the evidence the organisation must be able to produce before fieldwork. The AI Audit Evidence Request Checklist is written for AI systems but its owner / period / source / purpose structure is the same one we use for IT risk evidence requests.

Whether the right engagement is an advisory assessment or an internal audit depends on who needs to rely on the result; Gap Assessment vs. Internal Audit sets out the difference. Where the risks concern AI-generated changes to systems like Orrin's dispatch platform, AI Technical Controls Assessment: From Work Ticket to Production shows the same chain applied to a single change. And if the question is simply whether your AI-related risks are in any register at all, the free AI Governance QuickScan is a ten-minute starting point.

Key takeaways

Rewrite each risk with an asset, threat event, consequence, rating basis and owner before testing anything.
Map the controls relied on and check them against the CSF 2.0 functions to see whether detection and response exist at all.
Design each test with method, population, sample and pass condition selected by risk and scope; reliable records can support operation, and one automated-control test does not establish period-wide operation.
Insufficient evidence is neither a pass nor a failure; it means the control cannot be relied on until evidence exists, and the residual rating must reflect that.
Issue one prioritised finding per risk with ordered actions, owners and dates, then update the register with the tested residual rating.

References

Primary sources cited above. Standards are referenced by number and year; their text is licensed and is paraphrased, not reproduced.

NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, September 2012 (opens in a new tab) — Threat sources, threat events, vulnerabilities, likelihood and impact.
NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, February 2024 (opens in a new tab) — Govern, Identify, Protect, Detect, Respond and Recover functions.
NIST Cybersecurity Framework programme page (opens in a new tab)
NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls, January 2022 (opens in a new tab) — Examine, interview and test methods.
ISO/IEC 27001:2022, Information security management systems — Requirements (opens in a new tab) — Licensed text; risk assessment and treatment requirements referenced, not reproduced.
The IIA, Global Internal Audit Standards (effective 9 January 2025) (opens in a new tab) — Applies where the testing is performed as internal audit.