Dashboard Academy Control templates HIPAA Security Rule
Public Beta. Reference implementation only — not a compliance certification, attestation, or audit outcome. Read the full beta disclaimer →

Control template: HIPAA Security Rule

Status: Public Beta · Version: hipaa-security-rule/v0.1.0-beta

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

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

HIPAA Security Rule citation Architectural surface Control alias
§164.312(a)(2)(i) Unique user identification hipaa-unique-user-id
§164.312(a)(2)(ii) Emergency access procedure hipaa-emergency-access
§164.312(a)(2)(iii) Automatic logoff hipaa-automatic-logoff
§164.312(a)(2)(iv) Encryption / decryption of ePHI at rest hipaa-ephi-encryption-at-rest
§164.312(b) Audit controls (logging) hipaa-audit-controls
§164.312(c)(1) Integrity (tamper-evidence on ePHI) hipaa-integrity-controls
§164.312(d) Person / entity authentication (MFA) hipaa-authentication
§164.312(e)(1)+(2)(i)+(2)(ii) Transmission security (encryption in transit) hipaa-transmission-security
§164.308(a)(1)(ii)(D) Information system activity review hipaa-activity-review
§164.308(a)(7)(ii)(A) Data backup plan hipaa-data-backup-plan
§164.308(a)(7)(ii)(B) Disaster recovery plan hipaa-disaster-recovery

11 controls covering the Technical Safeguards in full plus the architecturally enforceable Administrative Safeguards. 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)(i) — Unique user identification (hipaa-unique-user-id)

Per-node. No shared accounts; every access is traceable to a named individual.

"hipaa-unique-user-id": {
  "description": "HIPAA §164.312(a)(2)(i) — assign a unique name and/or number for identifying and tracking user identity on ePHI access.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/unique-user-id",
      "config": {
        "control-id": "hipaa-unique-user-id",
        "shared-accounts-allowed": false,
        "identity-provider": "okta",
        "service-account-naming-convention": "svc-<system>-<purpose>"
      }
    }
  ]
}

§164.312(a)(2)(ii) — Emergency access procedure (hipaa-emergency-access)

Per-node. Documented break-glass mechanism for accessing ePHI during emergencies, with mandatory after-action review.

"hipaa-emergency-access": {
  "description": "HIPAA §164.312(a)(2)(ii) — emergency access procedure to obtain necessary ePHI during emergencies. Break-glass access is logged and reviewed after the event.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/emergency-access",
      "config": {
        "control-id": "hipaa-emergency-access",
        "break-glass-procedure-url": "https://internal.example.com/hipaa/break-glass",
        "post-event-review-required": true,
        "post-event-review-deadline-hours": 48,
        "logged-to": "centralized-siem-immutable"
      }
    }
  ]
}

§164.312(a)(2)(iii) — Automatic logoff (hipaa-automatic-logoff)

Per-node.

"hipaa-automatic-logoff": {
  "description": "HIPAA §164.312(a)(2)(iii) — terminate an electronic session after a predetermined time of inactivity.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/automatic-logoff",
      "config": {
        "control-id": "hipaa-automatic-logoff",
        "session-timeout-minutes": 15,
        "enforcement-layer": "session-middleware"
      }
    }
  ]
}

§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(b) — Audit controls (hipaa-audit-controls)

Per-node.

"hipaa-audit-controls": {
  "description": "HIPAA §164.312(b) — hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/audit-controls",
      "config": {
        "control-id": "hipaa-audit-controls",
        "events": ["read", "write", "auth-success", "auth-failure", "privilege-elevation", "config-change", "ephi-export"],
        "destination": "centralized-siem",
        "immutable": true,
        "retention-days": 2192
      }
    }
  ]
}

Note on retention: 2192 days = 6 years. HIPAA §164.316(b)(2)(i) requires policy and procedure documentation be retained for 6 years from the date of creation or last effective date. Many covered entities apply the same 6-year retention to audit logs. Tune to your retention policy.

§164.312(c)(1) — Integrity (hipaa-integrity-controls)

Per-node.

