Hi everyone — hoping to tap into the collective wisdom here. I'm in the middle of a pretty intense GRC platform migration (coming from a legacy system), and our internal audit team just hit us with a major roadblock. They’re saying the change logs and audit trails generated by our ServiceNow GRC workflows aren't "detailed enough" for their compliance requirements (think SOX, ISO 27001). Specifically, they want to see not just *that* a field changed, but more context around *why* and *who* approved that specific change mid-process.
This feels like a configuration deep-dive, not just an out-of-the-box switch. In my past life dealing with database migrations (MySQL to Postgres was a fun one 😅), the audit log was everything. I'm trying to apply that mindset here.
Here’s what we’re seeing vs. what they want:
* **Current Log (from `sys_audit` table):** "Risk Assessment" record updated. Field 'Inherent Risk Rating' changed from 'Medium' to 'High'.
* **Audit Team's Expectation:** "Field 'Inherent Risk Rating' changed from 'Medium' to 'High' **based on updated impact score from control failure on 04/15, as reviewed and approved by [Manager Name] via workflow activity 'Management Review'.**"
The gap is huge! It's missing the narrative thread.
I've been poking around in the GRC plugin and the platform's audit settings. Has anyone successfully bridged this gap? My thoughts so far:
* **Workflow Context:** I'm wondering if we can leverage the `wf_activity` and `wf_context` tables to pull the active workflow step and the user in that role into the audit comment automatically. Maybe using a business rule on the relevant tables?
* **Custom Audit Fields:** Perhaps creating a custom journal field on key tables (like `sn_grc_risk_assessment`) that captures a "Change Justification" mandatory on certain state transitions, and then having that journal entry feed into or augment the standard `sys_audit` log?
* **UI Policy & Client Scripts:** To force a "Reason for Change" text box to pop up when high-impact fields are edited. But then, how do we reliably glue that comment to the specific audit entry?
A super rough sketch of a business rule idea (for discussion, not production!):
```javascript
// Business Rule: After update of 'sn_grc_risk_assessment'
// Trigger: After, Async
if (current.inherent_risk_rating.changes()) {
var context = getWorkflowContext(); // Pseudo - need real API
var approver = context.getApprover();
var activity = context.getActivityName();
// This part is tricky — how to append to the audit log itself?
// Maybe write a related 'Audit Narrative' record instead?
gs.info('Audit Narrative needed: Change approved by ' + approver + ' in workflow step ' + activity);
}
```
My big worry is creating a parallel "audit of the audit" system that becomes a maintenance nightmare. The goal is to enrich the native `sys_audit` data.
**Questions:**
1. Has anyone implemented a "reason for change" mandate that ties cleanly to the GRC audit trail?
2. Are there OOTB settings in the GRC Audit Management module we might have missed that can elevate log detail?
3. How do you handle the "story" of a change, especially when it goes through multiple review rounds? Do you log each commentary update separately?
Any war stories, configuration snippets, or "don't do what I did" lessons would be incredibly helpful. This feels like a make-or-break for our go-live.
—B
Backup first.
So they want the "why" and the "who approved it" logged right alongside the field change. That's tricky, because the default audit trail usually just tracks the data itself.
Maybe you could extend the workflow to write that context into a custom field on the record right before the update? Then the standard sys_audit entry would capture that text, too. Or does that become too brittle?
I've only used ServiceNow for basic ticketing, never GRC. Do the workflow activities not log approver details automatically?
They do log the approver, but not the justification. Your custom field idea is a common workaround.
The problem is audit log hygiene. Now you've got business logic and user input stored in a data field, which gets included in every future audit entry for that record. If someone later changes that "why" field as part of normal work, you've corrupted the original context.
It forces you to lock down the custom field with ACLs, which creates more admin overhead. The brittle part isn't the initial setup, it's the long-term data integrity.
Your CRM is lying to you.
Oh, you're nailing the core frustration. That MySQL to Postgres comparison is spot on - it's exactly that mindset shift from simple data tracking to capturing business *intent*.
Your audit team's request is 100% legitimate for SOX and ISO. I've built exactly this for a financial services client. The "approved by via workflow activity" line they want is the killer. The out-of-the-box system logs the *fact* of approval, but the *justification* lives in the workflow variables, which evaporate after runtime.
Here's the new part: you don't necessarily need a custom field on the main record. Instead, look at the `sysapproval_approver` table and its audit log. You can configure the approval workflow to *write* the user's justification comment from the approval dialog into a field on the approval record itself. That approval record is a child of your Risk Assessment. The `sys_audit` table will then show a change on that child record, capturing the "why" directly alongside the approver's name, and it's immutable history. It's a cleaner separation than a field on the parent.
The real battle scar? Getting the process owners to *consistently* use that comment field. That's a change management fight, not a technical one. You'll need to lock down the workflow so the approval task can't be completed without that comment.
Implementation is 80% process, 20% tool.
Yeah, the `sysapproval_approver` route is the right target. The trick is getting the comment field to populate automatically from the approval activity variables. If you don't, users just skip it.
I've seen teams add a simple UI policy that makes the justification field mandatory on the approval form. It's a bit forceful, but it works. The cleaner alternative is a workflow activity right before the approval that pre-populates the field with the change request summary.
Mandatory fields are the duct tape of GRC configurations. They create the illusion of compliance while users just type "approved" or "n/a" to proceed.
Even if you pre-populate the field, what's the point? You're just moving a piece of text from one system variable to another. An auditor worth their salt will ask if the justification was actually *considered* by the approver, not just if a box was filled.
This whole dance feels like we're solving the symptom, not the disease. The system should capture intent implicitly through the workflow path, not force a narrative.
cg
That's a fair critique of forcing a narrative. You're right that a mandatory field alone doesn't prove the justification was considered.
But I think you can address that by linking the justification to the workflow's decision point. If the approval activity requires a user to select "Approve with Comment" from a choice list, then the comment itself becomes part of the actionable decision. The log shows they chose the path requiring input and then provided it. It's not foolproof, but it ties intent to action better than a free-floating text box.
—daniel
Yeah, the custom field idea seems clever at first. But I'm worried about what user339 said below, about it getting changed later and corrupting the log. That feels like a big risk.
Do the workflow activities themselves leave any kind of trail you could point the auditors to, even if it's not in the main change log?
The MySQL to Postgres comparison you made is exactly why this is such a config challenge. You're moving from logging state changes to capturing process context, which is inherently more complex.
The `sys_audit` table alone can't meet that expectation. You need a composite audit trail. The most maintainable method I've implemented uses a dedicated journal table. Each key workflow activity, like the 'Management Review' approval, writes an entry linking to the record, the `sysapproval_approver` instance, and a dedicated 'justification' field. This creates a queryable, timestamped narrative without polluting the main record's fields. The audit team can then correlate the `sys_audit` entry with the journal entry for the full picture.
This approach avoids the corruption risk of a custom field on the main record and satisfies the auditor's need for a clear, non-repudiable link between the change, the approver, and the business rationale.
Trust but verify.
Yeah, that MySQL to Postgres mindset is exactly right. You're shifting from logging data mutations to capturing process narrative.
The journal table approach user786 mentioned is the solid path. It's like creating a dedicated, append-only log for workflow context. That `sys_audit` entry can show the "what," and your journal table entry, linked to the `sysapproval_approver` record, holds the "why" and "approved by." Keeps everything clean and queryable.
Infrastructure as code is the only way