Walk into any risk assessment and you will find two very different tools sitting next to each other on the asset register. One is an enterprise SaaS platform — procured after months of vendor evaluation, negotiated at significant cost, integrated with four other systems, and managed by a dedicated administrator. The other is a spreadsheet — built by someone in finance three years ago, living on a shared drive, used every month to produce the numbers that go to the board.
On the assessment, they get the same question: "Do you have access controls in place?"
Both asset owners answer yes. Both get a checkmark. The assessment moves on.
This is not a failure of the people involved. It is a failure of the questions.
Two Kinds of Complexity
The assumption built into most risk assessment questions is that complexity lives on one side of the ledger — that enterprise software is inherently more controlled than informal tools, and that a tool's sophistication correlates with its security posture. Neither assumption holds up.
A spreadsheet used for business reporting is not a simple tool. Built by a finance or operations SME, it may contain dozens of interdependent formulas, lookup tables across multiple tabs, conditional logic that took months to develop, and data pulled from three different source systems. The person who built it is the only one who fully understands it. If they leave, that knowledge leaves with them. If someone edits the wrong cell, the output is wrong — and nobody may notice until the board asks a question that can't be answered.
That is a sophisticated, high-stakes tool. It just doesn't look like one from the outside.
A $5M SaaS platform carries a different kind of complexity. The vendor handles the infrastructure. Updates are automatic. Uptime is contractually guaranteed. But the platform has roles and permissions that may never have been fully configured. It has integrations with other systems that nobody fully mapped. It has data flowing in and out in ways the asset owner understands conceptually but couldn't diagram in detail. And it has an administrator — who may or may not have received formal training — making configuration decisions that affect who can see what, and what happens to that data downstream.
Both tools are complex. Both carry real risk. The nature of that complexity is different. But on a standard risk assessment, neither complexity gets surfaced — because the questions weren't designed to find it.
What the Assessor Is Actually Equipped to Do
Assessors are not expected to be SMEs in financial modeling, and they are not expected to be experts in every SaaS platform on the market. That is not a reasonable standard, and it is not what the assessment process requires.
What the assessment process should require — and almost never does — is questions designed to surface complexity through the people who are the SMEs. The asset owner who built the spreadsheet knows exactly how it works, what breaks it, and who depends on it. The platform administrator knows which integrations are live, which permissions haven't been reviewed, and whether the audit log is actually being monitored. That knowledge exists. The assessment just never asks for it.
The spreadsheet owner isn't being careless when they answer yes to an access control question. They're operating under a reasonable assumption — that IT has handled the access management layer, that HR's offboarding process connects to the systems that matter, that the infrastructure around their tool is someone else's domain. From where they sit, that's correct. They built the model. They didn't provision the drive.
The SaaS platform administrator makes the same assumption in the other direction. The vendor passed the security review. The contract has data processing terms. The platform is enterprise-grade. The assumption is that procurement rigor translates into operational security — that what was evaluated before purchase reflects what is actually configured and monitored today.
Neither assumption is unreasonable. Both assumptions are where risk hides.
The assessment question "do you have access controls in place?" doesn't help either person see past their assumed boundary. It doesn't ask the spreadsheet owner whether they know who currently has edit access, or whether they've ever been told that's something they should track. It doesn't ask the platform administrator whether the configuration matches what the security team reviewed during procurement, or whether anything has changed since go-live.
The question confirms the assumption rather than testing it. And an assessment built on confirmed assumptions is not measuring risk — it's measuring confidence.
The Procurement Trap
There is a specific version of this problem that appears consistently in assessments of enterprise SaaS tools: the confusion of procurement with implementation.
An organization buys a $5M platform. The procurement process was rigorous — security questionnaires, vendor assessments, legal review of data processing terms. By the time the contract is signed, the organization has done more due diligence on this vendor than on almost anything else in their environment. The security team is satisfied. The assessment reflects a mature, evaluated tool.
What the assessment does not capture is what happened after the contract was signed. Whether the implementation followed the vendor's security configuration guidelines. Whether the admin roles were set up correctly or defaulted to broad access because it was easier during the rollout. Whether the integrations were reviewed from a data flow perspective or just tested for functionality. Whether anyone has looked at the audit logs since go-live. What the assessment also rarely captures is whether the SaaS platform itself provides the security capabilities needed to maintain the organization's posture — a gap significant enough that the Cloud Security Alliance developed a dedicated framework to address it. That's a topic worth its own examination.
Procurement due diligence and operational security posture are not the same thing. But assessment questions written at the existence level treat them as equivalent.
The Question That Separates Both
There is a single follow-up question that changes the conversation for both the spreadsheet and the SaaS platform:
"If something went wrong with this — wrong output, unauthorized access, data loss — who would find out, and how?"
Ask the spreadsheet owner. If they pause, or say "I'd probably notice when the numbers looked off," or "I'm not sure anyone else would catch it" — that answer tells you more about the risk posture of that asset than any checkbox ever could.
Ask the platform administrator. If they say "we'd get an alert" — ask who gets the alert, when they last checked it, and whether it's been tested. If they say "I'd have to check with the vendor" — that is your finding.
Neither answer requires the assessor to understand financial modeling or SaaS architecture. It requires the assessor to ask what happens when the assumption of control breaks down.
What Gets Missed When Both Get the Same Checkmark
The consequence of treating a spreadsheet and a SaaS platform as equivalent on an assessment is not just a theoretical problem. It produces a risk register that cannot be prioritized meaningfully.
If both tools pass the same questions at the same level, there is no signal in the assessment that one carries significantly more exposure than the other. The risk register reflects documentation, not reality. Remediation efforts get directed toward whatever looks most incomplete on paper, rather than toward the assets where the actual exposure is highest.
The $5M platform may have a known misconfiguration that affects every user in the organization. The spreadsheet may be the only authoritative source for a calculation that drives a board-level decision every quarter. Neither of those facts will appear in an assessment built on existence questions.
Risk assessments that treat all tools equally produce organizations that don't know what they're actually protecting. The work of separating the spreadsheet from the platform — of understanding how each one works, who depends on it, and what breaks if it fails — is a shared responsibility between the assessor who asks the right questions and the asset owner who has the knowledge to answer them.
The assessment's job is to create the conditions for that conversation. Most assessments don't.