SOC 2 vs GDPR for SaaS: What to Do Before an EU Customer Signs

If an EU customer asks your SaaS company for both a data processing agreement and a SOC 2 report, handle them as separate decisions. GDPR duties depend on the processing, the parties’ roles, and where the law applies. SOC 2 is a CPA examination of controls for a described service. A report cannot approve your privacy terms, and signing a data processing agreement does not produce a report. Map the data flow with privacy counsel, then ask the buyer exactly which SOC 2 report it needs.

SOC 2 vs GDPR: what does each answer?

The European Data Protection Board (EDPB) says GDPR may apply to an organisation established in the European Economic Area, or to one outside it that offers goods or services to people in the EEA or monitors their behaviour there. Its duties concern the personal data and processing activities in scope. Names, email addresses, IP addresses, and other identifiers can be personal data; a product does not need medical or payment records for privacy questions to arise.

The AICPA describes SOC 2 as a CPA examination of controls at a service organisation relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy. The selected criteria, system description, report type, and date or period bound the report. The presence of a Privacy category does not turn that report into a legal GDPR determination. A customer may need both a suitable report and a contract governing its data.

Do not infer your company’s GDPR position from an EU billing address alone. Ask counsel to assess the establishments, whom the service targets or monitors, each processing activity, and the contractual role. An EU customer’s own GDPR duties can lead it to request processor terms even when you have not settled whether the law applies directly to every activity of your US company.

Which personal data does the product actually handle?

Before negotiating terms or setting a SOC 2 boundary, draw one short data flow for the proposed customer. Include:

1. The data a user enters or uploads, and whether it identifies a person.
2. Account, billing, support, analytics, and access logs, including email addresses and IP addresses.
3. Every system that receives a copy, such as hosting, backup, logging, support, and mail services.
4. Where each provider processes or can access the data, who can change that route, and how the data leaves or is deleted.

The EDPB’s small-business guide defines personal data broadly and includes email addresses and browsing history. “We do not store customer content” may still leave account and log data to assess. An engineer should verify the diagram against deployed systems rather than relying on the sales description.

Keep the diagram and decisions reviewable, but do not put raw customer data, credentials, or personal data that may need erasure into a Git evidence repository. Store such data in approved source systems and keep a safe reference where the SOC 2 team can find the relevant proof.

Are you the controller, processor, or both?

The role can differ by purpose. The EDPB explains that a controller decides why and how personal data is processed, while a processor acts on the controller’s instructions. A SaaS vendor may process customer records under the customer’s instructions and decide its own purposes for account administration. Do not give the whole company one role without checking each flow.

For each data set, write down the purpose, who decides it, who gives instructions, the parties with access, and the planned retention or deletion route. Have counsel review those facts against the agreement. The EDPB says a controller-processor contract must document the processing and address instructions, security, subprocessors, assistance with individuals’ rights, and return or deletion at the end of service. That is more specific than attaching a generic data processing agreement to a sales email.

If data moves outside the EEA, flag the route for counsel. The EDPB’s transfer guide explains that transfer rules have their own conditions, which apply alongside other GDPR duties. A SOC 2 report cannot supply a transfer mechanism or decide whether one is needed for a particular flow.

What should you ask the buyer about SOC 2?

Get the report request in writing. Ask for the product or service to be covered, Type 1 or Type 2, relevant criteria, the date or period, and when the buyer needs the report. A buyer may accept a security questionnaire or a plan while a report is pending, but only the buyer can say what its procurement process accepts.

Then set the SOC 2 system boundary with a qualified CPA firm. A report on one service does not automatically cover a new EU feature, region, or data flow. Management operates the controls and prepares evidence; the CPA firm tests controls, evaluates exceptions and evidence sufficiency, and issues the report. Compare the final scope with the buyer’s request.

The data map, provider list, access records, change history, and incident procedure may support both your privacy review and SOC 2 preparation. Keep the applicable requirement, owner, date, and source attached to each fact. Do not call one evidence file proof of legal compliance or assume a reviewer will accept it for a different purpose.

Where does FileGRC fit?

FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. You can connect SOC 2 scope, controls, decisions, and approved evidence references for review. Starter records are proposals, not compliance claims.

FileGRC does not decide GDPR applicability or roles, sign a processing agreement, run identity, logging, backup, or privacy source systems, or perform the SOC 2 examination. Use qualified counsel for the privacy questions and the CPA firm for the report. The startup SOC 2 guide helps decide when that report is worth starting, and the evidence repository guide helps keep sensitive source data out of Git.