Introduction
Third-party due diligence evidence for SOC 2 is the dated record that shows you reviewed a vendor before relying on it, and kept reviewing it: the questionnaire you sent and the answers you got, your notes on the vendor's SOC report, the security terms in the contract, the residual risk decision, and the monitoring that followed.
Most teams do some due diligence. The gap is usually the record. A security lead reads a vendor's SOC 2 report, decides it looks fine, and moves on. Months later, an auditor samples that vendor and asks what the reviewer checked, what they found, and who accepted the remaining risk. A PDF in a shared folder does not answer those questions.
Here is a concrete example. Your team adopts a customer support platform that will store customer emails. Before go-live, you send a questionnaire, receive the vendor's SOC 2 Type 2 report, and sign a data processing agreement. Strong evidence ties those pieces together in one file, with a reviewer name, a date, the findings, and an approved conclusion. Weak evidence is three attachments with no notes.
In plain language: this guide is a checklist for building a due diligence file that holds up in an audit. It covers questionnaires, SOC report review (including bridge letters and complementary user entity controls), contract security clauses, residual risk acceptance, and ongoing monitoring.
What Third-Party Due Diligence Evidence Means
Due diligence is the review you perform to decide whether a third party is acceptable for the access, data, or services involved. The evidence is everything that proves the review happened, what it covered, and what you decided.
A complete file for a higher-risk vendor usually answers six questions:
- Why does this vendor matter, and how risky is it?
- What did we ask the vendor, and what did they say?
- What independent assurance did we review, and what did it show?
- What security commitments does the contract include?
- What risk remains, and who accepted it?
- How are we watching the vendor now?
How This Guide Differs From Related Pages
AuditFlo has related pages with different jobs. Use them together.
| Page | Primary job | Use it when |
|---|---|---|
| What Is Third-Party Risk Management? | Defines the risk discipline: tiering, diligence depth, residual risk, monitoring | You need the concept and vocabulary |
| What Is Vendor Management? | Defines the operational lifecycle from inventory to offboarding | You need the relationship lifecycle |
| Vendor Management for SOC 2: Risk Reviews and Evidence | Program playbook: inventory, tiers, cadence, audit packet | You are building or running the vendor program |
| This guide | The contents of each vendor's due diligence file and how to prove each review step | You need to know what goes in the file and what good looks like |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include CC9.2: the entity assesses and manages risks associated with vendors and business partners. Points of focus under CC9.2 include establishing requirements for vendor engagements, assessing vendor risks, assigning responsibility for managing vendors, establishing exception handling procedures, assessing vendor performance, addressing issues found during vendor assessments, and implementing procedures for ending vendor relationships. Points of focus are illustrative, not a mandatory checklist.
The AICPA description criteria for a SOC 2 report also call for the service organization's system description to disclose complementary user entity controls and, when the carve-out method is used, the controls expected at subservice organizations. That is why reading those sections of a vendor's report is part of real diligence.
What is common practice, not a fixed SOC 2 rule:
- Sending a security questionnaire to every vendor
- Using a specific questionnaire, such as the Shared Assessments SIG or the Cloud Security Alliance CAIQ
- Requiring a SOC 2 Type 2 report from every vendor
- Annual re-review for all vendors
- A specific risk scoring model or tool
SOC 2 lets you define your vendor controls. Your auditor tests whether you followed them. If your policy says critical vendors get a questionnaire, a SOC report review, and annual re-review, the evidence must show all three for sampled vendors.
The Due Diligence File at a Glance
| File component | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Risk tier | Tier, reason, data and access involved | Tiering record with criteria and reviewer | A tier label with no reason |
| Questionnaire | Sent version, responses, follow-ups | Dated responses with reviewer notes on gaps | Unread responses in an inbox |
| SOC report review | Report, review notes, conclusion | Notes on scope, period, opinion, exceptions, and CUECs | The PDF alone |
| Bridge letter | Letter and date covered | Letter reviewed and filed with the report notes | No coverage for the gap months |
| Contract terms | Signed agreement, DPA, clause check | Clause checklist completed by a reviewer | A contract nobody checked for security terms |
| Residual risk decision | Decision, approver, expiry | Signed acceptance tied to the risk register | "Approved" in chat |
| Ongoing monitoring | Re-review dates, triggers, follow-ups | Calendar plus re-review tickets with outcomes | A renewal date with no review |
The sections below explain each component.
Security Questionnaires
A questionnaire collects the vendor's own description of its security practices. It is useful, but it is self-reported.
Scale it to risk. A low-risk tool with no customer data may need a short set of questions. A vendor that stores sensitive data or has production access may need a full questionnaire and a follow-up call.
What to keep:
- The questionnaire version you sent and the date
- The vendor's responses and the date received
- Your follow-up questions and the answers
- Reviewer notes on gaps, contradictions, or answers you checked against other documents
- The reviewer's name and the date of review
Good practice is to compare key answers with independent sources. If the vendor says it encrypts data at rest and enforces MFA for administrators, check whether its SOC report describes and tests those controls.
SOC Report Review
A vendor's SOC 2 report is often the strongest piece of independent assurance in the file. Filing it is not the same as reviewing it. A useful review records the following.
1. Scope matches the services you use
Check the system description. Confirm the report covers the product, service, and locations you actually rely on. A report on a different product line does not support your use case. See What Is a System Description?.
2. Report type and period
Note whether it is a Type 1 or Type 2 report, which Trust Services Categories are in scope, and the period or point in time covered. Record how many months have passed since the period ended.
3. The auditor's opinion
Read the service auditor's opinion. An unmodified opinion is the cleanest result. A qualified, adverse, or disclaimed opinion needs a written assessment of what it means for you.
4. Exceptions in testing
In a Type 2 report, read the tests of controls and results. Note each exception, the vendor's response if one is included, and whether the exception affects controls you rely on. An exception in a control that protects your data deserves a follow-up question.
5. Complementary user entity controls
Complementary user entity controls (CUECs) are controls the vendor assumes its customers will run. Common examples include managing your own user access to the vendor's product, reviewing admin accounts, and protecting your own credentials. List the CUECs that apply to you and map each one to a control you operate. If you cannot show that mapping, the vendor's controls may not fully work as described for your use.
6. Subservice organizations
Note any subservice organizations the report lists, such as a cloud hosting provider, and whether the report uses the carve-out or inclusive method. Under carve-out, the subservice organization's controls are excluded from testing, so you may need its report as well.
7. Your conclusion
Write a short conclusion: acceptable, acceptable with follow-ups, or not acceptable. Include the reviewer, date, and any actions.
A simple review note template:
- Vendor and service reviewed
- Report type, categories, and period
- Opinion type
- Exceptions noted and impact
- CUECs that apply and the matching internal controls
- Subservice organizations and method
- Conclusion, follow-ups, reviewer, and date
Bridge Letters
A bridge letter, also called a gap letter, covers the time between the end of a vendor's last SOC report period and today. It is a statement from the vendor's management, not the service auditor, that describes whether there have been material changes to controls since the period ended.
Because it is not audited, a bridge letter carries less weight than a report. It is still useful when a report period ended several months ago and the next report is not out yet.
What to keep:
- The letter, its date, and the period it covers
- A note linking it to the report it bridges
- A follow-up date to request the next report
If a vendor cannot provide a current report or bridge letter, record that as a gap and handle it through exception management rather than ignoring it.
When There Is No SOC Report
Not every vendor has a SOC 2 report. Alternatives can include:
- An ISO 27001 certificate, after checking its scope, issuing body, and validity dates
- A recent penetration test summary
- A detailed questionnaire with follow-up evidence, such as configuration screenshots or policy excerpts
- Compensating controls on your side, such as limiting the data shared or restricting the vendor's access
Record which alternative you accepted and why. A documented decision is stronger than a missing report with no explanation. See What Is a Compensating Control?.
Contract Security Clauses
The contract is where vendor commitments become enforceable. Legal owns the wording, but the security reviewer should confirm the key terms are present for higher-risk vendors. This is common practice, not legal advice.
Clauses reviewers often check:
- Security obligations, such as maintaining reasonable safeguards or a named standard
- Breach or incident notification, including timing
- Confidentiality of your data
- Use of subprocessors and notice of changes
- Data return or deletion when the relationship ends
- Assessment rights, such as access to reports or questionnaires on request
- Service levels for availability-critical services
What to keep:
- The signed agreement and any data processing agreement or security addendum
- A short clause checklist completed by the reviewer, with dates
- Notes on missing clauses and how the gap was handled
A clause that is missing from a contract you have already signed may still be manageable. Record the gap, the compensating step, and the plan to address it at renewal.
Residual Risk Acceptance
Diligence rarely ends with zero risk. Residual risk is what remains after you consider the vendor's controls, your own controls, and the contract. Someone with authority should accept it on the record.
A residual risk record usually includes:
- Vendor, service, and risk tier
- Key findings from the questionnaire, report review, and contract check
- Mitigations in place
- The residual risk rating or description
- The decision: accept, mitigate further, or do not proceed
- The approver, who should have authority under your policy
- An expiry or next review date
Link the record to your risk register when the risk is material. For evidence practices around registers and assessments, see Risk Register Evidence for SOC 2 and Risk Assessment Evidence for SOC 2.
Ongoing Monitoring Evidence
Due diligence is not a one-time event. Vendors change, reports expire, and incidents happen.
Monitoring evidence often includes:
- A re-review schedule by risk tier, written into your vendor policy
- Re-review tickets with outcomes and dates
- Tracking of SOC report and bridge letter expiration dates
- Notes on trigger events, such as a vendor security incident, an acquisition, or a major change in the data you share
- Follow-ups on open items from earlier reviews
Trigger-based reviews matter as much as scheduled ones. If a vendor announces a breach, a dated ticket showing your assessment and response is strong evidence. See incident management and Incident Response Evidence for SOC 2.
Example Scenario
A labeled hypothetical: a SaaS company adds a payroll provider that will hold employee personal data. The company's policy rates it as a critical vendor.
The due diligence file contains:
- A tiering record explaining the critical rating
- A completed questionnaire, with two follow-up questions about admin access answered in writing
- SOC 2 Type 2 review notes covering scope, period, an unmodified opinion, one exception in change management testing with the vendor's response, and three CUECs mapped to internal controls, including quarterly review of payroll admin users
- A bridge letter covering four months after the report period
- A signed agreement with breach notification and data deletion terms, plus a completed clause checklist
- A residual risk acceptance signed by the head of finance and the security lead, with a twelve-month expiry
- A calendar entry and ticket for the next annual re-review
During a Type 2 audit, the auditor samples this vendor. Every question about what was reviewed, what was found, and who decided has a dated answer.
Common Mistakes
- Filing a SOC report without review notes
- Reviewing a report that covers a different product or region than the one you use
- Ignoring exceptions in the vendor's testing results
- Never mapping CUECs to your own controls
- Accepting an expired report with no bridge letter or exception
- Treating a questionnaire as independent assurance
- Signing contracts with no security or breach notification terms
- Recording "approved" with no approver or expiry
- Doing diligence at onboarding and never again
- Applying the same deep review to every low-risk tool, which delays the reviews that matter
These gaps often show up as findings late in audit preparation. See Exception Management and Audit Findings Remediation.
Operating Model: Build a Repeatable Due Diligence File
1. Define what each tier requires
Write down which file components apply to each risk tier. Critical vendors may need every component. Low-risk vendors may need only a tier record and a short questionnaire.
2. Use templates
Create a standard questionnaire set, a SOC report review template, a clause checklist, and a residual risk acceptance form. Templates make reviews comparable.
3. Store the file in one place
Keep each vendor's file together in a system of record, such as your GRC platform, vendor tool, or ticketing system. Link everything to the vendor's inventory entry.
4. Record reviewers and dates
Every review step should show who did it and when. This is the detail auditors ask for most often.
5. Gate access on completion
For higher-risk vendors, require the file to be complete before the vendor receives production access or sensitive data. Record the approval.
6. Track expirations
Track report, bridge letter, certificate, and acceptance expiry dates. Request updates before they lapse.
7. Review vendor access inside your systems
Vendor accounts in your own tools also need review. See How to Run a SOC 2 User Access Review.
8. Run an internal sample
Before fieldwork, pick a few vendors and check that each file is complete for the period. Fix gaps, and record any late items honestly.
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors look at whether your vendor controls are suitably designed and in place at a point in time. Your vendor policy, templates, and a current file for key vendors support that.
For a Type 2 report, auditors test operation over the period. They may sample vendors onboarded during the period, critical vendors due for re-review, and vendors with expired reports. Dated files across the window matter more than a cleanup right before fieldwork. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Other Frameworks That Describe Due Diligence
SOC 2 is not the only source that describes these steps. Others can help you structure the file:
- The NIST Cybersecurity Framework (CSF) 2.0 includes outcomes for building security requirements into supplier contracts (GV.SC-05), performing planning and due diligence before entering a supplier relationship (GV.SC-06), and understanding, recording, assessing, and monitoring supplier risk over the course of the relationship (GV.SC-07). CSF is voluntary guidance.
- NIST SP 800-161 Rev. 1 gives detailed guidance on cybersecurity supply chain risk management practices.
- For banks, the 2023 interagency guidance on third-party relationships from the federal banking agencies outlines a third-party risk management life cycle that includes due diligence and ongoing monitoring.
Teams that also run ISO 27001 often reuse one due diligence file across programs through control mapping.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For due diligence, that can mean dated history for vendor review tickets, approvals, and follow-ups, so you can show when each review happened and who closed it. Your GRC platform or vendor tool remains the system of record for questionnaires, SOC reports, and risk decisions. AuditFlo does not assess vendors, does not score vendor risk, does not review SOC reports for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Third-party due diligence evidence is the proof behind your vendor decisions. For each higher-risk vendor, keep a file that shows the tier, the questionnaire and follow-ups, a real SOC report review with exceptions and CUECs addressed, any bridge letter, the contract security terms, a residual risk decision with an approver and expiry, and ongoing monitoring. SOC 2 does not dictate the exact components, so write your requirements by tier, follow them, and keep dates and names on every step.
If you are building the broader program, start with Vendor Management for SOC 2: Risk Reviews and Evidence, What Is Third-Party Risk Management?, and how to prepare for a SOC 2 audit.
FAQ
Does SOC 2 require a vendor security questionnaire?
No. CC9.2 addresses assessing and managing vendor risks, but it does not require a specific method. Many teams use questionnaires because they are practical. If your policy requires them, keep evidence that you sent, received, and reviewed them.
Is a vendor's SOC 2 report enough due diligence?
Often not by itself. You still need to confirm the report covers your services, read the opinion and exceptions, map the CUECs to your controls, and record a conclusion. Contract terms and residual risk decisions are separate steps.
What is a bridge letter, and does it replace a SOC report?
A bridge letter is a statement from the vendor's management about the period after its last SOC report ended. It is not audited and does not replace a report. It helps cover the gap until the next report is issued.
What are CUECs, and why do they matter?
Complementary user entity controls are controls the vendor expects its customers to operate, such as managing your own user access to the vendor's product. If you do not run them, the vendor's controls may not work as described for your use. Map each relevant CUEC to one of your controls.
Who should approve residual vendor risk?
Someone with authority under your risk policy, often the business owner together with security or a risk committee for critical vendors. Record the name, date, decision, and expiry.
How often should we redo due diligence?
Follow your written policy by risk tier, and add trigger-based reviews for events such as vendor incidents, acquisitions, or new data sharing. SOC 2 does not set a frequency. Many teams re-review critical vendors at least annually.
Does AuditFlo perform vendor due diligence?
No. AuditFlo helps organize dated evidence from systems you already use. It does not assess vendors, review their reports, or replace your auditor.