A risk register is a living inventory of identified risks, usually maintained as a structured table or system of record, that captures each risk's description, ratings, treatment decision, owner, and review dates so the organization can prioritize and prove how risk is managed over time.
In security and compliance programs, the risk register is the operational output of risk assessment. Assessment is the process of identifying and analyzing risks. The register is where those results live day to day: unique risk IDs, inherent and residual ratings, linked controls or tickets, acceptance records, and next review dates. It sits inside governance, risk, and compliance work alongside related activities such as gap analysis and vendor risk reviews.
In simple terms, a risk register answers:
- What risks have we formally identified for systems and data in scope?
- How severe are they before and after treatment, and what did we decide to do?
- Who owns each material risk, and when will we re-review it?
This page defines the artifact. It is related to risk assessment (the process that feeds the register) and to gap registers (framework readiness punch lists), but those are not the same thing. For SOC 2 period evidence habits around operating a register, see related live guides such as Risk Assessment Evidence for SOC 2 and What Is SOC 2 Evidence?.
Why a Risk Register Matters
A workshop without a durable register becomes folklore. People remember the brainstorm and forget owners, ratings, and acceptances.
A risk register matters because:
- Auditors and customers often ask for the current list of material risks and how they are treated.
- Treatment decisions explain why some controls are key controls and others are supporting.
- Accepted residual risk needs named owners and end or review dates, not silent hope.
- New products, vendors, and cloud accounts change the risk picture mid-audit period.
- A living register supports continuous compliance better than a one-time PDF nobody updates.
A short, current register that leadership can explain beats a long matrix with empty owners.
Risk Register vs Risk Assessment vs Gap Register vs Issue Log
Keep related artifacts distinct so stakeholders know what outcome to expect.
| Artifact | Primary question | Typical contents | Common confusion |
|---|---|---|---|
| Risk register | What risks did we identify, rate, and treat? | Risk IDs, ratings, treatments, owners, review dates | Treating sticky-note brainstorms as the register |
| Risk assessment | How did we identify and analyze risks for a scoped window? | Methodology, participants, dated assessment record that produces or updates the register | Calling the assessment slide deck the register |
| Gap register | Where do we fall short of a target framework or control set? | Gap IDs, "not met" rows, remediation plan | Mixing every gap into the risk register without threat framing |
| Issue / finding log | What known defects or audit findings are open? | Tickets, severity, remediation status | Assuming open bugs automatically appear as risk rows |
A risk assessment produces or refreshes the register. A gap analysis can inform which framework shortfalls to close first. Issues and findings may raise new risk rows or change ratings, but an issue tracker is not a risk register by itself. None of these replaces the others.
What Belongs in a Risk Register
Teams use GRC tools, controlled workbooks, or documented tables. Field names vary. The operating shape is usually similar:
- Risk ID. A stable unique reference across updates and exports.
- Description / threat scenario. What could go wrong in plain language.
- Assets or systems affected. Tie rows to the system description and data classification themes when relevant.
- Inherent rating. Severity before planned or existing controls.
- Residual rating. Severity after treatment.
- Treatment decision. Mitigate, transfer, accept, or avoid.
- Owner. A named human accountable for the row.
- Linked controls or tickets. Show action, not only opinion.
- Last updated and next review dates. Place activity inside the audit period.
- Acceptance end date (when accepted). Show time-bounded governance aligned with exception management when the acceptance is effectively a governed deviation.
Depth should match the decision you need: first SOC 2 readiness, annual enterprise assessment, or a focused refresh after an incident.
Examples
| Scenario | Register framing | Treatment example | Example evidence |
|---|---|---|---|
| Production admin access | Compromise of privileged cloud roles | Enforce MFA, least privilege, quarterly reviews | Risk row, MFA config export, access review packet |
| Single-region SaaS | Extended outage affecting customers | Multi-AZ design, tested backups, status comms plan | Risk row, backup restore ticket, availability notes |
| Critical payment vendor | Vendor breach exposing customer data | Contractual security terms, annual report review, exit plan | Vendor risk decision linked to register, SOC report on file |
| Rapid engineering change | Unauthorized production change | Branch protection, required reviews, break-glass procedure | Risk row, change management evidence samples |
| Remote workforce devices | Lost laptop with local data | Disk encryption, MDM, remote wipe | Risk row, encryption / MDM exports |
These examples show how register rows drive control priority. Related themes: multi-factor authentication, least privilege, logical access, encryption, and disaster recovery.
Evidence Themes Auditors May Expect
Illustrative artifacts. Not a mandatory universal checklist:
| Activity | Example evidence to retain |
|---|---|
| Register export | Machine-readable export with IDs, ratings, owners, treatments, dates |
| Methodology link | Written approach and rating scales used when the register was last refreshed |
| Ownership | Named owners for material residual risks |
| Treatment linkage | Controls, tickets, or projects that mitigate top risks |
| Acceptance | Time-bounded acceptances with approver identity |
| Refresh | Trigger-based or periodic update notes with dated exports |
| Vendor subset | Critical third-party risks reflected in the register or linked vendor reviews |
Evidence quality improves when the register shows who decided what, when, and what changed after treatment. See evidence collection, Risk Assessment Evidence for SOC 2, and What Is SOC 2 Evidence?.
Framework Notes
SOC 2
SOC 2 programs commonly expect organizations to identify and analyze risks that could affect objectives related to the Trust Services Criteria in scope. A maintained risk register is a widely used way to show those risks, treatments, and owners across the audit period. Auditors may ask for register exports covering the window, how results informed controls, and whether significant changes triggered updates. Treat this as common practice language, not a verbatim AICPA quotation. Related: SOC 2 Trust Services Criteria Explained and SOC 2 Type 1 vs Type 2.
ISO 27001
ISO 27001-oriented programs place risk assessment and risk treatment at the center of the Information Security Management System. Typical artifacts include methodology, risk register, risk treatment plan, and Statement of Applicability decisions. See ISO 27001 and control mapping.
Other programs
HIPAA security risk analysis, PCI DSS risk-related expectations, and NIST-oriented risk framing follow the same idea: identify, rate, treat, document, re-review. Reuse mapped controls carefully rather than assuming one register satisfies every obligation set.
Common Failures
Watch for these patterns:
- A brainstorm slide with no durable register or unique risk IDs
- Risks without owners or next review dates
- Acceptances with no end date or compensating control notes
- Register that lists threats but never links to controls or remediation work
- Confusing gap analysis "not met" rows with risk register rows
- Vendor inventory incomplete, so third-party risk is invisible
- Filing last year's PDF and calling the period covered (control drift)
- Multiple conflicting spreadsheets with no single system of record
These failures create diligence friction and weak prioritization.
Continuous Compliance Bridge
A kickoff register helps you start. It is not enough on its own for a Type 2 period. Continuous compliance means you refresh material risks when systems change, retain dated register exports, and connect treatment to live tickets and control evidence. See also AuditFlo's continuous compliance resource, Risk Assessment Evidence for SOC 2, and how to prepare for a SOC 2 audit.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for risk-adjacent and control artifacts when those records are stored or linked through connected systems and workflows your team already uses.
The focus is organizing dated proof so risk-informed control claims can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the risk register and assessment process your organization defines. It does not build your register for you, does not set your risk appetite, does not approve acceptances, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
A risk register is the living inventory of identified risks with ratings, treatments, owners, and review dates. It is the durable output of risk assessment, distinct from a gap register and from an issue log. Keep rows current, link treatments to controls, time-bound acceptances, and retain dated exports across the audit period.