ServiceNow Audit Management: Security and Access Design

Audit Independence and Access Control

Audit Management requires strict independence: auditors must not audit areas where they have operational responsibility. An auditor who manages a team cannot audit that team’s controls. Implement access controls in ServiceNow to enforce this: auditors can view audit workpapers and findings for audits they are assigned to, but cannot view findings for audits in areas where they have other roles. This technical control prevents conflict of interest and maintains the credibility of internal audit.

Who Accesses What Throughout the Audit Lifecycle

Audit Lead: Full access to audit plan, scope, workpapers, and findings for audits they lead. Can assign audit team members, change scope, and document findings. Audit Team: Access to assigned audit workpapers and findings, limited to the specific audit they are working on. Cannot modify the audit plan or findings documented by others. Cannot access other audits. Audit Function Director: Read access to all audits, findings, and status. Can review findings for quality, track audit progress, and escalate issues. Can mandate re-testing if findings are disputed. Auditee (Function Being Audited): Read-only access to findings that directly impact their area. Can see what was tested, what was found, and management’s planned response. Should not see findings about other departments. Cannot modify findings or challenge testing procedures directly; changes go through formal dispute process. Finance/Compliance: Read access to audit summaries and significant findings. Do not need detailed workpapers unless they have a compliance reporting responsibility.

Audit Scope and Data Restrictions

Audits often examine sensitive data (financial transactions, personnel records, security configurations). Restrict what auditors can see outside the audit scope. If an audit is scoped to review payment processing controls, the auditors should not access employee records or payroll data. Use field-level security to ensure auditors can only view the specific data types relevant to their audit scope. Document scope restrictions in the audit plan so auditors understand what they can and cannot access. If scope expands during the audit (for example, a control test discovers an issue in a neighboring area), update the audit plan and adjust access, rather than granting blanket access.

Audit Finding Escalation and Dispute Management

When an auditor documents a finding (a control did not operate as intended), the auditee receives notification and can respond with facts, evidence, or disagreement. An auditee cannot change the finding directly; disputes go through a formal process: auditee documents their response, Audit Lead reviews, Audit Director adjudicates if needed. This prevents audit findings from being watered down by the function being audited. Escalate high-risk or disputed findings to the Audit Committee (board oversight) when consensus cannot be reached. Maintain a complete record of the dispute and resolution for regulatory and governance purposes.

Audit Evidence and Documentation Access

Auditors collect evidence: logs showing transactions occurred, documentation of controls, emails confirming approvals. This evidence is sensitive: it may include customer data, financial details, or personnel information. Store audit workpapers securely and restrict access to the audit team and Audit Director. When an audit is complete, archive workpapers; they may be needed years later for regulatory investigations or disputes. Retain for the period required by law, which depends on industry. Do not discard audit evidence prematurely; many compliance frameworks require long-term retention.

Follow-Up and Remediation Tracking

When findings are issued, management must provide a remediation plan: what will be fixed and by when. Audit tracks the remediation. When the remediation is complete, the auditor tests the control again to verify it is now operating effectively. This follow-up testing is critical to ensure findings result in real control improvements. Track status: open findings (not yet remediated), in-progress (remediation underway), closed (remediation completed and re-tested). Report findings and remediation status monthly to leadership so the organization understands audit impact and remediation urgency.

Offboarding and Access Removal

When an audit team member leaves, remove their access to all audit workpapers promptly. Audit evidence must not remain accessible to departed staff. Assign their open audits to another team member and ensure continuity of work. Update audit documentation to reflect the change so future auditors understand work history. For Audit Directors leaving the role, the new director should review open and recent audits to maintain continuity.

Testing the access model with people who should be refused

Many access designs are checked by asking whether the right people can see what they need. That is the easier half. The harder half is confirming that the wrong people cannot see what they should not, and that is where audit platforms often leak. A role matrix that looks correct on paper can still expose a finding through a related list, a reference field or an attachment that inherits access from its parent. The useful test is to sign in as each role and attempt the things that role must be refused, then record what happened.

The routes by which restricted audit data leaks

Access leaks rarely come through the front door. They come through the records that sit around the main one. The table below lists the paths that most often expose data outside the intended scope, and the check that should be run for each.

A negative test routine for each role

Run the same routine for every role in the model, and keep the results with the access design as evidence that the design was tested.

1. Create one test account for each role, with the same department and location as a real holder of that role, so that scoping rules are exercised rather than bypassed.
2. Prepare a short list of refusals for each role. Each item should name a record, a field, an attachment or a report that the role must not reach.
3. Sign in as the test account and attempt each refusal through every route in the table above, not only through the main list view.
4. Record the outcome of each attempt with a screenshot and the time, and mark any route that succeeded as a defect.
5. Repeat the routine after any change to roles, ACLs, reports or notification rules, because a change that fixes one route often opens another.

What a working design looks like from the auditor’s side

A working design is quiet. An auditor on one engagement can open the audit, see its findings and attachments, and see nothing about a neighboring engagement, even where the two share a process owner. Related counts should reflect only what the auditor is permitted to see, so a count that differs from the platform’s own record is a signal to investigate. The design also leaves a trail: when access to a restricted record is granted for a specific piece of work, the grant is recorded, time-limited where the platform allows it, and removed when the work ends.

When access rules alone are not enough

Some audit data is sensitive enough that row-level rules are not a sufficient control. Personnel investigations, legal holds and certain financial records may need a separate table with its own administration, or in exceptional cases a separate instance. Make that decision during design, because moving restricted data later is more expensive than separating it at the start. Consider also whether a field that exists only to support one audit should be created at all, since the field itself becomes a place where information can leak.

Harder questions about audit platform access

Should auditors have read access to the whole audit table?

Not by default. Read access to the table lets an auditor see every engagement’s records through any route that reads the table. Grant access by engagement or by team, and check that the route used by reports and lists applies the same restriction as the main form.

How do we confirm that a removed user has lost access everywhere?

Run the negative routine on the removed account, not just check that the role is gone. Look at direct links to records, saved reports shared with the person’s former group, and any delegated approvals. A removed role that still receives notifications is a leak even when the screens are closed.

Does a restricted audit need its own instance?

Only when the data is restricted by law or by a requirement that row-level control cannot meet. Many restricted audits are adequately handled by a separate table and tight rules. A separate instance adds administration, upgrade and cost, so it should be chosen on evidence of need, not on a general sense of caution.

What do we do when a legitimate scope change needs wider access?

Update the audit plan first, record the change and its reason, and then grant the narrowest access that covers the new scope for the shortest period needed. Do not widen a standing role for a single task. A dated, specific grant can be reviewed and withdrawn, while a widened role is often never narrowed again.

Next step

The role model that the access rules rest on is covered in the RACI guide, and the routine for reviewing standing access is described in the post on access recertification.