Cloud compliance: SOC 2, HIPAA, and GDPR, explained

Compliance comes up in almost every migration conversation, usually as a deal blocker (“we can’t close enterprise customers without SOC 2”) or a legal obligation that arrived with the data. This guide explains what each framework actually is, what your cloud provider handles for you, and a realistic path through it. It is a map, not legal advice; involve counsel before you rely on any of it.

The three at a glance

	SOC 2	HIPAA	GDPR
What it is	Voluntary audit framework (AICPA)	US federal law	EU regulation
Protects	Customer data, via your controls	Protected health information (PHI)	Personal data of EU residents
Applies to you if	Enterprise customers ask for it	You handle US health data	You process EU residents’ data, anywhere
Proof	Auditor’s report (Type I or II)	No certificate; you comply and can prove it	No certificate; you comply and can prove it
Teeth	Lost deals	Fines up to $1.5M per violation category per year	Fines up to 4% of global revenue

SOC 2: proving your controls to customers

SOC 2 is not a law. It is an audit framework from the AICPA in which an independent auditor examines your security controls against the Trust Services Criteria: security (always in scope), plus optionally availability, confidentiality, processing integrity, and privacy. The output is a report you share with customers under NDA, and that report is what an enterprise security review is really asking for.

Two flavors matter. Type I checks that your controls are designed correctly at a single point in time. Type II checks that they actually operated over an observation window of 3 to 12 months, and is what mature buyers expect. Budget honestly: a first Type II typically costs $20,000 to $60,000 in audit fees plus compliance tooling, and 6 to 12 months end to end.

HIPAA: protecting health information

HIPAA is a US law covering protected health information: anything that ties a person’s identity to their health, treatment, or payment for care. It applies to covered entities (providers, insurers) and to their business associates, which is what you become the moment a hospital’s patient data lands in your product.

There is no HIPAA certificate. You comply by implementing the required administrative, physical, and technical safeguards, and by signing a Business Associate Agreement (BAA) with every vendor that touches PHI, your cloud provider first among them. The physical safeguards are largely the provider’s problem; the technical ones (access control, audit logging, encryption, integrity controls) are yours to configure.

GDPR: protecting EU personal data

GDPR applies to anyone processing personal data of people in the EU, regardless of where the company sits. A Montreal SaaS with three German customers is in scope. Its core demands: a lawful basis for processing, honoring data subject rights (access, deletion, portability), breach notification within 72 hours, a Data Processing Agreement (DPA) with every processor including your cloud provider, and lawful handling of data transfers out of the EU.

Unlike SOC 2, there is no audit to pass; unlike HIPAA, enforcement is active and fines are calculated against global revenue. The practical work is knowing what personal data you hold, where it lives, and being able to find and delete it on request.

What the provider covers versus what you own

This is the shared responsibility model applied to paperwork. AWS, Azure, and Google Cloud each hold SOC 2, ISO 27001, and dozens of other attestations, and offer HIPAA-eligible services and GDPR-ready DPAs. That gives you compliance of the cloud. Compliance in the cloud is not transferable.

Layer	Provider’s job	Your job
Physical data centers	Certified and audited	Nothing
Infrastructure and hypervisor	Certified and audited	Nothing
Service configuration	Provides the controls	Encryption on, IAM least privilege, logging enabled
Your application	Nothing	Secure code, access control, data handling
Your data	Nothing	Classification, retention, residency, deletion
Policies and people	Nothing	Written policies, training, incident response
Contracts	Offers BAA and DPA	Signing them before data flows

The one-line version: running on a SOC 2 compliant cloud does not make you SOC 2 compliant, in the same way that renting a certified kitchen does not make you a licensed restaurant.

Data residency: pick regions on purpose

All three frameworks intersect with geography. GDPR restricts transfers of EU personal data outside the EU unless a lawful mechanism covers them (Standard Contractual Clauses, or the EU-US Data Privacy Framework for certified US companies). Some sectors and countries go further with hard localization rules for health, financial, or government data.

