The Most Expensive Checkbox in Cybersecurity

Let me describe a scene you might recognise.

Your organisation has a third-party risk management programme. There’s a process document. There’s a questionnaire, probably a fancy spreadsheet with lots of sheets.

A hundred yes-or-no questions.

Out of date in 30 days.

Once a year, you send it to your vendors. They fill it in. You file it. The board gets a report that says “200 vendors assessed.”

Everyone is delighted.

Nobody asks what “assessed” actually means.

Nobody checks whether the supplier answers are true.

Nobody does anything when they’re not.

This is the state of third-party risk management in many organisations today. It’s not risk management. It’s box ticking. And the uncomfortable truth is that the frameworks we claim to follow — ISO 27001, NIST SP 800-161 — describe something fundamentally different from what we’re actually doing.

The Questionnaire Is Not the Programme

ISO 27001:2022 dedicates five separate Annex A controls to supplier and supply chain risk.

Not one. Five.

Control 5.19 requires processes and procedures to manage information security risks associated with supplier products and services.

Control 5.20 requires that security requirements are established and agreed with each supplier based on the type of relationship.

Control 5.21 addresses the ICT supply chain specifically — your vendor’s vendors.

Control 5.22 requires you to regularly monitor, review, evaluate, and manage change in supplier security practices.

And Control 5.23, new in the 2022 edition, addresses cloud services as a distinct category.

Read that list carefully. The standard talks about processes, procedures, agreements, monitoring, and change management.

It never mentions a questionnaire.

NIST goes even further. SP 800-161r1 is a 325-page publication dedicated entirely to cybersecurity supply chain risk management.

It describes a three-level governance model: enterprise strategy at the top, mission and business process management in the middle, and operational execution at the bottom. It requires involvement from eight disciplines — information security, procurement, enterprise risk management, engineering, software development, IT, legal, and HR.

Most organisations reduce all of this to a single annual questionnaire managed by one person in GRC.

The “Too Big to Audit” Problem

Here’s what happens in practice. You assess a vendor. They’re a blue-chip multinational. Their SOC 2 report doesn’t cover the specific service you’re using. Their ISO 27001 Statement of Applicability is doesn't cover the relevant controls, and the certificate is for a different country or a different business unit.

The certification exists, but it’s not relevant to what you’re buying.

Does anyone flag this? Rarely. And when they do, nothing changes.

Nobody gets fired for buying Microsoft. Or AWS. Or Salesforce. The vendor is too large, too embedded, too politically connected. Someone on the leadership team approved the relationship. Someone else negotiated the contract. The TPRM team was brought in after the decision was already made. They’re not there to assess risk. They’re there to document it.

The assessment becomes a record of a conversation that never really happened.

The Talent Gap Nobody Talks About

The people doing these assessments are, in many organisations, junior consultants. They were hired because they look nice in a suit and fit the recruitment budget, not because they have the experience to spot a SOC 2 report that doesn't cover the scope, or an irrelevant Statement of Applicability.

They don’t know what they’re looking at, because nobody taught them what to look for.

This isn’t their fault. It’s a structural problem. Organisations treat TPRM as a low-cost, high-volume activity.

They staff it accordingly.

The result is a programme that generates paperwork but doesn’t generate insight.

NIST 800-161 explicitly calls for a cross-disciplinary team with representatives from security, procurement, risk management, engineering, legal, and HR. The reality is one overwhelmed analyst with a spreadsheet and a deadline.

When Findings Have No Consequences

This is where the entire model breaks down.

A vendor assessment comes back with red flags. Gaps in encryption. Missing logging. No incident response plan. What happens next?

In a mature programme, there would be a risk treatment process. The findings would be escalated. A decision would be made — accept, mitigate, transfer, or avoid. That decision would be documented, owned, and reviewed.

In reality, the findings are swept under the carpet. Nobody wants to raise their hand and say a major vendor is failing.

Nobody wants to rock the boat.

The political dynamics of supplier relationships — who approved the vendor, who has a relationship with the account manager, who signed the original contract — make honest reporting uncomfortable.

So the findings go into a report that gets filed, and the vendor stays.

The board signs a contract amendment to “close the gaps.” Whether they read it is another question entirely.

ISO 27001 Clause 5.22 requires you to regularly monitor, review, evaluate, and manage change in supplier security practices. NIST 800-161 requires continuous monitoring across the entire system development life cycle. Neither standard considers “we sent them a questionnaire and filed the answers” to be monitoring.

The Tiering Illusion

Some organisations have vendor tiering models. Critical vendors get more scrutiny.

Non-critical vendors get a lighter touch.

On paper, this is sensible. In practice, it’s absurd.

A SaaS provider handling customer data is classified as 'non-critical' because the contract value is under the procurement threshold. The same platform processes 40% of the organisation's client transactions (20 million annually). The tiering model measures spend, not dependency.

The tiering model exists, but the classification decisions are made by people who don’t understand the technical dependencies. It’s often based on contract value rather than operational risk. A high-value catering contract gets more scrutiny than a low-value but operationally critical infrastructure provider.

Resource constraints make it worse. Teams set targets based on capacity, not risk. “We can audit 100 vendors this year” becomes the goal. If the number needs to come down, the goalposts move. The justification follows the budget, not the other way around.

What the Standards Actually Expect

Between ISO 27001:2022 and NIST SP 800-161, the picture of mature third-party risk management looks nothing like what most organisations do.

Here’s the gap:

The standards expect a governance structure with board-level visibility and enterprise-wide strategy. Most organisations have an operational team sending questionnaires with no strategic oversight.

The standards expect different assessment approaches for different types of supplier relationships. Many organisations use one questionnaire for everything.

The standards expect continuous monitoring of supplier security practices and service delivery. Most organisations assess at onboarding and forget.

The standards expect controls to flow down to subcontractors — your vendor’s vendors. Most organisations don’t even ask the question.

The standards expect a cross-disciplinary team involving security, procurement, risk, legal, and engineering. Most organisations assign it to a single function.

And NIST explicitly lists four validation methods: certifications, site visits, third-party assessments, and self-attestation.

Self-attestation — the questionnaire — is the lowest assurance method on the list. It’s the one almost everyone uses exclusively.

How to Give TPRM Teeth

If the process has no consequences, it’s not a process. It’s a ritual.

Giving TPRM teeth doesn’t mean terminating every vendor that fails an assessment. It means building a programme where findings lead to decisions, decisions lead to actions, and actions are tracked and reviewed.

It means ensuring the people doing assessments have the experience to understand what they’re looking at.

It means tiering vendors based on operational risk, not contract value. It means continuous monitoring, not annual checkbox exercises.

It means involving procurement before the contract is signed, not after.

And it means being willing to have uncomfortable conversations when a blue-chip vendor’s certification doesn’t cover what you’re buying.

Most importantly, it means accepting that a vendor risk assessment is not a document to be filed. It’s a decision to be made.

And right now, most organisations aren’t making it.

 References

ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A Controls 5.19–5.23.

NIST SP 800-161r1-upd1 — Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, May 2022.

NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations. Supply Chain Risk Management (SR) family.