HIPAA-Minded Architecture: An Engineering Checklist for Healthcare Product Teams

HIPAA compliance is not a security product you install. It is an ongoing set of engineering decisions about what data you store, who can access it, how it moves between services, and how you prove all of that to an auditor. This checklist is designed for engineering teams building or modernising healthcare software who want to get the foundational controls right from the start.

Define Your PHI Boundary First

Before writing a line of code, answer these questions about data scope:

• Which fields in your data model constitute PHI? (name + DOB + diagnosis, IP address + condition, appointment record, etc.)
• Which services touch PHI — even temporarily in memory, logs, or queues?
• Where does PHI leave your system? (third-party APIs, analytics, email providers)
• Which environments carry real PHI? (should only be production, with anonymised data in staging)

Document this boundary. It becomes the scope of every other control in this checklist.

Encryption: At Rest and In Transit

• At rest: Use AES-256 encryption for all PHI storage — databases, object storage (S3 with SSE-KMS), and backups. Use customer-managed keys where key rotation and audit evidence are required.
• In transit: Enforce TLS 1.2+ for all service-to-service communication, including internal VPC traffic where PHI is present. Reject downgrade requests.
• Application-level encryption: Consider field-level encryption for the most sensitive identifiers (SSN, diagnosis codes) so that a database breach does not expose plaintext PHI.
• Key management: Use AWS KMS, GCP Cloud KMS, or Azure Key Vault. Document rotation policy — HIPAA does not specify a rotation frequency, but annual rotation with documented justification is common practice.

Access Control and Minimum Necessary Access

HIPAA's Minimum Necessary standard means users and services should only access PHI required for their specific function. Implement this at multiple layers:

• Role-based access control (RBAC) scoped to patient cohorts or facility, not global read
• Attribute-based access control (ABAC) for more granular policies (treating clinician on record)
• Service-to-service: least-privilege IAM roles for every Lambda, container, or worker touching PHI
• Admin access: require MFA and just-in-time elevation for privileged database access
• Third-party integrations: scope OAuth tokens to minimum required scopes, review quarterly

Audit Logging That Actually Satisfies Auditors

An audit log is only useful if it captures the right events and cannot be altered. Design for this explicitly:

• Log every access to PHI: user ID, timestamp, action (read/write/delete), record ID, IP address
• Log all authentication events: login, failed login, MFA bypass, session expiry
• Log all administrative actions: permission changes, user provisioning, config updates
• Send logs to a write-once destination (CloudWatch with no-delete policy, S3 with Object Lock, or a dedicated SIEM)
• Retain audit logs for a minimum of 6 years per HIPAA documentation requirements
• Alert on anomalous patterns: bulk exports, off-hours access, repeated failed authentication

Data Transmission and Integration Controls

• Any PHI leaving your system (to a lab, EHR, insurer, analytics platform) must be covered by a BAA with that vendor
• Use HL7 FHIR APIs with OAuth 2.0 / SMART on FHIR for standardised, auditable data exchange
• Avoid PHI in URL parameters or HTTP headers — use request bodies over TLS
• Webhook payloads containing PHI must be signed (HMAC) and delivered over HTTPS with certificate validation
• Never send PHI to analytics or error-tracking tools (Segment, Sentry, Datadog) — strip or hash identifiers before ingestion

Infrastructure and Cloud Configuration

• Sign BAAs with your cloud provider before workloads go live
• Enable CloudTrail / Cloud Audit Logs for all management plane events across all regions
• Use VPC with private subnets for all PHI-holding services; no public database endpoints
• Enable S3 Block Public Access at the account level; audit bucket policies quarterly
• Enforce resource tagging policy for PHI-scope resources — this supports automated compliance monitoring
• Use AWS Config / Security Hub / GCP Security Command Centre for continuous configuration compliance checks

Breach Detection and Incident Response

HIPAA requires notification within 60 days of discovering a breach affecting 500+ individuals. Preparation reduces that timeline and limits harm:

• Define what constitutes a reportable breach and who makes the determination
• Set up automated alerts for: unusual data export volumes, access from unexpected geographies, new IAM principals accessing PHI
• Maintain a runbook: containment steps, forensic evidence collection, legal notification process
• Run a tabletop exercise annually — engineering, legal, and leadership together

What to Prioritise in an MVP

If you are building a healthcare MVP on a short timeline, these controls must be in place before launch regardless of scale:

1. PHI boundary documented and reviewed
2. Encryption at rest and in transit enforced
3. MFA required for all users accessing PHI
4. Audit log capturing access and authentication events
5. BAA signed with cloud provider and any third-party tools touching PHI
6. No PHI in staging, error logs, or analytics pipelines

Getting these right from the start is far cheaper than retrofitting them after your first audit. We have helped healthcare teams build HIPAA-ready products from the ground up as part of our 4-week MVP programme. If you are at the architecture stage, get in touch and we can review your current design.