Control template: HIPAA Security Rule

Status: Stable · Version: hipaa-security-rule/v1.0.0

A bundle of CALM control snippets covering the architecturally enforceable subset of the HIPAA Security Rule (45 CFR §§ 164.302–318). You copy these into your *.calm.json files on the nodes that store, transmit, or process electronic Protected Health Information (ePHI).

Who the HIPAA Security Rule applies to

• Covered entities (CEs): healthcare providers, health plans, and healthcare clearinghouses that transmit health information electronically in connection with HHS-defined standard transactions (45 CFR §160.102–103).
• Business associates (BAs): vendors, cloud providers, consultants, and other organizations that create, receive, maintain, or transmit ePHI on behalf of a covered entity (45 CFR §160.103). BAs are directly liable under HITECH amendments.
• Subcontractors of BAs: also directly liable as "downstream business associates."

If your organization handles ePHI in any of these roles, the Security Rule applies. The template focuses on the Technical Safeguards (§164.312) plus the architectural slice of the Administrative Safeguards (§164.308). Physical Safeguards (§164.310) are out of architectural scope (facility access, workstation security, device disposal).

What this template covers

3 controls covering the architecturally enforceable Technical Safeguards. Administrative Safeguards (activity review, backup plan, disaster recovery, emergency access procedure) and Physical Safeguards (§164.310) are out of architectural scope — document those in your firm's HIPAA program.

The ePHI-scope pattern

A node handles ePHI if it stores, processes, transmits, or significantly influences electronic Protected Health Information. Tag those nodes explicitly:

{
  "unique-id": "patient-records-service",
  "node-type": "service",
  "name": "Patient Records Service",
  "metadata": {
    "ephi-in-scope": true,
    "data-classification": "phi",
    "hipaa-role": "covered-entity-system",
    "baa-required-for-downstream": true
  }
}

Then attach the relevant controls below. Stricter expectations apply to nodes that transmit ePHI across organizational boundaries (those require BAAs and stronger transmission-security controls).

Control snippets

Copy each block under the controls key of the node it applies to.

§164.312(a)(2)(iv) — ePHI encryption at rest (hipaa-ephi-encryption-at-rest)

Per-node.

"hipaa-ephi-encryption-at-rest": {
  "description": "HIPAA §164.312(a)(2)(iv) — encryption of ePHI at rest. Addressable implementation specification; per HHS guidance, recommended approach is industry-standard cryptography (AES-256 or stronger).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/ephi-encryption-at-rest",
      "config": {
        "control-id": "hipaa-ephi-encryption-at-rest",
        "algorithm": "AES-256-GCM",
        "key-management": "hsm-or-kms-cmk",
        "key-rotation-days": 365,
        "fips-140-validated": true
      }
    }
  ]
}

§164.312(d) — Person / entity authentication (hipaa-authentication)

Per-node.

"hipaa-authentication": {
  "description": "HIPAA §164.312(d) — procedures to verify that a person or entity seeking access to ePHI is the one claimed. MFA strongly recommended per HHS guidance.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/authentication",
      "config": {
        "control-id": "hipaa-authentication",
        "mechanism": "saml-sso-plus-mfa",
        "factor-count": 2,
        "factor-types": ["password", "totp-or-webauthn"],
        "service-to-service-auth": "mtls-or-oauth2-client-credentials"
      }
    }
  ]
}

§164.312(e) — Transmission security (hipaa-transmission-security)

Relationship-level. Attach to edges that carry ePHI.

// On a relationship that transmits ePHI:
"controls": {
  "hipaa-transmission-security": {
    "description": "HIPAA §164.312(e)(1) + (2)(i) integrity controls + (2)(ii) encryption — ePHI in transit protected by strong cryptography over networks not exclusively under the firm's control.",
    "requirements": [
      {
        "requirement-url": "https://archrails.io/catalog/req/hipaa/transmission-security",
        "config": {
          "control-id": "hipaa-transmission-security",
          "minimum-tls-version": ["1.2", "1.3"],
          "forbidden-fields": ["http", "ftp", "telnet", "smtp-plain", "ws"],
          "integrity-mechanism": "tls-aead-or-message-auth-code",
          "mutual-auth-required-for-organization-boundary": true
        }
      }
    ]
  }
}

What the engine actually enforces

There is no HIPAA-specific cross-cutter — the engine has no "if ephi-in-scope: true, require these controls" sweep. Enforcement is graph-driven: you attach a control where you want it enforced; the absence of an attach is opt-out by silence.

For the 3 HIPAA controls above, here is the enforcement map:

• hipaa-ephi-encryption-at-rest — the architectural weak-crypto validator fires on deprecated algorithm references (MD5, SHA1, DES, RC4 etc.) in code on the PHI-classified node.
• hipaa-authentication — the authorization-removal validator fires when a code change strips @PreAuthorize (or equivalent) on a PHI-classified node, carrying §164.312(d) intent at code-change time.
• hipaa-transmission-security — the forbidden-fields list (http, ftp, telnet, smtp-plain, ws) feeds the regex-control validator; the relationship-protocol check fires when a code change adds a plaintext call across an edge declared TLS-carrying.

The other Technical Safeguards (unique user ID, automatic logoff, audit-event logging, integrity controls) declare policy or operational intent that no current ArchRails validator fires on against a diff. Author them in your HIPAA program documentation rather than CALM.

All checks are deterministic — pure function over your CALM JSON. Verdicts are replayable byte-for-byte. The same constraint engine handles PCI DSS, GDPR, SOC 2, MiFID II, ISO 27001:2022, NIST CSF 2, NYDFS Part 500, and any controls you author yourself.

Versioning

This is hipaa-security-rule/v1.0.0 — the first stable cut. Each surviving control has per-validator firing tests + cross-language coverage across 11 Tier A languages (Python, Java, C#, TypeScript, Go, Kotlin, Scala, Rust, Ruby, Swift, PHP). Future bumps: v1.x.y for additive controls and substantive validator coverage; v2.0.0 for breaking changes (control retired, semantics changed). Updates as authoritative guidance or enforcement priorities materially shift.

Out of scope for this template

• Physical Safeguards (§164.310) — facility access, workstation security, device disposal. Not architectural.
• Privacy Rule (§164.500-534) — uses and disclosures, notice of privacy practices, individual rights. Mostly process, not architectural.
• Breach Notification Rule (§164.400-414) — incident-detection architecture overlaps with audit controls above; the notification workflow itself is process.
• HITECH-specific provisions — penalty tiers, breach-disclosure thresholds: regulatory metadata, not architectural.
• HITRUST CSF certification — a separate, voluntary, third-party certification that maps to HIPAA + other frameworks; ArchRails does not certify HITRUST.

For those surfaces, pair this template with your HIPAA program documentation and engage a HIPAA-qualified auditor for certification.