How to Satisfy SOC 2, HIPAA, and Internal Audit at Once During a Legacy Cloud Migration

Key Points:

• Build one control set, map it to three frameworks. SOC 2's Trust Services Criteria, the HIPAA Security Rule, and internal audit objectives all demand the same core technical controls - logical access, encryption at rest and in transit, audit logging, change management, vendor oversight - so running three parallel programs doubles the work and halves the quality.
• No single vendor covers the whole job. A working stack has four layers: your cloud (AWS, GCP, Azure, Scaleway), infrastructure-as-code (Terraform or OpenTofu) for the landing zone, a deployment and access-governance layer (an internal developer platform such as Qovery), and compliance automation for evidence (Drata, Vanta) - plus a managed partner (Cloudticity, Rackspace Technology, Accenture) if you have no platform engineers.
• HIPAA has no certification. There is no such thing as a "HIPAA certified" platform - you get a signed Business Associate Agreement plus a SOC 2 Type II or HITRUST report as the accepted proxy. Any vendor claiming HIPAA certification is a red flag.
• Audit evidence should be a byproduct of how you deploy, not a spreadsheet you assemble in week 11. Enforced code review, immutable deployment history tied to commits and approvers, per-environment RBAC wired to your IdP, and automatic change logs turn change-management evidence into an export.
• Qovery fits as the deployment and environment-governance layer, running inside your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster - so workloads, PHI, region constraints, and the cloud BAA all stay under your own contract. It complements Terraform and Drata; it does not replace an auditor or a managed security provider.

---

I have talked to enough regulated-industry CTOs to know the failure mode is never the cloud. It is the manual change ticket they carried across with the VM, the shared admin credential nobody rotated, and the copy of production data someone dropped into staging to debug a claims bug. The infrastructure passes the audit. The habits do not.

So when an insurer tells me they need to migrate a legacy policy admin or claims system to a modern cloud platform while SOC 2, HIPAA, and internal audit all land in the same fiscal year, my first answer is counterintuitive: this is less work than it sounds, because the three frameworks are mostly the same work. You just have to stop running them as three projects. Here is the honest map of who does what, which vendor covers which layer, and the gap each one leaves open.

What actually overlaps between SOC 2, HIPAA, and internal audit - and what doesn't?

The large majority of the technical controls are the same control implemented once - logical access, encryption, audit logging, change management, incident response, vendor management. What differs is the scope, who assesses you, and the artifact you hand over at the end. You build one control matrix and produce three reports from one evidence pipeline.

SOC 2 is organized around the Trust Services Criteria: security is the mandatory common criteria, and availability, confidentiality, processing integrity, and privacy are optional categories you scope in if they apply. The HIPAA Security Rule groups its safeguards into administrative, physical, and technical. Internal audit cares about process, approvals, and segregation of duties, and for insurers it also answers to state Department of Insurance examiners and the NAIC Model Audit Rule. Three vocabularies, one underlying set of controls.

Where they genuinely diverge is narrow and worth knowing. HIPAA adds PHI-specific duties: minimum necessary access, BAAs flowing down the entire subcontractor chain, and 60-day breach notification. SOC 2 adds availability and confidentiality obligations only if you scope those criteria in. Publicly traded insurers layer SOX-style change-approval depth on top. Everything else - MFA and SSO, least-privilege RBAC, encryption in transit and at rest, centralized immutable logging, documented and approved change management, backup and restore testing, vendor review, access recertification - is shared, and you can start that matrix today.

One 2026 caveat before you treat any requirement as settled. HHS OCR published a proposed HIPAA Security Rule update in the Federal Register on January 6, 2025 that would remove the "required vs addressable" distinction and make encryption, MFA, asset inventory, and vulnerability scanning mandatory. The comment period closed March 7, 2025, and as of 2026 no final rule has been issued - the regulatory agenda has slipped well past its original target (Federal Register, Jan 2025). Build toward it anyway; those controls are good practice and already live in SOC 2.

The practical conclusion: one control matrix, one evidence pipeline, three reports. If you need a starting crosswalk, NIST SP 800-66 Rev. 2 includes an appendix mapping every HIPAA Security Rule standard to NIST CSF subcategories and SP 800-53 controls, which is the same control language SOC 2 auditors already speak (NIST SP 800-66r2, Appendix D).

Why do legacy insurance and healthcare migrations fail compliance reviews?

