ServiceNow Instance Scan Explained

Definition and Purpose

An Instance Scan is a ServiceNow-provided diagnostic tool that analyzes your instance for configuration issues, security vulnerabilities, performance bottlenecks, and deviation from best practices. It runs automated checks against tables, fields, business rules, workflows, and customizations, comparing them to ServiceNow’s recommended patterns and security policies.

ServiceNow releases updated scans with each platform version. Running a scan before upgrading reveals potential compatibility issues or deprecated features you are using. Running scans regularly (quarterly or annually) identifies technical debt and guides modernization efforts.

Accessing and Running Instance Scans

Access Instance Scan from the instance administration interface: search for “Instance Scan” and select “Run Scan.” The system evaluates your instance against a predefined checklist and generates a report within hours (large instances may take longer). The report categorizes findings by severity: Critical, High, Medium, Low. Reports are stored and can be compared across time to track improvement.

Results appear in the ServiceNow Instance Scan dashboard, organized by check category: Security, Performance, Customization Health, Upgrade Readiness, etc. Each finding links to documentation explaining why it matters and how to remediate it.

Common Findings and Remediation

High-risk security findings include: unused or overly-permissive roles, missing encryption on sensitive tables, outdated SSL certificates, default passwords still active, and unnecessary integrations. Performance findings include: inefficient business rules, large unindexed queries, too many observers or listeners on hot tables, and excessive workflow activity. Customization findings include: deprecated script methods, scripts that override core platform tables, update sets with pending status that were never deployed.

Not every finding requires immediate action. A low-priority finding on an unused module might not affect your operations. A high-priority security finding should be addressed before the next upgrade or before adding new users to the system.

Interpreting Results and Planning Remediation

Scan results should be reviewed by technical leadership and categorised by business impact: which findings affect security, which affect performance, which are cosmetic or low-risk. Create a remediation backlog and tackle findings incrementally over several releases rather than attempting a massive cleanup in one cycle.

Some findings conflict (performance recommends adding more indexes, but security recommends minimising table sprawl). In these cases, use business context to decide priority: if performance is causing outages, add indexes; if security is at immediate risk, remediate first.

Instance Scan vs Upgrade Readiness and Configuration Analysis

Instance Scan is one part of upgrade preparation. Upgrade Readiness checks whether your current configuration is compatible with the target version. Configuration Analysis (available for certain modules) provides deeper insights into alignment with industry best practices. Use all three tools together to plan comprehensive modernization.

A passed Instance Scan does not guarantee a smooth upgrade. You must also review release notes for breaking changes, test customizations in a clone of your instance, and plan a staged rollout.

Continuous Improvement Using Scan Data

Use scan results as a baseline and re-run periodically (annually or after major releases) to track improvement. If a finding persists across multiple scans, escalate and prioritize its remediation. If new findings appear in each scan, investigate whether your development practices are slipping (developers not following standards) and reinforce governance.

Share scan results with your team to educate them on best practices and why certain findings matter. Use findings as teaching moments rather than purely as a compliance checklist.

Some teams create a custom dashboard that displays Instance Scan findings over time as a trend chart. This visualisation makes it clear whether your instance is improving or accumulating debt. Use scan data as input to your quarterly roadmap planning: include remediation tasks alongside feature work, prioritising findings that affect security or performance.

Deciding what a scan result is allowed to change

An instance scan produces a long list of findings, and the list tempts teams to start fixing from the top. A more useful first decision is what the team is permitted to change without a wider review. Changing a role assignment, tightening an access control or altering a system property can all break a business process that nobody on the scan review thought about. Set a boundary before the review starts: which findings can be fixed by the platform team directly, which need a change record, and which need the application owner to agree first. Without that boundary, the review becomes a debate about every line.

Finding type	Usual first step	Who should approve
Unused or over-broad role assignment	Confirm the holders and the business reason	Application owner, then security
Weak or missing access control on a table	Test with a non-privileged account before changing it	Security with the application owner
Deprecated plugin or unused module	Check dependencies and scheduled jobs that use it	Platform owner
Performance advice on a large table	Measure the slow path in a non-production copy	Platform owner with the service owner

A sequence for working through the findings

A scan review is most productive when it follows a fixed order, because the same finding can be a symptom of a larger issue further down the list. Work the list in the sequence below, and record the decision for each finding in a single register rather than in chat.

1. Group the findings by the table, plugin or role they concern, so that one underlying cause is handled once.
2. Remove the findings that match a documented exception, and record the exception owner and the reason it is acceptable.
3. Check the access-related findings first, since their fixes are often the most urgent and can be made with little disruption when done carefully.
4. Pair each performance finding with a measured problem, such as a slow form or a long-running job. A finding without a symptom can wait.
5. Assign each remaining item an owner, a decision and a date for the next scan, so that the register shows progress rather than a static snapshot.

When two findings pull in opposite directions

Some recommendations conflict. A performance suggestion to add an index can increase the surface an administrator has to protect, and a security suggestion to restrict a table can slow a report that everyone uses. The resolution is rarely to pick the louder recommendation. Write down the business impact of each side and test both in a copy before deciding. The decision belongs to the owner of the service that would be affected, with the security and performance findings presented side by side.

Using scan results without confusing them with upgrade readiness

An instance scan is a configuration and hygiene check. It does not tell you whether a planned upgrade will behave, and a clean scan does not replace reviewing the impact of each change in the release. Teams sometimes read a passing scan as a green light, then discover breaking changes in customized code. Keep the scan review and the upgrade impact review as separate outputs, and make the upgrade decision depend on both. The scan shows what is fragile in your instance now, while the impact review shows what the next release will change.

Signs the scan is being ignored

A scan program is slipping when the same high-risk findings appear in review after review with no owner, or when findings are closed by marking them as accepted without a recorded reason. Another warning sign is a backlog that grows every quarter with nobody reviewing it. Count how many findings were closed, how many were accepted with a reason, and how many are still open after two review cycles. A rising open count with a falling closed count is a signal to reduce scope and fix the highest-risk groups first.

Checklist before the next scan review

• A written boundary for which changes the platform team can make directly.
• A register that records each finding’s owner, decision, reason and review date.
• A list of documented exceptions, with the owner who accepted each one.
• A test copy or sandbox where any proposed fix is tried before it reaches production.
• A short summary for leadership that separates security exposure from hygiene items.

When a scan is not the right tool

A scan checks known configuration patterns. It will not find a logic error in a custom script, a business rule that quietly overrides a field, or an integration that stores credentials in an unexpected place. Those need code review, targeted testing and a look at the integration design. Treat the scan as a starting point for those reviews, not as an assurance that they are unnecessary.

Frequently asked questions about instance scan reviews

Who should attend the review meeting?

The platform owner, a security representative and one application owner whose area is affected. Without the application owner, the review tends to close findings that look harmless to the platform team but matter to a business process.

Can a finding be closed without fixing it?

Yes, when the risk is accepted with a documented reason and a review date. Closing a finding with no reason is not acceptance, it is just deferral, and it hides the item from the next review.

Should we run the scan after every change?

Running it after significant changes such as a new plugin, a security configuration change or a planned upgrade gives the most useful comparison. Running it constantly produces noise that nobody has time to review.

How do we show progress to people outside the platform team?

Track the count of high-risk items, the age of open items and the number of accepted exceptions. Those three measures tell a non-technical sponsor whether the position is improving without requiring them to read individual findings.