ServiceNow Audit Management for Financial Services

Audit Management is the ServiceNow application that holds audit plans, test results, evidence and findings in one set of records. This page helps a financial services firm decide how to scope audits, rate results and close findings that hold up under regulatory review.

How Financial Services Organizations Use Audit Management

Audit Management in a bank or insurer has to serve internal audit, external auditors and regulators from the same records, and its value shows in whether findings turn into control improvements rather than filed reports. The sections below cover the regulatory requirements and standards that shape audit scope, planning and evidence collection, then follow the path from risk assessment to a finding that gets fixed, how test results and issue ratings are designed, and when continuous monitoring should replace a periodic test.

Regulatory Requirements and Standards

Financial Services organizations must comply with audit requirements from multiple regulators depending on their type and jurisdiction. Banking regulators require audit programs. Securities regulators require external audits. Other regulations like Sarbanes-Oxley require specific audit procedures over financial reporting controls. Each audit type has specific documentation requirements and timelines. Understanding these requirements is essential for compliance.

Audit standards define expectations for audit scope, objectivity, and documentation. Your Audit Management process should ensure that audits are conducted to these standards. External auditors expect to find evidence that internal controls are working and that findings from previous audits have been addressed. ServiceNow can hold the records that show this, provided plans, tests, issues and evidence are linked.

Audit Scope and Planning

Planning audits requires identifying what should be audited and in what priority order. An audit plan typically covers all significant business processes and systems within a multi-year cycle. For example, you might plan to audit Incident Management one year, Change Enablement the next, and Request Fulfillment the third year. High-risk areas are audited more frequently than lower-risk areas to match risk profile.

The audit plan should be reviewed by management and approved formally. It should be communicated to the organization so people know an audit is coming and can prepare. Some audits are routine and happen on a predictable schedule. Others are triggered by specific events: a significant incident, a new regulation, or a risk assessment finding. The audit plan can be updated to accommodate triggered audits.

Evidence Collection and Documentation

Audits require evidence: documentation that controls are working, records of transactions reviewed, reports on compliance with policy. Audit Management in ServiceNow helps collect and organize this evidence systematically. The audit coordinator requests evidence from process owners and documents what was received. The auditor reviews evidence and documents findings. This creates a complete audit trail that is valuable for regulatory purposes.

Evidence should be specific and verifiable. A claim that “we follow change management process” must be backed by evidence: a sample of changes with approvals, evidence that changes were tested, verification that the change was deployed as approved. Vague evidence does not satisfy auditors or regulators. Establish evidence standards and stick to them.

Audit Findings and Remediation Tracking

When an audit identifies a problem—a control is not working, a policy is not being followed—a finding is documented. Findings should describe the issue clearly, why it matters, and what should be done to fix it. The process owner responsible for the area being audited should review the finding and either agree to remediate or provide evidence that the issue does not exist.

Each finding is assigned a remediation target date and a responsible owner. The owner provides status updates on remediation progress regularly. When remediation is complete, the owner provides evidence that the issue has been fixed. The audit function verifies the evidence and closes the finding. Tracking remediation ensures that audit findings do not disappear without actually being addressed and prevents the same findings from recurring in future audits.

Audit Report and Communication

After the audit is complete, a formal report is issued. The report documents the scope of the audit, the evidence reviewed, the findings identified, and conclusions about the effectiveness of controls. The report is shared with management and with the board if required. External auditors review internal audit reports as part of their own assessment and planning. Clear reporting helps stakeholders understand the current state of control effectiveness.

From Risk Assessment to a Finding That Gets Fixed

Audit management is often described as a way to record findings, but the useful test is whether a finding leads to a control that works afterwards. A workable chain runs from the risk assessment to the control, from the control to the test, from the test to the evidence, and from the evidence to an issue with an owner and a verified closure. A break anywhere in that chain produces a finding that looks closed in the platform and remains open in practice.

Much of the effort belongs in the links, not the nodes. Decide how a test result is judged, who may overturn a result, and what happens when evidence is partial. These decisions are less visible than the engagement plan, but they determine whether two auditors reviewing the same workpaper reach the same conclusion.

Designing Test Results and Issue Ratings

Test outcome	What it means	Required record	Who may change it
Effective	Control operated as designed across the sample	Sample list, test steps, reviewer sign-off	Audit lead only, with a written reason
Effective with observation	Control operated but a weakness is worth recording	Observation text and an improvement suggestion	Engagement lead
Exception noted	One or more samples failed the control	Failed sample references and root-cause notes	Engagement lead, with the control owner consulted
Not testable	Evidence was not provided or the control does not yet exist	Request history and the date of the last follow-up	Audit lead, with a reason and a retest date

The “not testable” row is the one that often hides risk. A control whose evidence never arrives is not effective by default. Treat repeated not-testable results as their own issue, owned by the control owner, rather than letting them roll quietly into the next cycle.

Sequence for Turning an Exception Into a Closed Issue

1. Write the exception in terms of the control and the sample, not the person, so the statement survives staff changes.
2. Assess its rating using the institution’s agreed criteria, and record which criterion drove the rating.
3. Assign a remediation owner who controls the process, not the reviewer who found the gap.
4. Agree a remediation plan with a date and a defined evidence requirement, written before the owner starts work.
5. Require the owner to attach the evidence to the issue record rather than sending it by email.
6. Have the auditor retest the control, and close the issue only on a passing retest or on a formally accepted risk.
7. Record any risk acceptance with the approver’s name, the expiry date, and the review trigger.

Accepting risk is a legitimate outcome, but it is a decision with a time limit. An acceptance without an expiry can become a standing exception.

Where Audit Records Lose Their Value

