Common ServiceNow Integrated Risk Management Mistakes and How to Avoid Them

This guide sets out seven mistakes that weaken an Integrated Risk Management register, from risk scores based on intuition to controls that nobody has tested. For each mistake it gives the symptom, the root cause and a fix, and it ends with a quick assessment checklist.

Mistake 1: Risk Scores Disconnected from Reality

Teams assign risk scores (high, medium, low) based on intuition or historical precedent rather than actual likelihood and impact. A risk scored 5 years ago remains unchanged even though context has shifted.

Symptom: Risk register lists critical risks but resources go toward low-risk areas. When a “low-risk” issue materializes, teams are surprised.

Root cause: Risk scoring criteria are not defined or are inconsistently applied. Teams do not revisit scores regularly. Likelihood and impact are conflated (a high-impact but low-likelihood event gets low score).

Fix: Define scoring matrix explicitly: likelihood (rare, unlikely, possible, probable, certain) and impact (minimal, minor, major, severe, critical), then define combination rules (rare + critical = medium, probable + critical = high). Require evidence for scores: “why is this likely?” must be answered with data or expert justification. Revisit scores quarterly or after significant changes.

Mistake 2: Too Many Risks to Monitor Effectively

Risk register contains 200+ risks. No team can focus on that many. Most risks are forgotten; focus drifts to the loudest, not the most important.

Symptom: Risk reviews are quarterly check-the-box exercises. No one can name the top 10 risks. Mitigation actions are not tracked or completed.

Root cause: Every team registers every potential risk without filtering or prioritization. No governance to say “we cannot manage 200 risks; pick the top 20.”

Fix: Apply threshold: only register risks that score “high” or above based on your matrix. Keep a watch list for emerging risks that are not yet high but worth monitoring. Prioritize portfolio: top-3 strategic risks, top-5 operational risks, top-10 compliance risks. Focus leadership review on top-20; others reviewed by risk owner only.

Mistake 3: Controls Without Evidence

Risk register says “control: daily backup” but no one tests backups or verifies they are actually happening. Controls are listed but not validated. When the risk materializes, it is discovered that the control was not in place.

Symptom: Audit finds control failure on “mitigated risk.” Team says “the control should be in place” but has no evidence it is.

Root cause: Controls are designed but not audited. No one owns validation. Control effectiveness testing is ad-hoc or skipped.

Fix: For each high-priority risk, define control testing plan: what evidence will show the control is working? For daily backup: test a restore monthly, document result. For access control: audit access logs monthly, document who has access and whether it matches policy. Assign control owner (different from risk owner when possible) and require quarterly attestation: “I have verified this control is in place and working.”

Mistake 4: Risk Assessments Happen Once per Year

Risk landscape changes; threats emerge, mitigation efforts mature, business context shifts. Assessing risk once yearly means insights are stale by mid-year.

Symptom: Risk register from January is still used in October without updates. Major new risk emerges and is not captured until next annual refresh.

Root cause: Risk assessment is resource-intensive; teams assume annual is sufficient. Process is not built for continuous update.

Fix: Separate annual comprehensive assessment from continuous monitoring. Comprehensive assessment: deep dive, involve stakeholders, score all risks, update strategy. Quarterly touch-base: each risk owner reviews their risks, flags new issues, updates status. Incident happens, add risk to register and assess immediately rather than wait for next annual cycle.

Mistake 5: Risk Ownership Unclear or Misaligned

A risk is assigned to a team with no authority to mitigate (IT owns a compliance risk that requires business process change). Or risk owner changes and successor does not know they own it.

Symptom: Mitigation action overdue; when checked, risk owner says “I did not know this was my responsibility.”

Root cause: Risk owner designation is not binding; ownership is assumed not assigned. Role changes occur without updating risk register.

Fix: Explicitly assign risk to the business process owner (not IT, unless IT owns the process). For a data security risk, assign to security officer or IT security manager, not the data steward. Use RACI matrix: who is accountable (risk owner), who is responsible (mitigating the risk), who is consulted (stakeholders), who is informed (leadership). Send annual letter to all risk owners: “you are assigned to own these 3 risks; acknowledge receipt and confirm you accept responsibility.” Update risk register when roles change.

Mistake 6: Mitigation Actions Without Clear Success Criteria

Action says “implement automated controls” but does not specify by when, what the control will do, or how success is measured. Action drags on, unclear when to declare it done.

Symptom: Mitigation action has been open for a long time. Team debates whether it is half done. Progress is unclear.

Root cause: Action is vague. No target date, no definition of done, no way to measure completion.

Fix: Require each action to specify: what exactly is being implemented, by when (firm date), how it will be tested/validated, and success criteria (e.g., “nearly all of access reviews completed on time”). Break large actions into milestones (month 1: design, month 2: build, month 3: test, month 4: deploy). Track to milestone level so progress is visible and team can course-correct if slipping.

Mistake 7: No Link Between Risk and Strategy

Risk register exists separately from strategic plan. Teams do not see how addressing risk enables or prevents strategic goals. Risk becomes compliance checkbox rather than business priority.

