Cloud Compliance Framework: SOC 2, HIPAA, PCI-DSS and FedRAMP on Azure and AWS

The Shared Responsibility Model: What's Yours, What's Theirs

Cloud compliance operates under shared responsibility — the cloud provider and the customer each own specific security domains. Understanding the boundary is the first compliance requirement.

The critical insight: identity, data protection, and compliance configuration are always the customer's responsibility — regardless of service model. The cloud provider doesn't know what data is sensitive, who should access it, or what regulations apply. That's your responsibility. The provider gives you the tools (encryption, access control, monitoring); you configure them correctly.

SOC 2 in the Cloud: Trust Service Criteria Mapped

SOC 2 evaluates controls across 5 Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Cloud implementation maps each criterion to specific Azure/AWS controls.

SOC 2 evidence collection in cloud: Azure Policy enforces configurations continuously (not just at audit time). Activity logs capture every administrative action. Defender for Cloud Secure Score provides continuous compliance posture assessment. These cloud-native tools produce audit evidence automatically — replacing the manual evidence collection that makes on-premises SOC 2 audits painful. The auditor reviews: policy configurations (are the right controls enforced?), activity logs (was there unauthorized access or configuration change?), and Secure Score history (has the security posture been maintained?). Cloud-native evidence is more thorough and more current than on-premises evidence — a compliance advantage of cloud, not a burden.

HIPAA on Azure: Safeguards and BAA Requirements

HIPAA requires three safeguard categories for Protected Health Information (PHI): Administrative (policies, training, risk analysis), Physical (facility access, workstation security), and Technical (access control, audit controls, transmission security, integrity controls). The cloud provider handles Physical safeguards. Technical and Administrative safeguards are the customer's responsibility.

Technical Safeguard Implementation

Access control: Role-based access (Azure RBAC) limiting PHI access to minimum necessary. MFA for all users accessing PHI systems. Entra ID Conditional Access enforcing device compliance and location restrictions for PHI access. Privileged Identity Management for administrative access to PHI systems.

Audit controls: Azure Activity Logs + Diagnostic Logs capturing every access to PHI resources. Log retention for 6+ years (HIPAA requires 6 years). Microsoft Sentinel analyzing logs for unauthorized access patterns. Automated alerts for anomalous PHI access (unusual hours, unusual volume, unusual geography).

Transmission security: TLS 1.2+ enforced for all data in transit. VPN or ExpressRoute for hybrid connectivity. Private Endpoints for PaaS services containing PHI — eliminating public internet exposure entirely.

The BAA requirement: Before storing PHI on any cloud service, execute a Business Associate Agreement (BAA) with the provider. Microsoft offers BAAs covering Azure, Microsoft 365, and Dynamics 365. The BAA is a contractual requirement — not a technical control, but a legal prerequisite. Without it, storing PHI on the platform violates HIPAA regardless of technical controls.

PCI-DSS in Cloud Environments: Scope and Segmentation

PCI-DSS protects cardholder data (card numbers, expiration dates, CVV). The primary compliance strategy: minimize scope — reduce the number of systems that touch cardholder data, and segment those systems from the rest of the environment.

Scope reduction in cloud: Use a payment processor (Stripe, Adyen, Braintree) that handles card data directly — your application never touches the card number. This reduces PCI scope from the entire application environment to just the payment integration endpoint. Tokenization replaces card numbers with non-sensitive tokens in your systems — the token is useless to an attacker, and your systems are out of PCI scope because they don't store cardholder data.

Segmentation when in-scope: If your systems do process cardholder data, segment the Cardholder Data Environment (CDE) from the rest of the network. In Azure: dedicated VNet for the CDE, NSG rules allowing only required communication, Private Endpoints for all PaaS services in the CDE, Azure Firewall inspecting all traffic entering/leaving the CDE, and separate Entra ID groups with dedicated Conditional Access policies for CDE access. The segmentation must be validated through penetration testing — an assessor verifies that a compromised non-CDE system cannot reach CDE resources.

FedRAMP: Government Cloud Compliance

FedRAMP (Federal Risk and Authorization Management Program) authorizes cloud services for US government use. Three impact levels: Low (public data), Moderate (controlled unclassified data — most government workloads), and High (law enforcement, emergency services, critical infrastructure). Azure Government and AWS GovCloud provide FedRAMP High authorized infrastructure — the platform is pre-authorized, but your deployment must meet additional controls.

