Compliant Cloud Hosting: What SOC 2, HIPAA, PIPEDA, GDPR and PCI DSS Actually Require from Your Infrastructure

"Compliant cloud hosting" is a phrase providers use loosely. AWS and Azure are certified against SOC 2, ISO 27001, PCI DSS and the rest; that does not make anything you build on them compliant. Under the shared responsibility model the provider secures the physical estate, the hypervisor and the managed-service internals; you are responsible for identity, network design, encryption configuration, patching, logging, backup and everything in your application. This guide covers the infrastructure half: what each major framework actually expects from the way your cloud estate is built and run, and how to produce the evidence without a scramble before every audit.

Certification and audit engagements themselves (readiness, gap assessment, the audit) are delivered by our sister firm PraxisQ Consulting. What follows is the part we build and operate: the cloud infrastructure, server management and NOC monitoring that generate the evidence.

The controls every framework has in common

Whatever the framework, auditors look for the same infrastructure controls, phrased differently. Build these once and most of the mapping is done:

• Identity and access. MFA on every human account, no shared credentials, no long-lived access keys, least-privilege roles per workload, quarterly access reviews with a record, immediate revocation on leaving. IAM Identity Center or Entra ID with SSO; break-glass accounts locked in a vault.
• Network segmentation. Private-by-default subnets, security groups and NSGs that allow only what is needed, a single audited ingress path through a load balancer and WAF, private endpoints for provider services, no databases reachable from the internet.
• Encryption. At rest for every volume, bucket, database and backup, with managed keys (KMS, Key Vault) and key rotation. In transit with TLS 1.2 or higher enforced at the load balancer and between services.
• Logging and monitoring. CloudTrail or Azure Activity Log on every account, retained and immutable; VPC flow logs; OS and application logs shipped off-box; alerting on failed logins, privilege changes, security-group changes and configuration drift; an on-call path that acknowledges within a defined time.
• Vulnerability and patch management. Scheduled patching with records, vulnerability scanning with triage records, emergency windows for critical CVEs.
• Backup and recovery. Encrypted backups, retention aligned to the framework, cross-region or cross-account copies for the important data, and a tested restore with the result written down.
• Change management. Infrastructure as code with pull-request review, a change record per deployment, and a rollback path. Terraform history is the change log auditors wish everyone had.
• Asset inventory. A current list of every account, resource, server and data store, and which ones are in scope. Config, Azure Resource Graph or a tagging policy enforced by policy-as-code does this automatically.

Framework by framework: what is different

SOC 2

SOC 2 is an attestation against the Trust Services Criteria (security always; availability, confidentiality, processing integrity and privacy as chosen). It is control-driven rather than prescriptive: you define the controls, the auditor tests that they operated over the period (Type II, usually 6 to 12 months). Infrastructure-wise that means the common controls above plus evidence that they ran continuously: access reviews with dates, alert acknowledgements with timestamps, patch reports every month, restore tests with results, uptime reports against your availability commitment. A NOC that produces those artefacts as a by-product of operating the estate is worth more to a SOC 2 audit than any single tool.

Hosting note: your cloud provider's SOC 2 report is a subservice organisation report; you reference it, you do not inherit it.

HIPAA

HIPAA applies to US protected health information. AWS and Azure will sign a Business Associate Agreement (BAA) and publish which services are eligible; use only those for PHI. Infrastructure requirements from the Security Rule: unique user identification, automatic logoff, encryption of PHI at rest and in transit, audit controls that record access to PHI, integrity controls, backup and disaster recovery, and documented risk analysis. In practice: PHI only in BAA-eligible services, encryption everywhere, CloudTrail plus database audit logging with retention of six years for the documentation HIPAA requires, and a DR plan that has been exercised. Hosting PHI outside the US is not prohibited by HIPAA itself but usually is by the covered entity's own policy; most US healthcare clients want us-east or us-west regions only.

PIPEDA and Quebec Law 25

Canada's PIPEDA does not mandate in-country hosting, but it requires that personal information transferred to a third party or another jurisdiction has comparable protection, that individuals are told, and that safeguards are appropriate to sensitivity. Quebec's Law 25 goes further: a privacy impact assessment before transferring personal information outside Quebec, and stronger consent and breach rules. The practical hosting answer for Canadian clients is Canada Central (Montreal) or Canada West (Calgary) on AWS, or Canada Central and Canada East on Azure, with backups also kept in Canada, encryption with customer-managed keys, and a documented data map showing where every copy lives. Cross-border support access (an engineer in another country reading a database) is a transfer; log it and cover it in the assessment.

GDPR and UK GDPR

