Vendor & Third-Party Risk Management for SOC 2

What does SOC 2 CC9.2 actually require for vendors?

CC9.2 sits in the Risk Mitigation criteria and obligates you to assess and manage risks arising from vendors and business partners. In practice the Trust Services Criteria expect a repeatable lifecycle: due diligence before you grant access, a risk-based tier that sets how deep you look, ongoing monitoring proportional to that tier, and a formal offboarding step that revokes access and confirms data return or destruction.

Scope covers anyone who processes, stores, transmits, or can reach your in-scope production data or systems: cloud infrastructure, your CI/CD pipeline, an email provider handling customer PII, a support tool with session replay, a contractor with admin credentials. A vendor that only sees marketing analytics is a different risk class than one holding your database. Your program has to make that distinction explicit rather than treat every SaaS logo the same.

• Due diligence before onboarding: security questionnaire or SOC 2 review, data-flow mapping, and a documented risk decision.
• Risk tiering that drives review depth and monitoring cadence.
• Ongoing monitoring: annual re-review for critical vendors, report collection, and bridge-letter tracking.
• Offboarding: access revocation tied to your joiner/mover/leaver process, plus confirmation of data return or deletion.

How do I do vendor due diligence before onboarding?

Start before the contract is signed, because that is the last moment you hold real leverage. For a vendor that will touch in-scope data, request their current SOC 2 Type II report (or ISO 27001 certificate plus Statement of Applicability), a completed security questionnaire, and evidence of the basics you enforce internally: MFA, least privilege, encryption in transit and at rest, and a breach notification commitment. If they can only produce a SOC 2 Type I, note the limitation. A Type I attests control design at a point in time, not operating effectiveness over a period, so it carries far less assurance than a Type II covering a 6- or 12-month window.

Record a risk decision for every vendor, including the low ones. The decision names the data classification, the tier, the controls you relied on, any exceptions or qualified opinion in their report, and who approved onboarding. That memo is the artifact proving due diligence happened; a folder of downloaded PDFs with no analysis is not.

• Classify the data the vendor touches (public, internal, confidential, regulated/PII).
• Collect assurance: SOC 2 Type II preferred; Type I, ISO 27001, or a completed questionnaire as fallbacks.
• Confirm table-stakes controls: MFA, SSO and least privilege, AES-256 at rest, TLS 1.2+ in transit, breach notification terms.
• Write and approve a documented risk decision; this is your CC9.2 evidence.

How do I review a vendor's SOC 2 report and bridge letter?

Do not just confirm the report exists; read it. Check the report type and the service auditor's opinion first. An unqualified (clean) opinion is what you want; a qualified opinion means the service auditor found a control that failed testing, and you need to judge whether it affects you. Confirm the period covered and the Trust Services Categories in scope. Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are optional and only appear if the vendor selected them. Then read the exceptions in the testing tables and the management responses. A vendor with three access-review exceptions and a hand-wave response is telling you something.

Because a Type II report covers a past period, there is almost always a gap between the report's end date and your review date. You close that gap with a bridge letter (also called a gap letter): a short attestation from the vendor stating that no material changes to its control environment occurred between the report period-end and the current date. A bridge letter typically covers up to about three months; if the gap runs longer, ask for the next report rather than accept a stale attestation.

• Report type and opinion: Type II with an unqualified opinion is the baseline; scrutinize any qualification.
• Period and scope: confirm the coverage window and which Trust Services Categories are included.
• Exceptions and management responses: read the testing results, not just the summary.
• Bridge letter: obtain one to cover the gap between report period-end and today; treat gaps beyond ~3 months as unacceptable.

What are subservice organizations and CUECs, and why do they matter?