FedRAMP Moderate requires 325+ controls from NIST SP 800-53. Key implementation areas: continuous monitoring (monthly vulnerability scanning, real-time intrusion detection), incident response (defined response procedures, 1-hour notification for incidents affecting government data), access control (PIV/CAC authentication for privileged access), and boundary protection (dedicated government regions with US-person access only). For ISVs selling to government, FedRAMP authorization is a market-access requirement — without it, government agencies cannot use your cloud service.

Compliance Automation: Policy as Code

Manual compliance — quarterly reviews, spreadsheet tracking, point-in-time assessments — doesn't scale in cloud environments where resources are created and destroyed continuously. Compliance automation uses policy-as-code to enforce requirements continuously.

Azure Policy: Defines compliance rules as code — "all storage accounts must have encryption enabled," "all SQL databases must have TDE enabled," "VMs must not have public IP addresses." Azure Policy evaluates every resource creation and modification against these rules. Non-compliant resources are: denied (prevented from creation), audited (flagged for review), or auto-remediated (automatically corrected). Compliance dashboard shows real-time posture across all subscriptions — not a quarterly snapshot, but a continuous assessment.

Infrastructure as Code (Terraform, Bicep): Infrastructure defined in code includes compliance controls by default — every VM template includes disk encryption, every network deployment includes NSG rules, every storage account has public access disabled. Compliance is built into the deployment pipeline, not audited after deployment. This "shift-left" approach prevents compliance violations from reaching production instead of detecting them after the fact.

Cloud Audit Readiness: Evidence Collection and Reporting

Cloud environments produce richer audit evidence than on-premises — if configured correctly. Every API call logged (Azure Activity Log), every resource configuration tracked (Azure Resource Graph), every identity action recorded (Entra ID Audit Logs), and every security event captured (Defender for Cloud). The audit preparation effort shifts from "collect evidence" (manual on-premises) to "organize evidence" (automated in cloud). Configure log retention to meet regulatory requirements (SOC 2: flexible, HIPAA: 6 years, PCI: 1 year, FedRAMP: 3 years). Export compliance reports from Defender for Cloud — Secure Score history, policy compliance, and recommendation implementation provide the continuous compliance evidence auditors want.

Multi-Framework Compliance: One Architecture, Multiple Standards

Most enterprises need compliance with multiple frameworks simultaneously — a healthcare company needs HIPAA AND SOC 2; a financial services company needs PCI-DSS AND SOC 2 AND state regulations. The efficient approach: implement the superset of controls. Map every control from every applicable framework to the Azure implementation. Identify overlapping controls (encryption at rest satisfies SOC 2 Confidentiality, HIPAA Technical Safeguards, and PCI-DSS Requirement 3 — one implementation, three frameworks). The overlap is typically 60-70% — meaning implementing the strictest framework (usually PCI-DSS or FedRAMP) covers most requirements for the others. Track compliance against all frameworks through a single compliance dashboard (Defender for Cloud supports multiple regulatory benchmarks simultaneously). One architecture, one set of controls, multiple compliance certifications — the cloud advantage over on-premises where each framework was often managed by a different team with different tools.

Compliance as Continuous, Not Periodic

On-premises compliance was periodic — prepare for the audit, demonstrate compliance during the audit window, relax until next audit. Cloud compliance is continuous — Azure Policy evaluates every resource change in real time, Defender for Cloud updates Secure Score continuously, and activity logs capture every action permanently. This shift benefits the organization: compliance drift is detected in hours instead of discovered at the next annual audit. But it requires: monitoring the compliance dashboard weekly (not annually), investigating and remediating non-compliant resources within defined SLAs (24 hours for critical, 7 days for moderate), and treating compliance like operational health — a continuous metric, not a periodic checkbox.

Third-Party Risk in Cloud: Vendor Compliance Verification

Your compliance doesn't end at your cloud provider — it extends to every third-party SaaS, API, and service your cloud applications connect to. A HIPAA-compliant Azure deployment that sends PHI to a non-compliant analytics service creates a violation. Vendor compliance verification requires: BAA execution for every vendor processing PHI, SOC 2 report review for every vendor processing sensitive data, data processing agreement (DPA) for every vendor under GDPR, and annual reassessment of vendor compliance posture. Maintain a vendor compliance registry — each vendor entry includes: services provided, data shared, compliance certifications verified, agreement dates, and next review date.

Go Deeper

Continue building your understanding with these related resources from our consulting practice.