"hipaa-integrity-controls": {
  "description": "HIPAA §164.312(c)(1) — protect ePHI from improper alteration or destruction. Tamper-evidence required on ePHI stores; verify integrity on read.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/integrity-controls",
      "config": {
        "control-id": "hipaa-integrity-controls",
        "integrity-mechanism": "hmac-sha256-or-digital-signature",
        "verify-on-read": true,
        "tampering-alerts-to": "security-soc@example.com"
      }
    }
  ]
}

§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-protocols": ["http", "ftp", "telnet", "smtp-plain", "ws"],
          "integrity-mechanism": "tls-aead-or-message-auth-code",
          "mutual-auth-required-for-organization-boundary": true
        }
      }
    ]
  }
}

§164.308(a)(1)(ii)(D) — Information system activity review (hipaa-activity-review)

Graph-level. Declare the firm's process for periodic review of information-system audit data.

"metadata": {
  "controls": {
    "hipaa-activity-review": {
      "description": "HIPAA §164.308(a)(1)(ii)(D) — implement procedures to regularly review records of information-system activity (audit logs, access reports, security-incident tracking).",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/hipaa/activity-review",
          "config": {
            "control-id": "hipaa-activity-review",
            "review-frequency": "monthly",
            "responsible-role": "security-officer",
            "scope": ["audit-logs", "access-reports", "incident-records"],
            "review-evidence-url": "https://internal.example.com/hipaa/activity-reviews"
          }
        }
      ]
    }
  }
}

§164.308(a)(7)(ii)(A) — Data backup plan (hipaa-data-backup-plan)

Per-node.

"hipaa-data-backup-plan": {
  "description": "HIPAA §164.308(a)(7)(ii)(A) — establish and implement procedures to create and maintain retrievable exact copies of ePHI.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/data-backup-plan",
      "config": {
        "control-id": "hipaa-data-backup-plan",
        "backup-frequency": "hourly",
        "backup-encryption-at-rest": true,
        "backup-storage": "geographically-separate",
        "backup-retention-days": 2192
      }
    }
  ]
}

§164.308(a)(7)(ii)(B) — Disaster recovery (hipaa-disaster-recovery)

Per-node.

"hipaa-disaster-recovery": {
  "description": "HIPAA §164.308(a)(7)(ii)(B) — establish (and implement as needed) procedures to restore any loss of ePHI data.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/hipaa/disaster-recovery",
      "config": {
        "control-id": "hipaa-disaster-recovery",
        "rpo-minutes": 30,
        "rto-minutes": 240,
        "restoration-test-frequency": "semi-annual",
        "last-restoration-test-date": "2025-04-15",
        "dr-plan-document-url": "https://internal.example.com/hipaa/dr-plan"
      }
    }
  ]
}

What the engine enforces

Same constraint engine that handles PCI / DORA / SOX / your own controls. Per-rule behavior:

All deterministic — pure function over your CALM JSON. Verdicts are replayable byte-for-byte. Same trust direction as the other framework templates: ArchRails enforces what you authored.

BAA boundary note

When ePHI crosses an organizational boundary (covered entity → business associate, or BA → subcontractor BA), HIPAA requires a Business Associate Agreement (BAA) in place. This template records the technical controls; the BAA itself is contractual and out of architectural scope. Document BAAs in your firm's HIPAA program. Tag relationships that cross the BAA boundary:

// On a relationship that crosses the BAA boundary:
"metadata": {
  "crosses-baa-boundary": true,
  "baa-counterparty": "Acme Cloud Health Storage Inc.",
  "baa-document-url": "https://internal.example.com/hipaa/baas/acme-cloud-health"
}

ArchRails surfaces this metadata; your privacy / legal team owns the contractual lifecycle.

Auto-include during bootstrap (coming)

A future release will let archrails bootstrap detect healthcare repos (by asking, or by detecting phi / ehr / hl7 / fhir strings) and offer to auto-include this template. Until that ships, copy-paste.

Versioning

This is hipaa-security-rule/v0.1.0-beta. Pre-1.0 = beta. Bumps:

Updates as HHS-OCR enforcement priorities shift or as the Security Rule is amended (the proposed 2024 NPRM would materially expand several specifications — when finalized, this template publishes a new major version covering the changes). The constraint engine evaluates every version identically.

Out of scope for this template

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