A risk register is one of the most practical tools in security governance. It turns scattered concerns into a list that leaders can review, compare, and act on. For CISM, this matters because the exam does not want random technical facts. It expects you to think like a manager: define the risk clearly, evaluate it in business terms, choose a response, and explain it to stakeholders. A good risk register helps you do exactly that. In this guide, you will learn how to build a simple register, write strong risk statements, score likelihood and impact, choose treatments, report in a useful way, and track residual risk over time using a spreadsheet.
What a CISM-style risk register is really for
A risk register is not just a spreadsheet full of threats. It is a decision-making tool. Its job is to answer five basic questions:
- What could happen?
- What business asset or process would be affected?
- How likely is it?
- How serious would the impact be?
- What are we doing about it?
This is the mindset CISM expects. The exam usually frames risk in terms of business objectives, not isolated technical events. For example, “unpatched server” is not a complete risk statement. It is a condition. What matters is how that condition could harm the business, such as causing service downtime, exposing customer data, or breaking a regulatory requirement.
A useful register also creates accountability. Every listed risk should have an owner, a treatment decision, and a review date. Without that, risks become background noise. Teams know they exist, but nobody acts.
The core columns your risk register spreadsheet should include
You do not need a complicated GRC platform to think correctly. A spreadsheet is enough if the fields are chosen well. A solid CISM-friendly risk register usually includes these columns:
- Risk ID – A unique identifier such as R-001.
- Date identified – When the risk was first recorded.
- Business process or asset – The system, vendor, application, data set, or process at risk.
- Risk statement – A full sentence describing the risk.
- Threat – What could cause harm, such as phishing, hardware failure, insider misuse, or supplier outage.
- Vulnerability or condition – The weakness that makes the threat possible, such as missing MFA or poor backup testing.
- Likelihood score – How probable the event is.
- Impact score – The business effect if it happens.
- Inherent risk score – The risk level before additional treatment.
- Existing controls – What already reduces the risk.
- Treatment option – Accept, mitigate, transfer, avoid.
- Action plan – Specific next steps.
- Risk owner – The person accountable for the risk.
- Target date – When treatment should be completed.
- Residual likelihood – Likelihood after controls or treatment.
- Residual impact – Impact remaining after treatment.
- Residual risk score – The remaining risk level.
- Status – Open, in progress, accepted, closed, under review.
- Last review date – When the risk was last checked.
- Comments – Key updates, incidents, decisions, or exceptions.
These columns matter because they separate description from judgment. Many poor registers mix facts, assumptions, and treatment decisions into one messy note. A better structure forces clear thinking.
How to write risk statements the exam would accept
A strong risk statement should connect the source of risk to a business consequence. One of the easiest formats is:
If [threat] exploits [vulnerability/condition], then [business impact] may occur, affecting [asset/process/objective].
Here is a weak example:
- Weak: Email security is poor.
This is too vague. It does not say what could happen or why it matters.
Now a stronger version:
- Strong: If phishing emails bypass current filtering and employees submit credentials, unauthorized access to the finance system may occur, leading to payment fraud and disruption of month-end processing.
Why this works:
- It identifies the threat: phishing emails.
- It identifies the condition: filtering is not fully effective and users may submit credentials.
- It identifies the business impact: fraud and process disruption.
- It ties the issue to a business process: finance operations.
Another example:
- Weak: Backups need improvement.
- Strong: If backup restoration continues to go untested, the organization may be unable to recover critical customer data after ransomware, causing extended downtime, service penalties, and reputational damage.
CISM favors this kind of wording because it is clear enough for management decisions. It avoids technical detail that does not help prioritization.
How to score likelihood and impact in a practical way
Many organizations use a 1-to-5 scale because it is simple and easy to explain. The scale matters less than consistency. If one team uses “3” to mean “possible once a year” and another uses it to mean “rare,” the register becomes unreliable.
A simple scoring model could look like this:
Likelihood
- 1 – Rare: Unlikely under current conditions.
- 2 – Unlikely: Could happen, but not expected.
- 3 – Possible: A realistic scenario.
- 4 – Likely: Expected to happen in many circumstances.
- 5 – Almost certain: Happens often or has clear indicators.
Impact
- 1 – Insignificant: Small operational inconvenience.
- 2 – Minor: Limited disruption or low financial loss.
- 3 – Moderate: Noticeable business disruption, management attention needed.
- 4 – Major: Serious service interruption, regulatory concern, or major financial loss.
- 5 – Severe: Critical business failure, major legal exposure, or lasting reputational damage.
Most teams calculate risk score as likelihood × impact. That gives a range from 1 to 25. Then they map the number to low, medium, high, or critical. For example:
- 1–5: Low
- 6–10: Moderate
- 11–15: High
- 16–25: Critical
This is simple, but the real value comes from how you assign the scores. Do not guess. Use evidence where possible:
- Past incidents
- Known control weaknesses
- Audit findings
- Threat intelligence
- Vendor history
- Business dependency on the asset
- Regulatory exposure
For CISM thinking, impact should usually carry business weight. A low-frequency event can still rank high if the business impact is severe. That is why a risk to a payment platform or regulated data set often deserves management attention even if the event is not frequent.
Inherent risk versus residual risk
This distinction is important in both real life and the exam.
Inherent risk is the level of risk before considering additional treatment. It reflects the raw exposure.
Residual risk is what remains after current or planned controls are applied.
Example:
- A public-facing application has weak access control and no MFA.
- Inherent likelihood: 4
- Inherent impact: 5
- Inherent score: 20
Now the team implements MFA, strengthens monitoring, and limits admin rights.
- Residual likelihood: 2
- Residual impact: 4
- Residual score: 8
The impact may still be high because compromise would still hurt the business. But the likelihood drops because the controls make exploitation harder. This is a common exam pattern: controls often reduce likelihood more than impact.
Residual risk is what leaders need to accept, escalate, or continue treating. If the remaining risk is still above the organization’s tolerance, the action plan is not finished.
Choosing the right treatment: accept, mitigate, transfer, or avoid
Every risk in the register should have a treatment decision. Without one, there is no management action.
- Accept – The organization knowingly keeps the risk because it is within tolerance or treatment costs more than the likely loss.
- Mitigate – Add or improve controls to reduce likelihood or impact.
- Transfer – Shift some financial or operational burden to another party, such as insurance or a managed service provider.
- Avoid – Stop the risky activity entirely.
The right option depends on business context. For example:
- A legacy system supporting a critical process may need mitigation because shutting it down is not realistic yet.
- A low-value internal tool with known weaknesses may be avoided by retiring it.
- A high-loss, low-frequency event may be partly transferred through cyber insurance, but insurance does not replace controls.
- A low-impact issue may be accepted if leadership formally agrees.
CISM expects risk treatment to align with business goals, not just security preference. The best answer is usually the one that reduces risk in a cost-effective way while supporting operations.
A simple example of a well-formed register entry
Here is what one spreadsheet row might look like in plain language:
- Risk ID: R-014
- Asset/Process: Payroll system
- Risk statement: If privileged accounts in the payroll system remain without MFA, stolen credentials may allow unauthorized payroll changes, leading to financial loss, employee trust issues, and delayed payroll processing.
- Threat: Credential theft
- Vulnerability: No MFA on privileged access
- Likelihood: 4
- Impact: 4
- Inherent score: 16
- Existing controls: Password policy, access logging, quarterly access review
- Treatment: Mitigate
- Action plan: Implement MFA for all privileged accounts; enable alerting on payroll master file changes
- Owner: HR systems manager
- Target date: 30 June
- Residual likelihood: 2
- Residual impact: 4
- Residual score: 8
- Status: In progress
- Last review: 1 May
This entry works because it is actionable. A leader can quickly understand the risk, the reason for the rating, and the next step.
How to report risk to stakeholders without drowning them in detail
Different stakeholders need different levels of detail. A system owner may need control gaps and action items. A senior executive usually needs a shorter view: top risks, trends, decisions needed, and whether residual risk is within tolerance.
Good monthly reporting often includes:
- Top 5 or Top 10 risks by residual score
- Newly identified risks
- Risks that increased or decreased
- Overdue treatment actions
- Risks requiring acceptance or escalation
- Key themes, such as third-party risk, identity risk, or backup resilience
Keep the language tied to business effect. Instead of saying, “Several CVEs remain open,” say, “Delayed patching on customer-facing systems increases the chance of service interruption and data exposure.” That translation matters because executives fund business protection, not technical neatness.
If you are preparing for the exam, remember this pattern: report risk in a way that supports informed management decisions. The purpose is not to impress people with technical depth. It is to help them decide what to do.
Why monthly residual risk tracking matters
A risk register is not a one-time exercise. Risks change as the environment changes. New systems are deployed. Vendors change. Threats evolve. Controls weaken. Projects slip.
That is why residual risk should be reviewed at least monthly for important items. Monthly tracking helps you answer questions like:
- Did planned controls actually reduce risk?
- Is the risk still above tolerance?
- Has the treatment deadline passed?
- Did a recent incident change the score?
- Should leadership re-accept or re-prioritize the risk?
For example, if MFA implementation is delayed by two months, the residual score should not remain artificially low. The register must reflect reality, not hope. That is a common mistake in immature programs: once treatment is approved, the risk score is lowered before the control is actually working.
A monthly review cadence also makes the register more credible. People trust it when they see active ownership, updated dates, and real movement.
Common mistakes that weaken a risk register
Many registers fail for simple reasons. Watch for these problems:
- Listing issues instead of risks – “No MFA” is a control gap, not a full risk.
- No business impact – If the consequence is unclear, prioritization will be weak.
- Scoring without criteria – Ratings become subjective and inconsistent.
- No owner – If nobody owns the risk, nobody drives treatment.
- No treatment decision – Risks stay in limbo.
- No review cycle – The register becomes stale.
- Confusing inherent and residual risk – This hides the true exposure.
- Technical wording that leaders cannot use – This blocks decision-making.
Each of these mistakes reduces the value of the register. CISM thinking is disciplined: define risk clearly, score it consistently, assign responsibility, and communicate it in business terms.
Using a spreadsheet well for CISM practice and real work
A spreadsheet is enough to practice strong risk management habits. Keep it structured. Use drop-down values for status, treatment, and risk level so entries stay consistent. Add simple formulas for risk scoring. Highlight overdue actions. Filter by owner, business unit, or residual score.
If you are using a risk register spreadsheet as a study asset, try building five to ten example risks from different areas:
- Identity and access management
- Third-party risk
- Backup and recovery
- Cloud misconfiguration
- Data retention and privacy
- Incident response readiness
This gives you more than memorization. It trains you to think like the exam expects. If you want extra scenario practice, you can pair your spreadsheet work with a CISM practice test and compare how risk decisions are framed.
Final takeaway
A strong risk register does four things well: it states risk clearly, scores it consistently, assigns a treatment, and reports the remaining exposure in business terms. That is exactly the mindset CISM rewards. If your spreadsheet can show what could happen, why it matters, who owns it, what is being done, and what residual risk remains each month, you are already working at the level the exam expects. Keep it simple, specific, and current. That is what makes a risk register useful in the real world too.