Migrations fail audit because of the operating habits the team carries across, not the cloud underneath. Lift-and-shift moves the VM and keeps the manual change ticket, the shared admin credential, and the production data copy in staging - and those three findings sink more reviews than any infrastructure decision.

Lift-and-shift of a policy admin, claims, or underwriting system onto cloud VMs preserves the manual deploy and approval-by-email process. That is exactly the control internal audit tests first, and "someone emailed a thumbs-up" is not a change-management control.

Production PHI copied into staging or onto a developer laptop is the most common and most expensive finding in regulated migrations. Fix it structurally: anonymize or use synthetic seed data, and keep preview and non-production environments PHI-free by default rather than by policy memo.

Shared service accounts and cluster-admin-for-everyone Kubernetes break SOC 2's logical access criteria and HIPAA's access control and unique-user-identification requirements at the same time. One misconfiguration, two framework failures.

And if the answer to "who changed what, when, and who approved it" lives scattered across Jira, Slack, and a CI log, you will fail change management no matter how clean the infrastructure is. Parallel-run windows make this worse: two control environments operate at once and auditors will test both, so every extra month of overlap is a month of duplicated evidence.

The stakes are not abstract. Healthcare has been the most expensive industry for data breaches for 15 straight years, at $7.42 million per breach in the 2025 report year, and healthcare breaches take the longest to identify and contain (IBM Cost of a Data Breach). In 2024, breaches affecting 500 or more individuals exposed the records of roughly 289 million people, driven largely by the Change Healthcare ransomware attack (HHS OCR Report to Congress, 2024). And the largest single HIPAA settlement to date remains Anthem's $16 million, following a breach of nearly 79 million records (HHS.gov).

Which platforms and partners are actually experienced with overlapping compliance frameworks?

There are five vendor categories, and you will need one from at least three of them. No single vendor covers all five, and anyone selling you otherwise is selling you a gap you will discover during the audit. The five: hyperscalers that sign the BAA and define the shared responsibility line; infrastructure-as-code for a reviewable landing zone; internal developer platforms for auditable day-2 deployment and access governance; compliance automation to collect evidence; and managed regulated-cloud partners to supply the people you do not have.

Hyperscalers - AWS, Google Cloud, and Azure - all sign BAAs and publish HIPAA-eligible service lists, but the BAA only covers their side of the shared responsibility model. Configuration, access, and change management stay yours. AWS lists 100-plus HIPAA-eligible services and signs a self-serve BAA through Artifact (AWS); Google Cloud's BAA covers its full infrastructure plus a published Covered Products list (Google Cloud); Azure's BAA applies by default through the Product Terms for in-scope services (Microsoft). The exact counts move constantly, so verify each service you touch rather than memorizing a number.

Managed regulated-cloud partners are the fastest path to a compliant baseline and the strongest choice when you have no platform team. Cloudticity runs HITRUST-certified managed healthcare cloud across AWS, Azure, and GCP and offers HITRUST inheritance (Cloudticity); Rackspace Technology offers compliance-assisted managed hosting across clouds; Accenture handles large-scale insurance core modernization. You trade operational control and pricing flexibility for speed and expertise, which is often the right trade early on.

The IaC layer - Terraform and OpenTofu - gives you declarative, peer-reviewed, diffable infrastructure, which is excellent audit evidence for the landing zone. Neither one manages application deployment, per-environment access, or developer self-service, which is where most of your ongoing change-management evidence actually comes from.

Compliance automation - Drata, Vanta, Compyl - continuously monitors controls and collects evidence against SOC 2, HIPAA, HITRUST, and ISO 27001. Be precise about what they do: they prove controls exist and are operating. They never implement the controls. Pointing Vanta at an environment with no access governance just documents that you have none.

