Verizon DBIR 2024
Ponemon Institute
CrowdStrike 2024
IBM Security 2024
Why the Standard Vendor Questionnaire Is Broken
Most organisations approach third-party risk the same way: send a 50-question security questionnaire to new vendors, file the responses, repeat annually. If the vendor ticks all the boxes, they get access. If they're a big enough supplier, you might ask for their ISO 27001 certificate.
The problem is obvious once you say it out loud: a questionnaire tells you what a vendor's security policies claim to be. It tells you nothing about whether those policies are implemented, enforced, or tested. It's the equivalent of asking a job candidate to write their own reference letter.
Attackers didn't breach Target directly. They compromised Fazio Mechanical, a small HVAC contractor with remote access to Target's systems for monitoring heating and cooling equipment. The access wasn't segmented ,once attackers were on Fazio's systems, they could reach Target's payment infrastructure. 40 million credit card numbers were stolen. Total costs exceeded $200M. The HVAC vendor had almost certainly ticked the right boxes on a vendor questionnaire. Nobody had verified that their access was scoped to what they needed.
The Four Categories of Third-Party Risk You Actually Need to Track
Third-party risk isn't monolithic. Organisations that manage it well distinguish between different risk types and apply controls accordingly ,instead of treating a cloud payroll provider the same as a local printer supplier.
Cybersecurity & Data Access Risk
The vendor has direct or indirect access to your systems, data, or network. Highest-consequence category. Controls: access scoping, MFA enforcement, continuous monitoring, contractual breach notification requirements.
Compliance & Regulatory Risk
The vendor processes data subject to GDPR, HIPAA, DPDP, or PCI-DSS. If they mishandle it, you carry the regulatory exposure. Controls: DPA agreements, right-to-audit clauses, evidence of their own certification.
Operational Concentration Risk
You depend on this vendor for a critical business function. If they go down, you go down. Controls: BCP/DR review, SLA validation, fallback supplier identification.
Fourth-Party (Nth-Party) Risk
Your vendor's vendor. Many organisations don't realise their 'secure' SaaS provider runs on a cloud sub-processor that had a breach last year. Controls: supply chain transparency, sub-processor disclosures, contractual flow-down obligations.
Best Practice 1: Tier Your Vendors Before You Do Anything Else
Not all vendors deserve the same scrutiny. Treating every vendor identically wastes resources and creates fatigue ,which is how critical vendors end up under-reviewed. Effective tiering is based on two dimensions: the sensitivity of data or systems the vendor can access, and the business impact if that vendor is compromised or goes offline.
Most TPRM programmes tier vendors once at onboarding and never revisit. A vendor that starts as Tier 3 ,a small SaaS tool with limited access ,can become Tier 1 after a product expansion or an internal decision to integrate it more deeply. Without regular re-tiering, your risk posture drifts invisibly.
| Tier | Criteria | Review Cadence | Controls Required |
|---|---|---|---|
| Tier 1 ,Critical | Direct access to sensitive data or critical systems; significant business dependency | Continuous monitoring + quarterly review | Full technical assessment, access scoping, right-to-audit, incident notification SLA |
| Tier 2 ,Significant | Limited data access or moderate business dependency | Semi-annual review | Security questionnaire + evidence validation, contractual controls |
| Tier 3 ,Standard | No data access, low business impact | Annual review or at contract renewal | Standard vendor onboarding checklist |
Best Practice 2: Verify, Don't Just Trust
When a vendor submits their ISO 27001 certificate and completed questionnaire, the instinct is to file it and move on. Resist that instinct. ISO certification tells you a vendor had the right controls in place at the time of audit ,not whether those controls are still functioning, whether staff turnover has left gaps, or whether a recent infrastructure change introduced new vulnerabilities. Certifications age. Threats don't wait for renewal cycles.
The LAPSUS$ group compromised a customer support subprocessor used by Okta. Hundreds of Okta's enterprise customers ,who had no direct relationship with the subprocessor and no visibility into that vendor's security posture ,had to assess their own exposure. Okta's customers had vetted Okta. Nobody had vetted Okta's subprocessor. The lesson: your right-to-audit clause and sub-processor disclosure requirements need to cascade down the supply chain, not just to your direct vendors.
Verification in practice means requesting evidence rather than assertions, exercising right-to-audit clauses for Tier 1 vendors, using external threat intelligence to monitor vendor exposure, and asking every critical vendor to disclose their material sub-processors with notification of any changes.
Best Practice 3: Scope Access to What's Actually Needed
The Target breach happened because an HVAC contractor had broader network access than they needed. This pattern repeats constantly. Vendors are onboarded with access scoped to 'everything that might be relevant,' and nobody revisits it. Principle of least privilege applies to every vendor with a login, an API key, or a network connection to your environment.
- Audit current vendor access before the next breach. Map every third party with access to your systems and document precisely what they can reach. You will almost certainly find over-provisioned accounts.
- Time-box vendor access. Contractors and project-based vendors should have access that expires automatically when the engagement ends ,not accounts that linger indefinitely.
- Segment vendor access from your core network. A vendor managing your endpoint monitoring tool shouldn't be able to reach your finance systems.
- Require MFA for all vendor access. No exceptions. If a vendor pushes back on MFA requirements, that tells you something important about their security culture.
A financial services firm in Bengaluru implemented just-in-time (JIT) access for all third-party vendors. Instead of persistent credentials, vendors request access for a specific task window ,maximum 8 hours ,approved via a workflow that logs the requester, reason, and systems accessed. The result: zero lingering vendor accounts (previously 14 accounts for vendors whose contracts had ended), a complete audit trail for every vendor access event, and a dramatic reduction in available attack surface.
Scoping vendor access to exactly what is needed ,and no more ,is the single most impactful control in any TPRM programme. The Target breach exploited access that was never scoped correctly.
Best Practice 4: Contractual Controls That Actually Have Teeth
The legal side of TPRM is often treated as a procurement formality. Contracts get signed, DPA agreements get appended, and everyone moves on. But the contract is often the only leverage you have when something goes wrong ,and if it doesn't include the right clauses, you have no leverage at all.
- 1Breach notification within 24 hoursYour vendor contract should require notification within 24 hours of discovery ,you need time to assess your own exposure and meet your own regulatory obligations (DPDP zero-threshold, GDPR 72-hour rule).
- 2Right-to-audit clausesThe ability to audit a vendor's security controls on reasonable notice. Make it non-negotiable for Tier 1 suppliers. An annual or biennial technical assessment of a critical vendor's environment is table stakes ,not a sign of distrust.
- 3Sub-processor disclosure and approvalVendors must disclose their sub-processors and notify you of changes before implementing them. This is the contractual mechanism that catches the Okta-style fourth-party risk scenario before it becomes your problem.
- 4Security baseline requirementsSpecify minimum controls: MFA, encryption standards, patch cadence. Contractual requirements create accountability that questionnaires alone don't ,and give you grounds for termination if a vendor falls below the baseline.
- 5Termination for cause on security groundsIf a vendor suffers a breach affecting your data, you need the contractual right to terminate without penalty. Without this clause, you may be locked into a compromised vendor relationship while your own customers are exposed.
Attackers compromised a third-party JavaScript library running on British Airways' payment pages, skimming credit card details from approximately 500,000 customers. BA didn't write the malicious code ,it was injected into a vendor's script that BA included on their booking page. The ICO eventually settled the fine at £20M. Third-party code running in your environment is your risk. Sub-resource integrity checks, content security policies, and vendor code review processes are not optional for organisations running digital commerce.
Best Practice 5: Monitor Continuously, Not Annually
Annual vendor reviews were adequate when the threat landscape changed slowly and vendor relationships were stable. Neither is true anymore. A vendor that passed their security review in January may have suffered a breach in March that they haven't publicly disclosed yet. None of this surfaces in a point-in-time questionnaire completed eight months ago.
- External attack surface monitoring. Tools that continuously scan the internet-facing infrastructure of your critical vendors for open ports, expired certificates, and misconfigured services.
- Dark web and credential monitoring. Services that alert you when vendor credentials or data appear in breach databases or paste sites ,often before the vendor themselves are aware.
- News and adverse media monitoring. Automated alerting for press coverage of vendor incidents, regulatory actions, or financial distress.
- Vendor security ratings. Platforms like SecurityScorecard and BitSight provide continuous external security posture scores ,imperfect, but useful for prioritisation and trend analysis across your vendor portfolio.
The M&S ransomware attack, attributed to the Scattered Spider group, entered through a third-party IT help desk provider over a holiday weekend. Attackers used social engineering against the vendor's identity verification process to reset credentials and gain access to M&S systems. Continuous behavioural analytics on vendor access patterns ,unusual login times, credential reset requests outside normal patterns, access from unexpected geographies ,could have flagged anomalous activity before it escalated. Point-in-time vendor audits do not catch this. Continuous monitoring does.
Best Practice 6: Offboarding as Rigorous as Onboarding
Ask any IT team how many former vendor accounts are still active in their environment. The answer is almost always more than they expect ,and more than they're comfortable with. Vendor offboarding is the step that gets forgotten. A contract ends, the business relationship concludes, and nobody tells IT to revoke access. Six months later, the vendor's former employee ,who still has credentials ,has moved to a competitor, or their systems have been compromised.
- Tie access revocation to contract end dates automatically. Build offboarding triggers into your procurement workflow ,not a manual IT ticket, but an automated deprovisioning event.
- Audit vendor accounts quarterly for activity. Dormant accounts unused for 90 days are candidates for immediate review and likely deprovisioning.
- Recover company assets. Laptops, tokens, and physical access credentials need to be collected at offboarding ,document this as a step in your procurement close-out process.
- Document what data the vendor held. You need to know what was shared, where it lives, and what your data deletion obligations are under GDPR and DPDP.
A Practical TPRM Roadmap
If you're building or overhauling your TPRM programme, you don't need to boil the ocean. Here's a grounded starting point:
"The organisations that handle third-party risk well aren't the ones with the longest questionnaires. They're the ones that verify what their vendors claim, scope access to what's actually needed, and monitor continuously rather than annually."
Frequently Asked Questions
Third-Party Risk Management (TPRM) is the process of identifying, assessing, and mitigating the risks associated with external vendors, suppliers, and service providers that have access to your systems, data, or critical business functions. It covers cybersecurity risk, compliance risk, operational concentration risk, and fourth-party risk. Effective TPRM goes beyond annual vendor questionnaires to include tiering, access scoping, contractual controls, and continuous monitoring.
Fourth-party risk is the risk posed by your vendor's vendors ,the sub-processors, cloud providers, and contractors that your direct suppliers depend on. The Okta breach in 2022 is the clearest example: Okta customers had vetted Okta, but nobody had vetted Okta's subprocessor, which was compromised by the LAPSUS$ group. Managing fourth-party risk requires requiring sub-processor disclosures from your critical vendors and flowing contractual security obligations down the supply chain.
Vendors should be tiered by two dimensions: the sensitivity of the data or systems they can access, and the business impact if they are compromised or go offline. Tier 1 (Critical) vendors require continuous monitoring, quarterly review, full technical assessment, and right-to-audit clauses. Tier 2 (Significant) vendors require semi-annual review and evidence-validated questionnaires. Tier 3 (Standard) vendors require annual review at contract renewal.
ISO 27001 Annex A.5.19 and A.5.21 require information security in supplier relationships and management of ICT supply chain. SOC 2 CC9.2 requires vendor risk management processes. GDPR Article 28 requires Data Processing Agreements with all processors and sub-processors. The DPDP Act Section 8(5) requires reasonable safeguards including vendor oversight. PCI DSS Requirement 12.8 requires management of service providers who could affect cardholder data security.
Critical contract provisions include: breach notification within 24 hours of discovery, right-to-audit clauses exercisable on reasonable notice, sub-processor disclosure and prior approval requirements, minimum security baseline requirements (MFA, encryption, patch cadence), and termination for cause on security grounds without penalty. For GDPR and DPDP compliance, a Data Processing Agreement (DPA) is mandatory for all data processors.