Woyce
The Security Rule sets requirements, not implementations. This is what each one looks like as a concrete engineering decision, not a policy document.
| Rule | Requirement | How we build it |
|---|---|---|
| Access control | Unique user identification, emergency access, automatic logoff, encryption and decryption. | Role-based access control with per-tenant scoping, MFA enforced on every account with PHI reach, session timeouts, and documented break-glass access that alerts when used. |
| Audit controls | Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. | Append-only audit logs capturing actor, record, action, and timestamp for every PHI read and write. Retained to your policy, queryable, and shipped to storage the application itself cannot rewrite. |
| Integrity | Protect ePHI from improper alteration or destruction. | Versioned records rather than destructive updates, soft deletes with retention windows, checksums on stored documents, and restore procedures that get tested rather than documented and forgotten. |
| Transmission security | Guard against unauthorised access to ePHI transmitted over a network. | TLS 1.2+ on every hop including internal service calls, no PHI in URLs or query strings, and signed short-lived URLs for document access. |
| Encryption at rest | Addressable specification — implement, or document why an equivalent measure is reasonable. | KMS-managed encryption on databases, object storage, backups, and snapshots. We implement it rather than write the justification memo. |
| Business Associate contracts | Obtain satisfactory assurances that business associates safeguard ePHI. | We sign a BAA with you, and we check the BAA position of every subprocessor in the stack — model providers included — before PHI can reach them. |
What every healthcare build starts with, before the first feature ships.
Before any feature work, we draw the line: which services hold PHI, which never see it, and what crosses between them. Most compliance failures we are called in to fix are a boundary that was never drawn.
PHI stays inside AWS services covered by their BAA. Where a convenient managed service is not covered, we design around it rather than hope nobody asks.
Structured logging with PHI redaction at the emitter, scrubbed error reporting, and de-identification ahead of any third-party model call that is not covered by a BAA.
Scoped IAM roles per service, no shared credentials, and access grants that are reviewable — so the access-control matrix your customer's security review asks for already exists.
Architecture diagrams, data-flow documentation, and an access-control matrix handed over at launch. Your first enterprise customer will ask for these, and engineering should not be writing them under deadline.
Patterns we see often enough that they are worth naming before you make them.
Hosting on a BAA-covered platform is a precondition, not compliance. The application above it still has to handle access control, audit logging, and PHI minimisation — and that is where reviews actually fail.
The fastest way to turn an AI feature into a breach. Check the provider's BAA position for the specific deployment you are using, not the one on their marketing page.
Retrofitting audit trails means backfilling history you never captured. It is cheap in the first sprint and expensive in the twelfth.
Compliance automation tooling tracks your controls; it does not create them. It is useful, and it is not a substitute for the engineering.
There is no HIPAA certification scheme. A vendor claiming one is either confused or hoping you are — either way, it tells you something useful about them.
It means the application implements the HIPAA Security Rule's administrative, physical, and technical safeguards for electronic protected health information — access control, audit controls, integrity protection, and transmission security — and that every party handling PHI is under a Business Associate Agreement. It is an engineering and contractual posture, not a badge.
Usually, though the cost depends on how the PHI boundary was drawn originally. We start with a review of your data flows, access model, and logging, and come back with a prioritised remediation list. Retrofitting audit logging is normally the largest single item.
They answer different questions. HIPAA is a legal obligation covering PHI; SOC 2 is a voluntary attestation your enterprise customers may require regardless. Most digital health companies end up doing both, usually HIPAA first because it is not optional.
Only those covered by the AWS Business Associate Addendum, and the list changes, so it gets checked per project rather than from memory. The practical constraint is that convenience services often sit outside it, which shapes architecture decisions early.
Only on the specific tier that's actually covered — both offer BAA-eligible enterprise plans, but the free and standard API tiers are not covered by default, and that distinction gets missed more often than any other in a security review. We confirm the BAA position for your exact deployment during scoping and document it in the vendor list a security reviewer will ask to see.
For a greenfield product, the compliant baseline — boundary, encryption, access control, audit logging, BAA chain — is roughly the first two to three weeks of engineering and then a constraint on everything after. Retrofits vary far more widely and need a review to scope.