Disclaimer – This article is part of a series exploring the new features and capabilities introduced in the Zurich release. Since we’re still in the Early Availability (EA) phase, things may change before General Availability (GA). After GA, these articles will be reviewed and updated as needed. Also, this message will be removed.
Let’s talk about auditing in ServiceNow, one of those features everyone ignores until something’s on fire. The conversation usually starts at one of two extremes: either you’ve turned on auditing everywhere and your audit tables use most of your disk space, or you’ve barely audited anything, and an auditor asks for the change history of a column that surprisingly isn’t tracked. Neither is fun.
The solution is simple: define your audit strategy at the start of your implementation, then enforce it with proper governance so new tables and columns don’t slip in without a decision.
Configuring audit isn’t a complex task but going through all the dictionary records and audit attributes can be a time-consuming task without good user experience.
If that’s why you’ve postponed it, you’re out of excuses. With the Zurich release you can now use the Audit Management Console.
The Audit Management Console
Type Audit Management Console in the All menu and you’re there. You’ll also find a link from the Data Management Console. On the Overview tab, click Manage audit config to jump straight into the Audit Management Console.
The layout is simple. The Home tab shows three lists: tables with audit enabled, tables with audit disabled, and all tables.
Click a table and its configuration opens in a new tab. Use the Audit toggle to enable or disable auditing for that table. If auditing is on, click Edit Audit Status to manage fields. Uncheck a column, or remove it from the Selected columns list, then save. No new audit records will be created for that field. You can also hit “Clear All” and then pick only the fields you actually want to audit. Sometimes this is the faster way.
It looks like the Audit Management Console brings also new functionality and not just a fresh UI. You can activate an Audit Retention Job for a table on the Retention tab. When you enable Automatically Purge Audit Record, you can choose a retention period between 1 Month and 7 Years.
Audit retention jobs can only be created by security admins. So don’t forget to elevate your role otherwise you see the error message.
When successfully saved, this will create a record in a new table sys_audit_retention and a business rule will create or update a corresponding record in the new table sys_audit_cleaner_job_progress. Even though these records are created on my early availability instance I was not yet able to locate anything that uses these records to really do the remediation. No scheduled job or anything else I can think of how this feature could be implemented. So, I hope I overlooked something, or it is just an EA thing, and we will get a scheduled job in the GA release.
Audit Types
ServiceNow supports two approaches to configure audit. If you enable audit at the table level and do nothing else, you’re using a blacklist approach: every column is audited unless its dictionary record includes the no_audit attribute. If you add audit_type=whitelist to the attributes of the collection record for that table, you turn it around and only columns with audit=true are tracked.
If you enable audit for a table from the Audit Management Console, it will use the blacklist approach. If you already use the whitelist approach for some tables, the Audit Management Console can handle these as well. The catch is the console will not tell you which approach is used for a table and therefore gives you no opportunity to change it.
Do you need to know or change the audit type? If you only care which fields are currently audited, probably not. But if you take it more strategically, you absolutely do.
Every time you add a column to an existing table you need to decide whether this column should be audited. Based on your decision and the audit type of the table you may need to configure it differently; therefore, it is important to know which type is used.
If you forget to think about it, outcomes vary by audit type. With a blacklist you may end up with too many audit records, potentially including sensitive data like PII without realizing it. With whitelisting, you might miss changes you later need to retrace what happened. You need to make the decision about what’s best for your situation. Either way it would be helpful if the Audit Management Console would display and allows you to change the audit type.
This could be a good addition for the next release. But by all means the Audit Management Console is a big step in the right direction.
