Hot take: GRC's risk scoring is too black-box for actual audit trails.

Let's cut through the marketing. I've just finished my third large-scale ServiceNow GRC implementation for a financial services client, and the same critical flaw keeps surfacing: the risk-scoring engine is an opaque calculation that falls apart under real auditor scrutiny. You can't defend what you can't explain, and GRC's "out-of-the-box" scoring logic is a black box that creates more compliance risk than it mitigates.

The core issue is that the platform encourages you to use its proprietary scoring algorithms—the inherent risk and residual risk calculations—without providing a clear, step-by-step audit log of the mathematical and rule-based operations. When an auditor asks, "Why does this control failure result in a residual risk score of 5.8 instead of 6.2?" your answer cannot be "Because the system calculated it." They will—and should—reject that.

Here's what I've seen fail in production:

* **Aggregation Mysteries:** How are individual control scores rolled up to a process, and then to an entity? The weightings and formulas are buried in client scripts and business rules, not in a transparent, reportable configuration. A change in a weighting table six months ago can make current scores incomparable to historical ones, breaking your audit trail.
* **The "Inherent Risk" Mirage:** The platform often calculates inherent risk based on factors like "impact" and "likelihood" that are themselves subjective scores. The translation from a qualitative assessment (e.g., "Regulatory Impact: High") to a numeric value used in the calculation is rarely documented in a way that satisfies an audit. Where is the mapping?
* **Dynamic Threshold Obfuscation:** When scores change because a threshold in a metric was adjusted, the historical view often just shows the new score. The fact that the threshold changed—the *why* behind the score delta—is not intrinsically part of the risk record's lineage.

You end up having to build what I call "forensic documentation" around the platform, which defeats the purpose. We had to implement a parallel logging system that snapshots inputs, weights, and formulas every time a score is generated. It's absurd.

If you're going into an implementation, consider this mandatory:

1. **Bypass the black box where it matters.** For regulated risks, implement your own scoring calculations in a scoped app where every step is logged and configurable via data tables, not hidden scripts. Use GRC as the UI and workflow engine, not the brain.
2. **Demand calculation journals.** For any OOB scoring you must use, insist on a pre-go-live requirement: a documented, step-by-step specification of the algorithm, signed off by both your compliance team and the implementor. Treat it like a financial model.
3. **Log inputs religiously.** Every qualitative assessment that feeds the score must be versioned. You need to be able to replay the calculation from six months ago using the data *as it existed then*.

The platform is powerful for workflow and consolidation, but its core risk intelligence cannot be trusted as a compliant source of truth without significant, careful augmentation. Treat the native scoring as a prototype, not a production system.

—BW