Evidence held outside the platform is the first problem. A screenshot pasted into a chat or a file stored on a personal drive cannot be shown to a regulator with its context intact. Require evidence to be attached to the test or issue record, with the date and the source system recorded.

Findings written as observations about people rather than controls are the second. “The team did not follow the procedure” tells a reader nothing about where the control failed. Rewrite such findings against the control, the failed step, and the consequence.

Plans that run on calendar dates without owner acknowledgement are the third. A remediation date agreed in a meeting and never confirmed by the owner will slip silently. Ask for written acknowledgement from each remediation owner when the plan is agreed.

Signals That the Audit Process Is Producing Control Improvement

Look at how many issues reach verified closure rather than administrative closure, how many not-testable results are repeated across cycles, and how often a retest finds that a remediated control has drifted. A falling count of repeat findings matters more than a high count of closed issues. Track the time between identifying an issue and the first evidence being attached, since a long gap can signal an owner who does not yet accept the finding.

When Continuous Monitoring Should Replace a Periodic Test

Some controls, such as access reviews for privileged accounts, are better served by continuous monitoring than by a sample taken once a year. Where a control produces a complete log of its own operation, a monitoring rule may give stronger assurance than a sampled test. Periodic testing still has a role for judgment-based controls, where no log can show whether a decision was sound.

Questions Internal Audit Teams Ask About Platform Records

Who should be allowed to downgrade an audit rating?

The engagement lead, with a written reason and the reviewer informed. Rating changes after review should be visible in the record history, not made silently.

How should we store evidence that cannot be attached as a file?

Record a precise description of the evidence, its location in the source system, and the date it was viewed. Where the source can be exported, export it to the attachment at the time of testing.

Can the business run its own control self-assessments in the same tool?

Yes, but keep self-assessment records separate from independent test results. Mixing them makes it impossible to tell whether a control was verified by someone outside its operation.

What is the right point to involve the regulator’s requirements?

Map each control to the requirement it supports when the control is designed, not when the examiner asks. The mapping is cheaper to build early and more defensible when it is already in place.

OBLYTECH’s page on GRC, policy and audit evidence covers the design side, and the evidence practice is discussed in this guidance on audit trail evidence. Module detail for the sector is in governance, risk and compliance for financial services.

Audit Management Records, Tables and Names for Financial Services

Audit Management in ServiceNow is the part of the GRC suite that runs an audit engagement from scope to report. Its deciding feature for a bank or insurer is that engagements, controls, issues and evidence are linked records, so one finding can be traced to the control it tested.

These are common out-of-box names, so check them on your own instance and release, because labels and defaults change between releases.

Name	What it holds
sn_audit_engagement	The audit engagement: scope, team, timing and phase
sn_compliance_control	The control that an engagement tests
sn_compliance_policy	The policy a control supports
sn_risk_risk	The risk that a control is meant to reduce

Because these are ordinary tables on the same instance, standard list views, reports and access controls apply to them as they do to any other table, and evidence files are normally kept as attachments on the record they support. Issues raised from failed tests are tracked as their own records with an owner and a plan.

Example (hypothetical): an internal auditor opens an engagement for a lending process and selects the controls in scope. A test shows that approvals were skipped in a sample. The auditor raises an issue against the control and assigns a business owner, and the engagement report can refer to that issue instead of repeating its text. After the owner closes it, the aim is for the earlier failed test to stay visible beside the retest, which is the history a regulator usually asks to see. Check how your own instance retains test history before relying on it.

What is the difference between an issue and a finding?

Many firms use the two words interchangeably. A trackable issue needs an owner and a due date, while a finding is often the wording used in the report. Decide which term your team uses and keep it the same in reports and on record labels.

Can second-line risk and internal audit share the same control records?

Often, and they usually should. Sharing the control record means a test result from one team is visible to the other, but access rules need care so audit independence is not weakened by edit rights.

Where do the policy and risk records fit into an audit?

They give the engagement its reason to exist. Start from the audit management guide, then see how policy and audit evidence ownership works, and the financial services overview for sector context.

Whether ServiceNow Audit Management Fits an Internal Audit Team and When It Does Not

ServiceNow Audit Management fits a financial services audit team when its audit records depend on controls, risks and policies that already sit on the same platform. If an engagement, the controls it tests and the issues it raises need to trace to each other, the application does that job well. If the team keeps workpapers in separate tools and only needs a final report, the platform adds administration without much assurance.

Start the decision with the records you already hold. Check whether control inventories, risk registers and policy records are maintained in one place. When they are split across spreadsheets, a platform rollout tends to move the problem rather than fix it, because an audit issue cannot point at a control that does not exist as a record. Teams with a clean control inventory usually set up engagements quickly. Teams without one should fix the inventory first and treat the audit tool as the last step.

Next, settle how independence will work. Internal audit usually needs to read control records without being able to change how those controls operate, while the business needs edit rights for its own remediation work. Decide who owns each record type before anyone is given access, and plan the instance security and access control model early, because it is far harder to unwind once engagements and issues already carry history.

The table below sets out the signals that usually point each way. These are common implementation patterns, not measured results, and your audit volume may weigh them differently.

Fits well when	Think twice when
Controls, risks and policies already exist as linked records	The control inventory lives in spreadsheets with no named owner
Engagements, tests and issues must trace to one another	Workpapers are kept mainly in separate audit software
Regulators expect a repeatable history of test results	Audit work is occasional and small in scope

A simple test settles most arguments. Pick one closed issue from the last audit and trace it through its test and evidence to the retest. If the platform can show that chain without someone rebuilding it by hand, the fit is good. If the chain only exists in a covering email, the process is the problem, and the platform will not fix it alone. Teams that want help mapping this against their own instance can look at ServiceNow GRC and IRM consulting.