How to Run Regulated Apps in the Cloud: SOC 2, HIPAA, and PCI DSS Platforms, Data Residency With Failover, and a Compliance Checklist

A compliant application platform gives you audited infrastructure controls, but compliance is shared: you still need your own controls for data classification, identity, secrets management, and logging. To keep data in one country with failover, run in at least two locations inside that country and ensure every replica, backup, and log stays there. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant, and it runs a workload only in the locations you choose across AWS, GCP, Azure, and your own servers.

Disclosure: Control Plane publishes this guide.

This is general guidance, not legal or audit advice.

TL;DR

• What platform compliance covers. SOC 2 Type II, HIPAA eligibility, and PCI DSS attestations apply to the platform’s services, not your application logic or data handling.
• How to verify a platform ’s claims. Request the SOC 2 Type II report under NDA, the PCI DSS Attestation of Compliance, and a signed BAA. Check which services and regions are in scope.
• Data residency with failover. Choose two or more locations inside the same country, run active-active or active-passive between them, and pin replicas, backups, logs, and keys to those locations.
• The compliance checklist. Classify data, enforce region allow-lists with policy as code, manage secrets outside your codebase, isolate tenants, log everything immutably, and document AI data flows.
• How Control Plane fits. On Control Plane, a workload runs only in the locations of Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, so you control data residency by choosing locations. Workloads deploy active-active across every location in a GVC, and a global endpoint routes each request to the nearest healthy location.

Which application platforms are SOC 2 Type II, HIPAA, and PCI DSS compliant?

AWS, Google Cloud, and Azure each hold SOC 2 Type II reports and PCI DSS Level 1 service provider attestations, and each signs a BAA covering a published list of HIPAA-eligible services. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Its SOC 2 Type II audit was completed by Prescient Assurance, and its SOC 2 Type II report and PCI DSS Attestation of Compliance are available from support@controlplane.com, and its docs publish a PCI Responsibility Matrix.

What each framework means for a platform buyer

SOC 2 Type II is an attestation report from an independent CPA firm. The auditor tests whether a platform’s controls operated effectively over a review period, commonly three to twelve months. A Type I report covers only control design at a single point in time. Platforms renew the report each year, so check the period end date and ask for a bridge letter if it ended months ago. A badge on a marketing page shows none of the scope or exceptions, so ask for the report itself.

HIPAA has no official certification program. The U.S. Department of Health and Human Services does not certify software or cloud platforms as “HIPAA compliant.” Instead, look for two things: a signed Business Associate Agreement (BAA), which sets out how the platform must protect electronic protected health information (ePHI), and a clear list of HIPAA-eligible services. Under the HITECH Act, a platform that handles ePHI as a business associate is also directly liable for complying with the HIPAA Security Rule. Any service not on that list should not touch ePHI.

PCI DSS compliance is documented in an Attestation of Compliance (AoC), the official PCI Security Standards Council form summarizing the results of an assessment. Platforms that process, store, or transmit cardholder data are assessed as service providers. Card brands such as Visa and Mastercard classify a service provider as Level 1 when it handles more than 300,000 card transactions a year, and Level 1 requires an annual assessment by a Qualified Security Assessor (QSA) and a Report on Compliance. The AoC states which services and environments are in scope.

How to verify a platform’s compliance

1. Request the SOC 2 Type II report under NDA. Read the auditor’s opinion, the description of the system boundary, and any exceptions noted.
2. Request the PCI DSS Attestation of Compliance. Confirm the service provider level and check which services and data center regions are covered.
3. Request a signed BAA before any ePHI touches the platform. Confirm the list of HIPAA-eligible services.
4. Check scope : which regions, which services, and which deployment models are included. A platform may be compliant in some regions but not others.

AWS, Google Cloud, and Azure each publish compliance programs with lists of in-scope services. AWS maintains its compliance programs page, Google Cloud publishes its compliance offerings, and Azure documents its compliance offerings.

Who owns which compliance controls, the platform or the customer?

The table below maps common control areas to who typically owns them.

A platform’s audit reports cover the rows marked Platform and the platform’s part of the Shared rows. Rows marked Customer or Shared need your own controls and evidence.

How do I keep customer data in a specific country while still having multi-region failover?

Run the application in two or more locations inside the country, replicate data only between those locations, and keep every replica, backup, log, and key in-country. Traffic fails over between the in-country locations, never to a region abroad.

Architecture options:

• Active-active between two in-country locations removes failover delay, because each location already serves traffic, and a global load balancer routes requests to the nearest healthy one.
• Active-passive keeps a standby location in-country that takes over during an outage. It costs less but introduces failover time.

