SOC 2, ISO 27001, and GDPR: What Each Actually Covers for a Buyer

The procurement director had a checklist. It had two items on the compliance line: "SOC 2 compliant" and "GDPR compliant." Every vendor they evaluated checked both boxes. The director felt confident. Then legal flagged that the vendor's GDPR compliance referred to an outdated privacy policy, not a signed Data Processing Agreement. And until IT pointed out that the SOC 2 covered a scope that excluded the integration they were buying.

The problem wasn't dishonesty. The problem was that "SOC 2 compliant" and "GDPR compliant" are phrases that can be technically accurate while hiding significant gaps. A vendor can have SOC 2 certification for their core product and not for the AI module you're deploying. A vendor can be GDPR compliant in the sense that they've published a privacy policy without being GDPR compliant in the sense that they've signed a legally binding DPA with you.

These three frameworks are certifications and laws of different types. They don't substitute for each other. They don't overlap the way a checkbox implies. And vendors frequently emphasize the ones they have while obscuring the gaps in the ones they don't.

This guide explains what each framework actually covers and how to use that knowledge in vendor conversations.

Framework Overview: What You're Actually Comparing

The key distinction: SOC 2 and ISO 27001 are voluntary certifications that a vendor earns through a third-party audit or assessment. GDPR is a legal requirement. It doesn't matter whether the vendor has pursued certification: if they're processing EU personal data, they're subject to it.

SOC 2: What It Covers and What It Doesn't

What SOC 2 Actually Is

SOC 2 (System and Organization Controls 2) is an auditing standard developed by the American Institute of CPAs (AICPA). A SOC 2 report is produced by an independent CPA firm that has reviewed the vendor's controls against the Trust Service Criteria.

There are two types of SOC 2 reports:

Type I: A point-in-time assessment. The auditor confirmed that the vendor's controls were designed appropriately as of a specific date. This is a snapshot. It tells you the controls existed on that day.

Type II: A period assessment covering 6-12 months. The auditor confirmed that the controls were not only designed appropriately but were operating effectively over time. This is the standard you should require.

The Five Trust Service Criteria

A SOC 2 report can cover one or more of these criteria:

Most vendors only cover Security and Availability. This matters because Confidentiality and Privacy criteria are what govern how the vendor handles your data beyond basic access controls. If you're putting sensitive customer data, financial data, or HR data into a tool, ask specifically whether Confidentiality and Privacy criteria are in scope. The full security review process covers how to interpret a SOC 2 scope section and what to do when the report contains exceptions.

What SOC 2 Does NOT Cover

• Specific third-party integrations. If the vendor uses a third-party AI provider, data warehouse, or analytics tool, that component may be explicitly excluded from the SOC 2 scope. Read the scope section.
• Your use of the product. SOC 2 audits the vendor's controls, not how you've configured the product. If you've set up weak permissions or sharing settings, that's outside the scope.
• Current-day posture. A SOC 2 from 14 months ago reflects the vendor's state 14 months ago. Staff turnover, infrastructure changes, and new product features since then are not covered.

Questions to Ask Based on SOC 2

1. Is your current SOC 2 report Type I or Type II?
2. What trust service criteria does it cover? Does it include Confidentiality and Privacy?
3. What is the audit period? Is a current-year report in progress?
4. Can I review the scope section of the report? What infrastructure and products are explicitly excluded?
5. Are there any exceptions or qualified opinions in the report?
6. What third-party sub-processors are in scope vs. excluded?

Red flags:

• Type I report presented as equivalent to Type II
• Report that's more than 12 months old with no current audit in progress
• Scope that excludes the specific product or module you're buying
• Refusal to share the report under NDA

ISO 27001: What It Covers and What It Doesn't

What ISO 27001 Actually Is

ISO 27001 is an international standard for Information Security Management Systems (ISMS), published and maintained by the International Organization for Standardization (ISO). Certification means a vendor has implemented a documented, systematic approach to managing information security risks, covering policies, processes, people, and technology.

Unlike SOC 2, which audits specific controls against defined criteria, ISO 27001 certifies the existence and operation of a management system for information security. The standard has two main components:

• Main clauses: Requirements for the ISMS (risk assessment, leadership commitment, planning, operation, evaluation, improvement)
• Annex A controls: 93 control categories covering physical security, access management, cryptography, supplier relationships, incident management, and more

What ISO 27001 Does NOT Cover

• Data privacy. ISO 27001 is a security standard, not a privacy standard. It doesn't specifically address the rights of data subjects, data retention limitations, or consent requirements for processing personal data. For privacy, you need GDPR or equivalent.
• Specific technical outcomes. ISO 27001 certification means a management system exists. It doesn't certify specific technical controls are in place. A vendor can be ISO 27001 certified with relatively weak technical controls if those controls are documented and managed within the ISMS.
• The product's architecture. The ISMS scope may be narrow, covering corporate IT systems but not the product infrastructure. Check whether the scope covers the specific systems you're using.

Questions to Ask Based on ISO 27001

1. What is the scope of your ISO 27001 certification? Does it include the production product environment?
2. Which certification body issued the certificate and when?
3. When is your next surveillance audit?
4. Does your ISMS cover Annex A controls relevant to our use case (specifically access management, cryptography, and supplier relationships)?
5. How do you manage supplier information security risks for third-party sub-processors?

