RISK REGISTER AND EXCEPTION PROCESS

Identification · Treatment · Acceptance · Review

Table of Contents

1. Purpose and Scope
2. Roles and Responsibilities
3. Risk Identification
4. Risk Assessment and Scoring
5. Risk Treatment
6. The Risk Register
7. Exception Process
8. Approval Authority
9. Review, Escalation, and Reporting
10. Integration With Other Programs
11. Regulatory and Framework Alignment Summary
12. Procedure Control

1. Purpose and Scope

This procedure operationalizes the risk management principle established in CERG-POL-001 Principle 9. It defines how the organization identifies, documents, scores, treats, reviews, and reports cybersecurity risks, and how exceptions to established controls are requested, approved, tracked, and reviewed.

The risk register is the single, authoritative record of organizational cybersecurity risk. The exception process is the single, authoritative record of intentional deviations from established controls. The two are coupled: every approved exception is itself a risk-register entry.

1.1 Scope

This procedure applies to:

• All cybersecurity risks affecting in-scope assets, data, or operations
• All deviations from controls established in CERG-POL-001 and its subordinate standards and procedures
• All risk-related decisions requiring documentation: acceptance, transfer, avoidance, and reduction
• All organizational personnel, every CERG team member, every asset owner, every business sponsor of a system or process that holds cybersecurity risk

1.2 The Operating Premise

Undocumented Risk Is Accepted Risk Without an Owner

Every organization has more risk than it has time to remediate. The question is not whether risk exists, it is whether the organization has a documented, owned, and reviewed posture toward each one. An undocumented risk that materializes into an incident leaves no audit trail of what was known, who knew it, or why nothing was done. CERG treats the risk register as evidence of program maturity, not as a chore.

1.3 Risk Appetite and Tolerance

The organization’s risk appetite defines the amount and type of risk the organization is willing to accept in pursuit of its objectives. Without a stated appetite, “accept” decisions lack an objective anchor, and scoring discussions drift toward personal calibration.

Appetite Statement

The organization accepts residual risk only where (a) the cost or operational impact of further treatment demonstrably exceeds the residual risk, (b) compensating controls are in place and operating effectively, and (c) the risk does not threaten regulatory standing, customer trust, or safety. Risk that cannot satisfy all three conditions must be treated.

Quantitative Tolerance Thresholds

The durations below are scope-specific treatment horizons. They do not extend risk-acceptance authority or duration beyond the canonical limits in CERG-GOV-RMF-001 §9.7; when more than one rule applies, the shortest applicable duration wins.

Tolerance by Business Unit

Tolerance thresholds may vary by business unit where the business unit operates under materially different regulatory, contractual, or operational risk profiles. Business unit tolerance adjustments are proposed by the Risk Owner in that unit, reviewed by the Governance Pillar Leader, and approved by the CISO. Adjustments are recorded in the risk register as a standing annotation on the business unit’s scope.

Board and Leadership Engagement

The board or an authorized board committee reviews and affirms the organization’s risk appetite annually. Material changes to risk appetite - including adjustments to quantitative thresholds or tolerance by business unit - are submitted to the CISO for recommendation and board approval. The CISO owns the annual appetite affirmation cycle and reports the organization’s actual risk posture against appetite at each quarterly CISO-level review.

2. Roles and Responsibilities

3. Risk Identification

A risk is a potential event that could adversely affect organizational assets, operations, or obligations. Risks may be technical (a vulnerability, a misconfiguration, a control gap), programmatic (a process gap, a staffing gap), or external (a regulatory change, a vendor failure, a threat actor’s interest).

3.1 Sources of Risk

Risks are identified continuously from the following sources, each of which feeds the register:

3.2 Intake

Any personnel may submit a candidate risk through the centralized intake. Submissions include the proposed risk statement, affected assets, observed or estimated impact, and supporting context. Governance triages submissions within 5 business days into one of: accept as new register entry, merge with existing entry, escalate to active investigation, or return with explanation.

4. Risk Assessment and Scoring

4.1 Risk Statement

Each risk is expressed in a consistent, declarative form:

“[Event / condition] affecting [asset class / scope] could result in [impact] within [likelihood window] unless [control / treatment].”

Risk statements are specific enough to support scoring. “We need better cloud security” is not a risk statement; “Unauthorized changes to production cloud IAM roles could result in privilege escalation enabling exfiltration of customer data within the current control period unless drift detection and JIT elevation are enforced” is.

4.2 Scoring Framework

Risks are scored using the canonical 5×5 Likelihood × Impact model in CERG-GOV-RMF-001 §9.5. This procedure operationalizes that model; it does not define a separate scoring scale. If this procedure and RMF-001 differ, RMF-001 governs.

The matrix produces a residual risk rating after considering controls in place. Inherent risk (controls hypothetically absent) is recorded but not the primary driver of treatment decisions.

Likelihood Summary

Impact Summary

Rating Bands

4.3 Quantitative Calibration Guide

Quantitative calibration is maintained in CERG-GOV-RMF-001 §9.5 and §12. Local revenue, insurance, downtime, regulatory, and safety thresholds may be calibrated there, but calibrated thresholds do not override the acceptance authority in RMF-001 §9.7.

Using Calibration in Scoring Discussions

The calibration table is a coordination tool, not a precise calculator. When two analysts reach different scores: 1. Each states their rationale in terms of likelihood (what is the annualized frequency?) and impact (what is the estimated financial, operational, regulatory, safety, or customer consequence?). 2. The Governance Lead facilitates the discussion toward the better-supported score using RMF-001 §9.5. 3. If disagreement persists, the higher score is used and the rationale for both scores is recorded.

The goal is not perfect precision - it is consistent conversation that produces comparable risk rankings across the register.

4.4 Scoring Discipline

The 5×5 Trap

The 5×5 matrix is a coordination tool, not an oracle. Two analysts will reach different scores for the same risk; the value of the matrix is consistency of conversation, not precision of measurement. The Governance Lead enforces consistency within the register and reconciles outliers, but does not fight every score. The goal is comparable risks ranked comparably, not perfect calibration.

Re-score upon: material change in observed threat activity, completion of treatment work, new compensating controls, new exploitation indicators, or regulator / customer engagement that materially changes impact.

5. Risk Treatment

Each risk has one of four treatment decisions. Treatment is decided by the risk owner with input from CERG and approved per Section 8.

5.1 Treatment Plan Elements

Every treatment decision records:

• The selected treatment.
• The plan, for Reduce: target end-state controls and the steps to get there; for Transfer: the instrument and counter-party; for Avoid: the cessation steps; for Accept: the rationale and conditions of acceptance.
• Owner, accountable for the plan’s execution.
• Target dates, milestone and final.
• Compensating controls, in place now and required for the duration of the plan.
• Trigger conditions for re-evaluation, what would invalidate the current decision.

5.2 Funding or Capacity Decision Brief

When a treatment cannot proceed because funding, staffing, change-window capacity, vendor spend, or business prioritization is unavailable, the Risk Register Owner attaches a Control Funding Decision Brief using CERG-GOV-MTR-001 §6.1. The brief records the decision needed, control/risk link, business capability affected, options, deadline, and consequence of deferral.

A funding or capacity deferral does not by itself accept residual risk. If residual risk remains after the decision, the Business Owner or required RMF-001 authority must complete CERG-TMPL-RM-004, and the risk register records the acceptance, expiration, treatment owner, and next review date.

5.3 Risk Acceptance Has Two Forms

6. The Risk Register

6.1 Required Fields

6.2 Quality and Integrity

The Governance Lead curates the register for quality. Specifically:

• Risks shall not be duplicated; new submissions are merged with existing entries when appropriate.
• Risk statements that are vague or unscope-able are returned for clarification.
• Risks that are no longer relevant (e.g., the underlying system has been decommissioned) are closed with rationale.
• Closed risks remain queryable; the register is append-only at the audit-trail level.

6.3 Risk Taxonomy

The following taxonomy is the controlled vocabulary for risk categorization. Every risk entry must be assigned exactly one category from this taxonomy. Consistent categorization enables trend analysis, ownership clarity, and regulatory mapping.

