Vendor Risk (TPRM) for SaaS: What Procurement Expects

Every SaaS product is built on other SaaS products. Your application runs on AWS or GCP. Payments flow through Stripe. Customer data passes through Segment, gets stored in Snowflake, and gets analyzed in Looker. Your authentication layer depends on Auth0 or Okta. Your alerting depends on PagerDuty or Datadog.

Each of these vendors is a link in your security chain. If one of them suffers a breach, your customers' data is exposed, and your organization bears the responsibility. Enterprise buyers know this. That is why vendor risk management, often called Third-Party Risk Management (TPRM), has become a standard component of procurement security reviews and compliance audits.

This article covers how to build a TPRM program that satisfies auditors and enterprise buyers, how to tier vendors by risk, the assessment workflow, continuous monitoring, and how your TPRM program feeds into your own audit readiness.

Why Vendor Risk Matters for SaaS

SaaS companies face vendor risk from two directions. You need to manage the risk of your own vendors (the services you depend on), and you need to satisfy the vendor risk requirements of your customers (the enterprises buying your product).

The Compliance Mandate

SOC 2 CC9 (Risk Mitigation) requires evidence that you assess and manage risks from third-party vendors. ISO 27001 tests controls A.5.19 through A.5.23 (Supplier relationships and cloud services). GDPR Article 28 requires you to document and manage subprocessors with appropriate contractual safeguards.

If you cannot demonstrate that you assess and monitor your vendors, you will receive audit findings and procurement rejections. This is not a theoretical risk — it is one of the most common findings in SOC 2 audits for SaaS companies.

The Operational Reality

Beyond compliance, vendor risk is operational risk. A misconfigured third-party integration can expose customer data. A vendor's security incident becomes your security incident. A vendor that quietly changes their data handling practices can put you in violation of your own privacy commitments.

The 2023 MOVEit breach demonstrated this clearly: a vulnerability in a single file transfer vendor cascaded across thousands of organizations that relied on it. Managing vendor risk is about protecting your business, not just passing audits.

Vendor Tiering Model

Not every vendor requires the same level of scrutiny. A vendor that processes customer PII requires deeper assessment than one that provides an internal wiki with no customer data exposure. Tiering vendors by risk level allocates your limited security resources where they matter most.

Tier 1: Critical

These vendors have direct access to customer data, host critical infrastructure, or would cause significant operational disruption if compromised.

Examples: cloud providers (AWS, GCP, Azure), primary database services, payment processors (Stripe, Braintree), authentication providers (Okta, Auth0), analytics platforms processing user data (Segment, Amplitude), email delivery services (SendGrid, SES).

Assessment requirements: full security review including SOC 2 report review, security questionnaire, DPA with Article 28 compliance, annual reassessment, and continuous monitoring. Review penetration test summaries for Tier 1 vendors where available.

Tier 2: Important

These vendors have limited access to sensitive data or support important but non-critical functions.

Examples: monitoring tools (Datadog, New Relic), CI/CD platforms (GitHub, GitLab), project management (Jira, Linear), customer support platforms (Zendesk, Intercom), HRIS (BambooHR, Rippling).

Assessment requirements: SOC 2 report review or equivalent documentation, DPA where personal data is processed, reassessment every 18 to 24 months.

Tier 3: Standard

These vendors do not access customer data and present minimal risk.

Examples: internal collaboration tools with no customer data (Notion for internal docs, Figma for design), office productivity (Google Workspace if not processing customer data), development tools (VS Code extensions, Postman).

Assessment requirements: basic due diligence at onboarding (verify security page, privacy policy, no history of major breaches). Reassess at contract renewal.

Tiering Criteria