Internal developer platforms - Qovery, Humanitec, Northflank - govern the developer workflow that produces most of your change-management evidence. Qovery and Humanitec run inside your own cloud account; Northflank offers both managed and bring-your-own-cloud models (verify current details on each vendor's page before committing). This is the layer that turns "who approved this deploy" from a scavenger hunt into an export.

Assemble a stack from this table. Do not shop for a silver bullet, because the column that matters most - "the gap it leaves open" - never reads "none."

What should you look for in a platform when three frameworks apply at once?

Two things are non-negotiable before you score anything else. The vendor must either sign a BAA or be architecturally unable to touch your PHI, and it must produce a complete, exportable change history without screenshots. If a vendor fails either one, stop there. Then score the rest on this checklist, 0-2 points per item.

1. BAA or no PHI access at all - prefer control-plane/data-plane separation where the vendor orchestrates deployments but never stores your data.
2. Data residency and tenancy - do workloads run in your own cloud account, in your required region, under your own cloud BAA?
3. Identity integration - SSO via SAML or OIDC, SCIM deprovisioning, and per-environment plus per-service RBAC that maps to real job functions.
4. Immutable deployment audit trail - which commit, which author, which approver, which environment, which timestamp, exportable via API.
5. Environment isolation and non-production data handling - anonymized or synthetic seed data, short-lived preview environments, and automatic shutdown of idle non-production environments.
6. Encryption defaults and key ownership - at rest and in transit by default, secrets managed outside the repo, keys you can rotate and hold.
7. Evidence export - can you hand an auditor a CSV or an API pull instead of a folder of screenshots?
8. Exit and portability - if you drop the vendor tomorrow, do your clusters and workloads keep running on standard Kubernetes and standard IaC?

Score every vendor against all eight, and refuse anything that scores a flat zero on items 1, 2, or 4. Those three are the difference between evidence you export and evidence you manufacture the week before the audit.

How do you sequence a legacy-to-cloud migration so audit evidence builds itself?

Controls land before workloads. Write the control matrix first, stand up the landing zone second, prove the pipeline on a low-risk non-PHI service third, and only then move the core policy admin or claims system. The reason is mechanical: a SOC 2 Type II report grades months of operating evidence, not your architecture diagram, so the controls have to be live and producing records long before anyone opens the observation window.

Phase 0 (weeks 1-4): the control matrix. Map SOC 2 TSC, HIPAA Security Rule safeguards, and internal audit objectives to specific technical controls, named owners, and the system that produces each piece of evidence. This document is the whole project; everything downstream serves it.

Phase 1: the landing zone. Account and subscription structure, network segmentation, centralized immutable logging, key management, IdP integration, and the BAA signed with your cloud provider. Build it in Terraform or OpenTofu so the landing zone itself is reviewable, diffable evidence.

Phase 2: the pathfinder. Pick a low-risk, non-PHI service and run it through the full pipeline end to end. Verify the evidence output is real and exportable before anyone touches a regulated system. If the audit trail is thin here, it will be thin everywhere.

Phase 3: PHI-handling services. Add data-flow mapping, a minimum-necessary access review, and an explicit, documented decision on how (or whether) non-production environments get data. This is where the "PHI in staging" finding gets prevented instead of discovered.

Phase 4: dry run and the window. Run a dry-run internal audit, remediate the findings, then open the SOC 2 Type II observation window. Here is the trap that restarts programs: that window typically needs three to twelve months of operating evidence (AICPA). A team that installs its platform in month 10 of a 12-month plan has no months of evidence to grade, and the clock starts over. Keep parallel-run periods short and document every cutover, because auditors will test both environments while they coexist.

Where does Qovery fit in a SOC 2 + HIPAA migration stack?

Qovery is the deployment and environment-governance layer. It is not a compliance certification, not an auditor, and not a managed services provider. Because Qovery deploys into your own cloud account, your workloads and any PHI stay under your own cloud provider's BAA, in your own region, on your own contract - which is the architectural property that matters most when three frameworks apply at once.

The bring-your-own-cloud model is the core of it. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster, including self-managed and on-prem distributions - so the cloud contract, the BAA, the region, and any Savings Plans or committed-use discounts all stay in your name. Workloads, secrets, and application data remain in your account; the control plane handles deployment metadata only.

From there, the day-2 governance maps cleanly onto the control matrix:

• Per-environment and per-service RBAC so claims, underwriting, and vendor-facing teams reach only the environments they own - this maps directly to SOC 2 logical access criteria and the HIPAA access control standard.
• Git-push deployments with an immutable deployment history, where every change traces to a commit, an author, and an approval - which is precisely the change-management evidence internal audit asks for.
• Preview environments per pull request plus environment auto-stop, so non-production environments are short-lived, cheap, and far easier to keep PHI-free.
• Managed cluster upgrades that keep the Kubernetes layer patched, mapping to the patch and vulnerability management controls that otherwise eat a platform engineer's quarter.
• Databases backed by managed cloud services (Amazon RDS, Cloud SQL, Azure Database and equivalents), so encryption, backup, and HIPAA eligibility inherit from the cloud provider's own BAA-covered services.

How it coexists with the rest of the stack: Terraform or OpenTofu for the landing zone, Qovery for application deployment and environment governance, Drata or Vanta for evidence collection, and a managed partner for security operations if you need one. Qovery does not replace any of those.

And to be plain about the boundaries: Qovery is not a HITRUST managed services provider, not an audit firm, and not a substitute for compliance automation. Qovery does maintain a published trust center with its current security posture - check trust.qovery.com for the up-to-date certification, SOC 2, and BAA specifics rather than taking my word for a point-in-time claim here.

Build in-house, hire a managed partner, or use a platform - which is cheaper for a mid-size insurer?

Building a compliant internal platform from scratch typically consumes two to four platform engineers for nine to eighteen months before the first audited deployment. A managed regulated-cloud partner converts that into opex and gets you to a compliant baseline fastest, but puts every change into their queue. An internal developer platform on your own cloud account lands between the two and keeps the cloud contract and discounts in your name. There is no universally correct answer; there is a correct answer for your team's size.

Price the in-house option with real numbers. Platform engineers run a median base around $172,000 and total compensation around $235,000 at mid-career in the US (Levels.fyi), so a three-person team is roughly $700,000 a year in loaded comp before auditor fees - with the slowest time to first compliant deploy and the highest key-person risk.

The hybrid is common and legitimate: a partner for the landing zone and security operations, a platform for the developer workflow, compliance automation for evidence collection, and your own team owning the control matrix. Whatever you pick, name the hidden costs out loud - audit-readiness labor, evidence screenshotting, non-production environments left running 24/7, and the brutal cost of a failed audit window forcing you to restart the observation clock.

Frequently asked questions

Can one control set satisfy SOC 2, HIPAA, and internal audit at the same time?

Yes. The large majority of the technical controls - logical access, encryption, audit logging, change management, incident response, vendor management - are identical across all three. You build one control matrix and one evidence pipeline, then produce three reports from it. What differs is scope, who assesses you, and the final artifact, not the underlying controls.

Is there such a thing as a HIPAA certified cloud platform?

No. HIPAA has no certification body and no certificate. A vendor demonstrates HIPAA alignment by signing a Business Associate Agreement and providing a SOC 2 Type II or HITRUST report as the accepted proxy. Any vendor advertising itself as "HIPAA certified" is misrepresenting how HIPAA works, which is a reason for caution.

Which cloud providers sign a HIPAA Business Associate Agreement, and how many services does it cover?

AWS, Google Cloud, and Azure all sign BAAs. AWS lists 100-plus HIPAA-eligible services and offers a self-serve BAA through Artifact; Google Cloud's BAA covers its full infrastructure plus a published Covered Products list; Azure's BAA applies by default through the Product Terms for in-scope services. The counts change frequently, so verify each specific service against the provider's current eligible-services page before putting PHI on it.

Do I need SOC 2 Type I or Type II for an insurance or healthcare cloud migration?

Type II, in almost every case. Type I attests that controls are designed correctly at a single point in time; Type II attests they operated effectively over a window, typically three to twelve months. Enterprise and regulated buyers expect Type II because it proves the controls actually ran, not just that they existed on paper the day the auditor visited.

Should we use Terraform, OpenTofu, or an internal developer platform for compliant deployments?

Both - they solve different problems. Terraform or OpenTofu provisions the landing zone as reviewable, diffable infrastructure, which is strong audit evidence. An internal developer platform governs the application deployment workflow and per-environment access, which is where your ongoing change-management evidence comes from. Use IaC for the foundation and a platform like Qovery for day-2 deployment and governance.

Is Qovery HIPAA compliant, and does Qovery store our PHI?

Qovery deploys into your own cloud account, so your workloads, databases, secrets, and any PHI stay under your own cloud provider's BAA and never leave your account - the control plane handles deployment metadata only. For Qovery's current certifications, SOC 2 status, and BAA specifics, check trust.qovery.com rather than relying on a point-in-time claim.

How long does a legacy insurance application migration take when multiple compliance frameworks apply?

Plan for a full fiscal year, and front-load the controls. The limiting factor is usually the SOC 2 Type II observation window, which needs months of operating evidence, so the platform and controls have to be live early. Teams that stand up governance in Phase 0 and run a non-PHI pathfinder before touching the core system hit their audit window on schedule; teams that install the platform late restart the clock.

If you are assembling this stack and want the deployment and environment-governance layer to run inside your own cloud account - so your workloads and data stay under your own contracts - that is exactly where Qovery fits. Start there, keep the auditor and the managed partner in the stack, and let the evidence build itself.