ServiceNow Audit Management: Guides and Services

What Audit Management Covers

Audit Management provides a centralised platform for planning audits, tracking audit activities, collecting evidence and findings, and managing remediations. The module helps organisations coordinate internal and external audits, schedule audit activities, assign responsibilities, and maintain records for regulatory compliance. The system provides templates for audit planning and standard procedures that lead to consistent audit execution across the organisation.

Audit Management integrates with other governance modules so audits can assess the state of policies, vendor compliance, and security controls. The module provides audit evidence management so findings can be documented with supporting materials.

Core Audit Processes

Audit planning begins with assessment of what should be audited—business processes, IT systems, financial controls, compliance with policies—and how frequently each audit should be conducted. The audit lead uses templates to define the audit scope, the risks being assessed, the timeline for completion, and the resources needed.

Audit scheduling coordinates when audits will occur so resources are not over-committed. The platform shows which teams have audits scheduled, how many are in progress, and which are completed. Resource conflicts are identified early so the schedule can be adjusted to accommodate team capacity.

During audit execution, the team collects evidence such as policy documents, system configurations, access controls, and transaction records. Evidence is stored in the audit record linked to relevant findings. The auditor documents observations and determines whether each observation represents a finding or is within acceptable bounds based on defined criteria.

Finding Management and Remediation

Audit findings describe control gaps or process deviations discovered during the audit. Each finding includes severity assessment, root cause, and recommendations for remediation. Findings are assigned to business unit owners who develop remediation plans with target completion dates.

Remediation tracking shows the status of corrective actions. Target remediation dates are monitored, and overdue remediations are escalated to management. The audit module allows follow-up audits to verify that remediations have actually resolved the finding and that the same issue doesn’t recur.

Regulatory Compliance Tracking

Audit Management can track compliance obligations from regulations such as HIPAA, SOX, PCI DSS, or GDPR. The platform maps audit findings to regulatory requirements, showing which regulations a particular finding impacts. Compliance assessments aggregate findings by regulation, showing overall compliance status for each regulation the organisation operates under.

Integration With Governance and Risk Management

Audit Management integrates with the Policy and Compliance Management module so audits can assess policy compliance. Integration with Risk Management allows audits to assess the adequacy of risk controls. Integration with Vendor Risk Management allows audits to include assessment of third-party compliance with contractual requirements.

Oblytech’s Audit Management Support

We consult on audit program design, assessment of what should be audited and how frequently, alignment between audit scope and regulatory requirements, and design of the audit workflow. Implementation includes audit templates, finding classification schemes, and dashboards for audit tracking and remediation status. Managed support includes ongoing administration of the audit program and training for internal audit teams on effective audit techniques.

Audit Scheduling and Resource Planning

Audit scheduling must consider when business units can accommodate audit activities without disrupting operations. Annual audits might be scheduled to avoid peak business periods. Auditor availability and expertise must align with audit scope. The audit program tracks resource utilisation across the audit function.

Evidence Management and Retention

Audit evidence must be retained for the duration required by regulations and organizational policy. Digital evidence is preserved in the audit record. Physical evidence such as compliance documents or system logs must be stored and referenced. Evidence retention policies ensure nothing is lost or destroyed prematurely.

Follow one engagement through its life to see where the record breaks

The clearest way to understand an audit module is to follow a single engagement from the moment it is proposed to the moment its last finding is closed, and to note at each stage what the platform holds and what it leaves to other places. Many gaps in audit programs are not gaps in the software. They are moments where the engagement leaves the system, usually because an auditor takes a document offline to annotate it, or because a finding is agreed in a meeting and written up a week later. Knowing those moments in advance lets you decide which ones to close and which to accept.

The right-hand column is the list of questions to ask in any review. If an engagement can be reconstructed from the platform alone, the record is working. If it needs a folder of attachments and a memory of the meeting, the record is not.

Deciding what belongs in the platform and what stays outside