Access and Confidentiality

Risk register access is role-based. Business owners see their scope by default; CERG personnel see organization-wide. Specific risk entries may be marked Restricted (e.g., active high-sensitivity exposure, insider matters) with limited visibility. The CISO has full visibility at all times.

7. Exception Process

7.1 Exception vs. Risk Acceptance — Which Path to Use

Per CERG-GOV-RMF-001 §9.7a, CERG distinguishes two distinct decision paths. Using the wrong path bypasses the required approval authority.

Routing rule: If the trigger is a control or standard that cannot be met → Security Exception (TMPL-RM-002). If the trigger is residual risk the organization chooses to live with → Risk Acceptance (TMPL-RM-004). When in doubt, route as Security Exception; the Risk Register Owner may reclassify during triage.

7.2 What Requires an Exception

An exception is required whenever a system, person, or process intentionally deviates from a control established in CERG-POL-001 or its subordinate standards. Examples include:

• A system that cannot meet a hardening baseline due to a vendor or operational constraint
• A user role that requires standing privileged access despite the JIT requirement
• A SaaS application not behind SSO due to a technical limitation
• A vulnerability remediation that cannot meet the SLA
• A vendor account configuration not meeting the access management standard
• An OT system that cannot satisfy a CIP-007 requirement on schedule (in addition to the CIP deviation process)

7.3 Exception Workflow

7.4 Exception Discipline

Renewals Are Where Programs Decay

The most common failure mode of an exception program is the silent renewal. An exception is approved with a six-month duration; six months later it is renewed with a single email; six months after that the original reviewers have left the organization, the compensating controls have drifted, and the underlying control gap has become permanent. Governance enforces re-evaluation at every renewal: confirm the compensating controls are still in place, confirm the business justification is still valid, confirm the requested duration is still reasonable.

7.4.1 Exception Expiration Warning Chain

Every exception carries an expiration date. The following warning chain ensures no exception expires silently:

An exception renewed more than twice without material progress toward remediation escalates one approval tier above the original approver. If the renewal also accepts residual risk, the approval path follows RMF-001 §9.7. The renewal justification must document what has changed since the previous approval and what prevents closure.

7.5 Regulatory Overlays

For exceptions affecting regulated assets:

• NERC-CIP (BES Cyber Systems): A CIP deviation and mitigation plan is initiated in addition to this exception. Governance coordinates per CERG-STD-OT-001 §11.
• CMMC / 800-171 (CUI environments): A POA&M entry is opened in addition to this exception, per CERG-STD-CUI-001 §11.
• SOX-relevant systems: Internal Audit and CFO designee are notified for ITGC control gaps. Compensating ITGC controls are documented for audit.
• Customer / contractual: Where the affected control supports a customer contractual commitment, Account Management and Legal are notified for customer-notification decisions.

7.6 Exception Request Form and Risk Acceptance Form Templates

The following templates shall be used for all exception and acceptance requests. Use the correct form per the routing rule in §7.1. Completed forms are submitted through the centralized risk intake and referenced in the risk register.

For Security Exceptions (policy/standard deviation, Governance-tracked): use CERG-TMPL-RM-002 — Security Exception Request Form.

For Risk Acceptances (Business Owner accepts residual risk, per-RMF-001 authority): use CERG-TMPL-RM-004 — Risk Acceptance Request Form.

The Security Exception Request Form (TMPL-RM-002) template is reproduced below for reference. The Risk Acceptance Request Form (TMPL-RM-004) is a separate artifact. CERG-TMPL-RM-003 may be attached as a lightweight memo, but it does not replace TMPL-RM-004 or RMF-001 §9.7 approval authority.

EXCEPTION REQUEST FORM - EXC-YYYY-NNNN

1. REQUESTOR
   Name:
   Role / Title:
   Department / Business Unit:
   Date of Request:

2. CONTROL(S) TO BE EXCEPTED
   Control ID (from CERG-GOV-CB-001 or applicable standard):
   Control Description:
   Standard / Policy Reference:

