IT Risk
IT Risk Assessment: Getting from a Risk Register Entry to a Tested Control
In short
Turn an IT risk-register entry into a control, a test and a finding you can act on.
Company names and figures are invented.
A high-rated cloud risk needs more than a line in a register. Follow one fictional storage risk through control mapping, test design and findings to give its owner a practical order of work.
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 organizes 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.
These NIST publications provide methods and vocabulary; citing them alone does not create a compliance obligation. Use the organization's applicable requirements as criteria. For an ISO/IEC 27001:2022 management system, that includes its risk methodology and the standard's risk assessment and treatment requirements. The licensed text is referenced rather than reproduced.
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.
The rewrite already changed the conversation: 'two near-misses caught by chance' means the organization 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 organization is relying on prevention alone.
Reference table · every row is included.
| Control | Type | CSF 2.0 function | Owner | Management's description (self-reported) |
|---|---|---|---|---|
| C-17.1 Organization 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." |
Make the risk testable.
For the fictional R-17 register entry, management names five controls; the article inspects their records and runs an injected test only in an isolated sandbox. Results split into observed exceptions (policy exemptions, a failed alert, missing inventory entries) and evidence limitations (unretained scan history, an undocumented runbook exercise). Each feeds a prioritized, owned action with a date. The scenario and results are invented.
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 behavior 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 organization'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.
Reference table · every row is included.
| 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 organization (policy inheritance); one sandbox attempt per project type. | Policy present and enforced at the organization 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 organization. | 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.
Reference table · every row is included.
| Control | Result | Evidence basis | Note |
|---|---|---|---|
| C-17.1 Org policy | Exception | Inspected + tested | Policy enforced at the organization 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 prioritized finding, not five equal ones
Five results do not deserve five equal findings. Prioritize 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.
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 work proportionate
Start with the risks that matter most to the decision. In our IT Audit & Technology Risk work, the review can focus on high-rated entries and risks the sponsor cannot yet assess. The audit plan names the period, the controls to inspect or test and the records needed 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 a method, population, sample and pass condition chosen by risk.
- 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 prioritized 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 program 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.