Module 18: Risk Register
If a risk isn't documented, it isn't governed.
The risk register operationalizes everything from Domain 1 and Domain 2:
- Risk scenarios
- Inherent risk
- Residual risk
- Ownership
- Response decisions
- Escalation
CRISC does not treat it as administrative paperwork.
It treats it as a governance instrument.
What the exam is really testing
When risk register appears, CRISC is asking:
- Are risks documented consistently?
- Is ownership assigned?
- Is risk evaluated properly?
- Is status tracked?
- Is escalation triggered when required?
- Is aggregation possible?
If the register is incomplete, governance visibility fails.
What a risk register must include
CRISC does not mandate a specific template, but expects structured components.
At minimum, a mature risk register includes:
- Risk ID
- Risk description (complete scenario)
- Asset/process affected
- Threat source
- Vulnerability
- Inherent risk rating
- Control effectiveness
- Residual risk rating
- Risk owner
- Response strategy
- Status
- Review date
- Escalation flag (if applicable)
Missing ownership or residual risk is a major governance weakness.
Inherent vs residual in the register
This is commonly tested.
Inherent risk = before controls
Residual risk = after controls
If a register only shows one risk rating without distinction, maturity is low.
CRISC expects visibility into:
- Raw exposure
- Control-adjusted exposure
Ownership is not optional
Every risk must have a defined owner.
Ownership means:
- Accountability
- Decision authority
- Acceptance authority
- Escalation responsibility
If a register lists “IT” or “Security” generically without a named accountable party, governance clarity is weak.
CRISC prefers clear ownership.
Risk response tracking
The register must reflect the chosen strategy:
- Avoid
- Mitigate
- Transfer
- Accept
And the current status:
- Open
- In progress
- Accepted
- Closed
- Escalated
Without tracking, risk governance becomes static.
The most common exam mistakes
Candidates assume:
- The register is only for IT risks
- Once documented, no further action is required
- Control existence eliminates risk documentation
- Aggregation happens automatically
CRISC expects:
- Enterprise visibility
- Continuous review
- Formal acceptance documentation
- Escalation when tolerance is exceeded
Example scenario (walk through it)
Scenario:
A high-impact risk is identified and mitigation controls are implemented. The remaining exposure is within tolerance. The risk is removed from the register.
What governance weakness exists?
A. Poor mitigation
B. Failure to reassess inherent risk
C. Lack of residual risk tracking
D. Excessive risk appetite
Correct answer:
C. Lack of residual risk tracking
Even if residual risk is within tolerance, it should remain documented for monitoring and aggregation.
Escalation trigger
If residual risk exceeds tolerance:
- The risk register should reflect escalation
- Formal risk acceptance must be documented
- Leadership visibility is required
If the register does not capture escalation status, governance maturity is low.
Aggregation & reporting
The register supports:
- Risk profile development
- Trend analysis
- Enterprise aggregation
- Board reporting
If risk entries are inconsistent or incomplete, aggregation becomes unreliable.
CRISC favors structured standardization.
Slightly harder scenario
An organization tracks risks in multiple spreadsheets across departments with inconsistent formats and scoring methods.
What is the MOST significant governance issue?
A. Weak threat modeling
B. Lack of centralized and standardized risk register
C. Excessive risk tolerance
D. Poor asset inventory
Correct answer:
B. Lack of centralized and standardized risk register
Without standardization, enterprise aggregation and visibility fail.
Register vs log
The risk register is not:
- An incident log
- A vulnerability scan output
- A project task tracker
It documents exposure — not events that already occurred.
Incident logs record past events.
Risk registers document potential exposure.
CRISC expects you to distinguish this.
Quick knowledge check
1) What must be included in a mature risk register entry?
A. Only inherent risk
B. Only residual risk
C. Assigned risk owner
D. Technical scan output
Answer & reasoning
Correct: C
Ownership is mandatory for governance accountability.
2) Removing a risk from the register because it is “within tolerance” indicates:
A. Strong ERM
B. Weak residual risk tracking
C. Excessive mitigation
D. Asset misclassification
Answer & reasoning
Correct: B
Risks should remain documented even when within tolerance.
3) Why is standardization of risk register entries important?
A. Reduces documentation workload
B. Supports enterprise aggregation and comparison
C. Improves encryption
D. Lowers inherent risk
Answer & reasoning
Correct: B
Consistent structure enables aggregation and enterprise visibility.
Final takeaway
The risk register is:
- A governance tool
- A visibility mechanism
- A tracking system
- An escalation trigger
- A foundation for aggregation
If risks are not documented clearly, owned formally, and evaluated consistently, governance fails quietly.
CRISC rewards candidates who understand that documentation is discipline — not bureaucracy.