3. AFFECTED SCOPE
   System(s) / Asset(s):
   Environment (IT / Cloud / SaaS / OT):
   Data Classification(s):
   Regulatory Scope (NERC-CIP / CUI / SOX / Other):
   Number of Users Impacted:

4. BUSINESS JUSTIFICATION
   Why is the exception necessary? What business outcome depends on it?

   What alternatives were considered and why were they rejected?

5. RISK ASSESSMENT OF THE EXCEPTION
   Inherent Risk (Likelihood × Impact):
   Description of the risk created by this exception:
   Existing Compensating Controls:
   Residual Risk after Compensating Controls (Likelihood × Impact):
   Residual Risk Rating (Low / Medium / High / Critical):

6. COMPENSATING CONTROLS (detailed)
   | Control | Description | Owner | Implementation Date | Validation Method |
   |---|---|---|---|---|
   | | | | | |

7. DURATION
   Proposed Start Date:
   Proposed End Date:
   Renewal Expected? (Yes / No):
   If yes, what conditions must be met for renewal?

8. APPROVAL
   | Role | Name | Decision | Date |
   |---|---|---|---|
   | Business Owner (Risk Owner) | | Approve / Deny / Conditional | |
   | Engineering Pillar Leader | | Approve / Deny / Conditional | |
   | Governance Pillar Leader | | Approve / Deny / Conditional | |
   | CISO (if High or Critical) | | Approve / Deny / Conditional | |
   | Executive Sponsor (if Critical) | | Approve / Deny / Conditional | |

9. RISK REGISTER LINKAGE
   Risk Register Entry ID:
   Exception ID cross-reference:

10. CLOSURE
    Actual End Date:
    Closure Rationale:
    Closure Approver:

8. Approval Authority

Risk treatment decisions require documented approval from the authority matching the risk’s severity. The canonical approval authority table — including the Business role at every level — is maintained in CERG-GOV-RMF-001 §9.7. The table below summarizes approval authority for convenience; the RMF table is authoritative. Security assesses, recommends, and validates. The business owner owns the consequence.

Approvers may delegate within their authority but shall document the delegation. The CISO retains final authority for any risk-related decision. Acceptance of residual risk at any tier follows the canonical authority table in CERG-GOV-RMF-001 §9.7. The business owner accepts the business risk — security does not accept business risk. No acceptance expires automatically; every acceptance at every tier requires a fresh approval cycle at expiration.

9. Review, Escalation, and Reporting

9.1 Review Cadence

9.2 Escalation Triggers

The following trigger escalation to the CISO outside the standing cadence:

• A new High or Critical risk
• A material score increase on any existing risk
• A risk acceptance approaching expiration without a credible treatment plan
• A material deterioration in compensating control performance
• Realization of a risk into an incident
• A regulator or auditor inquiry referencing a register entry
• A renewal request for an exception in its second consecutive cycle

9.3 Reporting

Standing reports (consumed by Governance dashboards):

9.4 Quality Indicators

The Governance Lead monitors the register itself for health:

• Median age of open High and Critical risks
• % of treatment plans on schedule
• Exception re-evaluation rate (declined vs. renewed)
• % of risks with a documented owner
• % of risks reviewed within their scheduled review date

10. Integration With Other Programs

The risk register is the integration point for several other programs. Risk-register entries derive from and feed back into:

The register is not a parallel system to these programs. It is the connective tissue that lets each program point to the same set of facts.

11. Regulatory and Framework Alignment Summary

12. Procedure Control

Revision History

Review Triggers

This procedure shall be reviewed annually and upon any of the following:

• Material change to risk taxonomy or scoring scheme
• Material change to risk-management tooling
• Material change to regulatory expectations affecting risk acceptance, POA&M, or CIP deviation processes
• A significant incident or audit finding affecting the program
• Direction from the CISO

Governance owns this procedure. The Risk Register Owner is responsible for revisions, ongoing maintenance, and obtaining CISO approval for material updates.

Related Documents

Identify it. Score it. Record it. Own it.

CERG-PRC-RM-001 · Version 1.01 · Public

Source: procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md · Download .md · View on GitHub