The spreadsheet graveyard
Somewhere in your organisation, there is a spreadsheet. It contains the names of your vendors, their SOC 2 status, a risk rating that was assigned when the vendor was onboarded, and a "last reviewed" date that is embarrassingly stale. This is your vendor risk management program.
It is not working.
The spreadsheet exists because a framework requires it — SOC 2's CC9, ISO 27001's Annex A.15, or the procurement team's due diligence policy. It was populated with good intentions. But the operational reality is that once a vendor clears the initial assessment, they enter a state of benign neglect. The questionnaire responses gather dust. The risk rating is never updated. The vendor's actual security posture evolves — for better or worse — completely unobserved.
This is the norm, not the exception. And it represents one of the most significant unmanaged risk surfaces in modern organisations.
Why third-party risk matters more than ever
The average organisation's technology stack includes dozens to hundreds of third-party services. Each one represents a trust relationship — you are granting a vendor some degree of access to your data, your infrastructure, or your customers' information.
The attack surface implications are substantial. When a vendor is compromised, the blast radius extends to every customer that trusted them. The pattern repeats with disturbing regularity: a supply chain attack compromises a widely used tool, and thousands of downstream organisations are affected simultaneously.
Your security program is only as strong as the weakest link in your vendor chain. This is not a theoretical concern. It is an operational reality that most vendor risk programs are structurally incapable of addressing.
What is wrong with questionnaires
The standard vendor risk assessment is a questionnaire — sometimes a standardised one like SIG or CAIQ, sometimes a bespoke set of questions. The vendor fills it out, you review the responses, and you make an approval decision.
The problems are structural:
Self-reported data is unreliable. Vendors have every incentive to present their security posture in the most favourable light. Questionnaire responses describe intended controls, not necessarily implemented ones. There is no verification mechanism built into the process.
Point-in-time assessment. A questionnaire captures the vendor's state at the moment they responded. Security postures change continuously — new vulnerabilities are discovered, configurations drift, teams turn over. A questionnaire from 12 months ago tells you almost nothing about today's risk.
One-size-fits-all. The same 200-question questionnaire is sent to every vendor, regardless of the nature of the relationship. The cloud infrastructure provider that hosts your production data receives the same assessment as the marketing analytics tool that processes anonymised usage metrics. This wastes effort on low-risk vendors while potentially under-scrutinising high-risk ones.
No operational follow-through. Even when questionnaire responses reveal concerning gaps, the findings rarely trigger meaningful action. The vendor is onboarded with a "residual risk acceptance," the concerns are documented, and the relationship proceeds. The risk acceptance is never revisited.
A tiered approach to vendor risk
The first step toward a functional vendor risk program is triage. Not all vendors carry equal risk, and your assessment effort should be proportional to the risk each vendor introduces.
Tier the relationship, not the vendor
Risk tiering should be based on the nature of your relationship with the vendor, not on the vendor's overall profile. A Fortune 500 company with a mature security program is still a high-risk vendor to you if they have access to your production database. A two-person startup is a low-risk vendor if they provide a design tool that never touches customer data.
Four factors determine tier placement:
Data access. What data does the vendor process, store, or transmit on your behalf? Customer PII, financial data, and protected health information warrant the highest scrutiny.
Integration depth. Does the vendor have network access to your infrastructure? API access to your systems? Do they receive webhooks with sensitive payloads? Deeper integration means a wider blast radius if the vendor is compromised.
Business criticality. If this vendor disappeared tomorrow, what would happen? Vendors that are critical to your operations — your cloud provider, your identity provider, your payment processor — warrant closer monitoring because the impact of their failure extends beyond security to business continuity.
Substitutability. How easily can you switch vendors if this relationship needs to be terminated? High switching costs increase your exposure because they limit your ability to respond if the vendor's risk posture deteriorates.
A simple three-tier model works for most organisations:
Critical (Tier 1): Vendors with access to sensitive data, deep integration, or high business criticality. Full assessment, annual review, continuous monitoring.
Significant (Tier 2): Vendors with moderate data access or integration. Streamlined assessment, annual review.
Standard (Tier 3): Vendors with minimal data access and low integration. Lightweight assessment at onboarding, periodic check.
Assess proportionally
Each tier should have a different assessment protocol:
Tier 1 vendors warrant a thorough evaluation: review their SOC 2 or ISO 27001 report (not just the certificate — the actual report, including exceptions), evaluate their incident response capabilities, understand their subprocessor chain, and conduct a focused questionnaire on areas not covered by their attestation reports. Request evidence, not just assertions.
Tier 2 vendors can be assessed through their attestation reports supplemented by a focused questionnaire on the specific aspects of their service that affect you. A vendor's general security posture matters less than their security posture in the context of your data and integration.
Tier 3 vendors may only require verification that they have a basic security attestation (SOC 2 or equivalent) and a review of their terms of service and data processing agreement. The assessment effort should reflect the limited risk these relationships introduce.
Continuous monitoring: the missing piece
The most critical gap in traditional vendor risk programs is the absence of continuous monitoring. Annual questionnaire reviews are insufficient for the same reason that annual penetration tests are insufficient — the world changes between assessments.
Continuous monitoring means establishing ongoing visibility into your vendors' risk posture between formal reviews. This includes:
Attestation tracking. When does each vendor's SOC 2 report expire? Are they maintaining their ISO 27001 certification? Set alerts for expiration dates and follow up proactively.
Breach and incident monitoring. Monitor public breach disclosures, security advisories, and news reports for your critical vendors. If a Tier 1 vendor discloses a breach, you should know about it immediately — not when you read about it in the press days later.
Contractual compliance. Are vendors meeting the security commitments in your agreements? Data processing agreements often include specific obligations — breach notification timelines, data deletion upon termination, subprocessor notification. Track compliance with these obligations.
Subprocessor changes. Your vendors use vendors. When a critical vendor changes a subprocessor — particularly one that handles your data — you should be notified and have the opportunity to assess the change. Most data processing agreements include this right. Few organisations exercise it.
The vendor lifecycle
Effective vendor risk management is not an event. It is a lifecycle:
Selection and due diligence. Before signing, assess the vendor's risk profile and ensure contractual protections are in place. Data processing agreements, security addenda, breach notification obligations, and audit rights should be negotiated before the relationship begins — not retrofitted after.
Onboarding. Conduct the formal risk assessment, assign the tier, document the risk acceptance, and configure monitoring. Ensure the vendor is provisioned with least-privilege access.
Ongoing management. Monitor continuously, review formally at the cadence determined by tier, and reassess the tier assignment when the relationship changes (new data types, deeper integration, increased criticality).
Offboarding. When a vendor relationship ends, ensure data is returned or destroyed per your agreement, access is revoked completely, and the vendor is removed from your inventory. This step is consistently overlooked and represents a real risk — former vendors with residual access to your systems or data.
Making it operational
The difference between a vendor risk program that exists on paper and one that reduces risk is operational integration. Vendor risk findings should trigger actions: access reviews, contractual amendments, compensating controls, or relationship termination. Risk acceptances should have expiration dates and review triggers.
Track vendor risk alongside your other risk domains. A risk register that includes third-party risks alongside technical and operational risks gives leadership a complete picture. A vendor risk program that operates in isolation — disconnected from the broader risk practice — will always be an afterthought.
The goal is not to eliminate third-party risk. That is impossible in a modern technology environment. The goal is to understand it, manage it proportionally, and respond to changes before they become incidents. A spreadsheet of stale questionnaires does not achieve this. A structured, tiered, continuously monitored program does.