The practical move: decide residency before you build, choose your regions accordingly, and restrict unused regions by policy so data cannot quietly land in the wrong jurisdiction. Moving a data store between regions later is a migration of its own, with egress fees attached. This belongs in your landing zone design, not in a post-launch cleanup.

The paperwork: BAAs and DPAs

Two documents come up constantly, and both are free to sign with the major providers:

• BAA (HIPAA): sign it before any PHI enters the account. Critically, each provider’s BAA covers only a published list of eligible services. Compute, managed databases, and object storage are generally covered; newer or niche services often are not. Architect from the list, not toward it.
• DPA (GDPR): every major provider offers a standard DPA with SCCs built in, usually accepted in the console or bundled into the service terms. You need equivalent DPAs with your other subprocessors too (email, analytics, support tooling), and a public list of who they are.

A practical getting-compliant path

1. Decide what you actually need. Frameworks follow the data and the customers: health data means HIPAA, EU users mean GDPR, enterprise pipeline means SOC 2. Do not pursue badges nobody is asking for.
2. Inventory your data. What personal or health data you hold, which systems store it, where it flows, who can touch it. Every framework starts here, and it is the step teams skip.
3. Lay the technical foundation. The first-account checklist and IAM best practices cover most technical controls every framework expects: MFA, least privilege, audit logging, encryption, private-by-default networking.
4. Sign the contracts and set residency. BAA and DPA in place, regions chosen and restricted, subprocessor list written down.
5. Write the policies and collect evidence. Access control, incident response, vendor management, employee onboarding and offboarding. A compliance automation platform (Vanta, Drata, and similar) pays for itself here by pulling evidence from your cloud APIs continuously.
6. Audit, then keep it alive. For SOC 2, engage an auditor and schedule the observation window. For HIPAA and GDPR, run a gap assessment. Then treat compliance as a quarterly rhythm, because the renewal audit arrives every year and controls that lapsed in month three are findings in month twelve.

Compliance work is mostly disciplined engineering plus honest documentation, and the technical half overlaps almost entirely with the security work you should do anyway. If you want an engineer who has been through these audits to review your architecture before the auditor does, talk to a Webisoft cloud engineer.

FAQ

Does hosting on AWS, Azure, or Google Cloud make me SOC 2 compliant?

No. The provider’s certifications cover their data centers and infrastructure, not your usage of them. Your access controls, encryption settings, logging, application code, and policies are what your own SOC 2 audit examines. Inheriting the provider’s reports saves you from auditing the physical layer, and that is all it saves you from.

Do I need a BAA with my cloud provider for HIPAA?

Yes, before any protected health information touches the account. AWS, Azure, and Google Cloud all sign Business Associate Agreements at no extra cost, but each BAA only covers a specific list of eligible services. Storing PHI in a service outside that list is a violation even with the BAA signed, so check the list before you architect.

Does GDPR require my data to stay in the EU?

Not strictly. GDPR restricts transfers of EU personal data to countries without adequate protection, but lawful transfer mechanisms exist, including Standard Contractual Clauses and the EU-US Data Privacy Framework. Many teams still choose an EU region anyway because it simplifies the legal analysis and reassures customers.

How long does it take to get SOC 2 compliant?

Plan on 6 to 12 months for a first SOC 2 Type II: a few months to implement controls and gather evidence, an observation window of 3 to 12 months, then the audit itself. A Type I report, which checks control design at a single point in time, can be done in 2 to 3 months and is often enough to unblock an early enterprise deal.

Which compliance framework should a small SaaS company pursue first?

Usually SOC 2, because it is the one enterprise customers ask for in security reviews. HIPAA only applies if you handle US health data, and GDPR applies automatically if you process EU residents’ data, so it is less a choice than an obligation to meet. Let your customers and your data types decide, not the frameworks’ prestige.