A ServiceNow instance can look clean while still exposing data through old roles, loose ACLs, or forgotten integrations. That’s why a ServiceNow security audit can’t stop at login settings.
For enterprise admin teams, risk sits in the details. One overbroad group, one shared API account, or one rushed update set can weaken the whole platform. Start with access, follow the data, then verify the evidence.
Start with identity and admin reach
Review roles, groups, and stale access
Export users, groups, and effective roles from every production and non-production instance. Then compare them with HR status, team ownership, and actual job need. Look for inactive users, local accounts that bypass SSO, orphaned groups, and roles that piled up after project work ended.
Don’t stop at direct role grants. Inherited roles and nested group logic often hide the real problem. A user may appear low risk until one group adds reporting rights, API access, and CMDB visibility in one step.
Privileged access needs its own review. Check who can activate security_admin, change ACLs, edit system properties, install plugins, or move app changes into production. Those users can change the rules of the platform, not only the records inside it.
Use a short evidence list for this pass:
- Separate daily admin accounts from elevated accounts.
- Require MFA for admins and review any SSO bypass or break-glass users.
- Keep service accounts non-interactive, named, and tied to an owner.
- Log every admin role grant, revoke, and elevation event.
Run ServiceNow SecureCheck and compare the findings with a current ServiceNow hardening guide. That gives you a fast baseline before you move into record-level access.
Test how data moves, not only who logs in
Audit ACLs, reports, and CMDB exposure
ACL review should cover tables, fields, related lists, reports, exports, and APIs. A form may look locked down while a list view, report, or scripted query still exposes the same data. Test read, write, create, and delete behavior from the perspective of real roles, not only admins.
CMDB deserves extra scrutiny. It often holds hostnames, IP data, business service maps, support groups, vendor links, and outage relationships. Broad read access lets an attacker map your estate before they ever touch a server.
Where your release supports stronger high-security settings, use them. Default-deny behavior, tighter property control, and better protection for logs reduce the chance of quiet drift over time.
If CMDB read access is open to “everyone who might need it,” you’ve likely granted too much.
Review integrations, APIs, and app changes
Machine access often grows faster than human access. Inventory every inbound and outbound integration, including REST, SOAP, scripted APIs, MID Server traffic, IntegrationHub spokes, and third-party store apps. For each one, record the auth method, owner, target system, data touched, and last use date.
Focus on weak patterns. Shared integration users, long-lived tokens, hard-coded secrets, wide IP access, and unused endpoints all widen the attack surface. Also review Connection and Credential records, certificate rotation, OAuth scopes, and whether the API account can read more tables than the integration needs.
A ServiceNow security audit should also inspect the change path. Review update sets, emergency fixes, plugin activations, and app installs that touched ACLs, business rules, flows, scripted REST APIs, or system properties. One rushed change can reopen a door you closed last quarter. Peer review and clear approval trails matter here, especially for security-sensitive changes.
The ServiceNow security assessment checklist is a useful outside reference for exposed objects, external access paths, and SaaS control gaps.
Prove protection and keep it current
Classify data, encrypt it, and keep evidence
You can’t protect what you haven’t labeled. Map which tables and fields hold HR, legal, finance, customer, or regulated data. Then verify that classification drives ACLs, masking, retention, and export controls. Attachments often get less attention than fields, yet they can hold the most sensitive content.
Check encryption at rest, TLS for data in transit, and field-level protection where needed. If teams rely on cloned non-production instances, confirm that sensitive data is masked or excluded before refreshes. That control matters because test environments often have weaker monitoring and broader access.
Logging should answer four questions fast: who changed access, who viewed sensitive data, who exported records, and what changed in the platform. Review login events, admin elevations, role changes, ACL edits, property changes, API activity, and mass exports. Then send the right signals to your SIEM so your audit trail survives outside the instance.
Patch known issues and watch drift every week
As of April 2026, one check can’t wait. If you use Now Assist AI Agents or Virtual Agent API, verify you’re on fixed versions for the public CVE-2025-12420 issue. That means Now Assist AI Agents 5.1.18 or 5.2.19 and newer, and Virtual Agent API 3.15.2 or 4.0.4 and newer, based on your branch. Also confirm your release family, such as Australia or Xanadu, is on current security hotfixes.
Patch status is only half the job. Vulnerability response should tie each platform finding to an owner, due date, and change record. The same goes for risky plugins, unused apps, and stale integrations that fail your review.
Finally, watch for drift. Schedule reports that flag new admin-like role grants, disabled MFA paths, new integrations, unusual CMDB exports, plugin enablement, and changes to sensitive system properties. For a broader cadence model, this guide to instance audit best practices is a helpful reference.
A strong audit isn’t flashy. It proves who has access, why they have it, what data they can reach, and which changes left evidence.
Run this checklist against production first, then mirror it in non-production. If any control still depends on memory, a spreadsheet, or “the one admin who knows,” treat that gap as a finding.
