A common oversight in governance platforms is treating audit logging as a binary "on/off" switch without considering the performance tax. Enabling every audit trail is akin to provisioning a massively over-sized instance "just in case"—it guarantees waste and sluggishness.
From a cloud cost perspective, uncontrolled log generation has a direct analog: it consumes excessive compute cycles for processing and storage for retention, both driving up your TCO. In ServiceNow GRC, this manifests as increased transaction times, slower UI load, and general platform latency.
You need to apply a rightsizing strategy to your audit configuration. I recommend a systematic review:
* **Identify High-Volume, Low-Value Events:** Focus first on tables with the highest transaction rates. Audit trails on `task` or `sys_audit` related tables are often prime culprits. Determine if every field change truly needs to be logged for compliance, or if you can limit it to critical fields.
* **Leverage Conditional Auditing:** Instead of auditing "All" actions, use criteria. For example, only audit records when a specific field (like `state` or `risk_rating`) changes, or when the record meets a certain condition.
* **Review Audit Tables Retention Policy:** Navigate to `System Audit > Tables`. Examine the retention period for each audited table. Does a development change need 7 years of history? Adjusting retention can reduce table size and improve query performance.
* **Targeted Table Auditing:** In the GRC application, audit settings are often granular. For key processes like Policy Violations or Risk Assessments, ensure you are not auditing auxiliary or related tables that contribute little to the compliance narrative.
The goal is to shift from blanket logging to a surgical, risk-based approach. This reduces the volume of writes, shrinks your database, and improves response times. Start with the highest-transaction tables, measure the performance impact after each change, and iterate.
Optimize or die.
CloudCostHawk
Agreed on conditional auditing. The performance hit often comes from unindexed queries on audit tables.
Filtering on non-indexed fields like state can still cause full table scans. Check your audit query execution plans. You might need to add composite indexes on the fields used in your criteria.
Otherwise you're just trading writes for expensive reads.
That's a crucial and often missed point. The index overhead on the audit tables themselves can become a secondary performance issue, especially with composite indexes on frequently updated fields.
If the audit criteria use fields like 'state' or 'priority', every single transaction that modifies those fields will now trigger index maintenance on the audit table in addition to the base table write. You can end up with a scenario where the indexing cost for the audit trail rivals the cost of the original operation.
One approach is to consider indexed fields that are less volatile, like 'sys_created_by' or 'sys_updated_on', for your conditional filters. Another is to periodically rebuild indexes during maintenance windows if you must index high-churn fields, as fragmentation will compound the problem.
brianh
You're not wrong about index maintenance cost, but that's treating the symptom. The real problem is that you're indexing audit tables for query performance in the first place.
Those tables should be write-optimized firehoses. Queries against them for compliance or debugging are inherently analytical and infrequent. Dump the audit stream to a separate columnar datastore built for scans - think Snowflake, BigQuery, even a denormalized table in your data warehouse. Then you can index to your heart's content on the copy without impacting transaction performance.
Trying to make your OLTP audit table serve OLAP needs is where everyone gets burned.