RISK REGISTER TEMPLATES AND REPORTING

Register Schema · Exception Request · Scoring Examples · CISO Slice-and-Dice Reporting

Table of Contents

1. Purpose and Scope
2. Risk Statement Standard
3. Risk Register Schema
4. Worked Examples
5. Exception Request Template
6. Risk Scoring Guide
7. CISO Slice-and-Dice Reporting Views
8. Document Control

1. Purpose and Scope

CERG-PRC-RM-001 defines how risks and exceptions move through the program. This document is the executable package that makes that procedure operable: the register schema, the exception template, scoring examples, and the reporting views the CISO actually consumes. It is referenced from PRC-RM-001 and from CERG-GOV-CB-001 (control-to-evidence mapping).

Why Bind Risk Statements to Controls

A risk that does not map to at least one control is either a controls gap to add to the baseline or an over-broad risk to refine. A control that does not map to at least one risk is a control that nobody can defend. The register is the place those two libraries reconcile.

2. Risk Statement Standard

Every risk register entry has a single sentence, the Risk Statement, in this form:

Because of [threat / weakness], affecting [asset / scope], there is a possibility that [adverse event] occurs, resulting in [business impact].

The Risk Statement is derived from a control. The derivation pattern is:

If a risk does not map to a control in CERG-GOV-CB-001, one of three things happens: (1) the control is added to the baseline as a CERG-X control, (2) the risk is reframed against an existing control, or (3) the risk is rejected as out of scope.

3. Risk Register Schema

The schema below is the system-of-record contract regardless of tool (Excel, ServiceNow, Archer, RSA, custom).

3.1 Computed Fields and Workflow States

• Residual Score drives auto-routing to the approval queue per PRC-RM-001 §8.
• Review Cadence is set by residual score: Critical/High = Quarterly, Medium = Semi-Annual, Low = Annual.
• Last Validated Date is updated whenever the risk is reviewed, treatment status changes, control evidence is refreshed, closure is verified, or acceptance conditions are reapproved.
• Status transitions: Open → In Treatment → (Closed | Accepted) → Retired. Retired risks are kept for audit history.

4. Worked Examples

4.1 Example A: Risk Derived From a Partially Implemented Control

4.2 Example B: Risk Derived From a Risk-Accepted Exception

4.3 Example C: Risk Derived From an Inheritance Failure Mode

5. Exception Request Template

The exception is a request to deviate from a baseline control. It is a risk register entry once approved.

EXCEPTION REQUEST - EX-YYYY-NNNN

Requestor              :
Business Sponsor       :
Date Submitted         :
Requested Effective    :
Requested Expiration   :   (per RMF §9.7 default durations; shortest applicable regulatory or procedural duration wins)

Affected Asset(s)      :   (inventory ID + name)
Operating Unit         :
Regulatory Scope       :   CUI / BES / SOX / None

Control Being Deviated :   ([CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) control ID + family)
Subordinate Standard   :   (CERG-STD-* reference)
Standard Language      :   (quoted parameter that is being relaxed)
Proposed Deviation     :   (precise; not "we won't do X" but "we will do Y in place of X")

Business Driver        :   (why this is needed)
Compensating Controls  :   (specific, named, in place - not future tense)
Residual Risk Score    :   (per Section 6)
Risk Statement         :   (per Section 2)

Treatment Plan to      :
Close the Exception    :   (what makes this expire - usually a planned control)

Risk Owner             :
CERG Coordinator       :
Approver Required      :   (per PRC-RM-001 §8 - Engineering Mgr / CISO / Exec Sponsor)

Exception register fields mirror the risk register schema and add: Exception ID, Standard Reference, Deviation Text, Compensating Controls, Expiration Date, Renewal Allowed (Y/N), Renewal History.

Exceptions Are Not “Forever”

Every exception has an expiration date and a treatment plan that retires it. An exception renewed more than twice without movement on the treatment plan is escalated by the Risk Register Owner to the approver one level above the original.

6. Risk Scoring Guide

CERG scores risk on a 5×5 matrix, with control effectiveness as a step-down from inherent to residual.

6.1 Likelihood (1–5)

6.2 Impact (1–5)

Impact is scored across Safety, Operational, Financial, Regulatory, and Reputational dimensions; the highest dimension wins.

6.3 Control Effectiveness Step-Down

Residual cannot fall below 1. Step-downs are applied to inherent, never to residual.

6.4 Heat Map Bands

7. CISO Slice-and-Dice Reporting Views

The CISO will not consume the operational view. The CISO will consume views that compare and trend. The package below is what gets published, heat-maps, trend lines, and scorecards first; narrative memos in reserve for specific questions.

7.1 The Five Standing CISO Views

7.2 Anti-Shallow-Metrics Guardrails

Don’t Reward Closing Easy Vulns While Criticals Sit

The reporting views above deliberately weight score sum and Critical+High count over raw counts. A view that rewards closing 200 Lows while 4 Criticals sit untouched is a view that lies to the CISO. CERG reports the residual-score weighted sum first; raw counts second.

Additional guardrails baked into the views:

• OU Scorecard “Trend Arrow” is computed on residual-score weighted sum, never on count.
• Top 10 Risks rows must include the age of the highest-impact unmitigated finding inside that risk, so a 6-month-old Critical does not hide behind a freshly closed Low.
• OU Heat Map colors on Critical+High concentration, not on total count.
• Regulatory Posture “Practices Implemented %” is computed on the in-scope practice set with Partially Implemented counted as 0.5, not as 1.

7.3 Cadence

8. Document Control

Source: templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md · Download .md · View on GitHub