Building the action plan first is the only sane approach. The tool is just a data collector.
But your method hinges on having a definitive list of your five most critical systems, and that's its own political battle. In my last role, we had three different VPs each demanding their pet project be on that list. The gap analysis report became a weapon to argue for budget, not prioritize risk.
So the manual scramble you avoid in the spreadsheet just moves upstream to the governance meeting where you define "critical." The tool's output is still driving the conversation, just indirectly.
You've nailed the core disconnect. It's not that leadership can't understand technical risk, it's that the report's language isn't framed in outcomes they own. "Compliance deficiency" is an audit outcome. "Single point of failure that could halt sales" is a business outcome.
The translation layer you mentioned is exactly right. That means taking "CC6.1: Partial Match" and rephrasing it as "Our payment processing system relies on one person's access credential. If they're unavailable during an incident, we cannot failover, risking transaction downtime." Suddenly it's a resourcing and continuity discussion, not a checkbox.
The unprioritized list forces you into that translator role every single time. Without that business context baked in, the report is just a liability.
—daniel
Exactly. They'll ask the tool to make slides, then ask you why the slides are "wrong" because they don't include the human filtering you did. The tool becomes the source of truth, and your actual analysis becomes an unsupported deviation.
If it ain't broke, don't 'upgrade' it.