Your vendors have vendors. When a SaaS you rely on runs on AWS, AWS is a subservice organization to that vendor, and their SOC 2 report will either carve out AWS (excluding it from their controls and pointing you to AWS's own report) or use the inclusive method (testing it within scope). Under the carve-out method you inherit responsibility for confirming the subservice organization is covered: obtain AWS's SOC 2 and check the complementary subservice organization controls the vendor expects AWS to perform. For critical infrastructure, expect assessors to ask about this fourth-party awareness.

The part teams most often miss is complementary user entity controls (CUECs). Nearly every vendor SOC 2 report includes a section listing controls the vendor assumes you operate for its controls to be effective: that you configure SSO correctly, enforce MFA on your side, run your own user provisioning and quarterly access reviews, and restrict admin roles. These CUECs are your responsibility, not the vendor's. If you never mapped them, you have an unowned control gap, and CC6.1 through CC6.3 (logical access) is exactly where it surfaces. Extract the CUEC list from each critical vendor's report, map each item to a control you actually run, and keep the evidence.

• Subservice organization: a vendor's vendor (e.g., AWS under your SaaS); confirm it is carved out or inclusive, and collect its report if carved out.
• CUECs: the controls the vendor's report assumes you run; you own these outright.
• Common CUECs you own: MFA enforcement, user provisioning and deprovisioning (joiner/mover/leaver), quarterly access reviews, encryption key management, and timely offboarding.
• Map every critical vendor's CUECs to a named internal control with evidence; unmapped CUECs become findings.

How should I tier vendors by risk?

Tiering keeps the program proportionate so diligence effort lands where the exposure is. Score each vendor on data sensitivity, system access, and business criticality, then sort into three or four tiers. Critical (Tier 1) vendors, those with production data access or that would halt operations if they failed, get a full SOC 2 review, annual re-assessment, bridge-letter tracking, and CUEC mapping. Moderate (Tier 2) vendors get a questionnaire and a lighter annual check. Low (Tier 3) vendors with no sensitive data may need only an inventory record and a renewal-time glance.

Write the tiering criteria down and apply them consistently. An assessor will test whether your tier assignments match the criteria and whether the monitoring cadence you promised actually happened. A Tier 1 vendor whose last review was two years ago is a control failure regardless of how the vendor is doing.

• Tier 1 (Critical): production data or access; full SOC 2 review, annual re-assessment, bridge letters, CUEC mapping.
• Tier 2 (Moderate): limited sensitive data; security questionnaire and annual lightweight review.
• Tier 3 (Low): no sensitive data; inventory record and renewal-time review.
• Document the scoring logic so tier assignments are defensible and repeatable.

What evidence will an assessor want to see?

For a Type II examination the assessor samples across your review period, so the program has to have operated all year rather than been assembled the week before fieldwork. Expect them to pull a sample of vendors from your inventory and trace each one through the lifecycle: onboarding due diligence, the collected report and bridge letter, the risk decision, and evidence that monitoring occurred on the cadence your policy states.

The strongest evidence is a maintained vendor inventory with tiers, dated review records, and CUEC mappings, backed by the underlying reports and letters. Gaps that reliably draw findings: a critical vendor with an expired SOC 2 report and no bridge letter, CUECs that were never mapped to an internal control, a vendor onboarded with no documented risk decision, and a tiering policy that exists on paper but was never applied.

• A current vendor inventory with tier, data classification, and owner for each entry.
• The vendor's SOC 2 report (or ISO 27001 certificate) plus a bridge letter closing any period gap.
• A dated risk decision per vendor showing what you relied on and who approved it.
• CUEC mappings linking each critical vendor's expected user controls to a named internal control with evidence.
• Proof of monitoring on the stated cadence: annual re-reviews for Tier 1, plus offboarding records showing access revocation.

SOC 2 CC9.2 is satisfied by a documented, risk-tiered vendor lifecycle: due diligence before onboarding, reading (not just collecting) each critical vendor's SOC 2 report with a bridge letter closing any gap, tracking subservice organizations, and mapping every CUEC to an internal control you own. The assessor wants dated evidence that this ran all year, not a folder assembled before fieldwork.