ServiceNow Audit Management Governance Model

An audit management governance model sets out who decides what in an internal audit program: which audits go on the plan, how findings are classified, who owns remediation, what evidence must be kept, and who may change the plan mid-cycle.

Audit Planning and Annual Audit Calendar

Audit effectiveness requires that audits are planned based on risk, not scheduled randomly. If your audit team audits a low-risk function because a slot was available, while a high-risk function is skipped because nobody thought to schedule it, your audit program does not reduce risk effectively. Audit planning should follow a structured risk assessment: which functions or processes pose the highest audit risk? Which regulatory requirements demand the most scrutiny? Where have past findings been concentrated?

Conduct an annual audit planning session where your audit committee (mix of internal audit, management, and board representatives) reviews risk factors and develops an audit calendar for the coming audit cycle. Prioritize audits based on risk, frequency, and regulatory requirements. Schedule major audits that span multiple months to allow sufficient audit time. Include contingency slots for reactive audits that may be needed in response to incidents or emerging risks. Communicate the audit calendar to the organization so that departments know when they will be audited and can prepare evidence and documentation in advance.

Finding Classification and Root Cause Analysis

Audit findings vary in severity from minor process gaps to control failures with significant business impact. If findings are not consistently classified, it becomes difficult to prioritize remediation or track whether your audit program is improving control maturity over time. A finding categorized as “routine improvement” by one auditor might be categorized as “control deficiency” by another for the same issue.

Establish a consistent finding classification standard: routine observations (minor improvements with low risk), control deficiencies (controls are missing or not operating), and control failures (controls failed to prevent or detect a bad event). Define clear criteria for each classification. For all findings rated control deficiency or above, conduct root cause analysis: why does the control not exist or fail to operate? Is it a process problem, a lack of resources, inadequate training, or a systems limitation? Use root cause to inform remediation; if the root cause is a resource constraint, remediation may need to include a budget request.

Remediation Tracking and Accountability

Many audit programs suffer from chronic non-remediation: findings are identified, recommendations are made, but remediation is delayed or incomplete. If management does not hold people accountable for remediating findings, the audit program becomes a box-checking exercise with no real impact on control improvement.

Create a remediation workflow in ServiceNow where the audit team issues a finding with a recommended remediation, management agrees or proposes an alternative remediation, and a remediation owner is assigned with a target completion date. Track remediation progress monthly: which remediations are on track, which are delayed, and why? Hold monthly reviews with audit findings sponsors where the audit team and management discuss remediation progress. If a remediation misses its deadline, escalate to the department head to understand the obstacle and commit to a revised timeline. Link remediation progress to performance evaluations so that management is personally accountable for addressing audit findings.

Evidence Collection and Documentation

Audit findings require documentation. The auditor should be able to show exactly what they tested, what evidence they reviewed, what the control is supposed to do, and how the control was found to be deficient. If evidence is not documented or is lost after the audit, you cannot defend your findings or learn from the audits to improve in future years.

Establish an audit documentation standard that requires auditors to retain evidence of their testing for the period their regulatory requirements set. Use ServiceNow’s audit module to link findings to evidence records (testing procedures, samples, screenshots, exception reports) so that the supporting documentation is permanently associated with the finding. If a finding is disputed in the future, auditors can reference the evidence and explain their judgment. Create audit working papers in ServiceNow that show what was tested, sample size, results, and the auditor’s conclusion. These working papers should be reviewed and approved by a senior auditor before a finding is issued.

Trends and Continuous Improvement Metrics

A mature audit program is not just about identifying findings; it is about tracking whether the organization is improving control maturity over time. If you conduct the same audit year after year and find the same control deficiencies, your audit program is identifying problems but not driving improvement.

Calculate audit metrics that show trends: number of findings by classification, finding categories (access control, financial controls, data protection), and average remediation time. Track which findings are repeat findings (same issue found in consecutive years) and investigate why remediation did not stick. Calculate metrics by department or function to identify which areas have stronger control maturity. Share these metrics with leadership quarterly so they understand whether the audit program is effective at driving improvement. Set improvement targets, agreed with leadership, for repeat findings, average remediation time, and on-time remediation. These targets drive accountability.

Decide who may change the audit plan mid-cycle

An annual audit plan is approved once and then revised many times. A regulator asks for a review, a system goes live early, a business unit is restructured or a finding turns out to point at an area nobody had planned to examine. Each of those events is reasonable, and each changes what the audit function will spend its time on. The governance question is not whether the plan can change but who can change it, by how much and with what record. Without that answer, plan changes accumulate through individual requests and the final plan no longer reflects the decision the committee approved.

A workable model separates changes into a few classes. Minor reshuffles within the same risk tier can be approved by the audit lead. Moves that add or remove a whole area need the committee chair. Changes that affect the independence of an engagement, such as assigning a team to review its own function’s controls, are not a matter of convenience and should be refused or escalated to the charter owner. Writing those classes down before the first request arrives prevents the same debate from being repeated in every quarter.

Removing an area from the plan is a risk decision

Dropping an engagement feels like a scheduling matter, but it is a decision to accept the risk that the engagement would have reduced. Treat it as such. The committee should see which risk is being left unexamined, who in management owns that risk, and what the next scheduled look will be. Where the removal is caused by resource shortage rather than a judgment that the risk is low, the plan should say so openly, because the committee is then deciding how to fund the audit function rather than how to rank risks.

A procedure for handling a mid-cycle change request

1. Record the request with its trigger, the area affected and the person making it.
2. Check the request against the change classes in the charter and identify the approver.
3. Assess the effect on the rest of the plan, including staff availability and any engagement already in fieldwork.
4. Confirm that the change does not place any auditor in a position to review their own function.
5. Decide, and record the decision with its reason and the date it takes effect.
6. Tell the people whose areas are affected, and update the plan the committee sees at its next meeting.

Reporting to the committee so it can actually govern

An audit committee that receives a long report each quarter often reads the summary and approves the rest. Structure the reporting so the committee has three things to decide on each cycle: whether the plan still reflects the risk picture, whether any finding has been accepted rather than remediated, and whether the audit function has the capacity to deliver the plan. The rest can be an appendix. A short paragraph on each of those three questions is usually more useful than a dashboard with twenty indicators, because it asks the committee for a judgment rather than a reading.

Keep the minutes specific. “The committee noted the plan” is not a decision. “The committee approved the removal of the procurement engagement, accepting the risk, with the head of procurement as owner” is.

Questions people ask about audit governance decisions

Should the committee review the plan every quarter or only once a year?

Approve the annual plan once, then review it at each meeting against the risk picture. The review is short when nothing has changed and it catches the change early when something has.

Who is the charter owner?

The person or body to whom the internal audit function formally reports. Naming them in the charter matters because independence questions cannot be settled by the people whose independence is in question.

What do we do when a regulator asks for an audit the plan does not include?

Treat it as an event-driven addition and route it through the committee chair. Record it separately so the plan shows how much of the year was consumed by external requests.

Does accepting a risk need its own approval?

Yes. A decision to leave an area unexamined or a finding unremediated should carry the name of the manager who accepts the residual risk and the date the acceptance expires or is reviewed.

If the plan and the charter have drifted apart, a targeted review of the governance model is often a smaller step than rebuilding the audit program.

For who approves each step, read the roles and RACI guide alongside the KPIs and metrics guide, which covers the measures to track. The principles behind the charter itself are discussed in the note on a platform governance charter. The ServiceNow health checks and audits page describes OBLYTECH’s health check work.