What goes wrong in digital health
The moment PHI enters your system, youโre operating under HIPAA
Early infrastructure decisions become compliance liabilities, causing teams to spend months on rework. These are the five failure modes we see most frequently.
Non-prod becomes in-scope
Staging turns into production. A support escalation needs โa real example,โ so someone copies a production row into staging. A demo environment quietly keeps real patient data because โweโll delete it later.โ It rarely gets deleted.
Access expands and never retracts
โTemporary adminโ becomes permanent. A contractor gets broad access for a migration. A break-glass key gets shared in Slack during an incident. A CI token that can read everything stays alive long after the fire is out.
Documentation drifts from reality
Docs say one thing, infra does another. The security policy says โleast privilege,โ but IAM roles are wide because tightening them breaks deploys. The runbook says โlogs retained,โ but retention depends on a tool nobody owns.
Customer security reviews force archaeology
Youโre asked to prove, not promise. Buyers ask: โShow me who accessed production,โ โHow long are logs retained,โ โWhat changed last week,โ โWhere does PHI go,โ โWhatโs your incident process.โ Deals stall or fail because teams canโt produce complete, attributable evidence on demand.
Deploy PHI workloads
Run apps, databases, and AI with encryption, isolation, access logging, and least-privilege IAM enforced by default.
Add services safely
Introduce new apps, workers, databases, or AI endpoints without redefining network boundaries, rewriting IAM, or rebuilding your logging model.
Produce audit artifacts
Export access history, change events, backup posture, and retention settings directly from the platform.
Pass security reviews
Answer diligence questions about PHI flow, isolation, access, and incident response without re-architecting your stack.
FAQs
Can we start building before we're ready to process PHI?
Yes. You can build and test on the Development plan with non-PHI environments, then move regulated apps and databases to a dedicated stack with an executed BAA before handling PHI.
Aptibleโs HIPAA documentation recommends that if you know youโll process ePHI, you should host on a dedicated stack from day one, since every resource there meets HIPAAโs required specifications by default. Support can migrate existing resources from a shared to a dedicated stack.
If youโre prototyping AI workflows, the LLM Gateway security and compliance model has separate BAA coverage and doesnโt require a dedicated stack.
Can we keep some services in AWS, S3, or external AI tools?
Yes. You could host apps and databases on Aptible, with S3, analytics, AI vendors, or other AWS services alongside, connected through VPC peering or a site-to-site VPN on a dedicated stack.
Any of those services that handles PHI needs appropriate controls and contracts of its own. For AI specifically, the LLM Gateway can centralize provider access and compliance controls under one BAA instead of negotiating with each provider. For private access patterns, Aptible also documents integrations such as Twingate.
What do our customers and auditors get as proof of infrastructure compliance?
From your own dashboard: a Shareable Compliance Posture Report, a print-friendly PDF showing how each control is implemented against the resources in scope, honoring whatever environment and control filters youโve applied.
You also get Activity Reports, which export every operation in an environment, including operations on resources since deleted.
From Aptible: the SOC 2 Type 2 Report, Penetration Test Summary, HITRUST CSF Letter of Certification and Validated Assessment Report, and the PCI DSS Service Provider Level 2 attestation are available through trust.aptible.com after e-signing an NDA. Aptibleโs Security & Compliance overview summarizes available compliance evidence, and Aptibleโs HITRUST shared responsibility matrix is published through the HITRUST Alliance.
You can also add a Secured by Aptible badge linking to the implemented controls.
Which of our telemetry destinations are in scope for PHI?
Treat any destination that receives PHI as in scope for your compliance program. If your app processes PHI, PHI may appear in application logs, SSH session logs, analytics events, traces, or AI prompts and responses unless your team actively prevents it.
Keep telemetry that may contain PHI inside Aptibleโs compliant infrastructure, or send it only to vendors with appropriate contractual coverage, including a BAA where required.
For AI workflows, Aptibleโs LLM Gateway keeps requests, responses, and audit logs inside compliant infrastructure under one BAA. Gateway providers are contractually prohibited from retaining or training on your data, and Aptibleโs LLM Gateway audit logging documentation explains retention and retrieval.
How do we keep staging and other non-production environments out of scope?
Donโt put PHI in staging or development. Use synthetic, anonymized, or de-identified data, and keep production and non-production in separate environments. Our guide to isolating staging and production compares the three common models and when each makes sense.
Shared stacks are built for development, testing, and staging and cannot hold regulated data. Aptible also recommends a leaner backup retention policy for non-production: 1 to 14 daily backups, no monthly or yearly, no cross-region copies, no final backups.
