- Findings from internal assessments, monitoring, incidents, and supplier reviews — the register's four feeder sources
- The POA&M (ATL-006), so mitigation decisions land as tracked entries rather than intentions
- An agreed likelihood and impact scale, written down before the first risk is rated
ATL-005REGISTEREDITORIAL REVIEW COMPLETE
Risk Register
A working register of the organization's security risks — each one stated as condition and consequence, rated on a fixed scale, given an explicit treatment decision and a named owner, linked to the POA&M entry that carries its mitigation, and reviewed on a cadence that keeps the ratings honest.
Using this artifact
Purpose, inputs, and completion
Purpose. A risk register is where an organization decides, on the record, what it will fix, what it will live with, and who said so. Kept honestly, it converts scattered worries into rated, owned, dated decisions; kept badly, it is a spreadsheet of anxieties nobody reads. This template supplies the columns and — more importantly — the discipline for the honest version.
When to use it. Feed it from four sources — assessments, monitoring, incidents, and supplier reviews — and record the source on every row so a reviewer can see where risks come from and which source has gone quiet. Rate against fixed scales, decide treatment explicitly, and route mitigations to the POA&M rather than tracking work here. Review High risks monthly and everything quarterly; the Last reviewed column is the register's own freshness meter.
- Write each risk as condition then consequence: because X is true, Y could happen to Z — one risk per row, no compound entries.
- Rate likelihood and impact against the fixed scales before discussing treatment, so the rating is not argued backward from the preferred answer.
- Record an explicit treatment decision — accept, mitigate, transfer, or avoid — with a named owner and a due date; 'monitoring it' is not a decision.
- Link every mitigate decision to a POA&M entry, and bring every acceptance to the approver by name.
- Update Last reviewed at every review, even when nothing changed — an unreviewed register decays silently.
Keeping it honest
Evidence, validation, and failure modes
- A dated register of identified risks with explicit, owner-signed treatment decisions
- A traceable link from each mitigated risk to the POA&M entry carrying its work
- A review trail showing ratings were revisited on cadence, not set once and abandoned
- Pick any Accept row and ask who accepted it and when; if the answer is not the named approver on a recorded date, the acceptance never actually happened.
- Pick any Mitigate row and follow its linked POA&M entry; the entry must exist, be open or closed with evidence, and describe the same risk.
What looks done but is not
- Risk statements that are really just topic labels — 'ransomware', 'phishing' — which cannot be rated, treated, or closed because they assert nothing.
- Every risk rated Medium, because Medium offends no one and commits no one; a register with no High and no Low is a register no one believed.
- Acceptances by default: risks that sat untreated so long they became accepted in practice without anyone with authority ever deciding.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain the register and its change history for at least three years; treatment decisions — acceptances above all — are the record both an incident review and an assessor will ask to see.
Full document
Preview — exactly what prints
REGISTER · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
Risk Register
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
A risk register is where an organization decides, on the record, what it will fix, what it will live with, and who said so. Kept honestly, it converts scattered worries into rated, owned, dated decisions; kept badly, it is a spreadsheet of anxieties nobody reads. This template supplies the columns and — more importantly — the discipline for the honest version.
How to use it
Feed it from four sources — assessments, monitoring, incidents, and supplier reviews — and record the source on every row so a reviewer can see where risks come from and which source has gone quiet. Rate against fixed scales, decide treatment explicitly, and route mitigations to the POA&M rather than tracking work here. Review High risks monthly and everything quarterly; the Last reviewed column is the register's own freshness meter.
How to use this register
One row per risk. The register records the decision about a risk; the POA&M records the work. Keeping those separate is what lets an executive read this register in ten minutes: every row shows what could happen, how bad, and what was decided — not a project plan.
The Source column is the register's health check
Every risk arrives from somewhere: an assessment, monitoring, an incident, or a supplier review. If months of rows all cite the same single source, the other feeders are silent — which is itself a finding about your program, visible right in this register.
Writing risk statements that mean something
A risk statement is a condition and a consequence. If a row cannot be read as 'because X, Y could happen to Z', it cannot be rated and cannot be treated.
- State the condition — something true today and verifiable
- 'VPN accounts authenticate with password only' is a condition; 'phishing' is a topic.
- State the consequence — what could happen to what asset or obligation
- '…a phished credential reaches the file share holding contract data' names the harm and the stake.
- One risk per row
- Compound statements get one rating for three problems, and the rating fits none of them.
- No solutions inside the statement
- 'We lack tool X' presumes the treatment; state the exposure and decide treatment separately.
The register
The working table. The CSV download carries the same columns for use in a spreadsheet.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| ID | Risk statement | Source | Likelihood | Impact | Rating | Treatment decision | Owner | Due date | Linked POA&M entry | Status | Last reviewed |
|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: R-001 | Because VPN accounts authenticate with password only, a phished credential could reach the file share holding contract data | Internal assessment, 2026-06 | Likely | High | High | Mitigate | J. Rivera (IT lead) | 2026-10-15 | POAM-004 | Open | 2026-08-01 |
Rating discipline and review cadence
- Write the likelihood and impact scales down before rating anything
- Three levels each is enough; what matters is that 'Likely' and 'High' mean the same thing on every row.
- Rate before treatment is discussed
- Ratings argued after a treatment preference exists get bent to justify it.
- Never change a rating without a note saying what changed in the world
- Review High risks monthly, the full register quarterly, and touch Last reviewed every time
- Escalate any risk past its due date with no status change to the approver by name
- A stale High risk is an acceptance nobody signed.
Acceptance is a legitimate decision — some risks are genuinely not worth their mitigation. What is not legitimate is acceptance by drift. Every Accept row needs the approver's name and a date, and every acceptance gets re-argued at the quarterly review, because the world that justified it moves.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Monthly for open High-rated risks; the full register quarterly and after every incident or assessment |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain the register and its change history for at least three years; treatment decisions — acceptances above all — are the record both an incident review and an assessor will ask to see. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.