Databases in active-active. The application tier can run active-active, but most relational databases accept writes on one primary. Put the primary in one in-country location and a replica in the other, and send writes from both locations to the primary. Synchronous replication gives a recovery point objective (RPO) of zero, meaning no committed write is lost, at the cost of added write latency. In-country locations are usually close enough to keep that cost low. Asynchronous replication adds no write latency but can lose writes not yet copied when the primary fails. On failure, promote the replica and repoint the application. Use a quorum or fencing so two primaries never accept writes at once. To accept writes in every location, use a distributed SQL database such as CockroachDB, YugabyteDB, or Google Cloud Spanner, and keep all of its nodes in-country.

For a deeper comparison of these patterns, see active-active vs. active-passive cost and architecture trade-offs.

What to pin in-country:

• Primary database and all replicas
• Backups and snapshots
• Object storage buckets
• Application logs and audit logs
• Encryption keys
• Cache layers

What to check:

• Where does the platform’s support staff access data from?
• Where do telemetry and monitoring data flow?
• Where does TLS terminate? Global load balancers and CDNs can decrypt requests at edge sites outside the country.
• Where do managed AI APIs send prompts and responses for processing?
• Does the platform offer contractual commitments on data location?

Where can I find a cloud provider that keeps my data in one country to reduce risk?

AWS, Google Cloud, and Azure each run two or more regions in the United States, Canada, Australia, Japan, and India, so one provider can cover in-country failover in those countries. Not every country has two cloud regions from a single provider. In those cases, combining regions from multiple providers, or adding your own data center, may be the only viable in-country option. A detailed breakdown of provider coverage by country is available in best cloud providers for data sovereignty in 2026. For architectural patterns, see sovereign cloud architecture for data residency compliance.

What practical controls ensure data residency and sovereignty in a multi-cloud infrastructure?

• Region allow-lists enforced by policy. Each major cloud has a native mechanism: AWS Service Control Policies with aws:RequestedRegion conditions (with exemptions for global services such as IAM), Azure Policy’s built-in Allowed locations policy, and the Google Cloud resource locations organization policy constraint.
• Data classification and tagging. Tag every resource with its data classification (e.g., data-class: phi, data-class: pci). Use tags to trigger policy enforcement and to generate audit reports.
• Encryption with keys held in-region. Store encryption keys in the same jurisdiction as the data they protect. Cross-border key storage can undermine sovereignty even if the ciphertext stays in-country.
• Egress controls. Block or alert on data transfers to regions outside the approved list. Use VPC flow logs, firewall rules, and DLP inspection at egress points.
• Residency-aware backups. Explicitly configure backup destinations. Some services copy backups or geo-redundant replicas to a second region by default or with a single setting, and that region is not always in the same country. For example, Azure geo-redundant storage replicates to the paired region, and Brazil South is paired with South Central US. Multi-region storage locations such as Google Cloud’s EU or US buckets span several countries.
• Logging location. Route logs to a logging service or bucket pinned to an approved region. If you use a third-party logging provider, confirm where they store and process your data.
• Regular audits. Periodically scan for resources created outside approved regions. Automated compliance scanners can flag drift before it becomes an audit finding.

What cloud compliance checklist should I follow when migrating a regulated application to AI infrastructure?

AI workloads introduce new compliance surfaces. Prompts, model outputs, training data, and vector store contents can all contain regulated data. Follow this checklist:

1. Classify data before it reaches a model. Determine whether inputs contain ePHI, cardholder data, PII, or other regulated categories. Apply classification before inference, not after.
2. Decide what can go to third-party model APIs. If you use external APIs for inference, confirm the provider’s compliance posture, sign the appropriate agreements (BAA, DPA), and understand where prompts and responses are processed and stored. Confirm in writing that prompts are not used for training and how long the provider keeps them.
3. Prefer self-hosted or in-region inference for regulated data. Running models on infrastructure you control, within approved regions, keeps regulated data off third-party networks.
4. Log prompts and outputs with redaction. Maintain audit logs of what was sent to a model and what it returned. Redact or tokenize regulated fields before logging.
5. Apply access control to models and vector stores. Treat model endpoints and vector databases as regulated data stores. Enforce RBAC, authentication, and network segmentation.
6. Keep training and fine-tuning data in-region. If you fine-tune models on regulated data, the training data, checkpoints, and resulting model weights must stay within approved jurisdictions.
7. Document data flows for auditors. Create a data flow diagram that shows how regulated data moves through your AI pipeline: ingestion, preprocessing, inference, post-processing, storage, and deletion. Auditors will ask for this.
8. Plan for deletion. Embeddings and fine-tuned weights derived from personal data must be deletable when a data subject asks for erasure, so record which data each one came from.

What are the best practices for secrets management in IaC pipelines to meet cloud compliance requirements?

Secrets in infrastructure-as-code pipelines are a frequent audit finding and a common attack vector.