Not everything an auditor produces should live in the audit record. Draft correspondence, personal working notes and early hypotheses add noise. The discipline is to decide, for each kind of material, whether it is evidence, a decision or a working note. Evidence and decisions belong in the record. Working notes can stay outside, provided they do not contain anything that a reviewer would need to reach the same conclusion.

One check is to ask whether a second auditor could pick up the engagement the next morning and reach the same findings. If the answer depends on a conversation that only the first auditor had, the record has a gap that a note is not enough to close.

Running the first audit cycle on the platform

The first cycle is where habits form. The order below keeps the early choices visible so they can be changed before they harden.

1. Agree the list of engagements for the period and record the selection reason for each one.
2. Set up the engagement templates and the finding classes before the first fieldwork starts, so the same words mean the same things.
3. Define who may see each engagement’s workpapers, and confirm that auditors cannot review engagements in areas where they hold operational roles.
4. Run the first engagement end to end on the platform, including the evidence requests, and note every step that required leaving the system.
5. Review those exit points at the close of the engagement and decide which ones to bring in and which to formalize outside the platform.
6. Repeat the review after the second engagement, before the templates are rolled out across the rest of the plan.

What a healthy audit record shows an outsider

An engagement record is judged by an external reader, often a regulator or an external auditor who was not involved. That reader should be able to see the scope, the population tested, the sample drawn, the evidence reviewed, the findings, the management response and the verification of each closed item, all without asking anyone. Where the record cannot answer those questions, the audit function is exposed in exactly the place where its credibility is tested.

Questions people ask about the audit lifecycle

Should auditors record their interview notes in the platform?

Record the outcome of the interview as evidence, with the date, the interviewee’s role and the point it supports. Full notes can stay in a working file, but the conclusion drawn from them should be traceable from the finding.

What if a finding is agreed verbally before it is written up?

Write it up within the timeframe your audit charter sets, and record the agreement as the management response once it is confirmed. Agreements that exist only in a meeting tend to be disputed later, when the owner changes.

How do we handle an engagement that changes scope partway through?

Update the scope in the record, with the date and the reason, and note which testing has been carried out under the earlier scope. A change without a trail is one of the most frequent reasons an engagement is challenged on review.

Do we need the whole lifecycle in the platform on day one?

No. Start with the stages that carry the most risk to credibility, usually findings and their closure, and extend outward as the team gains confidence in the templates.

A lifecycle that has already been configured is worth a second look while the first engagement is still open.

The people side of the lifecycle is covered in the audit roles and RACI guide, and the questions to settle before design begins are in the requirements workshop questions. The audit trail evidence note covers what an audit trail should capture for a material change. The wider risk picture the audit feeds into is covered on the governance, risk and compliance guides.

ServiceNow audit tables and names: the platform audit log versus Audit Management

In ServiceNow, “audit” means two separate things: the platform audit log, which records field changes in the sys_audit table, and the Audit Management application, which runs engagements and findings. Decide which one your question is about first, because they hold different records and different owners.

These are common out-of-box names. Check them on your own instance and release, because labels, plugins and defaults change.

Example (hypothetical): an auditor wants to know who holds a privileged role. The auditor lists rows in sys_user_has_role for that role, notes which are inherited through a group, and then checks the change history of the group membership. The engagement itself, with the test steps and the conclusion, belongs in the Audit Management record, while the raw membership list is system evidence attached to it.

Where does ServiceNow record who changed a field?

It writes the old value, new value, user and time to sys_audit, but only for tables where auditing is enabled. A table that was never audited has no field history to find later, so confirm the setting before an auditor asks.

Are Audit Management records and sys_audit the same thing?

No. Audit Management holds the planned work, evidence and conclusions of a review. The audit log holds raw change history. A finding may cite log rows as evidence, but neither table replaces the other, and the governance, risk and compliance overview shows where each sits.

Does switching on auditing for a table have a cost?

Yes. Every change to an audited field adds rows to sys_audit, so the table grows with edit volume. Audit the tables that matter for control evidence, and plan retention, as the policy and audit evidence service and a health check both cover.