SOC 2, HIPAA, and GDPR each impose different infrastructure requirements: SOC 2 requires demonstrable security controls across categories like access management and monitoring, HIPAA requires specific administrative, physical, and technical safeguards for health data, and GDPR requires data protection controls plus strict rules on cross-border data transfer and individual data rights. None of the three is optional if your business handles the data type each one governs, and none can be satisfied by generic “we take security seriously” infrastructure choices.

Cloud compliance gets treated as a single checklist item more often than it should, when in reality SOC 2, HIPAA, and GDPR are three distinct frameworks with different scopes, different enforcement mechanisms, and genuinely different infrastructure implications. A business handling EU customer data and US health data simultaneously needs to satisfy all three at once, and understanding where their requirements overlap versus where they diverge is what actually makes that manageable, rather than treating each as a separate, unrelated project competing for the same limited engineering time. This guide breaks down what each framework requires, as part of the same DevOps and cloud solutions planning that should underpin any infrastructure handling regulated data.

What Is Cloud Compliance?

Cloud compliance is the practice of configuring and operating cloud infrastructure to meet the specific security, privacy, and data-handling requirements of applicable regulations or industry standards. It’s distinct from general security best practices in one important way: compliance frameworks require demonstrable evidence, documented controls, audit trails, formal policies, not just infrastructure that happens to be reasonably secure. A well-secured system can still fail a compliance audit if it can’t produce the specific evidence a given framework requires.

SOC 2 vs. HIPAA vs. GDPR: What Each Actually Covers

Understanding the scope of each framework before diving into specifics prevents a common and costly mistake, assuming compliance with one automatically satisfies another.

Reading this table correctly means recognizing these frameworks aren’t competing options, a business can need all three simultaneously depending on who its customers are and what data it handles, and satisfying one doesn’t automatically satisfy another even where their underlying security practices overlap significantly.

What Is SOC 2?

SOC 2 (System and Organization Controls 2) is an auditing standard developed by the AICPA that evaluates a service organization’s controls against five Trust Services Criteria, resulting in a formal report used to demonstrate security posture to customers and partners. Unlike HIPAA or GDPR, SOC 2 isn’t a law, it’s a voluntary attestation that’s become a de facto requirement for B2B software companies, since enterprise customers frequently require a current SOC 2 report before signing a contract.

The Five Trust Services Criteria

The AICPA’s Trust Services Criteria define five categories an audit can cover: Security (the only category required in every SOC 2 audit), Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations start with Security alone and add additional categories as customer requirements demand them, rather than pursuing all five simultaneously without a specific driver requiring the broader scope.

What Is HIPAA?

HIPAA (Health Insurance Portability and Accountability Act) is a US federal law that establishes national standards for protecting individuals’ health information, enforced through the Privacy Rule, Security Rule, and Breach Notification Rule. For infrastructure purposes, the Security Rule matters most directly, it specifically governs how electronic protected health information (ePHI) must be safeguarded.

Administrative, Physical, and Technical Safeguards

HHS’s own summary of the Security Rule organizes requirements into three safeguard categories: administrative (policies, training, risk assessments), physical (facility access controls, device security), and technical (access controls, audit logs, encryption, and transmission security). Cloud infrastructure decisions map most directly onto the technical safeguards, but a compliance program that only addresses the technical category while neglecting administrative and physical safeguards will still fail an audit, since HIPAA treats all three as equally required, not optional add-ons to a technically secure system.

What Is GDPR?

GDPR (General Data Protection Regulation) is a European Union regulation governing the processing of personal data belonging to EU residents, applying to any organization that processes that data regardless of where the organization itself is located. That extraterritorial reach is what catches many non-EU businesses off guard, a US-based SaaS company with EU customers is subject to GDPR requirements even without any physical presence in the EU.

Data Subject Rights and Cross-Border Transfer Rules

The official EU summary of the regulation highlights individual rights, access, correction, deletion, and portability of personal data, as central obligations, alongside strict rules on transferring data outside the EU, which is where cloud infrastructure decisions become directly relevant. Choosing a cloud region, and understanding what data residency and transfer mechanisms apply to it, is a genuine architectural decision under GDPR, not just a performance or latency consideration the way region selection often is for non-regulated applications.

Infrastructure Requirements Common to All Three

Encryption in Transit and at Rest

