On this page
A recent Verizon data breach investigation report read that third-party vendors were involved in 30% of data breaches at the end of October 2025, almost double the previous year's record. If you are moving up-market, this number changes how you vet software. Every new tool that connects employee or customer data becomes part of your attack surface.
Yet, most of you restrict your reviews to badges. Notice a SOC 2-compliant logo or a vague GDPR ready claim without signed agreements, and you are ready to go with the tool. But badges don’t tell you if the report is current, whether a valid Article 28 DPA is in place, or if it covers the exact environment you plan to use to host the data.
Enterprise deals aren’t cleared on a security page alone. It's cleared when Vendor Risk Management signs off, and VRM teams read the audit scope, sub-processor lists, and breach SLA in detail. The real risk is a hidden liability that shows up only after an incident.
This guide gives you a comprehensive framework comprising three verification steps and a five-question internal survey. Run it before granting any vendor access to your systems and turn invisible risk into a clear go or no-go gate.
› SOC 2 vs. GDPR: The Core Pillars You're Actually Vetting For
SOC 2 and GDPR often share one line item on your vendor’s checklist. But they are different. One proves how your vendor operates, and the other governs what is legally allowed with the data that belongs to EU citizens. This is where most deals stall.
SOC 2 Type II is an operational audit that tells you if the vendor’s security controls held up over a 6–12-month window or just on the day when someone planned the architecture. GDPR is a legal regime, and you won’t find proof of this compliance in a certificate. What you must check is if Article 28 Data Processing Addendum and the documented sub-processor list are signed and whether it is legal to move data across borders.
Here’s what you shouldn’t miss in your review: the scope. A SOC 2 report may be completely accurate but still leave out the most useful parts if it covers only the vendor’s corporate IT environment and not the actual cloud environment hosting the data.
So, before you read the controls, confirm what system the report in your hand is describing.
| Framework | What It Proves | What to Inspect |
| SOC 2 Type II | Operational security, availability, and processing integrity. It is verified over 6-12 months. | Confirm the audit scope covers the exact environment hosting your data and check the auditor’s opinion for exceptions |
| GDPR Compliance | Lawful, transparent, and secure processing of EU personal data | Confirm a signed Article 28 DPA, a current sub-processor list, and documented cross-border transfer safeguards |
This should be your first filter in a SOC 2 GDPR software vetting checklist. If the scope doesn’t match your data flow, the remaining parts of the report won’t save your deal either.
› The SOC 2 GDPR Software Vetting Checklist: Three Steps Before You Grant Access
The three-step framework helps you vet the third-party software you are considering before connecting it to your database.
» Step#1: Authenticate SOC 2 Type II Report
Get a full SOC Type II report under NDA instead of settling for a one-page summary or website badge. You need a detailed system description, the Trust Services Criteria tested, and the auditor’s opinion.
The details mentioned in the report will confirm whether it contains only corporate environment details or the hosting environment as well.
Check the observation period carefully. If the report is older than 12 months without a bridge letter, it is considered effectively expired for enterprise purposes.
In case there is a bridge letter, make sure it is signed by the vendor’s management and not the auditor. It should clearly state there haven’t been any material control changes since the last report.
- Treat the bridge letter beyond approximately 3 months with no renewal date as a red flag
- Don’t accept Type I in place of Type II. Type I checks design for one day, while Type II checks if controls worked for the months.
- Verify if the system description matches your use case
- Scan for exceptions and remediation timelines. Always ask for context on high-severity findings
» Step#2: Map the Trust Services Criteria to Actual Risk
Security should be in scope always. If the vendor handles sensitive IP or secrets, add a confidentiality feature. If the software touches customer or employee PII, you must check privacy as well. A vendor covering only security while processing PII has a gap that you will inherit.
Ask for exception details instead of a pass/fail summary. One exception mentioned with a clear remediation plan is normal in a mature program. If there is a pattern of unresolved or recurring exceptions, it suggests control fatigue or understaffed security.
- Confirm controls tested actually cover the services you will use, like auth, data export, APIs, and backups
- If privacy is in scope, verify how they handle retention, data subject requests, and deletion.
- Look for alignment between TSC and your internal risk register. If you ignore top risk during audit, it becomes your problem.
» Step#3: Audit GDPR Data Flow and Sub-Processors
Confirm a signed Article 28 DPA exists before onboarding and moving any data. GDPR runs on contracts. That’s why the DPA should explicitly mention all categories of PII you will send, define processing purposes, and set clear security and breach notification obligations.
Get the current sub-processor list and ask how they will notify you regarding changes. Confirm if data is actually stored and processed and what safeguards cover cross-border transfers.
If the answer you get is “we use AWS so we are compliant by default,” that becomes the inherited compliance fallacy.
- Check the breach notification SLA. If it is vague or slower than the compliance obligations you need, it becomes your problem when something goes wrong.
- Ask for their incident response playbook summary. It should mention who gets notified, in what timeline, and what evidence you will receive.
- Validate data residency commitments against your internal policy. For example, EU data staying in EU regions only.
- Ensure the DPA covers all PII categories you may send. Avoid software that uses generic language without examples backing it.
All these three steps are core to your SOC 2 GDPR software vetting checklist. Follow them before you grant any vendor access to employee or customer databases.
› The Five-Question Internal Survey
Turn this checklist into something you can actually use: a five-question survey. This will help you vet vendors before any new vendor touches your core databases.
You will be creating a repeatable vendor risk assessment framework to prevent invisible risk before it becomes a breach headline. Just run these five vectors as part of your SOC 2 GDPR software vetting checklist and log answers in a simple risk register.
» #1 Is SOC 2 Type II Current?
Check the observation period and report date to verify the recency of the audit. If the report is older than about 12 months, you must ask for a bridge letter. Confirm if the renewal timeline has been attached to the report.
» #2 Does DPA cover our data?
The signed Article 28 DPA should explicitly name categories of customer and employee PII, data centre locations, and cross-border safeguards. Check for SCCs, BCRs, or EU-US DPF.
» #3 What sub-processors do they use?
Ask for the sub-processor register and the process they use to notify you of additions or changes. If there are vague responses here, it indicates downstream risk.
» #4 Will they share exceptions and breach SLAs?
Mature vendors can share high-level exception details and breach notification timelines under NDA. If they refuse or use “best practices” language, then consider it a red flag.
» #5 Who owns renewals and security contact?
Look for a clear renewal cadence for SOC 2 and DPA. Get a named security contact. If there are one-time certifications with no owner, you are monitoring a gap that you might inherit.
| Survey Vector | Green Flag | Red Flag |
| Audit Recency | SOC 2 Type II issued within 12 months, or there is a valid bridge letter covering your reliance date | Report is over 12 months old with no bridge letter. Or there is a bridge letter that is past 3 months with no renewal timeline mentioned |
| Data Scope and DPA | Signed Article 28 DPA covering all customer/employee PII, with explicit data locations and transfer safeguards | Vague privacy policy, unclear data residency and no standalone DPA |
| Sub-Vendor Risk | Clear sub-processor list with compliance status and change notification process | We use AWS, so we are compliant by default, with no app-layer evidence |
| Incident & Exception Transparency | Willing to share exception summaries, remediation plans, and breach SLAs | Refuses to share exceptions or SLAs. Offers generic “best practices” language |
| Ongoing Monitoring | Commits to annual renewals and DPA updates. Gives a named security contact | One-time certification, no renewal cadence and no contact |
Log every artefact, such as report, DPA, sub-processor, and even the bridge letter, in the vendor risk register. Set renewal reminders 60 to 90 days before SOC 2 expires. Make the approval gate binary. No current SOC 2 Type II and no signed DPA means there is no production access.
› The “Inherited Compliance” Fallacy
If your vendor says that running on AWS makes them SOC 2 compliant by default, it is the biggest blind spot in vendor vetting.
Cloud providers secure their infrastructure, hypervisor, data centre, and even physical servers. But they don’t secure the application built on that infrastructure.
Weak access controls, poor secret management, sloppy code, and unencrypted fields that live with the vendor don’t show up in AWS compliance posture.
This is the shared responsibility model in plain language. AWS can be fully compliant while the vendor’s app layer leaks data via misconfigured roles, flawed logic, and missing audit trails. That’s why a SOC 2 GDPR software vetting checklist must demand app-layer evidence.
If your vendor’s answer to the question “show me your SOC 2 report” is “we are hosted on AWS,” that’s not an answer. It is the exact gap that exists in the framework.
Width: 0px, Height: 0px
Width: 1106px, Height: 738px
Width: 1106px, Height: 738px
› FAQ
1. How often should we request an updated SOC 2 report?
Ans. At least every 12 months. It should be tied to the vendor’s audit cycle. If the report expires mid-cycle, ask for a bridge letter rather than waiting for the next full report.
2. What’s the real difference between SOC 2 Type I and Type II?
Ans. Type I checks whether controls are designed correctly on one specific day. But Type II checks whether they worked over 6-12 months. You need Type II for software touching production data.
3. Does GDPR apply if our vendor is based in the US?
Ans. Yes. If the vendor processes personal data belonging to EU residents, GDPR applies irrespective of where they are headquartered. That is why the DPA and cross-border safeguards are important.
4. What counts as a valid bridge letter?
Ans. A statement signed by the vendor’s management confirming there were no material control changes since the last SOC 2 report covers the gap up to your reliance date. It is just a stopgap and shouldn’t be treated as a substitute for a current report.
› Conclusion
None of this vetting is about slowing down your deal. It is about giving your legal and IT team a fast and defensible way of saying yes. Run the three-step checklist and incorporate the five-question survey on every vendor touching your employee or customer data. Keep all artefacts in one place and set renewal reminders so nothing lapses quietly.
Enterprise buyers slow deals down when they cannot verify your vendors. By closing that gap, you stop vetting friction and let legal and IT teams sign off faster than your competitors do.
Adopt this SOC 2 GDPR software vetting checklist as your pre-upgrade standard, log each data point in the vendor risk register, and tie your procurement to it.
If you are vetting a vendor for SOC 2 or GDPR compliance, browse through our directory of enterprise-ready SaaS tools with verified security certifications.
