Third-Party Risk Management Policy for SaaS: Template, Tiers, and Controls
Supply chain attacks aren't theoretical anymore. SolarWinds (2020), Kaseya (2021), 3CX (2023), MOVEit (2023) — each one used a trusted third party to breach hundreds or thousands of downstream customers. The Ponemon Institute's 2024 third-party risk report found that 62% of data breaches involved a third party, up from 51% three years earlier.
That's why every enterprise security review now asks: "Show me your Third-Party Risk Management policy." If you can't produce one, you'll lose enterprise deals. If you can't follow one, you'll fail audits.
This guide covers what a TPRM policy needs to contain, how to tier your vendors, and what controls to put in place — with a free template generator you can use right now.
Why You Need a Formal TPRM Policy
Multiple frameworks now explicitly require a documented TPRM program:
- ISO 27001:2022 A.15 (supplier relationships, also clause 6.6 of the 2022 update) — requires controls over supplier security, supplier service delivery management, and information protection in supplier agreements
- SOC 2 CC9.2 — vendor and business partner risk management is an explicit Trust Service Criterion. Auditors will ask for the policy, the vendor inventory, and evidence of due diligence and monitoring.
- GDPR Art. 28 — processors must ensure sub-processors provide "sufficient guarantees" of GDPR compliance. You can't sign a DPA and walk away.
- NIS2 Art. 21(2)(d) — supply chain security is one of the ten mandatory measures for essential and important entities in the EU.
- HIPAA §164.308(b)(1) — business associate contracts and assurance that they will protect PHI.
- PCI DSS Req. 12.8 — maintain a list of service providers, written agreements, and a process to monitor compliance.
Enterprise buyers in 2026 routinely ask for the TPRM policy as part of their own due diligence — it's no longer just a compliance checkbox.
Vendor Tiering — The Foundation of TPRM
Not every vendor is equal. AWS holding your production database is not the same risk as your invoicing tool. Tiering lets you spend time and money proportional to risk.
| Tier 1: Critical | Tier 2: High | Tier 3: Medium | Tier 4: Low | |
|---|---|---|---|---|
| Data access | PII, PHI, CHD, or production data | Internal non-PII | Limited data | No company data |
| System access | Direct prod access | Indirect/limited | None | None |
| Business dependency | Single point of failure | Significant | Moderate | Low |
| Due diligence | Full set + on-site/virtual review | Questionnaire + SOC 2 | Questionnaire only | Self-attestation |
| Monitoring | Quarterly + continuous | Semi-annual | Annual | On change only |
| Examples | AWS, Stripe (CHD), GitHub (source code), EHR partner | HubSpot, Intercom, Google Workspace | Figma (no PII), Notion (internal only) | Public APIs, invoicing tools |
Tier 1 examples for a typical B2B SaaS: AWS (everything), Stripe (payment data), GitHub (source code), Auth0 / Okta (authentication), your EHR integration partner if you're healthcare. If they go down or get breached, you go down or get breached.
Tier 2 examples: HubSpot (customer contact data), Intercom (support conversations), Google Workspace (employee email, calendars), Slack (internal comms). Important, but not core production.
Tier 3 examples: Figma (no PII in design files), Notion (internal documentation only), Jira / Linear, project management tools.
Tier 4 examples: Invoicing-only tools with no customer data access, public APIs you call as a customer, marketing analytics that only see aggregate data.
Due Diligence Requirements by Tier
| Requirement | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| Security questionnaire / VSAQ | ✓ | ✓ | ✓ | — |
| SOC 2 Type 2 report | ✓ | ✓ | Recommended | — |
| Penetration test evidence (12 months) | ✓ | ✓ | — | — |
| Privacy policy & DPA review | ✓ | ✓ | ✓ | If applicable |
| Financial viability check | ✓ | Recommended | — | — |
| Reference check from other customers | ✓ | Optional | — | — |
| On-site or virtual security review | ✓ | — | — | — |
| GDPR/HIPAA/PCI compliance confirmation | ✓ | ✓ | If applicable | — |
A common SaaS mistake: applying Tier 1 due diligence to every vendor. You'll burn out the team and slow the business. Tier first, then scale the rigour accordingly.
Contract Requirements by Data Type
- DPA (GDPR Art. 28) — required for any processor that touches personal data of EU/UK/EEA/Brazilian/etc. subjects. DPA Generator →
- BAA (HIPAA §164.504) — required for any business associate that accesses PHI. BAA Generator →
- NDA — default for all vendors before sharing internal information. NDA Generator →
- SLA — mandatory for Tier 1 and 2 production dependencies. Define uptime, support response, incident escalation.
- Right-to-audit — Tier 1 mandatory, Tier 2 on request. Often via SOC 2 report rather than physical audit.
- Data destruction on termination — universal. Always require a destruction certificate.
- Breach notification — timelines: 72 hours for GDPR (vendor to you), 24 hours for NIS2 initial notice.
- Sub-processor approval — GDPR Art. 28(2) requires either general or specific authorisation for sub-processors. Specify which.
- Cybersecurity insurance — increasingly expected for Tier 1 vendors. Verify limits.
Ongoing Monitoring Framework
Why annual reassessment isn't enough for Tier 1 vendors: a vendor's security posture can change in 11 months. A SOC 2 from a year ago tells you nothing about what they did last week.
Security ratings platforms: SecurityScorecard, UpGuard, and BitSight continuously rate vendors based on external signals (open ports, expired certificates, leaked credentials, patching cadence). All three have free tiers for monitoring a small number of vendors — useful if you have a tight budget.
News and breach monitoring — free approaches:
- Google Alerts on "[vendor name] breach", "[vendor name] data leak", "[vendor name] vulnerability"
- HaveIBeenPwned domain monitoring for company-managed email domains
- CISA / NCSC vulnerability alerts for major software you depend on
- RSS or email subscriptions to vendor security advisories
Contract renewal reminders: set a calendar event 90 days before each renewal to trigger reassessment. Don't let multi-year auto-renewals slip past without due diligence refresh.
Annual questionnaire refresh: rotate through all tiers annually. Many vendors will just re-send last year's response — that's fine for Tier 2/3, but Tier 1 should produce updated evidence (new SOC 2, new pen test, updated sub-processor list).
Vendor Incident Response
When your vendor reports a breach involving your data, you have hours to act:
- Acknowledge and triage: What data was involved? Whose data subjects? When did it occur? When was it discovered?
- Internal escalation: Security lead + Encarregado/DPO + Legal + relevant business owners. Open an incident in your IRP system.
- Regulatory assessment: Does this trigger GDPR Art. 33 (72h to DPA)? HIPAA breach notification rule? NIS2 24h initial notice? You as the controller have your own obligations regardless of what the vendor does.
- Customer notification: If individuals are at risk, GDPR Art. 34 may require direct notification. CCPA / state breach laws may impose state-by-state notification.
- Post-incident: Document everything. Update the vendor's risk score. Decide on continued use, additional controls, or termination.
Your IRP should explicitly include a vendor-breach branch. Incident Response Plan Generator →
Offboarding Checklist
- Revoke all access and credentials (SSO, API keys, integrations, shared accounts)
- Collect data return in standard format (or confirm not needed)
- Obtain a signed certificate of destruction for all data
- Confirm sub-processor data deletion (chain of destruction)
- Close billing accounts and remove payment methods
- Update your vendor inventory with termination date and reason
- Archive the contract documentation for the legally required retention period
- Final audit log check — any unexpected access in the 30 days before/after termination?
Policy Document Structure
A complete TPRM policy should contain:
- Purpose and scope
- Vendor categorisation & tier definitions
- Due diligence requirements (by tier)
- Procurement process
- Contract and legal requirements
- Onboarding controls
- Ongoing monitoring
- Incident and breach response (vendor-side)
- Offboarding and termination
- Roles and responsibilities
- Exceptions process
- Policy compliance and enforcement
- Review & version history
- Vendor inventory template (appendix)
Generate yours in minutes with the TPRM Policy Generator — it produces all of the above mapped to your selected frameworks (ISO 27001 A.15, SOC 2 CC9.2, GDPR Art. 28, NIS2 Art. 21(d), HIPAA, PCI DSS).
Related tools: Vendor Risk Assessment Questionnaire · DPA Generator · Sub-Processor List Generator · NDA Generator · ISO 27001 Gap Assessment
Related reading: Vendor Risk Management Guide · SaaS Vendor Due Diligence Checklist · ISO 27001 vs SOC 2 for SaaS
⚠️ This guide is for informational purposes and does not constitute legal advice. Have your TPRM policy and contracts reviewed by qualified security and legal counsel before adoption.