Third-Party Risk Management: A Practical Framework

Why Third-Party Risk Is Everybody’s Problem

Your security posture is only as strong as your weakest vendor. If a third party has access to your systems or data and they get breached, you get breached — regardless of how good your own controls are.

Third-party incidents account for a significant and growing proportion of data breaches. The attack surface isn’t just your perimeter; it’s every SaaS tool, every contractor, every API integration.

The TPRM Lifecycle

A mature TPRM program follows a consistent lifecycle for every vendor:

1. Identification and Tiering Not all vendors carry equal risk. A SaaS tool with read-only access to non-sensitive data is very different from a managed service provider with admin access to your production environment.

Tier your vendors by risk — typically Critical, High, Medium, Low — based on:

• Data access (what data, how much, what sensitivity)
• System access (read vs. write vs. admin)
• Operational dependency (what breaks if they do?)

2. Initial Assessment Before onboarding a vendor, assess their security posture. For critical and high-tier vendors this typically means:

• Security questionnaire (SIG, CAIQ, or custom)
• Review of certifications (ISO 27001, SOC 2 Type II)
• Penetration test results
• Data processing agreement review

3. Contracting Security requirements should be embedded in contracts — not bolted on afterwards. Key clauses:

• Right to audit
• Breach notification obligations and timelines
• Data handling and deletion requirements
• Sub-processor restrictions
• Minimum security standards

4. Ongoing Monitoring One-time assessments go stale. Ongoing monitoring should include:

• Annual reassessments for critical and high-tier vendors
• Continuous monitoring for breach news and security ratings changes
• Review when vendors change their sub-processors or undergo significant changes

5. Offboarding When a vendor relationship ends, don’t leave data behind. Confirm deletion, revoke access, and document the offboarding.

The Questionnaire Problem

Security questionnaires are the backbone of most TPRM programs — and also the biggest source of pain. Vendors hate receiving them; your team hates sending and reviewing them.

A few ways to make it manageable:

• Accept third-party certifications in lieu of questionnaires — a SOC 2 Type II report covers most of what a questionnaire asks. Don’t duplicate effort.
• Use a standardised questionnaire — the SIG Lite or CAIQ reduces friction because vendors have often completed them before
• Right-size the assessment to the risk tier — critical vendors get the full treatment; low-tier vendors might just need to confirm they have basic security controls

What Auditors Want to See

If you’re going through ISO 27001 or SOC 2, auditors will look for evidence of a functioning TPRM program:

• A vendor register with risk tiers
• Completed assessments for material vendors
• Contracts with security clauses
• Evidence of ongoing monitoring and periodic reassessment
• Records of vendor incidents and how they were handled

The most common gap: organisations have onboarding assessments but no evidence of ongoing monitoring. Point-in-time is not enough.