Troubleshooting ServiceNow Integrated Risk Management: A Practical Guide

Troubleshooting Integrated Risk Management means tracing a symptom, such as a risk missing from a dashboard, to one of a few causes: the data, the configuration, the access rules or the integration feed. This guide takes those symptoms in turn, gives the diagnosis and fix for each, and says when to escalate to the platform team.

Faults in Integrated Risk Management rarely announce themselves, because a risk record depends on dashboards, scoring rules, assessment schedules, integrations and escalations that each belong to a different part of the platform. The sections below take the common symptoms in turn, such as risks missing from dashboards, mitigations that do not change the score, stuck assessments, failed data feeds and silent escalations, and for each give where to look, the likely cause and the fix, before covering when to escalate and how to stop the same fault returning.

Symptom: Risks not appearing in dashboards or reports

A risk has been created but does not show in dashboards or reports that should display it.

Diagnosis: Start by confirming the risk record exists in the database. Search the risk module directly (not through a dashboard). If the risk exists but the dashboard does not show it, the issue is usually filtering, permissions, or a stale cache.

Fix: Check the dashboard filter (is it filtering out this risk by status, owner, or category?). Check user permissions (does the user have read access to the risk table?). Clear the dashboard cache (hit refresh or restart the browser). If the risk is new, dashboards may update on a schedule, not in real-time.

Common cause: dashboards filtered to active risks, but the new risk has status “draft”. Update the risk status to active.

Symptom: Risk mitigations not updating the risk score

A mitigation is created and assigned, but the risk score does not change.

Diagnosis: Check if the risk score is calculated automatically or manually. If manually, someone needs to update the risk score after reviewing mitigations (the system does not do it automatically). If automatically calculated, check if the mitigation is properly linked to the risk and if the calculation rule is configured.

Fix: If manual, the risk owner needs to review the mitigation and update the residual risk score. If automatic, check the calculation rules in the Risk module configuration. Confirm mitigations are linked to the risk (not just floating independently). Run the calculation manually if an automatic process is stuck.

Common cause: mitigation created but not linked to the risk, or mitigation effectiveness is not set (the system does not know how much the mitigation reduces risk).

Symptom: Risk assessments not triggering or getting stuck

A risk assessment should run automatically (on a schedule) or be triggered by an event, but it is not running or is stuck in progress.

Diagnosis: Check the assessment schedule or trigger. Is it enabled? Has the schedule passed the trigger date? Check the workflow: is it stuck waiting for an approval or input?

Fix: If the schedule has not passed, wait or trigger it manually (IRM usually has a “run assessment” button). If the workflow is stuck, check the workflow state and see what step it is waiting on. If waiting for an approval, check who needs to approve and send a reminder. If waiting for data, check if the data is available.

Common cause: Assessment scheduled but the module is not configured to run assessments (workflows not set up or disabled).

Symptom: Data integration failures (risk data not syncing from other systems)

IRM is configured to pull risk data from another system (ServiceNow modules like ITOM, GRC submodules, or external systems), but data is not syncing.

Diagnosis: Check the integration configuration (is it enabled?). Check integration logs (most integrations log sync results). Check if the source system has data to sync.

Fix: If the integration is disabled, enable it. If there are sync errors in the logs, address the specific error (authentication failure, data format mismatch, field mapping wrong). If the integration is running but data is not syncing, check if the source system has changed (new data format, new fields, API changes).

Common cause: integration credentials expired or source system API changed.

Symptom: Risk escalations not working

A risk score is high and should trigger an escalation (notification, workflow, or escalation to leadership), but escalation does not happen.

Diagnosis: Check the escalation rules and thresholds. Is the risk score above the escalation threshold? Is the escalation rule enabled? Check notifications: is escalation supposed to send a notification, and if so, are notifications working?

Fix: If the risk score is below the threshold, escalation should not happen (this is correct). If the score is above the threshold, check that the escalation rule is enabled and correct. Check that escalation is not filtered by status or other conditions. If escalation is supposed to send a notification, check that notifications are working (send a test notification).

Common cause: escalation rule configured but disabled, or threshold set incorrectly (too high so it never triggers).

Symptom: Compliance or audit records missing

An audit or compliance report should show risk decisions, mitigations, or assessments, but records are missing.

