I've been evaluating the ServiceNow GRC survey tool for control self-assessments (CSAs) over the last two implementation cycles, and I have to say, my initial optimism has been replaced by significant frustration. The tool is serviceable for extremely basic, one-off questionnaires, but it falls apart under any real-world, scalable data collection scenario for a mature GRC program. It feels like a feature bolted onto the platform without serious consideration for how control testing and evidence collection actually work in an enterprise.
My primary gripes are structural and data-centric:
* **The data model is rigid and non-relational.** Survey responses are stored in a `task_survey` table, but linking a response to the specific control instance, framework, and assessment cycle often requires a convoluted web of `sys_id` references. Trying to run analytics on response rates, historical trends, or control performance over time requires a maze of joins that shouldn't be necessary. You essentially have to build your own reporting layer on top of it.
* **Lack of true conditional logic.** You can do simple "show another question if answer is X," but you cannot implement complex branching required for real controls. For example, if a control has multiple parts (e.g., "Is the policy documented? Is it communicated annually?"), you cannot skip the evidence upload question for part B if part A was answered "No." This leads to noisy, incomplete data collection.
* **Evidence handling is clunky.** The attachment mechanism is the standard ServiceNow attachment widget. There's no native integration to tie an evidence file directly to a specific control attribute or answer. You get a generic comment field and an attachment list. Auditors hate this because the audit trail from control -> question -> answer -> evidence file is not clean.
* **No built-in support for automated testing.** A modern control self-assessment program needs to mix manual surveys with automated checks (e.g., "Is AWS CloudTrail enabled?"). The survey tool has zero capacity for this. You're forced to manually create a "survey" for an automated control, which is a conceptual mismatch and creates data inconsistency.
If you're determined to use it, here is a bare minimum configuration checklist you must address before going live, based on hard lessons learned:
```javascript
// Example of a scripted fix you'll likely need for reporting
// This fetches survey responses with their related control info - a query not natively efficient.
var gr = new GlideRecord('task_survey');
gr.addQuery('assessment_cycle', sysparm_cycle_id);
gr.query();
while (gr.next()) {
// You have to traverse to the control via the task/CI
var controlId = gr.task.ci_item.sys_id; // This path is illustrative, often more complex
var answer = gr.getValue('answer');
// Now join to other tables for framework, owner, etc. It's expensive.
}
```
You will spend more time building workarounds for these limitations than you will using the core tool. My blunt recommendation: if your CSAs are more than a simple annual checkbox exercise, look at a specialized survey/product built for compliance (like RSA Archer, Lockpath, or even a well-designed Qualtrics setup with a tight ServiceNow integration via REST API). Use the ServiceNow tool only if you are locked into the platform for everything and have ample development resources to extend its basic functionality.
For those who have used it, what has your experience been with the data extraction and reporting side? Have you found a sustainable way to model the response data for historical trend analysis, or did you also have to build a separate data mart?
—davidr
—davidr