Set up auditing for a table or field in ServiceNow

 

Configuring auditing for a table or field in ServiceNow

TLDR 

• Use table-level auditing for governance-critical operational records such as Incident or Security Incident tables
• Use field-level auditing selectively for custom or high-volume tables where auditing every field is unnecessary
• ServiceNow already audits many operational tables by default to support compliance, traceability, and lifecycle governance

Intro

Auditing in ServiceNow is crucial for maintaining data integrity, operational traceability, security, and compliance.

ServiceNow provides two primary auditing approaches:

• Table-level auditing
• Field-level auditing

A common misconception is that field-level auditing should always be preferred for performance reasons.

While selective field auditing can reduce storage overhead on large or low-governance tables, many critical operational tables in ServiceNow — such as Incident, Security Incident, Change Request, and Task-related records — are intentionally audited at the table level by default.

This is because these records require strong governance, lifecycle traceability, auditability, and operational accountability.

Understanding when to use table-level auditing versus field-level auditing is important when designing scalable and maintainable ServiceNow implementations.

Understanding Table-Level Auditing

Some ServiceNow tables are configured with auditing enabled by default.

Examples include:

• Incident [incident]
• Security Incident [sn_si_incident]
• Change Request [change_request]

When a table is audited at the collection level, ServiceNow tracks changes across fields automatically and stores those changes in auditing tables such as:

• sys_audit
• sys_history_line
• sys_history_set

This enables:

• operational traceability
• compliance reporting
• lifecycle visibility
• rollback investigations
• accountability tracking

For governance-heavy processes such as ITSM and Security Operations, this behavior is intentional and aligns with ITIL and security governance best practices.

Configuration

In some scenarios, auditing is already enabled at the table level by default.

You can verify this by navigating to:

• System Definition > Dictionary [sys_dictionary]
• and checking whether the table's Collection record has the Audit checkbox enabled.

If auditing is enabled at the collection level, changes to audited fields will automatically appear in the sys_audit table.

For custom implementations where auditing should be limited to specific fields only, you can configure selective field-level auditing using the audit_type=whitelist attribute.

Procedure 

1. Log in as administrator 
2. Navigate to System Definition > Dictionary [sys_dictionary] 
3. Find the record of the table whose type is 'Collection' 
4. Tick the Audit field of this record 
5. Enter 'audit_type=whitelist' in the Attributes field 
6. Save 
7. Find the record of the specific field of the table 
8. Enter 'audit=true' in the Attributes field 
9. Save 

Practical Observation

During a Security Incident Response implementation, I noticed that the Security Incident table [sn_si_incident] is audited at the table level by default.

This means that changes to operational fields such as:

• state
• impact
• ownership
• escalation data
• lifecycle information

are automatically recorded in the sys_audit table without requiring additional customization.

This highlights an important architectural principle in ServiceNow:

Operational governance and traceability are built into the platform itself.

In many cases, organizations attempt to recreate these governance capabilities manually through custom logging or duplicated tracking mechanisms, which often introduces unnecessary complexity and maintenance overhead.

For instance, with auditing of the State field on the Incident table enabled, changing the value of the State field on an Incident record might produce an audit record like the following:

Procedure:

1. Log in as administrator 
2. Navigate to Audit table [sys_audit] 
3. Find the record of the specific field of the table 
4. Analyse the audit record

In essence, choose the auditing strategy based on governance requirements, operational criticality, and scalability considerations.

Use update sets to configure auditing for a table or specific fields.

Other resources:

• Varan explains auditing in ServiceNow
• How to audit a specific field of a table
• How to use the field inclusion list with table field auditing
• Exclusion list Auditing - How to activate/deactivate auditing for a specific table or field 
• https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/administer/security/task/t_EnableAuditingForATable.html
• How to Enable Table Audits in ServiceNow: A Step-by-Step Guide
• Enable auditing on a field

That's a wrap!