The ISO 27001/SOC 2 relationship: Many vendors pursue both. ISO 27001 has stronger international recognition; SOC 2 has stronger US market penetration. A vendor with ISO 27001 but no SOC 2 may be appropriate depending on your geography and industry. A vendor with SOC 2 but no ISO 27001 is the standard US mid-market profile. For AI-enabled tools, neither standard fully covers the additional data handling questions around model training, which is why evaluating AI-enabled SaaS adds a separate layer to this review.

GDPR: What It Covers and What It Doesn't

What GDPR Actually Is

The General Data Protection Regulation is an EU law that governs the collection, processing, and storage of personal data of EU residents. The full GDPR regulation text is published on EUR-Lex and applies to any organization that processes EU personal data, regardless of where the organization is based.

For a SaaS buyer, GDPR relevance comes in two forms:

1. You are a data controller. You decide what personal data is collected and why. If your SaaS tool collects or processes personal data of EU residents on your behalf, you need a Data Processing Agreement (DPA) with the vendor.

2. The vendor is a data processor. They process personal data on your instructions. The DPA governs the terms under which they process that data.

The DPA: The Document That Actually Matters

"GDPR compliant" without a signed DPA is legally meaningless. The DPA is the contract that establishes:

• What personal data the vendor processes on your behalf
• The purposes and means of processing
• The vendor's obligations around data security, breach notification, and sub-processor management
• The mechanism for cross-border data transfers (Standard Contractual Clauses or equivalent)
• Data subject rights and how the vendor supports them
• Deletion and return of data at contract termination

DPA Checklist (15 items):

• DPA is a signed, standalone document (not just a privacy policy)
• Scope defines exactly what personal data is processed
• Processing purposes match your actual use case
• Sub-processor list is current and updated notice is provided
• Security measures are described with specificity
• Breach notification timeline is 72 hours or less
• Data subject rights process is documented (erasure, access, portability)
• Cross-border transfer mechanism is specified (SCCs, adequacy decision, or other)
• Data deletion timeline post-termination is defined (30 days or less is standard)
• Data return option is available
• Vendor confirms no data use for purposes beyond your instructions
• Vendor right to use data for AI training is explicitly addressed
• Audit rights are specified
• Liability for GDPR violations is defined
• DPA is governed by EU law or equivalent standard

What GDPR Does NOT Cover

• Non-EU data subjects. GDPR doesn't cover the data of US, Australian, or other non-EU individuals. Other regulations may apply (CCPA for California, LGPD for Brazil, etc.), but GDPR specifically covers EU residents. The European Data Protection Board's guidance provides authoritative interpretations of territorial scope for organizations unsure whether GDPR applies to their specific data flows.
• Anonymized data. Truly anonymized data (where re-identification is not possible) is outside GDPR scope. Pseudonymized data (where re-identification is possible with a key) is still in scope.
• B2B contact data. In many jurisdictions, business contact information of companies (not individual consumers) falls outside GDPR's personal data definition. This is contested and jurisdiction-specific.

Questions to Ask Based on GDPR

1. Can I receive a copy of your standard DPA before signing the main contract?
2. Do you have a current list of sub-processors, and how is notice provided when sub-processors change?
3. What mechanism do you use for cross-border data transfers (SCCs, adequacy decision)?
4. What is your process for responding to data subject rights requests (erasure, access, portability)?
5. What is your breach notification commitment and how does it compare to the 72-hour GDPR standard?
6. If AI features are in scope, is customer data used for training? Is there an opt-out, and is it in the DPA?
7. What personal data is processed if we use only [specific product module]?

Red flags:

• Vendor presents their privacy policy as the DPA
• DPA includes the right to use customer data for model training without opt-out
• Sub-processor list is not maintained or is more than 6 months old
• Breach notification commitment exceeds 72 hours
• No mechanism specified for cross-border transfers

The Framework Comparison Table

How to Use This in Vendor Conversations

Don't say: "Are you SOC 2 and GDPR compliant?"

Instead, ask:

• "Can I see the scope section and trust service criteria in your current SOC 2 Type II report?"
• "Does your ISO 27001 scope cover the production product environment?"
• "Can I receive your DPA before we sign? What sub-processors are listed and are any of them AI providers?"

These questions surface the information that compliance theater hides. A vendor with genuine compliance answers them directly. A vendor with compliance theater answers them with marketing language. Once you've gathered this information, the vendor diligence checklist shows how to integrate compliance findings into a complete risk assessment before any contract is signed. And when it comes time to negotiate, SaaS contract red flags covers the DPA and liability clauses that protect your data rights post-signature.

Learn More

• Security and Compliance Review: What a Mid-Market Buyer Should Actually Check — the five-layer review process this framework context enables
• The Pre-Purchase Vendor Diligence Checklist for Mid-Market Buyers — where compliance review fits in the broader diligence framework
• SaaS Contract Red Flags: Auto-Renewal, Usage Caps, and Termination Clauses to Watch — the contract terms that affect your data rights post-signature
• Evaluating AI-Enabled SaaS: What's Real, What's Marketing — how AI features expand the GDPR and data handling questions
• AI governance policy for departments — internal policies that complement vendor-side compliance requirements
• AI readiness assessment templates — how to assess your own organization's data-handling readiness before deploying AI SaaS