ServiceNow IT Audit Software Consulting

IT auditors testing ITGCs for a SOX programme need two things from ServiceNow, and they are frequently conflated: source evidence and testing workflow. Source evidence is the change request, incident, and access-request records ServiceNow generates as the ITSM platform governing a financial ERP's infrastructure — who requested a change, who approved it, what testing preceded deployment, who has access to what. Testing workflow is a separate question of where the IT auditor plans, executes, and documents the ITGC testing itself, which can live in Audit Management or IRM regardless of which ITSM platform the underlying tickets come from.

Many organizations only need the first: ServiceNow as ITSM generating the change and access records IT audit samples, while the IT audit team plans and documents its testing in a different GRC tool entirely. Others consolidate both inside ServiceNow, using Audit Management to structure the ITGC testing engagements against evidence pulled from the same platform's own ticket history. Scoping an IT audit engagement correctly means being explicit about which of these two roles — or both — is actually in play before designing test procedures.

Change management is the ITGC most commonly tested against ServiceNow records, because ServiceNow's Change Management module is the dominant enterprise ITSM change-control system independent of which financial ERP a company runs. A properly configured change request record captures requester, an independent approver (typically via a Change Advisory Board or delegated approval matrix), a documented risk assessment, a scheduled implementation window, a backout plan, and a post-implementation review — each of which maps to a specific element of what PCAOB AS 2201 testing expects for change-management design and operating effectiveness.

The IT audit test procedure typically samples a population of change tickets tied to the in-scope financial system for a testing period, verifies that the approver is independent of the requester on each, confirms emergency changes went through the required retrospective review rather than bypassing approval entirely, and cross-references the ticket to the actual deployment artifact in the target ERP — a transport number in SAP, a release ID in Oracle — to confirm the documented change and the implemented change are the same thing. A ticket showing approval with no link to a verifiable deployment artifact is a common finding, because it proves authorization but not correct implementation.

Access provisioning as an ITGC is tested through ServiceNow's access-request and approval workflow when it governs who receives credentials to the financial ERP — a request record showing business justification, manager approval, and (for elevated access) a segregation-of-duties check before provisioning. Periodic access recertification, whether run natively in IRM or through a connected identity-governance tool, produces the review-and-disposition evidence (retained, revoked, exception) that supports both the provisioning control and the broader SoD control set an IT auditor tests separately.

The limit that has to be explicit in test design: a ServiceNow ticket proves a request was made and approved, not that the access granted matches what was requested, or that a revoked user's access was actually removed at the ERP or database layer. IT audit test procedures that stop at 'the ticket shows approval' without a secondary check against the actual entitlement in the target system are testing paperwork, not control effectiveness, and this gap is one of the more common findings in IT audit walkthroughs of ServiceNow-governed access processes.