Compliance is a code property HIPAA, SOC 2, and HITRUST as things you ship, not slides you write.

The standard failure mode in healthcare software is a slide deck called HIPAA Compliance that has no functional relationship to the running system. It cites §164.308 through §164.312, it lists policies the team agrees to follow, it includes a diagram with a lock icon over a database. None of it is executable. None of it stops a single unsafe action at runtime. The deck is read once during procurement and once more during an incident, and between those two readings the actual system does whatever the actual code says it does.

That gap is where compliance becomes theater. A team can pass vendor security questionnaires for years while leaking PHI through a logging library, a forgotten test endpoint, or a vendor that was never under a BAA. The auditor never finds it because the auditor reads the deck. The patient never finds out because the breach is silent. The regulator finds out eventually, and the conversation that follows is not about the deck.

Compliance is not a document about the system. It is a property of the system. If you cannot point at running code and show me where the rule is enforced, the rule is not enforced.

What it means to treat compliance as a code property

Reframe the question. Instead of do we have a policy, ask where in the deployed system is this rule a constraint that cannot be bypassed. The answer should be a file path, a type signature, a database column, a CI gate, or a key custody boundary. If the answer is a paragraph in a Notion page, the rule is not in the system.

A short list of the things that actually matter, each of which can be expressed as code:

1. Row-level audit. Every read and write against PHI produces an append-only event with actor, subject, purpose, policy version, and timestamp.
2. PHI boundaries in the schema. Tables that contain PHI are typed and tagged. Cross-boundary joins go through a policy function or they do not compile.
3. BAA-scoped vendor surface. The list of services that can receive PHI is enumerated and enforced at the egress layer, not in a vendor spreadsheet.
4. Key custody. Envelope encryption with a separate KMS, documented key holders, scheduled rotation, and a tested procedure for revoking access in under fifteen minutes.
5. Log retention. Six years for audit, the minimum under §164.316, with immutability that is enforced by the storage layer, not by policy.
6. Time-to-revoke. A measured number for how long it takes to fully remove an offboarded employee's access, including third-party tools and any cached tokens.

None of those bullets are aspirational. Each one is a code artifact a reviewer can run, read, or query. That is the distinction between compliance-as-code and compliance-as-deck.

The PHI boundary as a typed value

The single highest-leverage pattern is to treat PHI as a type, not a convention. In a strongly typed codebase, every read of PHI should go through a policy function that takes the actor, the subject, and the purpose, and returns either the value or a typed refusal. Every write should produce an audit row in the same transaction, not a fire-and-forget log line.

type PHI<T> = {
  readonly value: T,
  readonly subjectId: PatientId,
  readonly dataClass: "demographic" | "clinical" | "payment",
}

// All PHI access flows through this single accessor.
// There is no other way to read the value out of PHI<T>.
function readPHI<T>(
  actor: Actor,
  field: PHI<T>,
  purpose: AccessPurpose,        // "treatment" | "payment" | "operations" | ...
  policy: PolicyBundle,          // signed, versioned, see §below
): Result<T, AccessDenied> {

  const decision = policy.evaluate({
    actorRole: actor.role,
    subjectId: field.subjectId,
    dataClass: field.dataClass,
    purpose,
  })

  // Append-only audit row, written in the same transaction
  // as any downstream use. No row, no value.
  audit.append({
    actor: actor.id,
    subject: field.subjectId,
    dataClass: field.dataClass,
    purpose,
    decision: decision.kind,        // allow | deny
    policyVersion: policy.version,
    policyChecksum: policy.checksum,
    timestamp: now(),
  })

  if (decision.kind === "deny") return Err(decision.reason)
  return Ok(field.value)
}

The point of this signature is not the specific language. The point is that the value is unreachable without the policy evaluation and the audit row. A new engineer cannot accidentally pipe PHI into a log statement, because there is no path from PHI<T> to T that does not go through this function. The audit table becomes the source of truth for what was accessed, by whom, for what, and against which version of the policy. That table is the artifact an auditor actually wants to see.

HIPAA §164.308 to §164.312, as code artifacts

The Security Rule is often treated as a paraphrasing exercise. Each subsection maps cleanly to a concrete engineering artifact, and the map is the same across most production healthcare systems.

• §164.308 administrative safeguards. Role definitions in code (RBAC), an offboarding runbook with a measured time-to-revoke, and a workforce access review that reads from the actual IAM state, not a spreadsheet.
• §164.310 physical safeguards. Inherited from your cloud provider's SOC 2 and ISO 27001 attestations, plus a documented device policy for any human endpoint that touches production.
• §164.312(a) access control. RBAC enforced inside the policy function above. Unique user identification is a foreign key, not a convention. Automatic logoff is a session timeout in the auth layer.
• §164.312(b) audit controls. The append-only event log. Immutable at the storage layer. Queried by both engineering and compliance from the same underlying table.
• §164.312(c) integrity. Signed checksums on policy bundles, signed checksums on model artifacts, and a replay mechanism that can reconstruct any past decision from the audit log and the version-pinned policy.
• §164.312(e) transmission security. mTLS between services, envelope encryption for data at rest, and a tested path for revoking the KEK if a key holder leaves.

