Just migrated our risk process to AuditBoard from a spreadsheet. Now every risk assessment is getting flagged for "matrix misalignment."
Turns out, if a risk has a "Likelihood" of 3 and an "Impact" of 4, the system insists the inherent rating must be whatever's at that intersection. In our old sheet, we had a buffer zone there—could call it High or Medium based on mitigating factors pre-assessment.
AuditBoard's logic seems to be: the matrix is law. No discretion until you get to the residual rating phase.
So, is there a config setting I'm missing to allow some leeway in the initial rating, or is this just how it's built? Feels like they've automated the thinking out of the process.
CRM is a necessary evil
I ran into this too when we switched to a dedicated GRC tool. That rigid matrix logic drove me nuts at first.
>based on mitigating factors pre-assessment
I think that's the key disconnect. These systems treat the initial inherent rating as a pure calculation, before any controls are considered. Your discretion point is meant to be applied later, when you're working on the residual rating. It's not a bug, it's a design choice for consistency.
Have you checked if AuditBoard lets you customize the matrix itself? Sometimes you can tweak the thresholds or the labels in the grid, which might give you the buffer zone you're missing. If not, you might have to adjust your likelihood/impact scores before hitting submit, which feels backwards.
Our team just accepted it as the new normal, but it still feels a bit robotic. Does yours allow any manual override flag, or is it truly locked?
Oh, that's really interesting. I haven't used AuditBoard, but I've seen something similar in the marketing risk tools we use for campaign compliance.
It sounds like the system is forcing you to separate the raw score from your judgement in a way the spreadsheet didn't. You used to combine them early.
>based on mitigating factors pre-assessment
Maybe those factors aren't actually "pre-assessment" in the system's logic? They might be considered a control, so they belong in the residual phase. It's a tough change in mindset from a flexible sheet.
I get why they'd want that strict initial calculation for audit trails, but it does feel clunky. Did you find any way to adjust the matrix labels or the score ranges themselves? That might be the only workaround.
That's a good catch about separating the raw score from judgment. It's a common pain point in migrating from spreadsheets. The system's view is that any mitigating factor applied *before* that first rating is, by definition, a control, and therefore belongs in the residual assessment.
You're right that it's a tough mindset shift. The consistency helps during audits, but it can feel like it's missing the nuance you had before. In my experience, the only real configurable piece is the matrix thresholds themselves, not the enforcement of its logic.
Keep it constructive.
Yeah, that "control or not" framing is a good way to look at it. It's like the system is forcing you to declare your hand early, which is the opposite of the spreadsheet where you could fudge it.
I'm curious about something though - does the matrix threshold customization actually work for this? Like, if you adjust the labels or the score ranges, can you effectively create a "medium-high" zone that gives you some wiggle room? Or does the rigid intersection logic still force one specific rating?
In marketing automation, we run into similar friction with lead scoring rules. You can tweak the thresholds but the underlying math stays the same. Sometimes you just have to accept that the tool's logic is the new baseline and build your judgment layer on top of that. Still feels like a step backward for nuance though.
Just here to learn.
Your marketing automation comparison is spot on. The threshold customization question hits on the core architectural difference. In my experience with these platforms, adjusting the labels or score ranges only changes the map, not the rule of travel. You can redefine what a '3' likelihood means, or stretch the 'Medium' band, but the moment you input Likelihood=3 and Impact=4, the lookup function will still return the single, predefined value at that coordinate. The system is designed to treat the matrix as a strict function, not a guideline.
The real workaround, which is inelegant, is to build your nuanced judgment into the input scoring itself before it hits the matrix. If you feel a risk with scores of 3 and 4 should be a 'High' rather than the matrix's 'Medium', you're forced to manually downgrade the likelihood to 2 or the impact to 3 on the front end. This creates its own audit trail problem, as your rationale for that pre-adjustment now lives outside the system's formal control logic.
It is a step back for nuanced judgment in the initial phase, and you're right to feel that. The tradeoff is a consistent, defensible audit trail that cleanly separates raw assessment from management action. You learn to move your discretionary fudging entirely into the residual rating phase, which is where the system expects all mitigation to be applied.
You've hit on the fundamental philosophy shift between a manual spreadsheet and a structured GRC platform. That "buffer zone" you had was the discretion itself, embedded in the process. AuditBoard, like most similar tools, removes that by design to ensure every risk rating is auditable and traceable back to a raw, unadulterated score.
The short answer is no, there's likely no config setting to inject leeway into the inherent rating calculation. The matrix *is* law in that phase. Where you might find some flexibility is in how you define the inputs. If a risk feels like it deserves a different rating, you're forced to adjust your likelihood or impact score *before* it hits the matrix, essentially baking your judgment into the input rather than the output. It's a different kind of fudge, but it's the only lever you usually have.
It absolutely feels like automating the thinking out, but from an audit trail perspective, it's crystal clear: this score led to this rating, period. The thinking is supposed to happen in the residual phase, or when you're arguing why the likelihood should be a 2 instead of a 3.
connected