Most HIPAA guidance is written for compliance officers, not engineers. Translated into infrastructure, the Security Rule is a fairly concrete checklist and the Privacy Rule is an access-control model. Here is how we map each one onto the systems you actually run.
The Security Rule is your access, audit, and encryption spec
The Security Rule's technical safeguards read almost like a platform backlog. Access control means unique user IDs, automatic logoff, and least-privilege IAM, not a shared admin login. Audit controls mean systems that record who touched PHI. Integrity controls mean you can prove records were not altered. Transmission security means encryption in transit. We implement these as code: SSO-backed IAM with short-lived sessions, centralized audit logging, and TLS everywhere PHI moves, all encrypted at rest with envelope keys you control.
The Privacy Rule is minimum-necessary, enforced by IAM
The Privacy Rule's minimum-necessary standard is an authorization problem. An engineer debugging a billing service does not need to read clinical notes; a support agent does not need raw PHI when a tokenized reference will do. We design role- and attribute-based access so each system, and each human, sees only the PHI its job requires, and we make de-identification the default path for analytics and lower environments.
A BAA is necessary, not sufficient
AWS, Azure, and GCP will all sign a Business Associate Agreement and cover their HIPAA-eligible services. That does not encrypt your buckets, scope your IAM, or turn on logging. Under the shared responsibility model, the configuration is yours. We build the controls that make the BAA meaningful and enforce allow-lists so PHI never lands on a service the BAA does not cover.
HITRUST is the certifiable overlay
HIPAA tells you to encrypt PHI; HITRUST CSF tells you the key length, rotation cadence, and evidence format, and gives you a certificate that enterprise customers and payers actually recognize. Because HITRUST maps to SOC 2, NIST, and ISO 27001, one well-instrumented control environment can satisfy several frameworks at once. We generate that evidence from your infrastructure-as-code and Git history rather than assembling it by hand before each assessment.
Change control a clinician-safe system can live with
Segregation of duties and documented change control are non-negotiable, but they do not require a weekly change advisory board that clicks approve on everything. We tier changes by risk: low-risk changes ship on green with a full audit trail, while changes to PHI stores or clinical workflows get explicit peer approval and a hard separation between who writes and who releases. Velocity where it is safe; friction only where it counts.
Ship secure by default, not secure-after-audit
Compliance evidence is worthless if the code moving through the pipeline is insecure. That is more acute now that AI assistants generate large volumes of plausible-but-unreviewed code; we wrote about the resulting security tech debt and design a secure SDLC to catch it: SAST, dependency and container scanning, secret detection, and SBOMs as pipeline gates, not afterthoughts.
Clinical systems fail closed, and stay up
PHI protection means little if the system is down when a clinician needs it. High availability is a patient-safety property, not just an SLA line item. We bring the same reliability engineering we run for SaaS platforms to clinical workloads: multi-AZ and multi-region design, error budgets, and incident response, delivered through our SRE practice.
None of this is theoretical. We run the same evidence-first playbook under other strict regimes, PCI-DSS, SOC 2, and RBI, for regulated finance clients; see DevOps for Fintech for the parallel. Compliance frameworks differ; the engineering discipline that satisfies them does not.