What is a Risk Register?

What is a Risk Register?

A risk register is a centralized document or tool that records identified risks, their assessment (likelihood and impact), assigned treatments, owners, and current status. It serves as the foundation of an organization's risk management program and is a key artifact required by frameworks including ISO 27001, SOC 2, and NIST CSF.

What a risk register contains

A well-structured risk register typically includes the following fields for each risk:

• Risk ID — a unique identifier for tracking
• Risk description — a clear statement of the risk, typically describing the threat, vulnerability, and potential impact
• Risk category — classification such as operational, technical, compliance, strategic, or third-party
• Likelihood — the probability of the risk materializing (often rated on a scale such as 1-5 or low/medium/high)
• Impact — the potential consequence if the risk materializes (rated similarly)
• Risk score — calculated from likelihood and impact (e.g., likelihood x impact)
• Risk owner — the person accountable for managing the risk
• Treatment option — mitigate, accept, transfer, or avoid
• Controls — the specific controls implemented to address the risk
• Residual risk — the remaining risk level after treatment is applied
• Status — current state (open, in treatment, accepted, closed)
• Review date — when the risk was last reviewed or when the next review is due

Building a risk register

Creating a risk register follows a systematic process:

1. Identify risks — gather risks through workshops, interviews, threat modeling, vulnerability assessments, incident reviews, and industry threat intelligence
2. Assess each risk — evaluate the likelihood and impact of each risk to determine its severity
3. Prioritize — rank risks by their risk score to focus attention and resources on the most significant threats
4. Assign ownership — designate a responsible owner for each risk
5. Determine treatment — decide how each risk will be handled
6. Document controls — record the specific controls that address each risk
7. Calculate residual risk — assess the remaining risk after controls are applied
8. Review and approve — have management review and approve the register

Maintaining the risk register

A risk register is only valuable if it is kept current. Regular maintenance includes:

• Periodic reviews — review the full register at least quarterly, with management review at least annually
• Triggered updates — update the register when significant changes occur (new systems, new services, organizational changes, incidents)
• New risk identification — continuously identify and add new risks as the threat landscape evolves
• Treatment progress tracking — monitor and update the status of risk treatment activities
• Residual risk reassessment — re-evaluate residual risk as controls are implemented or change

Risk scoring methodologies

How you score risks determines how actionable the register is. The most common approaches:

Qualitative (low/medium/high) — Fast and intuitive, useful for getting started or communicating with non-technical stakeholders. The downside is limited precision; everything tends to collect in the middle.

Semi-quantitative (1–5 scales) — A 5×5 matrix with likelihood and impact each rated 1 through 5 produces a 1–25 risk score. This is the most widely used approach because it balances simplicity with discrimination.

Quantitative (dollar-based) — Approaches like FAIR (Factor Analysis of Information Risk) estimate Annual Loss Expectancy in dollars. This is the gold standard for board reporting but requires more mature data and analyst time.

Most compliance programs start with a 5×5 matrix, then introduce quantitative methods for top-tier risks. Whichever scale you choose, document the definitions — what does "likelihood 4" actually mean in your organization? Without clear definitions, different raters produce wildly different scores.

Risk register in compliance frameworks

Different frameworks require or recommend risk registers, often with specific expectations:

Auditors typically look for: documented scoring criteria, evidence of regular review cadence, treatment decisions tied to each risk, and linkage between risks and controls. A register without review dates, owner signatures, or treatment tracking will draw findings even if the risks themselves are well-identified.

Risk treatment options

For each risk, pick one of four treatment strategies (often documented in a parallel risk treatment plan):

• Mitigate — implement controls to reduce likelihood or impact. Most common choice. Example: deploy MFA to reduce account takeover likelihood.
• Accept — acknowledge the risk as within tolerance and proceed. Requires documented rationale and, for significant risks, executive sign-off.
• Transfer — shift the risk to a third party via insurance, contract, or outsourcing. Cyber insurance is the canonical example.
• Avoid — eliminate the activity causing the risk. Example: decide not to launch a feature in a high-risk jurisdiction.

Residual risk — the risk remaining after treatment — must be reassessed and either accepted or subjected to additional treatment. Chained mitigation (stacking controls) is a legitimate strategy for high-severity risks.

Connecting the risk register to operational workflows

A risk register that lives in isolation quickly goes stale. High-performing programs integrate it with:

• Vendor risk management — third-party risks from vendor assessments feed into the enterprise register
• Incident response — post-incident reviews identify new risks or update likelihood scores for known ones
• Change management — significant system or business changes trigger a register update before deployment
• Policy reviews — annual policy reviews check whether controls still address the risks they were designed for
• Board reporting — top-tier risks roll up into executive dashboards showing trends, treatment progress, and heat maps

Example risk register entry

A concrete example makes the structure tangible. Consider a risk identified during an ISO 27001 internal audit:

This level of detail turns the register into a practical management tool rather than a compliance artifact.

Common pitfalls

Organizations often struggle with risk registers due to:

• Making the register too complex or too simple
• Failing to review and update regularly
• Not assigning clear ownership or clear treatment deadlines
• Rating all risks as "high" without meaningful differentiation
• Treating the register as a compliance checkbox rather than a management tool
• Disconnecting the register from incident response and vendor management workflows
• Keeping risks open indefinitely without closure criteria or residual risk acceptance
• Not versioning the register, making it impossible to demonstrate historical decisions to auditors

Risk register tools and templates

Organizations use a range of tools to maintain a register:

• Spreadsheets — acceptable for small teams or early-stage programs. The limitation is that spreadsheets do not track version history, send review reminders, or link risks to other artifacts cleanly.
• GRC platforms — purpose-built tools (including episki) handle scoring, ownership, treatment workflows, and evidence links out of the box.
• Issue trackers — some teams use Jira or Linear to track risks as tickets. This works for operational visibility but typically lacks the scoring and reporting structure auditors expect.

Whatever tool you choose, exportability matters: auditors frequently ask for point-in-time snapshots, and regulators may request historical registers during an investigation.

How episki helps

episki provides a built-in risk register with configurable likelihood and impact scales, automatic risk scoring, owner assignment, treatment tracking, and review scheduling. The platform links risks to controls and evidence, creating a complete chain from risk identification through treatment. Learn more on our compliance platform.