--- question: "What is a risk register?" title: "What Is a Risk Register" seoTitle: "What Is a Risk Register? Fields, Scoring, Examples" summary: "A risk register is the log of risks an organisation has identified, each with an owner, an assessment of likelihood and impact, a treatment decision, and a residual score after treatment. It is the central artifact of a risk management programme and the one auditors ask for first under SOC 2 CC3 and ISO 27001 clause 6.1. The most common failure is a register with owners and treatments but blank inherent and residual scores." publishedAt: "2026-08-18" keywords: - "risk register" - "risk registration" - "risk register template" - "inherent vs residual risk" pillar: "Beyond SOC 2" faqs: - question: "What goes in a risk register?" answer: "A description of the risk, the asset or objective it threatens, an owner, inherent likelihood and impact, the treatment decision, the controls applied, residual likelihood and impact after treatment, and a review date. Anything less than that fails to show an auditor that a decision was actually made." - question: "What is the difference between inherent and residual risk?" answer: "Inherent risk is the exposure before controls. Residual risk is what remains after them. Recording both is what demonstrates the controls did something. A register showing only one score cannot show whether treatment was effective, which is why blank residual scores are a standard audit finding." - question: "How often should a risk register be reviewed?" answer: "At least annually, and after any material change: a new product line, a major vendor, an incident, or a significant infrastructure shift. What auditors test is whether the stated cadence was actually followed, so a realistic cadence you meet beats an ambitious one you miss." --- ## What is a risk register? A risk register is the **log of risks an organisation has identified**, each carrying an owner, an assessment of likelihood and impact, a treatment decision, and a residual score after treatment. It is the central artifact of a risk management programme and usually the first thing an auditor asks for under SOC 2 CC3 or ISO 27001 clause 6.1. Its purpose is to show that risks were identified, decided on, and owned, not merely listed. ### The fields that matter | Field | Why it is there | |---|---| | Risk description | What could go wrong, stated specifically enough to act on | | Asset or objective affected | What it threatens | | Owner | A named person, not a team | | Inherent likelihood and impact | Exposure before controls | | Treatment | Avoid, reduce, transfer, accept, or share | | Controls applied | What actually mitigates it | | Residual likelihood and impact | What remains after treatment | | Review date | When it was last looked at | ## The failure auditors find most often **Blank inherent and residual scores.** A register with well-written risks, assigned owners, and sensible treatment plans, and no numbers, is extremely common in young programmes. It fails because without both scores you cannot show that treatment changed anything, and the whole point of recording residual risk is to evidence that the controls did something. The second most common: **acceptance with no record of who accepted it.** Accepting a risk is a legitimate treatment and auditors see it constantly. What fails is an undocumented acceptance, because from the outside it is indistinguishable from having missed the risk. ## Scoring without overengineering A 5x5 likelihood-by-impact matrix is the common default and is entirely sufficient. What matters is that the scale is **defined somewhere** and applied consistently, not that it is sophisticated. An auditor will ask what a 4 means. "High" is not an answer; "more likely than not within 12 months" is. Quantitative methods exist and are rarely worth it below a certain size. A qualitative matrix, applied consistently and reviewed on schedule, passes every audit a small company will face. ## What the register connects to - **Treatments** come from the five options: avoid, reduce, transfer, accept, share. See [what are the five risk mitigation strategies](/resources/answers/what-are-the-five-risk-mitigation-strategies). - **Controls** implemented as treatment are the same controls your framework tests. - **Vendors** are a risk category of their own, usually tracked in a separate register. See [what are the 5 stages of third party management](/resources/answers/what-are-the-5-stages-of-third-party-management). ## Where frameworks require it | Framework | Requirement | |---|---| | SOC 2 | CC3 series, risk identification and analysis | | ISO 27001 | Clause 6.1, plus a documented risk assessment methodology | | HIPAA | Security Rule risk analysis, the most cited enforcement gap | | NIST 800-53 | RA family | ISO is the strictest: it wants the **methodology** documented, not just the output, so that the assessment is repeatable by someone else.