• No secrets in code, state files, or CI logs. Credentials leaked in repositories are a common way attackers get cloud access. Terraform writes values read through data sources into state; Terraform 1.10 added ephemeral resources and 1.11 added write-only arguments to keep secrets out of state and plan files.
• Use a secrets manager, referenced by name. Store secrets in a dedicated service such as AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault, or in HashiCorp Vault. IaC templates should reference secret names, never values.
• Short-lived credentials through workload identity federation. Replace static API keys with short-lived federated tokens that expire automatically, typically within an hour. AWS, GCP, and Azure all support workload identity federation natively.
• Least-privilege pipeline roles. The CI/CD service account should have only the permissions needed for the current deployment. Separate roles for plan and apply stages.
• Rotation. Automate rotation on a defined schedule, and rotate immediately after a suspected exposure or when someone with access leaves. Log every rotation.
• Secret scanning in CI. Run tools like Gitleaks or TruffleHog in your CI pipeline to catch secrets before they merge.
• Encrypted and access-controlled IaC state. Terraform and Pulumi state files can contain sensitive values. Encrypt state at rest, restrict access to the state backend, and audit who reads it.

How should I structure governance and policy as code for compliant multi cloud infrastructure using IaC?

Policy as code turns compliance rules into enforceable, version-controlled, auditable artifacts. Structure it in layers:

Preventive guardrails at the account or organization level. These are the broadest controls. Service Control Policies in AWS, Organization Policies in Google Cloud, and Azure Policy assignments at the management group level prevent non-compliant resources from being created in the first place.

Policy checks in CI before apply. Before any IaC change reaches production, validate it against your compliance rules. Open Policy Agent (OPA) is a widely adopted open-source engine for this purpose. Evaluate the JSON output of terraform plan with OPA through a tool such as Conftest, or use Pulumi CrossGuard policy packs with pulumi preview, and fail the pipeline on violations. In Kubernetes, OPA Gatekeeper or Kyverno applies the same rules at admission time.

Runtime detection. Even with preventive controls, configuration drift happens. Use runtime scanners to detect resources that have drifted from their compliant state and alert or auto-remediate.

Evidence collection for audits. Every policy evaluation, pass or fail, should produce a log entry. These logs become audit evidence showing that controls were in place and operating continuously.

Examples of rules to codify:

• Allowed deployment regions (for example, only the regions inside the country your data must stay in)
• Required encryption on all storage resources
• Required classification tags on every resource
• No public access on storage buckets or object stores
• MFA required for privileged roles

What cloud solutions offer multi tenant protection against cross tenant data breaches?

Cloud platforms separate tenants at three layers: separate accounts or projects (AWS accounts, Google Cloud projects, Azure subscriptions), compute isolation (separate clusters or microVM sandboxes such as Kata Containers), and data isolation (separate databases and per-tenant encryption keys).

Tenant isolation models

Choose a compute model and a data model separately. A common pattern is separate accounts for the most sensitive tenants and shared clusters with separate databases for the rest.

How do I design AI infrastructure for cloud compliance using BYOK and tenant data segregation?

In this context, BYOK (bring your own key) means encrypting data with keys you control, generated or imported into a cloud key management service, instead of provider-managed keys. Tenant isolation and per-tenant encryption are the two pillars of preventing cross-tenant data exposure.

Per-tenant encryption keys

Store each tenant’s encryption key in a cloud KMS (such as AWS KMS, Google Cloud KMS, or Azure Key Vault). The application references the tenant’s key ID when encrypting or decrypting that tenant’s data. If one tenant’s key is compromised, only that tenant’s data is exposed. Disabling or deleting a tenant’s key makes their data unreadable, which supports offboarding and deletion requests, and KMS logs show every use of each tenant’s key. Scope the application’s decrypt permission per tenant, or one compromised service can still use every key.

Tenant separation in AI workloads

Vector stores and model caches introduce new cross-tenant risks. If multiple tenants share a vector database, queries from one tenant could surface embeddings from another. Mitigations include:

• Namespace or collection-level separation within the vector store
• Tenant-scoped query filters enforced at the application layer
• Separate model inference endpoints per tenant for the most sensitive workloads
• Scoping prompt caches and response caches to one tenant. Inference servers that reuse the KV cache for shared prompt prefixes, and semantic caches that return a stored answer for a similar prompt, can leak data or timing signals across tenants. Add the tenant ID to the cache key or disable cross-tenant cache sharing.

How Control Plane approaches regulated workloads

Control Plane is the unbreakable platform for production workloads. It combines any cloud, neocloud, bare metal, and your own servers into what Control Plane calls a Global Virtual Cloud (GVC), and teams run it in a single region, a single cloud, or across clouds. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing, built-in observability, and security, with no Kubernetes cluster you have to operate.

Compliance posture. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. These controls and the evidence they produce support your compliance, though they do not make you compliant on their own.