Diagnosis: Check if the records exist (search the database directly). If records exist but are not in the report, check the report filter and date range. Check permissions (does the report requester have access to see the records?).

Fix: If records do not exist, they may have been deleted or never created. Check change logs to see if they were deleted. If records exist but the report misses them, adjust the report filter. If there is a permissions issue, check the user’s access to the risk tables.

Common cause: report date range mismatched (report shows Jan-Mar, but records are from Apr-Jun).

Symptom: Slow dashboard or report performance

IRM dashboards or reports load very slowly or time out.

Diagnosis: Check the volume of risk data (how many risks, assessments, and mitigations are in the system). Large datasets slow dashboards. Check if the dashboard is querying efficiently (some dashboards query all risks, others filter to a subset).

Fix: Optimize the dashboard query (narrow the date range, filter by status or owner, limit the number of records displayed). Archive old risk data if appropriate (depends on your audit requirements). Add indexes to the risk database tables if a large number of records. If the issue persists, escalate to your database administrator.

When to escalate

Escalate to your platform team if: troubleshooting steps do not resolve the issue, the problem appears to be a system configuration or database issue, performance problems persist after optimization attempts, or an integration is not syncing and you cannot identify the cause. Provide the platform team with: the symptom, the troubleshooting steps you tried, system logs related to the problem, and any error messages from the system.

Sorting a complaint into data, access or display first

A complaint that says an Integrated Risk Management record is wrong often falls into one of three buckets. The data may actually be wrong, the user may be unable to see what is there, or the screen may be showing something other than the record. Each bucket needs a different response, and wasted effort often comes from fixing the wrong bucket. Before anyone opens configuration, establish which bucket the problem belongs to.

Work through the questions in order. The table gives the first question to ask and what each answer should send you towards.

Recording the answers takes minutes and changes the rest of the investigation. A ticket that says the view is wrong becomes a ticket that says a draft record is missing from an active-only view, and that second ticket can be closed without touching anything. For the access side of this sorting, for the roles that tend to appear, check the security and access design page.

Changes that make an IRM fault harder to diagnose

Under pressure, administrators tend to make several changes at once. Each change hides the evidence of the one before. The table lists changes that commonly cause this, with a safer route for each.

Checking a fix from the record rather than the screen

A fix is confirmed when the underlying record behaves correctly, not when a dashboard looks different. Use this sequence before closing any IRM ticket:

• Open the record directly and confirm each field that the complaint concerned.
• Check the record’s audit history for the change you expected and for no unexpected ones.
• Confirm the report or dashboard reads the same values from a fresh session under the reporting user’s role.
• Look at a second record of the same kind, chosen at random, to be sure the fix is not a one-off.
• Write the verification into the ticket with the record identifiers and the time each check was made.

Keeping that verification trail is also what makes a later audit query answerable. The note on audit trail evidence covers how changes are explained in the record, which is the same question a verification trail answers.

Preventing the same fault from returning

Recurring IRM faults often trace back to a small number of design habits: views built on a single status value, scores that depend on manual steps nobody documented, and integrations whose owners have changed without a handover. Each habit is cheap to correct once it has been identified. Write down the recurring causes in the platform change log, and review that list in each governance cycle. A short standing check, run after each release that touches risk data, can catch a regression before the business notices it. Its testing and acceptance checklist offers a usable base for that check.

Where the faults point to a wider platform issue, such as slow queries across every risk view, the problem belongs to a broader health review and not to IRM alone. The platform health check readiness page describes OBLYTECH’s approach to that wider picture.

Common questions about IRM troubleshooting

Why does a risk look correct in one report and wrong in another?

The two reports usually filter, sort or join the records differently. Compare the filter definitions line by line before assuming the data differs. A report that counts draft records and one that ignores them will disagree even when the underlying data is perfectly consistent.

Is it safe to fix a problem directly in production?

Fix data problems through the normal governed change path, and fix view problems on a copy first. Direct edits to production records bypass the audit trail that explains the correction, so they should be a last resort and always recorded.

Who should own the triage log?

Assign it to the platform administrator who handles the risk module, with the risk function as the reviewer. A log owned by no one tends to record symptoms but not outcomes, which makes the recurring causes invisible.

How do I tell a permissions problem from a data problem quickly?

Ask a user with the same role to open the record directly. If they see the same values, the data is consistent and the issue lies in the view or the report. If they cannot see the record at all, start with access rules.