ServiceNow Risk Register Explained

What Is a Risk Register?

A risk register in ServiceNow is a central record of the identified risks to your organisation: the threats and uncertainties that could affect projects, operations, services or business goals. Each entry carries a clear description, an assessment of likelihood and impact, the mitigation under way and a named owner. Project managers, enterprise architects and security teams use it to surface threats before they become crises, and the sections below cover how to score, govern and maintain it, and when a register is the wrong tool.

In ServiceNow, a risk register is configured in the Risk Management module or as records in a custom risk table. Each risk record tracks what could go wrong, why it matters, what is being done about it, and who is responsible for monitoring it. Unlike problems or incidents, which are reactive—something has already gone wrong—risks are proactive. You identify risks before they occur and take preventive action.

Risk Components: Likelihood, Impact, and Mitigation

Each risk has a likelihood assessment: how probable is this risk? Low, medium, high? And an impact assessment: if this risk occurs, how severe is the consequence? Low, medium, high? The combination of likelihood and impact determines the risk’s overall priority. A high-likelihood, high-impact risk needs immediate attention. A low-likelihood, low-impact risk might be monitored but not prioritised.

Every risk should have a mitigation strategy: what actions reduce the likelihood or impact? You might eliminate the risk entirely, reduce it to an acceptable level, transfer it to someone else (through insurance or outsourcing), or accept it and plan for contingency. Effective mitigation strategies are specific, measurable, and assigned to an owner with accountability for execution.

Risk Register Governance

A well-run risk register requires ownership and regular review. Someone must own the overall risk register—typically a chief risk officer, security lead, or programme manager—and ensure it stays current. Individual risks have owners who are responsible for tracking the risk, implementing mitigation, and updating status. A governance model specifies how often the register is reviewed, who reviews it, and how decisions are made about risk appetite and mitigation investment.

Common Risk Categories

Strategic risks affect your long-term direction: changes in market conditions, new competitors, regulatory changes. Operational risks affect day-to-day delivery: system failures, staffing gaps, vendor reliability. Project risks affect specific initiatives: schedule slippage, scope creep, resource constraints. Technical risks affect systems and platforms: security vulnerabilities, performance limits, technology obsolescence. Financial risks affect budgets and spending. Most organisations track risks across multiple categories.

Risk Assessment Frameworks

Assessing risks requires a framework. For each risk, ask: What is the probability this will happen? (Low/Medium/High, or numeric). What would the impact be if it occurs? (Low/Medium/High, or numeric). Some organisations use a matrix: high-likelihood, high-impact risks are critical and require immediate mitigation. Low-likelihood, low-impact risks are monitored but not actively managed.

The assessment framework should be documented and consistently applied. A risk that one assessor rates as medium should rate similarly when another assessor assesses it. Inconsistent assessment creates misleading priority rankings. Some organisations use expert judgment; others use historical data—”incidents of this type happen on average once per quarter, so probability is once per quarter.”

Risk Response Strategies

For each risk, define the response strategy. Mitigate: take action to reduce probability or impact. Accept: acknowledge the risk and plan for contingency if it occurs. Avoid: change plans to eliminate the risk entirely. Transfer: buy insurance or outsource to someone else. Terminate: eliminate the root cause. Effective risk management uses all five strategies depending on the risk.

Risk Register Maintenance

A static risk register is not useful. You must regularly review and update it. Established mitigations should reduce risk scores; new threats should be identified and added. Closed risks should be archived. Risks that have become realities—they actually occurred—should move to the incident or problem system. A quarterly or monthly review cycle is common, with continuous addition of newly discovered risks.

Related Concepts

Risk responses link risks to projects or change initiatives. If a change has a risk of service disruption, you might link that risk to a specific mitigation task. Audit trails in ServiceNow let you track who updated a risk, when, and what changed. Escalation rules ensure that high-priority risks receive management attention. Analytics let you trend which risk categories are growing or shrinking over time.

Deciding what belongs in the register and what does not

Many registers fail early because they accept everything. A risk entry is a statement about something that has not happened yet and may never happen. Once an exposure has actually hit a service, it stops being a risk and becomes an incident, a problem or an audit finding, and it should leave the register with a link to the record that now owns the work. Keeping that boundary sharp is the first operating decision. A register crowded with realised problems stops being read by the people who are supposed to make decisions from it.

The table below is a working test for each candidate entry. Agree it with the people who attend the review meeting, then apply it the same way every time someone proposes an entry.

Candidate item	Register entry?	Where it belongs instead
A vendor may stop supporting a platform component before the planned replacement date	Yes	Stays in the register with a named owner and a review date
A security patch is overdue on production servers today	No	Vulnerability tracking, with the affected configuration items linked to it
An audit found that approvals were not evidenced for a control	Only as a risk describing the exposure that remains	An audit issue, referenced from the risk, as covered in audit management
A migration task is behind plan	Only if the slip creates an exposure nobody has accepted	The project plan, with escalation when a business outcome is threatened

