# IT risk register entry checklist

Use this to check that each entry in an IT risk register will stand up to a risk committee, an auditor or a
regulator. The fields follow the risk assessment, response and monitoring topics in ISACA's CRISC exam
content outline (2025).

## The risk

- [ ] Written as a risk scenario: a threat, a vulnerability or event, and the impact on a business objective
- [ ] Linked to the business process and assets it affects
- [ ] A named risk owner: the person accountable for the business outcome, not the analyst who wrote it up

## The analysis

- [ ] Inherent risk rated (likelihood and impact before controls)
- [ ] Each control mapped to the likelihood or the impact it reduces (a control that maps to neither is not
      reducing this risk, so do not count it)
- [ ] Controls checked as operating, not only documented
- [ ] Residual risk rated after the controls that operate today
- [ ] Compared with the risk appetite and tolerance set by the board and senior management

## The response

- [ ] Response chosen: accept, mitigate, transfer or avoid
- [ ] If accepted: accepted by the risk owner, against residual (not inherent) risk, and recorded
- [ ] If mitigated: an action plan with owner and date, and the residual risk expected afterwards
- [ ] A cheaper control rejected if it leaves residual risk above tolerance
- [ ] Compensating controls only where the intended control cannot be implemented, and only if they bring
      the risk to a level the owner accepts
- [ ] Exceptions and exemptions recorded with an expiry date

## Monitoring

- [ ] Key risk indicators (KRIs) and key control indicators (KCIs) defined, with thresholds
- [ ] A trigger to reassess: a KRI breach, a change in business objectives, a change in appetite, or an incident
- [ ] Entry closed or downgraded when a treatment action is completed and verified
- [ ] Ratings never lowered because remediation is unaffordable; the cost goes into the response decision instead