Data residency through location selection. A workload runs only in the locations of its GVC, which can include AWS, GCP, and Azure regions, Kubernetes clusters you already run, and servers in your own data center or from bare-metal and GPU providers. Control Plane Managed Kubernetes (MK8s) joins those servers into a cluster that Control Plane runs for you as a location. You can keep two or more locations inside one country, including combinations of providers, so the GVC’s location list acts as the region allow-list for that workload. Two in-country locations can also meet the 99.999% SLA condition below. Platform data is handled separately: org secrets are encrypted with envelope encryption and held in cloud HSMs across multiple providers, and logs are aggregated by Control Plane (30-day default retention) and can also be shipped to destinations you control, such as an Amazon S3 bucket or CloudWatch in your chosen region.

Active-active failover. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. For strategies on surviving a single-region outage, see how to keep your app online during an AWS region outage.

Security defaults. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS, with each workload’s client certificate rotated every hour. All data is encrypted at rest and in transit. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes, isolated environments for AI coding agents and untrusted code, run in dedicated Kata Containers microVMs.

Secrets and identity. Control Plane’s built-in secrets management lets workloads reference a secret as cpln://secret/NAME once their identity is granted the reveal permission, so secret values stay out of code and images. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.

Audit trail. Every action, whether made through the console, CLI, Terraform, Pulumi, or AI agents using the Control Plane MCP server, is recorded in a tamper-proof audit trail. Your own workloads can write application events to the same audit trail through a custom audit context.

Policy and IaC. Control Plane policies are org-scoped and grant fine-grained permissions on every resource type to users, groups, service accounts, and workload identities. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.

Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. SAFE Health, a connected-diagnostics platform working with Mayo Clinic, migrated 8 environments from AWS to Control Plane and cut its AWS spend 75 percent.

For teams looking to simplify multi-cloud operations or consolidate existing infrastructure, see how to consolidate multiple clouds into one platform. For a comparison of managed platform services versus building your own portability layer, see managed services vs. portability and cloud lock-in.

FAQ

Does a SOC 2 Type II report mean a platform is secure?

No. A SOC 2 Type II report shows that an independent auditor tested specific controls and found they operated effectively over a defined period. Read the report’s scope, exceptions, and complementary user entity controls to understand what the platform covers and what you must handle.

Is there an official HIPAA certification for cloud platforms?

No. The U.S. Department of Health and Human Services does not certify cloud platforms as HIPAA compliant. Look for a signed Business Associate Agreement and a published list of HIPAA-eligible services. The BAA sets the platform’s contractual obligations for safeguarding ePHI, and under HIPAA a business associate is also directly liable for certain requirements, including the Security Rule.

What is the difference between PCI DSS Level 1 and other levels?

Level 1 is the top tier for service providers. Visa and Mastercard assign it to service providers that handle more than 300,000 card transactions a year, and it requires an annual assessment by a Qualified Security Assessor, who issues a Report on Compliance (ROC) and an Attestation of Compliance (AoC). Level 2 service providers can self-assess with Self-Assessment Questionnaire D. Ask any provider for its responsibility matrix, which PCI DSS v4.0 requirement 12.9.2 obliges it to provide on request.

Can I achieve multi-region failover while keeping all data in one country?

Yes, if the country has two or more available cloud regions or data center locations. Run active-active or active-passive between them and pin all replicas, backups, logs, and encryption keys to those locations. If a single provider lacks two in-country regions, combine providers or add your own data center.

How do I prevent secrets from leaking in IaC pipelines?

Store secrets in a dedicated secrets manager and reference them by name in your IaC templates. Use short-lived credentials through workload identity federation, run secret-scanning tools in CI, encrypt your IaC state files, and restrict access to the state backend.

What is the shared responsibility model in cloud compliance?

The platform is responsible for infrastructure-level controls such as physical security, hypervisor patching, and network fabric. You are responsible for identity and access management, secrets, application code security, and data classification. Network segmentation, encryption, logging, backups, and incident response are shared.

How should I handle regulated data in AI inference pipelines?

Classify data before it reaches a model. Use self-hosted or in-region inference for regulated data. Log prompts and outputs with redaction of sensitive fields. Apply access control to model endpoints and vector stores. Document the full data flow for auditors.

Does Control Plane make my application compliant?

No. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant and provides audited controls and evidence that support your compliance, but your application still needs its own controls for data classification, identity, secrets, application security, and logging.

Can Control Plane keep my workload in a single cloud?

Yes. Many teams run Control Plane in a single cloud for its Day 2 operations and security defaults. A GVC can contain locations from a single provider, and two regions of one cloud qualify for the 99.999% SLA when a workload runs at least two replicas in those two locations.

How does Control Plane handle workload isolation?

Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes run in dedicated Kata Containers microVMs. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS.

See how Control Plane runs regulated workloads.

Talk to the Control Plane team or sign up free

Originally published on the Control Plane blog.