Teams that try to log every problem in the register often end up with two lists that disagree. Keep the register for forward-looking exposure, and let the operational records carry the things that have already happened. The operational risks article covers keeping decisions and owners visible, which matters for how the two sets of records relate.

Setting a scoring scale that assessors apply the same way

A likelihood and impact scale is only useful when two people rating the same risk reach the same answer. Many scales break because the impact levels describe a feeling rather than a consequence. “Major” means one thing to a finance lead and something else to a service desk manager. Write each level as a consequence that someone can observe, and agree which dimensions the impact is measured in before anyone scores an entry.

Use this sequence when you set up or repair a scale:

1. List the impact dimensions your organization actually cares about, such as customer harm, regulatory exposure, direct cost, delivery schedule and reputation. Keep the list short enough that assessors can hold it in mind while they score.
2. Write one sentence per level for each dimension. The top level should describe something a board would hear about, and the bottom level should describe something absorbed inside a single team without anyone outside it noticing.
3. Test the scale against three risks that have already happened. Ask two assessors to score each one independently and compare the results. Where they disagree, rewrite the sentence that caused the gap rather than adjusting the score.
4. Decide which combinations of likelihood and impact trigger escalation, and who receives the escalation. Set the trigger at a level your service owner can defend in a review, not at a figure borrowed from another organization.
5. Record who approved the scale and where it is kept, so a later reviewer can see why a rating was given.

A scale written this way also makes the disagreements visible. When two assessors split, the team learns which sentence is ambiguous, and the next calibration session becomes a short, concrete discussion rather than a debate about opinions.

Where registers drift in their second year

The first version of a register is usually careful. The problems arrive later, once the people who wrote the entries have moved on and the review has become routine. Duplicates appear after a reorganization, when two teams each log the same vendor dependency under different names. Accepted risks sit without a review date, so nobody notices when the conditions that made acceptance reasonable have changed. Mitigations are marked complete with no evidence attached. Scores set at creation are never revisited, so the register describes the situation as it was when the entry was made rather than what it is now.

What you see	Likely cause	First check
Almost every risk rated high	The scale is not calibrated, or assessors are scoring the worst case by default	Ask two assessors to score the same entry without discussion, then compare
Closed risks reappear under new names	Closure criteria are unclear, so entries are closed and then recreated	Read the closure notes on the last few closures and look for recreated titles
Mitigation finished but the rating did not move	Only the inherent rating is maintained, with no residual rating after controls	Check whether the residual rating is populated and reviewed each cycle
Accepted risks with no recent activity	Acceptance was recorded as a decision, but no review date was set	Filter accepted risks by review date and count the overdue entries

Drift is often not noticed by the person who causes it. A quarterly check of the register against these four symptoms takes less time than one escalation that arrives because nobody reviewed an entry for a year.

Signs the register is doing its job

A register is working when it changes decisions, not when it looks complete. A few observable signals separate a living register from a filing cabinet, and each one can be checked in a single review meeting without special reporting.

• At least one rating or mitigation changed in the last review cycle, with a recorded reason.
• When a risk materialised, the register entry links to the incident or problem that now owns the work, and the entry was updated within the same cycle.
• Budget or scope decisions made in the period can be traced back to a named entry, which is the practical test of risk accountability inside a working team.
• Escalated risks reached the decision owner, and the decision was written against the entry rather than made in an email thread.

When these signals are absent, the cause is usually process rather than software. Teams often add fields or dashboards when the real gap is that nobody is required to decide anything at the review.

When a register is the wrong tool

A formal register carries overhead: scoring, ownership, review cycles and evidence. For a team with a handful of exposures that already get discussed every week, a shared list reviewed in the meeting can be the more honest choice. Move to a governed register when entries need separate owners and review dates, when auditors ask for evidence of acceptance decisions, or when several teams must see the same exposure with the same rating. Teams that already run integrated risk management across several domains will often need the governed version. Teams that are only starting will often get more value from fewer, better-owned entries than from a structure built for later needs.

Questions for a register owner in the second year

Can a risk have more than one owner?

Give each risk one accountable owner who answers for the entry and its review date. Other people can be named as contributors to mitigation tasks. Two accountable owners tend to produce no owner at all, because each assumes the other is keeping the record current.

What should happen when an accepted risk actually occurs?

Reopen the entry, change its status to realised, and link it to the incident or problem record that now carries the work. Then review whether the acceptance decision was reasonable given what happened. That review is often more useful than the incident itself for improving the scale.

How do you keep ratings comparable across business units?

Calibrate them together. Run one session in which representatives score a shared set of example risks, then compare the results. Differences in rating are normal, but they should be explainable by different exposures rather than by different readings of the scale.

Should residual ratings replace inherent ratings?

Keep both. The inherent rating shows what the exposure looks like without controls, and the residual rating shows what remains. If only the residual rating is kept, nobody can tell whether a control is doing any work.

Bring a sample of your current entries so the conversation starts from real records rather than a template.