Use four dimensions to tier vendors: data access (does this vendor touch customer data, employee data, or no sensitive data), service criticality (would a failure disrupt your product or operations), integration depth (API integration, embedded SDK, or standalone tool), and regulatory exposure (does this vendor's processing trigger GDPR, HIPAA, or other regulatory requirements).

Score each dimension 1-3. Total score determines tier: 8-12 is Tier 1, 5-7 is Tier 2, 4 is Tier 3.

Due Diligence Workflow

For Tier 1 and Tier 2 vendors, your assessment process should follow a structured workflow from intake to approval.

Step 1: Intake

When any team wants to adopt a new vendor, they submit a vendor intake form: vendor name, service description, data access requirements, business justification, and contract terms. This ensures no vendor enters the environment without assessment.

Step 2: Tiering

Apply the tiering criteria based on the intake form. The security or compliance team determines the assessment level required.

Step 3: Evidence Collection

For Tier 1 vendors, collect: SOC 2 Type II report (review the auditor's opinion, exceptions noted, and trust service criteria covered), ISO 27001 certificate (verify current status and scope), security questionnaire responses (SIG Lite or CAIQ for vendors without SOC 2), DPA signed by both parties, penetration test executive summary, incident history (has the vendor experienced a breach in the past 24 months), and business continuity documentation.

For Tier 2 vendors: SOC 2 report or equivalent, DPA if personal data is involved, and basic security documentation review.

Step 4: Evaluation

Do not just collect documents and file them. Review each piece of evidence against specific criteria.

Does the SOC 2 report contain qualified opinions or material exceptions? Are the trust service criteria in the report relevant to the services you use? Does the vendor's data handling align with your commitments to your own customers? Are there red flags in questionnaire responses (no MFA, no encryption at rest, no incident response plan, no backup testing)?

Document your evaluation with a risk rating (acceptable, acceptable with conditions, unacceptable) and any follow-up items.

Step 5: Approval and Onboarding

For acceptable vendors, approve onboarding and add them to the vendor register. For vendors with conditions, document the conditions (e.g., "vendor must complete SOC 2 Type I by Q3 2026") and track remediation. For unacceptable vendors, reject and recommend alternatives.

Red Flags During Assessment

Missing SOC 2 or ISO 27001 with no clear remediation timeline. Unwillingness to complete a security questionnaire. DPA terms that deviate from Article 28 requirements without justification. No incident response plan. No encryption at rest. Shared credentials or no MFA. No backup testing evidence.

Continuous Monitoring

An annual vendor assessment is necessary but not sufficient. Risks change between assessment cycles.

Security Ratings Platforms

Tools like SecurityScorecard, BitSight, and RiskRecon provide continuous external risk monitoring. They scan vendors' internet-facing infrastructure for vulnerabilities, misconfigurations, and compromised credentials. These platforms generate a security score that can trigger reassessment if a vendor's score drops below your threshold.

For most SaaS companies with fewer than 50 vendors, these platforms are optional. For companies with 50+ vendors or those in heavily regulated industries, the automation justifies the cost.

Monitoring Without a Platform

For smaller programs, structured manual monitoring works. Subscribe to vendor security advisories and status pages. Set Google Alerts for vendor names combined with "breach," "incident," or "vulnerability." Track SOC 2 report expiration dates and request updated reports annually. Subscribe to vendor subprocessor change notifications (GDPR requires processors to provide these). Monitor vendor changelogs for changes that affect security posture.

Reassessment Triggers

Beyond the scheduled reassessment cycle, these events should trigger an immediate review: vendor reports a security incident, vendor SOC 2 report contains new exceptions or qualified opinions, vendor changes ownership (acquisition, merger), vendor changes data processing locations, vendor modifies terms of service affecting data handling, your own risk assessment identifies new threats related to the vendor, and regulatory changes affecting the vendor's operating environment.

Subprocessor Management for GDPR

GDPR Article 28 imposes specific requirements on how you manage subprocessors — vendors that process personal data on behalf of your customers.

DPA Requirements

Every subprocessor DPA must include: subject matter and duration of processing, nature and purpose, type of personal data and categories of data subjects, controller's obligations and rights, and specific processor obligations (security measures, sub-processor restrictions, DSAR assistance, data return/deletion at contract end, audit rights).

When vendors insist on their own DPA template, compare it against Article 28 requirements and flag gaps. Common gaps: missing audit rights, vague security commitments, no subprocessor notification obligation, and no data deletion commitment at contract end.

The Subprocessor List

Your subprocessor list is a procurement artifact that enterprise buyers request in every deal. Include: subprocessor name, location (country), categories of data processed, processing purpose, DPA status (signed/pending), and date of last security assessment.

Publish it on your trust page and update it whenever you add or remove a vendor. This transparency accelerates procurement reviews.

Notification Obligations

When you add a new subprocessor, check every customer DPA for notification requirements. Some require prior written consent, others require advance notice with an objection window (typically 30 days).

Build a notification workflow: maintain a list of customers with notification obligations, draft the notification, send it with the required notice period, track responses and objections. Failure to notify is a DPA breach, which creates contractual and regulatory liability.

Vendor Offboarding

When a vendor relationship ends, offboarding needs to be as structured as onboarding. Data left in a former vendor's systems after contract termination is an uncontrolled risk.

Offboarding Checklist

Confirm data deletion or return: request written confirmation that the vendor has deleted all your data (and your customers' data) from their systems, including backups. Define a deletion timeline — most DPAs specify 30 to 90 days for post-termination deletion.

Revoke access: disable all API keys, OAuth tokens, SSO connections, and service accounts associated with the vendor. Remove the vendor from your identity provider groups.

Update documentation: remove the vendor from your subprocessor list, vendor register, and any customer-facing documentation. Send subprocessor change notifications to affected customers.

Verify deletion: request a deletion certificate or written confirmation from the vendor. For critical vendors, consider requesting audit evidence of deletion.

Archive assessment records: keep the vendor's assessment history (SOC 2 reports, questionnaire responses, DPA) for your retention period. This evidence may be needed for audit questions about historical vendor relationships.

Building TPRM Evidence for Your Own Audits

Your TPRM program produces evidence that directly feeds your SOC 2 and ISO 27001 audits.

SOC 2 CC9 Evidence

For the SOC 2 evidence checklist under CC9, prepare: vendor management policy defining assessment methodology, vendor register with tier classifications and assessment dates, completed vendor assessments for Tier 1 and Tier 2 vendors, vendor SOC 2 reports on file, DPAs for vendors processing personal data, evidence of annual reassessment (dated assessment reports), and vendor management review meeting notes.

ISO 27001 Annex A Evidence

For A.5.19 (information security in supplier relationships): your vendor management policy and assessment procedure. A.5.20 (addressing security within supplier agreements): DPAs and security terms in vendor contracts. A.5.21 (managing information security in the ICT supply chain): evidence that you assess your vendors' vendors (their SOC 2 reports cover this). A.5.22 (monitoring, review, and change management of supplier services): your continuous monitoring records and reassessment evidence. A.5.23 (information security for use of cloud services): specific cloud security assessments for AWS, GCP, or Azure.

Cross-Framework Efficiency

The same vendor assessment satisfies SOC 2, ISO 27001, and GDPR requirements. A single assessment of AWS covers CC9 vendor management, A.5.19-A.5.23 supplier management, and Article 28 processor obligations. Build the assessment once, tag the evidence for each framework, and avoid duplicating work.

Building the Program Incrementally

If you do not have a TPRM program today, do not try to build everything at once. Start with the highest-risk vendors and expand.

Week 1-2: complete your vendor inventory and identify Tier 1 vendors. Week 3-4: collect SOC 2 reports and DPAs from all Tier 1 vendors, send questionnaires to Tier 1 vendors without SOC 2 reports. Month 2: evaluate Tier 1 documentation, document findings and risk ratings. Month 3: expand to Tier 2 vendors, establish the reassessment calendar. Month 4 onward: formalize the vendor assessment procedure, set up monitoring, integrate with procurement.

This approach produces a functional program within 90 days while prioritizing the vendors that present the greatest risk. For a detailed look at how to manage the security questionnaire side of vendor assessments (both sending and receiving), see our playbook.

Getting Started

Vendor risk management is a core component of every compliance framework your SaaS company will encounter. Building a proportional, documented, and repeatable TPRM program protects your organization from third-party risk and satisfies the vendor management requirements of SOC 2, ISO 27001, and GDPR simultaneously.

Start with the vendor inventory. You cannot manage risk for vendors you do not know about. Then tier them, assess the critical ones, and build the cadence. Within one quarter, you will have a program that passes audits and impresses procurement teams.

CertifyOps helps SaaS companies build and operationalize TPRM programs that integrate with their existing compliance framework. If you need to stand up vendor risk management or strengthen your existing program, reach out to discuss your requirements.