Every framework covered here requires encryption for sensitive data, both while it moves across a network and while it sits in storage, making this one of the few genuinely universal requirements regardless of which specific framework applies to a given business.

Access Controls and Least Privilege

Audit Logging

Beyond restricting who can access sensitive data, every framework requires being able to demonstrate who accessed what and when, which means audit logging isn’t optional infrastructure, it’s a compliance requirement in its own right across SOC 2, HIPAA, and GDPR alike.

Data Residency and Cross-Border Considerations

For GDPR specifically, and increasingly relevant for other frameworks too, where data physically resides and where it gets transferred matters as much as how it’s protected.

Example: Choosing an AWS Region for GDPR Data Residency

A business serving EU customers that deploys its infrastructure in an EU-based cloud region, rather than a US region with data flowing back and forth across the Atlantic, sidesteps a substantial share of GDPR’s cross-border transfer complexity entirely, a decision that’s considerably easier to make at initial architecture time than to retrofit once an application and its data have already grown up in the wrong region.

Incident Response and Breach Notification

All three frameworks require a documented incident response process, and HIPAA and GDPR both impose specific breach notification timelines, meaning “we’ll figure out what to do if something happens” isn’t a compliant posture under either regulation, a formal, rehearsed process needs to exist before an incident, not be improvised during one. This connects directly to the broader discipline covered in our web app security checklist, since the technical controls that prevent a breach and the process that governs responding to one are both required, not a substitute for each other.

Deciding Which Framework to Pursue First

For a business facing multiple potential requirements at once, sequencing matters, since pursuing all three simultaneously from a standing start is rarely realistic for a small or mid-sized team. The practical driver is usually external rather than internal: if enterprise sales conversations keep stalling on a security questionnaire, SOC 2 is probably the immediate priority, since it’s the one most directly tied to closing revenue. If the business genuinely handles protected health information, HIPAA compliance isn’t really optional or sequenced at all, it’s a legal requirement from the moment that data starts flowing through the system, regardless of what else is on the roadmap. GDPR sits somewhere in between, technically mandatory the moment EU personal data is processed, but the practical urgency of formal documentation and process maturity often tracks how much EU business a company actually has today versus how much it’s planning to pursue. Whichever comes first, the infrastructure-level controls, encryption, access management, logging, are shared enough across all three that building them well the first time pays off regardless of which framework’s audit comes next.

Common Mistakes When Pursuing Cloud Compliance

Businesses frequently assume that hosting on a major cloud provider automatically confers compliance, when in reality providers offer compliant infrastructure options, but the responsibility for configuring and using that infrastructure compliantly still sits with the business itself, a shared responsibility model that catches many teams off guard.

Organizations pursuing multiple frameworks simultaneously often duplicate effort by treating each as an entirely separate project, when SOC 2, HIPAA, and GDPR controls overlap substantially, encryption, access control, audit logging, satisfying one well often gets a business most of the way toward another. Compliance also frequently gets treated as a one-time certification rather than an ongoing operational discipline, similar to the pattern covered in our mobile app security best practices guide, controls that were compliant at the time of an audit can drift out of compliance as infrastructure and processes evolve if nobody’s actively maintaining them.

This drift risk applies just as directly to the web app layer as it does to backend infrastructure, a frontend that starts logging or transmitting data in a new way after a feature update can quietly introduce a compliance gap that nobody notices until an audit or, worse, an actual incident surfaces. And data residency decisions frequently get made purely on performance or cost grounds early in a project, without considering the compliance implications that become expensive to unwind once real customer data already lives in the wrong region.

How The Apps Developers Approaches Cloud Compliance

Compliance requirements get scoped as part of the same API and backend development architecture conversation that shapes any project handling regulated data, rather than treated as a separate audit exercise addressed after a system is already built.

This connects to the broader architecture thinking in our SaaS web app architecture guide, since decisions like data residency, encryption architecture, and access control design are far cheaper to build in correctly from the start than to retrofit once an application has grown around assumptions that don’t hold up under audit scrutiny.

If your business needs to satisfy SOC 2, HIPAA, GDPR, or some combination of the three, and you’re not confident your current infrastructure would hold up under a real audit, that’s worth a direct conversation. You’re welcome to talk to our team about what genuine compliance-ready infrastructure looks like for your specific requirements.

Frequently Asked Questions