Every one of those is a thing you can run a test against. None of them is a paragraph that asks the reader to trust the team.

SOC 2 Type II is the build, not a sprint

The most common misreading of SOC 2 is that it is something you do in the month before the auditor arrives. SOC 2 Type II is the opposite. It tests whether your controls have operated continuously over a period, usually six to twelve months. The audit is the build.

Treat the trust service criteria the way you treat a test suite. CC1 through CC5 (control environment, communication, risk assessment, monitoring, control activities) are mostly organizational, but the artifacts behind them, change management, access reviews, vendor reviews, are all queryable systems. CC6 (logical and physical access) is your IAM and your network policy. CC7 (system operations) is your incident response, your on-call rotation, your monitoring. CC8 (change management) is your CI pipeline. CC9 (risk mitigation) is your vendor and BAA inventory.

Each of those becomes a CI gate. A PR that introduces a new third-party service should fail the build until the vendor is added to the BAA inventory, the egress allow-list is updated, and the data classification of what flows to that vendor is declared. A PR that adds a new role should fail the build until the role appears in the access review export. A PR that touches the policy bundle should fail the build until the bundle is re-signed and the checksum is updated.

The eval harness is the runtime version of the same idea. SOC 2 asks whether your controls operate continuously. The eval harness asks whether your model operates within its tested envelope continuously. Same shape, different layer.

HITRUST CSF v11, when and why

HITRUST is the superset. The current CSF v11 framework maps HIPAA, SOC 2, NIST 800-53, ISO 27001, and a handful of state-level requirements into a single set of controls with specific implementation maturity levels. It is more work, and the certification is more expensive, but for some operators it is the only credible answer.

The honest rule of thumb. If you sell to large payers, large integrated delivery networks, or any covered entity that has been burned before, the procurement team will ask for a HITRUST r2 or i1 letter. If you sell to clinics, smaller groups, and most DPC-style organizations, SOC 2 Type II plus a clean HIPAA posture is usually sufficient. Pursuing HITRUST early, before the deal flow requires it, is a real cost without a real return. Pursuing it late, after the deal flow requires it, is a six to nine month delay on a contract you have already signed.

BAA scoping is architecture

The vendor list is part of the system, not part of the paperwork. Every BAA-covered vendor is an additional attack surface, an additional key custody dependency, and an additional place where PHI can leave the controlled boundary. The architecture has to constrain this explicitly.

Practically, that means egress from any service that handles PHI is not open to the public internet. It is restricted to a declared allow-list of BAA-covered endpoints. Adding a vendor is a code change, not a Notion update. Removing a vendor is a code change. The vendor inventory in your HIPAA compliance program should be generated from the egress configuration, not the other way around. If the two ever disagree, the configuration wins, because the configuration is what is actually in production.

The honest tradeoff

Compliance-as-code is not free. It requires engineering discipline that compliance-as-deck does not. The PHI accessor pattern slows down some refactors. The egress allow-list slows down some vendor integrations. The append-only audit log uses real storage, and the policy bundle signing process adds a step to every release. The eval harness needs to be maintained the way a test suite is maintained, which means someone owns it.

What you get in return is that you cannot fake the audit and you do not need to. A reviewer can ask any question about any historical access to any patient record and you can answer it in a SQL query. You can show calibration of model behavior over time. You can produce an evidence package on demand instead of in a panic. Procurement cycles get shorter because the answers are not paraphrased, they are observed.

Some teams will prefer the deck. The deck is faster to produce, cheaper to maintain, and avoids the up-front engineering investment. It also reliably collapses under any real scrutiny, and it leaves the patient population exposed in ways the team does not see. The choice is real, and it is worth making deliberately.

The principle

Compliance is not the slide. Compliance is the system. HIPAA, SOC 2 Type II, and HITRUST are not certifications that decorate a marketing page. They are properties of a deployed architecture that either hold continuously or do not hold at all. The work to make them hold is engineering work, and the artifacts that prove they hold are code artifacts. If the auditor cannot point at the running system and see the control operating, the control is not operating, regardless of what the deck says.

The reframe is small but the consequences are large. Compliance stops being a quarterly distraction and becomes a continuous output of the build pipeline. The same engineers who ship features ship the controls. The same observability that catches production bugs catches access anomalies. The same review process that gates merges gates vendor additions. Once the architecture is built this way, compliance is something you ship, not something you write.