Vendor Due Diligence for SOC 2 and DPA: What to Actually Check

Your new analytics vendor just sent over a pre-signed DPA and a PDF of their SOC 2 Type II report. Your first instinct is to countersign and move on. That instinct is wrong—and auditors know it.

Signing a vendor into your compliance perimeter without actually reading what they've sent you is one of the most common ways a small engineering team ends up with a finding on their first SOC 2 audit, or a regulator inquiry after a data breach traced to a third party. The vendor questionnaire they filled out is self-attested. The SOC 2 report has a scope section almost nobody reads. The DPA may reference subprocessors you've never heard of who are based in jurisdictions your own privacy policy prohibits.

This post walks through what to check, in what order, before you sign anything.

---

Why Vendor Review Is Now a Hard Requirement—Not a Courtesy

SOC 2 doesn't mandate a specific vendor risk program, but the AICPA Trust Services Criteria (CC9.2 in particular) require that you "assess and manage risks associated with vendors and business partners." In practice, every auditor will ask for your vendor inventory and some evidence that you've reviewed each in-scope vendor. "They sent us a SOC 2" is not evidence of review; it's evidence of receipt.

Under GDPR, the obligation is more explicit. Article 28 requires that before you engage a processor, you must conduct "sufficient guarantees" assessment—that the vendor will implement "appropriate technical and organisational measures." The European Data Protection Board's guidance on Article 28 makes clear this is a substantive inquiry, not a checkbox. If you're operating under CCPA, the California Privacy Rights Act similarly requires contractual controls and ongoing oversight of service providers.

Small teams usually get caught in the same three traps:

1. Trusting the questionnaire. Security questionnaires (SIG, CAIQ, homegrown) are self-reported. A vendor can fill one in incorrectly, optimistically, or based on aspirational controls they haven't actually implemented.
2. Reading the SOC 2 cover page, not the report. The opinion page says "Type II, unqualified." The scope section says "excluding our EU infrastructure." That's the infrastructure your data lives on.
3. Accepting DPAs without verifying the subprocessor list. Most DPAs include language permitting the vendor to use subprocessors "as listed on our website." That list changes. Sometimes without notice.

---

Step 1: Define Scope Before You Review Anything

Before you open a single document, answer two questions:

Does this vendor touch personal data you're responsible for? If yes, you need a DPA (under GDPR/UK GDPR) or a Data Processing Addendum (under CCPA). If they're a "controller" in their own right—making decisions about the data—you may need a data-sharing agreement instead, which has different legal mechanics entirely.

Does this vendor have access to systems or data in your SOC 2 scope? If yes, they are a "subservice organization" and your auditor will want to see your review of their controls. If they're excluded from scope but have network access to in-scope systems, that's a gap you need to document and explain.

Getting this wrong upfront means doing the whole review twice. Build a one-column spreadsheet: vendor name, data access (yes/no), data categories, systems accessed, SOC 2 in-scope (yes/no). Thirty minutes now saves three weeks later.

---

Step 2: Read the SOC 2 Report—Actually Read It

A SOC 2 Type II report has four sections that matter. Most people read one of them.

Section 1: The Auditor's Opinion

This is the cover page. Unqualified is good. Qualified means the auditor found exceptions they couldn't overlook. An adverse opinion is rare and disqualifying. Read this, but don't stop here.

Section 2: The System Description

Written by management, not the auditor. It tells you what the vendor says their environment looks like—what's in scope, what's excluded, which data centers, which subservice organizations they rely on. Read the exclusions. If their SOC 2 covers "production systems in US-EAST-1 only" and your data is in their EU region, this report tells you nothing useful about your data.

Section 3: The Controls and Tests of Operating Effectiveness

This is where auditors list what they actually tested and what they found. Look for "exceptions noted." An exception means a control failed—either it wasn't in place when it was supposed to be, or it didn't work the way it was designed to. One exception on MFA enforcement during a 12-month period means someone got in (or could have) without MFA. Ask the vendor what happened and what they changed.

Section 4: Complementary User Entity Controls (CUECs)

Almost always skipped. CUECs are controls the vendor has explicitly designed you to implement on your end for their controls to work. If a vendor's SOC 2 says "user entities are responsible for configuring role-based access controls," and you haven't done that, their clean report doesn't cover your exposure. Map every CUEC to whether you've actually implemented it.

---

Step 3: Verify the DPA Against Your Own Privacy Policy

Most small teams sign whatever DPA the vendor sends. Here's the minimum you need to check:

Lawful transfer mechanism. If you're sending EU personal data to a US vendor, how is that transfer authorized? The EU-US Data Privacy Framework (DPF) is the current mechanism for certified US companies. Standard Contractual Clauses (SCCs) are the fallback. Check whether the DPA actually references a valid mechanism, and if SCCs, whether they use the 2021 SCCs—the pre-2021 versions are no longer valid.

