The risk register and the exception register: recording what was accepted

Accepting risk is a decision, and a decision that lives only in a meeting is not a governance record. Two records carry it. The risk register holds the risks an organisation has identified with the response chosen for each, and keeps the reasoning behind the choice. The exception register holds the deviations somebody with authority allowed, and records when they end. They fail differently: a register that is only a list of problems records no decisions, and an exception with no expiry becomes a permanent waiver.

The register is a decision log

NISTIR 8286r1 treats the register as the document that carries risk information through the whole process (lines 331–332), and adopts OMB Circular A-11’s definition: “a repository of risk information including the data understood about risks over time” (line 341). Table 1 lists the elements of its notional register (lines 807–851): identifier, priority, description, category; likelihood, impact, exposure rating; response type, cost, description; risk owner; status. r1 calls this a model rather than a schema — it “illustrates a single point in time”, and the register may hold more or fewer data points than Table 1 describes (line 859). SP 800-53r5 RA-3 requires the assessment results behind those rows to be documented in the security and privacy plans or in a risk assessment report (line 15892); the register is the summary layer above that documentation.

A row of elements is still not a decision, so r1 splits the record. A risk detail record “documents the considerations, assumptions, and results of risk management activities to keep the formal risk register a summary rather than a large, detailed report” (lines 872–874), and carries “the roles involved in risk decisions and management” plus the dates that make an entry reviewable: first documented, last assessment, mitigation completion, next expected assessment (lines 893, 897–899).

Who signs an entry, and who may accept

Table 1 defines the risk owner as “the designated party responsible and accountable for ensuring that the risk is maintained in accordance with enterprise requirements”, who may work with a designated risk manager (lines 847–850); r1 adds the authority: “Each risk in the register is assigned a risk owner … The risk owner is accountable for applying the priority … to select and assign appropriate risk responses” (lines 1932–1934). The acceptance itself is not the owner’s to give: “The explicit acceptance of risk … cannot be delegated to other officials within the organization” (SP 800-37r2, lines 4942–4943).

The exception register: authority, justification, expiry

CSF 2.0 places exceptions with changes: at ID.RA-07, “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked” (lines 905–906). “Exception register” is not NIST vocabulary: the phrase does not occur anywhere in the corpus. A usable entry answers four questions: who authorised the deviation, what justifies it, what compensates for it, when it ends. SP 800-53r5 defines no exception control; where its controls handle one, they attach those obligations. SC-7(4) requires organisations to “Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need” and to “Review exceptions … and remove exceptions that are no longer supported” (lines 19594–19597). CM-7(8) permits an exception to its prohibition on binary code from sources with limited or no warranty “only for compelling mission or operational requirements and with the approval of the authorizing official” (lines 7772–7773). A register with fewer fields than that can be read, but not reviewed.

risk identified and assessed       likelihood, impact, exposure rating
        |
response chosen                    mitigate, avoid, transfer, share, accept
        |
decision recorded                  who decided, on what evidence, until when
        |
deviation authorised?              named official, justification, compensating measure
        |
expiry and review                  the deviation ends, or it is renewed on the record

Where an accepted deviation actually lives

There is no “waiver control” in SP 800-53r5, and inventing one records a mechanism nothing defines. FIPS 200’s section headed “Waivers” says only that FISMA provides no waiver route for the FIPS it makes mandatory (lines 150–153). What NIST supplies instead is two documented decisions. The first is authorisation — “the final action before a system is placed into operation is the explicit acceptance of risk by the authorizing official” (SP 800-37r2, lines 2013–2014). The second is the plan of action and milestones: CA-5 requires the POA&M to document the planned remediation of weaknesses and deficiencies (lines 6636–6637); RA-7 adds that where a mitigation “cannot be completed immediately, a plan of action and milestones entry is generated” (lines 16273–16274); and SP 800-37r2 gives the converse — “Plan of action and milestones entries are not necessary when deficiencies are accepted by the authorizing official as residual risk” (lines 4640–4642).

What age does to each register

A register that is never revisited becomes the history of a past opinion. r1 asks programmes to “specify the frequency and methods for monitoring, evaluating the effectiveness of, and adjusting risk responses” (lines 1951–1952); it is blunt about accepted entries: “Even when risks are identified and marked as accepted, they need to be measured to ensure that they remain within established risk tolerance parameters” (lines 2005–2006). An exception ages differently — it is terminated, not re-judged — and until it is, the deviation also owes a change record: CM-3 requires configuration-controlled changes to be approved or disapproved “with explicit consideration for security and privacy impact analyses” (lines 7242–7243).

Level and prerequisites

L2 — operational: the two records, their fields, their owners, their review. Prerequisites are the L1 vocabulary of risk, response and acceptance; quantification and remediation timelines are later material.

Where to go next

Knowledge — the index.
Cybersecurity Governance — the area this sheet belongs to.
Risk management — this sheet’s node.

Related sheets are unpublished and named in prose only: at L1, risk appetite and acceptance criteria, risk factors and treating a risk; in this batch, asset and service inventory.

References

NIST — NISTIR 8286r1, Integrating Cybersecurity and Enterprise Risk Management (ERM) (December 2025) — https://doi.org/10.6028/NIST.IR.8286r1 — the register as a decision record, its template elements, the risk detail record, the risk owner and the review and archiving of entries.
NIST — SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — https://doi.org/10.6028/NIST.SP.800-53r5 — RA-7 (risk response and the POA&M entry), CA-5 (plan of action and milestones), SC-7(4) and CM-7(8) (documented exceptions), CM-3 (the change record).
NIST — SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations — https://doi.org/10.6028/NIST.SP.800-37r2 — the explicit acceptance of risk by the authorising official, and what the POA&M does and does not need to contain.
NIST — The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 — https://doi.org/10.6028/NIST.CSWP.29 — ID.RA-07 (changes and exceptions managed, recorded and tracked), the anchor for the exception register, with ID.RA-06 (responses tracked) and GV.RM-06 (a standardised method for documenting risks).
NIST — FIPS 200, Minimum Security Requirements for Federal Information and Information Systems (March 2006) — https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf (no DOI is printed in this 2006 edition) — used only for its section “Waivers” and the statement that FISMA provides no waiver route for the mandatory FIPS.
NIST — SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations — https://doi.org/10.6028/NIST.SP.800-53Ar5 — used only to confirm the enhancement numbering SC-7(4), SC-7(5) and CM-7(8) against the interleaved summary table of SP 800-53r5.