Symptom: “Why are we investing in this risk mitigation?” Answer: “Because it is on the risk register.” No connection to business value.

Root cause: Risk and strategy are managed by different teams or forums. Annual risk assessment is not tied to strategy review.

Fix: When setting strategy, identify top risks to strategy success. Conversely, when assessing risks, score based on impact to strategy (revenue, market share, brand, compliance). Include risk discussion in strategy quarterly review. Allocate budget and people to both opportunity (pursue strategy) and risk (protect from failure). This makes risk governance feel strategic, not defensive.

Quick Risk Assessment Checklist

Mistakes that appear after go-live rather than during design

Many integrated risk programs do not fail at the design workshop. They look sound on the day the register is loaded, then drift over the following months as records multiply, owners change roles and reviewers stop opening the tasks assigned to them. The patterns below are the ones a program lead often meets once the application is carrying real decisions rather than test data. Each one is easier to catch early when you know what the warning sign looks like inside the platform, not only in a steering deck.

Each row describes a symptom whose cause sits in configuration or process rather than in anyone’s intentions. Duplicate statements often appear because business units were allowed to create library entries before anyone agreed a naming standard. A clear view of how a risk register is structured makes the duplicates easier to spot. Reviews that close unchanged often mean the review task was designed as a reminder instead of a decision point, so reviewers click through it.

A triage sequence for a register that nobody trusts

When leadership says the register is no longer believed, resist the urge to re-score everything. Re-scoring a disordered register produces a second disordered register with a newer date on it. Work through the steps below in order, because each one narrows the scope of the next.

1. Pause new risk creation for a short, announced window and export the current register with owners, scores, linked controls and last review dates.
2. Reassign records whose owners are inactive so that every open risk has a reachable person responsible for it.
3. Merge duplicate statements by keeping the earliest record as the parent and linking the retired record to it, so that the assessment history survives.
4. Sample recently closed reviews and confirm that a score or control change was recorded wherever a reviewer said one had been made.
5. Re-confirm each indicator that feeds an escalation rule, checking that it has a current value and a named source system.
6. Reopen risk creation only with a short intake rule, such as requiring a linked business process before a statement can be saved.

Signs that repair will not succeed

Some registers should be rebuilt rather than cleaned. If most statements cannot be traced to a business process or an authority source, if the scoring method changed midway and historical scores can no longer be compared, or if the people who designed the original fields have left and nobody can explain why a field exists, a clean restart with a smaller and deliberately chosen set of statements often produces a register people use. Keep the old records readable for audit, but do not let them feed the new dashboard. Owner roles for the rebuilt set should follow the role split in the RACI guidance.

Decisions to settle before a library is copied between units

A common shortcut is to copy the risk library from one business unit into another so every unit starts from the same statements. It saves time at the start and creates the duplication problem later. Before anyone copies anything, the program needs three answers in writing: who may edit a shared statement, whether a local unit may add a variant without changing the parent, and what happens to a variant when its parent is retired. Without those answers the library becomes a set of forks that cannot be reported together.

Consider a team where two units both record a supplier concentration risk. One unit scores it on revenue dependence and the other on delivery lead time. The register can hold both, but only if the relationship is recorded and the executive view groups them under one parent. If the statement is simply duplicated, leadership sees two concentration risks with different scores and cannot tell which one needs an owner to act.

Checks that show a closure was genuine

A closed risk is only useful if closure means the exposure was reduced or formally accepted. Many registers close a record as soon as the mitigating task is marked complete, even when the control that task was meant to install has never been tested. Require the closing reviewer to record which of three outcomes applies: the risk was reduced and the reduction was tested, the risk was accepted by a named approver with an expiry date, or the risk was transferred to a party whose agreement is attached to the record. A record that fits none of these outcomes should not move to closed. The question of who signs off each outcome is covered in the piece on risk management accountability.

Questions program leads raise after the first clean-up

Can duplicate statements be merged without losing assessment history?

Yes, provided the merge links the retired record to the parent instead of deleting it. Assessments, control links and review tasks should be reattached so that trend views stay continuous. Deleting the duplicate breaks the trail an examiner would follow to see how a score moved over time. The risk assessment and control testing page describes OBLYTECH’s work on this kind of linking.

Why are reminder notifications ignored when the owner is still active?

Often because every record triggers the same reminder at the same frequency, so owners learn to dismiss them. Limiting reminders to records that are overdue or whose indicator has crossed the agreed threshold keeps the signal meaningful. People tend to respond to a short list that carries a clear decision, not to a steady stream of generic prompts.

What should happen to open risks when an owner changes role?

The former owner’s manager should reassign the records as part of the role change, rather than the gap being discovered in an overdue report. Build the handover into the manager offboarding steps, and make sure the successor receives the open tasks along with the reasoning behind any accepted exceptions.

How do we tell a high score that is current from one that is stale?

Compare the score with the date of the latest evidence, not the date of the latest edit. A score backed by a recent control test or indicator reading carries more weight than one that was simply confirmed again. Where the evidence is older than the review cycle, flag the record for an evidence refresh before it goes to committee.