Just wrapped up a 14-day trial. I get the core GRC modules—Risk, Compliance, Audit. But the new "Resilience" module feels like it's overlapping. Or is it?
Can someone break down its actual, different job? My take from poking around:
**What it seems to do uniquely:**
* Ties operational resilience (think: critical business services) directly to tech and vendor risks. Not just listing assets, but mapping service dependencies.
* Focuses on impact tolerances—"how much disruption can this service handle?"—and tests scenarios against that.
* Feels more forward-looking: "Here’s what breaks if this supplier goes down," vs. "Here’s our current vendor risk score."
**Still fuzzy on:**
* How its "Business Service" modeling isn't just a fancy CMDB view.
* If it actually uses different data or just repackages Risk & Compliance workflows.
Is it genuinely a new tool, or a new lens on existing data? Would love real-world examples.
Trial number 47 this year.
You've hit the nail on the head with the forward-looking aspect. The key difference is the shift from a *state* assessment (Risk, Compliance) to a *process* simulation. Resilience isn't about scoring a vendor today. It's about modeling the failure propagation and time-to-recovery chain if that vendor's API starts returning 503s.
Your question about the "Business Service" modeling is the right one. A CMDB tells you Component A depends on Server B. Resilience modeling forces you to define the *recovery flow*: if Database Cluster C fails, does Service D fail over automatically within 30 seconds, or does it require a manual runbook execution that takes 45 minutes? That's where impact tolerances get tested. It uses the same foundational data (assets, vendors) but adds a new layer of temporal and dependency graph data that pure risk workflows ignore.
A real-world example: a high vendor risk score might trigger a mitigation plan over 90 days. A resilience test on that same vendor reveals that our payment service hits its impact tolerance after 2 hours of downtime because of a cascading failure in our message queue. The action isn't to re-score the vendor, it's to implement a circuit breaker pattern or a fallback payment processor *specifically* for that service path. It's a different class of problem.
--perf
Good points. You're right about it being a new lens. But the real value is the "what if" simulation that other modules don't do.
For your Business Service question - a CMDB shows a static map. Resilience forces you to assign recovery times and manual steps to each connection. That's the new data layer. So you're not just seeing that your payment service needs Vendor X's API, you're defining that a 4-hour outage from Vendor X exceeds your 1-hour impact tolerance, triggering a specific failover plan.
We tried modeling our email delivery service. The Risk module flagged the ESP as high-risk. Resilience showed our backup mail server wouldn't auto-switch, requiring a manual change in DNS that took 90 minutes. That's the difference - it found a gap in the *process*, not just the asset.
Trial number 47 this year.
Exactly! That gap in the process is everything. We had the same "aha" moment modeling our lead-to-cash flow. Risk flagged our payment processor, sure. But Resilience showed that a failure during month-end closing wouldn't just stop new sales, it would stall the entire revenue recognition process for 48 hours because of a manual reconciliation step no one had connected.
It's that second, third-order impact on business operations, not just the first broken tech link. Your DNS switch example is perfect. It turns a static vendor score into a live operational timeline. Makes you ask, "Do our runbooks actually match our recovery targets?"
Data is the new oil