GDPR requires appropriate technical and organisational measures (Article 32), records of processing, breach notification within 72 hours, and a lawful basis for any transfer outside the EU or UK. Hosting in EU regions (Frankfurt, Paris, Stockholm, Ireland) or London for UK data avoids transfer questions for the primary data; backups and logs must stay there too, which is easy to forget when a monitoring SaaS or log platform is in the US. Encryption, pseudonymisation where practical, retention limits enforced by lifecycle policy, and the ability to locate and delete a data subject's records are the infrastructure-side requirements. The EU-US Data Privacy Framework and standard contractual clauses cover transfers where they are unavoidable; the engineering job is to make them avoidable.

PCI DSS

PCI DSS is the most prescriptive. If cardholder data touches your estate, the in-scope segment needs: network segmentation that is tested, no direct internet access from the cardholder data environment, a WAF or code review for public web applications, quarterly external ASV scans and internal vulnerability scans, annual penetration tests, file integrity monitoring, centralised logging with daily review, MFA for all access to the CDE, and strict key management for stored PAN. The single most effective hosting decision is scope reduction: use a PCI-validated payment provider or tokenisation so PAN never lands on your infrastructure, and the cardholder data environment shrinks to almost nothing. Quarterly ASV scanning and the audit are delivered by PraxisQ Consulting; the segmentation, logging and hardening are built here.

Regional frameworks worth knowing

• India (DPDP Act, RBI, CERT-In): RBI's payment-data localisation requires payment system data to be stored in India; CERT-In directions require 180 days of log retention and reporting within six hours for listed incidents. Mumbai and Hyderabad regions, with logs retained in-country.
• Australia (Privacy Act, APRA CPS 234, Essential Eight): Sydney and Melbourne regions for APRA-regulated entities, Essential Eight maturity for government suppliers, and IRAP-assessed services for protected workloads.
• UAE (PDPL, DESC, NESA): UAE region for federal and Dubai government-related workloads; DESC's ISR standard for Dubai government suppliers.
• Singapore (PDPA, MAS TRM): Singapore region; MAS Technology Risk Management guidelines shape logging, DR testing and outsourcing controls for financial institutions.
• New Zealand (Privacy Act 2020, NZISM): Auckland region now available on AWS and Azure for in-country hosting.

A compliant cloud hosting checklist

Use this as the build spec for a new environment or the gap list for an existing one.

1. Multi-account or multi-subscription landing zone with in-scope workloads isolated in their own accounts.
2. SSO with MFA enforced; no IAM users with passwords; access keys replaced by roles and OIDC federation.
3. Every account logging to a central, immutable audit account with retention set to the longest applicable requirement (six years for HIPAA documentation; 180 days minimum for CERT-In logs; one year online plus history for PCI DSS).
4. Encryption at rest with customer-managed keys for in-scope data; TLS 1.2 or higher enforced.
5. Private subnets by default; a single ingress path through ALB or Application Gateway with WAF; private endpoints for provider services.
6. Regions chosen for residency, with backups and logs in the same jurisdiction.
7. Patch cycle monthly with reports; vulnerability scanning weekly with triage records; emergency window for critical CVEs.
8. Backups encrypted, copied cross-account, retention per framework, restore tested quarterly with the result recorded.
9. Monitoring with alerting on security-relevant events and an acknowledged on-call path; SLA report monthly.
10. Everything in Terraform or Bicep, changed by pull request, with the repository as the change log.
11. Asset inventory generated from the platform (Config, Resource Graph), not maintained by hand.
12. A data map showing every copy of in-scope data and every party with access, kept current.

Evidence without the scramble

The difference between a calm audit and a bad month is whether evidence exists as a by-product of operations. Patch reports, access reviews, restore tests, alert records and change history should be generated monthly by whoever runs the estate and filed where the auditor can read them. That is how we run managed estates: the monthly report is written for the CTO, with the audit artefacts attached, so when PraxisQ or your own auditor asks for twelve months of evidence, it is twelve reports, not twelve weeks of archaeology.

Frequently asked questions

Is AWS or Azure HIPAA, SOC 2 or PCI compliant? Both providers hold those certifications for the services and layers they operate. Your workload is compliant only if you configure and operate your part correctly. The shared responsibility model is explicit about where the line is.

Does GDPR require hosting in the EU? Not strictly, but hosting personal data in EU or UK regions, including backups and logs, avoids the transfer-mechanism requirements and is the simplest defensible position.

Does PIPEDA require Canadian data residency? No, but it requires comparable protection and transparency for cross-border transfers, and Quebec Law 25 requires an assessment before transferring outside Quebec. In practice, Canadian regions with Canadian backups are the low-risk choice.

What is the cheapest way to reduce PCI DSS scope? Tokenisation or a hosted payment page from a PCI-validated provider, so cardholder data never enters your environment. The remaining scope is then the web tier that redirects to it.

Can Techtweek host compliant workloads? We design, build and operate the infrastructure and produce the evidence for SOC 2, HIPAA, GDPR, PIPEDA, PCI DSS and the regional frameworks above. Audit readiness, gap assessments and certification are delivered by PraxisQ Consulting.