If you run risk assessments for a living, you are probably good at your job. You know the frameworks. You know which controls to ask about, which domains to cover, and how to structure findings into a report that holds up under audit scrutiny. The assessment gets completed, the documentation is clean, and the organization has a record it can point to.
And yet something is missing. Not from the process — the process is fine. What's missing is in the questions themselves.
Standard risk assessment questions were designed by compliance professionals, for compliance purposes. They are written to verify that controls exist and that an organization can demonstrate awareness of its obligations. What they were never designed to do is verify that the person answering the question actually understands what they're describing — or that the control in question maps to how the business actually operates.
The Assessment That Looked Perfect
Picture a mid-sized company. The GRC team runs their annual risk assessment across twelve asset owners. Every question gets answered. Every response is "yes" or "in place" or "managed by IT." The final report comes back largely green. Senior leadership sees it. The board sees it. Everyone is satisfied.
Six months later, an incident. The forensic review traces it back to an access control that was technically in place but not enforced in the way anyone assumed. The system in question was a custom-built internal application — not a standard SaaS tool. The access control the asset owner described was the one they understood: a login screen, managed by IT. What the assessor needed to understand was how that application handled permissions across different user roles, and whether those rules were enforced at the application layer or just assumed to be. That distinction never surfaced. The question on the assessment had asked: "Do you have access controls in place?" The answer — honestly given — was yes.
No one lied. No one cut corners. The assessment worked exactly as designed. That's the problem.
The Translation Problem Nobody Talks About
Here is what actually happens when an assessor — whether that's an analyst, a consultant, or a GRC practitioner — asks a technical question to a non-technical asset owner.
The assessor asks: "Do you have multi-factor authentication enabled on your systems?" In the assessor's mind, this question is probing for a specific technical posture — MFA coverage, enforcement policy, exception handling, audit logs. They've been trained to think about it that way.
The asset owner — who might be a marketing operations lead, a finance manager, or a department head with a handful of SaaS tools — hears: "Do people need more than a password to log in?" They think for a moment. Their email requires MFA. Their laptop has a fingerprint reader. They say yes.
Both parties are telling the truth. But they're not having the same conversation.
The second question isn't harder to ask. It doesn't require technical expertise. It just asks the asset owner to describe their specific reality rather than confirm a general statement. That distinction produces completely different data.
The Question That's Almost Never Asked
There is one question that cuts through more ambiguity than almost any other in a risk assessment. It's not technical. It's not adversarial. It doesn't require technical expertise to ask.
The question is: "How would you know if something went wrong?"
Ask it after any control question. Ask it after the asset owner confirms they have logging in place, or that their backup runs nightly, or that access is restricted to authorized users. Then ask: how would you know if that stopped working?
Real-World Pattern
That last answer is not a failure of the asset owner. It's a risk finding. The control exists but has no active monitoring, no failure notification, and no owner who would catch a silent failure. That is meaningfully different from a control that is actively verified.
This is the question your assessments are never asking. And the absence of it means you're regularly recording controls as "in place" when what you actually know is that they were set up at some point, by someone, and haven't been reported as broken.
What You're Really Measuring
When a risk assessment relies on questions that can be answered with a yes or no — without requiring the respondent to describe how something works or how they'd know if it failed — what it actually measures is awareness, not posture.
The asset owner is aware that MFA exists. They are aware that backups run. They are aware that there is an incident response plan somewhere. Awareness is not security. Awareness is not risk posture. And awareness-level data is not sufficient to produce an accurate risk score.
This isn't a criticism of the people running assessments or the people answering them. It's a structural problem with how the questions are written. The frameworks that most assessments are built around were designed to ensure documentation and demonstrate compliance. They were not designed to surface the gap between what an organization believes about itself and what is demonstrably true.
"The most useful thing you can learn from an asset owner isn't what controls they have. It's whether they can describe how those controls work — and whether they'd know if one stopped working tomorrow."
Three Questions Worth Adding to Every Assessment
You don't need to redesign your entire assessment process. Adding three follow-up questions to your highest-risk asset conversations will produce significantly better data:
“Can you describe how that works in your environment?”
Not whether it exists — how it actually works. An asset owner who can walk you through the process has demonstrated control. One who gives a vague answer has given you a signal worth capturing.
“When was the last time that was tested or verified — and what happened?”
This is the operational reality check. A control that was last verified three years ago has a different risk profile than one tested last quarter. The assessment should reflect that difference.
“If something went wrong with this, who would find out first — and how?”
This question surfaces monitoring gaps, ownership ambiguity, and single points of failure that no checkbox question will ever catch.
None of these require technical expertise to ask. They require a willingness to go one level deeper than the framework demands — and to treat the uncertain, qualified, sometimes "I'm not sure" answer as data rather than an incomplete response to move past.
The "I'm Not Sure" Answer Is Your Most Valuable Data Point
Here is the reframe that changes how you approach every assessment: an asset owner who says "I'm not sure" or "IT handles that" or "I'd have to check" has not failed the assessment. They have given you the most accurate answer possible — and it is telling you something important about the actual risk posture of that asset.
An organization where the asset owner can describe their controls in operational detail has a different risk profile than one where controls are assumed to be working because no one has reported otherwise. Current assessments treat both answers the same. They shouldn't.
The question your risk assessments are never asking isn't a technical question. It's the question that comes after the checkbox: and how do you know?