Module 18: Risk Register

CRISC Domain 2 — IT Risk Assessment Section B 10–12 min read
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.

Next Module Module 19: Risk Analysis Methodologies