Subprocessor list and change notice. Every DPA should name subprocessors or link to a public list. More importantly, it should specify how much notice the vendor gives you before adding a new one, and whether you have a right to object. Thirty days is reasonable. "We'll update the website" with no notice period is not.

Data retention and deletion. When you terminate the contract, what happens to your data? Within what timeframe? In what format? The DPA should specify deletion timelines—typically 30–90 days—and whether you get a certificate of deletion. "We'll delete it" without a timeline is unenforceable.

Breach notification. GDPR requires you to notify your supervisory authority within 72 hours of becoming aware of a breach. Your vendor needs to tell you fast enough for that to be possible. The DPA should require vendor notification within 24–48 hours of confirmed breach discovery—not 72, not "promptly."

Audit rights. Article 28(3)(h) requires that the vendor allow you to conduct audits. Many DPAs replace this with "the vendor will provide audit reports on request." That's weaker, but acceptable in practice for most small teams—as long as the language actually gives you access to the reports, not just the right to ask for them.

---

Step 4: Check the Vendor's Public Record

The documents the vendor sends you are curated. What they haven't sent you is often more useful.

Regulatory enforcement history. The FTC's database of actions includes data security cases. The HHS Office for Civil Rights breach portal lists healthcare data breaches—relevant if your vendor touches any PHI or data about health-adjacent services. EU regulators publish enforcement decisions via the EDPB enforcement tracker.

Corporate structure. Who actually owns this vendor? A small SaaS company with a parent entity in a jurisdiction with weak data protection laws may be subject to government data access requests that your DPA can't prevent. Look up the corporate tree via OpenCorporates or your state's Secretary of State registry. This matters more than most teams think—the Schrems II ruling invalidated the old Privacy Shield partly because US surveillance law could override contractual protections.

Sanctions and watchlists. If your vendor has operations in sanctioned jurisdictions, or if key individuals appear on OFAC's SDN list or equivalent EU/UN lists via OpenSanctions, you have potential violations beyond just compliance—you could be facilitating prohibited transactions. For most vendors this is low probability; for vendors with offshore engineering teams or foreign parent companies, it's worth five minutes to check.

Recent news. A structured database search is better than a Google search here, but at minimum: search the company name plus "breach," "lawsuit," "FTC," "GDPR fine" in the past 24 months. A vendor who had a breach two years ago isn't automatically disqualified—how they responded matters. A vendor who had a breach and quietly settled without disclosing it to customers is a red flag.

---

Step 5: Ask Three Questions in Writing

After reviewing everything, send the vendor three questions and keep the responses:

1. "Have you had any security incidents affecting customer data in the past 24 months? If yes, please summarize what happened and what changed." Most reputable vendors will answer honestly. Evasion is informative.

2. "Please confirm your current list of subprocessors who may process [data category] data, and your current notice period for adding new ones." This forces them to be specific and gives you a baseline to compare against if something changes later.

3. "Please confirm which Complementary User Entity Controls from your SOC 2 report you consider applicable to our environment." This one surprises vendors who aren't used to sophisticated customers. The answer tells you a lot about whether their compliance team has actually read their own report.

Document the responses. Your auditor will want to see that you asked.

---

What "Good Enough" Actually Looks Like for a Small Team

You don't need a GRC platform and a dedicated vendor risk analyst. You need:

• A spreadsheet with every vendor, their data access, and their review status.
• A file folder (Notion page, Google Drive folder, whatever) per in-scope vendor with: the signed DPA, the current SOC 2 report, your notes on the review, and any written correspondence.
• An annual calendar reminder to request updated SOC 2 reports and check the subprocessor list.
• A documented process—even a one-paragraph SOP—so your auditor can see you're doing this intentionally, not ad hoc.

That's it. The goal isn't perfection; it's demonstrable, repeatable diligence. Auditors and regulators are looking for evidence that you took the obligation seriously. A well-maintained folder of vendor records is more persuasive than an elaborate process with no documentation.

---

The Part That Usually Gets Skipped

Most vendor review processes handle the obvious vendors: the AWS, the Stripe, the Salesforce. The gaps are almost always in the long tail—the A/B testing tool someone added last quarter, the AI writing assistant with an API key that touches customer data, the freelance developer who got added to the production database "temporarily" six months ago.

If you're building your vendor inventory for the first time, the honest question isn't "did we review all our vendors?" It's "do we actually know who all our vendors are?" That audit of your own SaaS spend, your SSO-connected apps, and your engineering team's API keys is the real first step—and it's often the most surprising one.

Run that list first. Then review it.