Evidence-of-design crosswalk. Not legal advice. The HIPAA Security Rule (45 CFR Part 164 Subpart C) is the binding federal regulation, enforced by the U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR). NIST SP 800-66 Rev. 2 is voluntary NIST implementation guidance, not a regulation in its own right. This crosswalk describes how SAIHM technology is designed to assist a HIPAA-regulated entity (Covered Entity or Business Associate) with selected Security Rule technical and physical-safeguard implementation specifications. It is not a HIPAA compliance certification, not a substitute for a Security Rule risk analysis under § 164.308(a)(1)(ii)(A), and not a substitute for qualified healthcare-privacy counsel. SAIHM, as open-source technology distributed under Apache 2.0, is not itself a Business Associate; Business-Associate Agreements (BAAs) between Covered Entities and any SAIHM-deploying Business Associate remain the regulated entity’s responsibility.
SAIHM × NIST SP 800-66 Rev. 2 (HIPAA Security Rule) crosswalk
NIST Special Publication 800-66 Revision 2: Implementing the HIPAA Security Rule — A Cybersecurity Resource Guide (Marron; published February 14, 2024; DOI 10.6028/NIST.SP.800-66r2) is the canonical NIST guide that helps HIPAA-regulated entities implement the Security Rule’s Administrative, Physical, and Technical safeguards. It supersedes SP 800-66 Rev. 1 (October 2008). Rev. 2 cross-references NIST SP 800-53 Rev. 5 controls, the NIST Cybersecurity Framework, and the NIST Risk Management Framework (NIST SP 800-37 Rev. 2); the formal HIPAA-Security-Rule-to-SP-800-53 mapping table has been removed from the PDF (Appendix D) and externalised to the NIST Cybersecurity and Privacy Reference Tool (CPRT) for ongoing maintenance.
SAIHM’s cell envelope (encryption-before-egress, per-cell data-encryption key, ML-DSA-65 signatures, on-chain audit anchor) and the saihm_forget cryptographic-erase operation are designed to assist regulated entities in addressing selected Security Rule implementation specifications — primarily Device-and-Media Controls § 164.310(d)(2)(i)/(ii) (Disposal and Media Re-use; both Required), and the Technical Safeguards under § 164.312 (Access Control, Audit Controls, Integrity, Person-or-Entity Authentication, Transmission Security). Whether any specification is satisfied in a given deployment is determined by the regulated entity’s own risk analysis and implementation choices, not by deploying SAIHM. This crosswalk is intended as an RFP-ready evidence-of-design artefact, subject to operator review and the regulated entity’s legal counsel.
Required vs Addressable — the framing that decides everything
The HIPAA Security Rule (§ 164.306(d)) classifies each implementation specification as either Required (R) or Addressable (A). Addressable does not mean optional: a regulated entity must (a) assess whether the specification is “reasonable and appropriate” in its environment; (b) if yes, implement it; (c) if no, document the rationale and implement an equivalent alternative measure (or document why no measure is reasonable and appropriate). SP 800-66 Rev. 2 reinforces this framing throughout Sections 5.1–5.5.
The implementation specifications most directly addressed by SAIHM, and their status under the rule, are:
| HIPAA Security Rule citation | Implementation specification | Status |
|---|---|---|
| § 164.310(d)(2)(i) | Disposal of ePHI / media | Required |
| § 164.310(d)(2)(ii) | Media Re-use (removal of ePHI before reuse) | Required |
| § 164.312(b) | Audit Controls | Required (standard) |
| § 164.312(c)(1) | Integrity | Required (standard) |
| § 164.312(d) | Person or Entity Authentication | Required (standard) |
| § 164.312(e)(1) | Transmission Security | Required (standard) |
| § 164.312(a)(2)(iv) | Encryption and Decryption (at rest) | Addressable |
| § 164.312(c)(2) | Mechanism to Authenticate ePHI (integrity) | Addressable |
| § 164.312(e)(2)(ii) | Encryption (transmission) | Addressable |
| § 164.308(a)(1)(ii)(A) | Risk Analysis | Required |
| § 164.308(a)(1)(ii)(B) | Risk Management | Required |
| § 164.314(a) | Business Associate Contracts | Required (organizational) |
Source: HIPAA Security Rule at 45 CFR § 164.306(d) and Table 1 of SP 800-66 Rev. 2 (pp. 12–13). The Required-vs-Addressable framing applies independently of whether SAIHM is deployed; SAIHM is one of several technology choices a regulated entity may use to address these specifications, and deploying SAIHM does not by itself satisfy any specification.
Technical Safeguards (§ 164.312) — primary SAIHM mappings
| HIPAA citation (& SP 800-66 R2 section) | SAIHM mechanism |
|---|---|
| § 164.312(a)(2)(iv) Encryption and Decryption (Addressable). SP 800-66 R2 § 5.3.1 sample question: “Based on the risk assessment, is encryption needed to effectively protect ePHI at rest from unauthorized access?” | SAIHM cells are encrypted with AES-256-GCM (FIPS-197 / NIST SP 800-38D), 256-bit key strength. Per-cell data-encryption keys (DEKs) are derived via HKDF-SHA-256 (RFC 5869) from a holder wallet-bound identity key, through the canonical chain MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1 with the per-cell DEK info-context MPS-CELL-DEK-v1, per the protocol specification (Internet-Draft draft-saihm-memory-protocol). By design, the operator does not hold plaintext. No ECB mode. FIPS-140-3 cryptographic module validation, where required by the regulated entity’s risk analysis, is an operator-selectable choice; the SAIHM reference implementation does not include a FIPS-140-3 module by default. |
| § 164.312(b) Audit Controls (Required). SP 800-66 R2 § 5.3.2: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” | Every SAIHM operation (saihm_remember, saihm_recall, saihm_forget, saihm_share, saihm_revoke_share, governance operations) emits a signed receipt and an audit anchor on the COTI V2 mainnet (chain ID 2632500, block explorer mainnet.cotiscan.io). The chain anchor attests to the occurrence, type, and timestamp of each event; receipt contents are signed with ML-DSA-65 (NIST FIPS-204). Operator-side audit records covering content-level detail (which ePHI elements were affected) remain a separate operator-domain obligation. |
| § 164.312(c)(1) Integrity (standard, Required) and § 164.312(c)(2) Mechanism to Authenticate ePHI (Addressable). SP 800-66 R2 § 5.3.3 Key Activity 5 example mechanisms: “Error-correcting memory; Digital signatures.” | SAIHM cells carry an ML-DSA-65 (FIPS-204) post-quantum signature over the encrypted cell payload and metadata. Verification at recall time corroborates that the cell has not been altered since signing. AES-256-GCM additionally provides authenticated encryption with associated data (AEAD), detecting any unauthorised modification of ciphertext or associated metadata. |
| § 164.312(d) Person or Entity Authentication (Required). SP 800-66 R2 § 5.3.4: “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.” The guide references NIST SP 800-63B for authentication. | SAIHM identity binding is signature-based: every operation must be signed by an ML-DSA-65 key derived from the holder’s wallet identity. The signature is verified at the protocol layer before any cell read, write, share, or erase. The wallet-bound key is “something the person has” (a cryptographic possession factor); multi-factor authentication at the holder’s endpoint (e.g., hardware wallet PIN, biometric unlock) is operator-selectable and recommended where the regulated entity’s risk analysis warrants. SAIHM’s authentication layer does not by itself satisfy SP 800-63B Authenticator Assurance Level 2 or 3; AAL conformance is a deployment-time configuration question. |
| § 164.312(e)(1) Transmission Security (standard) and § 164.312(e)(2)(ii) Encryption (Addressable). SP 800-66 R2 § 5.3.5 Key Activity 4: “Implement a mechanism to encrypt ePHI whenever appropriate.” | SAIHM cells are encrypted with AES-256-GCM before egress from the holder process; transit over public networks therefore carries ciphertext only. The MCP-tool transport between holder and operator additionally relies on standard TLS at the operator interface (operator-selectable, typically TLS 1.2 or 1.3). |
SP 800-66 Rev. 2 § 5.3.1 also covers Unique User Identification (Required), Emergency Access Procedure (Required), and Automatic Logoff (Addressable); these are operator-domain procedural controls layered around a SAIHM deployment.
Physical Safeguards — Device and Media Controls (§ 164.310(d))
| HIPAA citation (& SP 800-66 R2 section) | SAIHM mechanism |
|---|---|
| § 164.310(d)(2)(i) Disposal (Required). SP 800-66 R2 § 5.2.4 Key Activity 1: “Implement policies and procedures to address the final disposition of ePHI…. Ensure that ePHI is properly destroyed and cannot be recreated.” Sample question: “Prior to disposal, have media and devices containing ePHI been sanitized in accordance with [SP 800-88]?” | saihm_forget(cellId) is designed to perform a Cryptographic Erase as defined in NIST SP 800-88 (see the dedicated SP 800-88 Rev. 2 crosswalk). The per-cell DEK is zeroised in memory; the cell’s content identifier (CID) is blacklisted; a signed tombstone receipt is emitted; and an audit anchor is published on the COTI V2 mainnet. The plaintext becomes computationally infeasible to recover from the ciphertext at the operator’s storage tier. SP 800-66 Rev. 2 itself cites SP 800-88 Rev. 1 (2014); see the “SP 800-88 revision note” section below. |
| § 164.310(d)(2)(ii) Media Re-use (Required). SP 800-66 R2 § 5.2.4 Key Activity 2: “Implement procedures for the removal of ePHI from electronic media before the media become available for reuse. Ensure that ePHI previously stored on any electronic media cannot be accessed and reused.” | After saihm_forget, the underlying ciphertext blocks at the storage tier are decoupled from any retrievable plaintext (the DEK is destroyed; the CID is blacklisted). The storage media themselves remain available for reuse by the underlying storage provider; SAIHM’s cell-scoped erase is designed to address the Media-Re-use specification at the logical-data scope. Physical media reuse outside SAIHM’s cell scope (e.g., disk-level reuse by the storage provider) is the provider’s sanitization domain and remains the regulated entity’s obligation to confirm under its own risk analysis. |
| § 164.310(d)(2)(iii) Accountability (Addressable); § 164.310(d)(2)(iv) Data Backup and Storage (Addressable). | The signed-receipt + on-chain anchor trail records who initiated each operation (by wallet-bound identity) and when, providing accountability evidence for the cell-scoped activity. Backup-and-storage policy (geographic redundancy, retention horizons) is operator-domain; SAIHM cell metadata records the storage tier and is exposed via saihm_status. |
Administrative Safeguards — selected mappings (§ 164.308)
| HIPAA citation (& SP 800-66 R2 section) | SAIHM applicability |
|---|---|
| § 164.308(a)(1)(ii)(A) Risk Analysis (Required) and § 164.308(a)(1)(ii)(B) Risk Management (Required). SP 800-66 R2 Sections 3 and 4. The guide defers methodology to NIST IR 8286A, SP 800-30 Rev. 1, and SP 800-37 Rev. 2. | Operator-domain. SAIHM does not perform the risk analysis on behalf of a regulated entity. SAIHM technical-control documentation (this crosswalk, the Internet-Draft, the protocol specification, the reference implementation) can be cited as evidence of selected technical-control implementation choices within the entity’s risk-management program. |
| § 164.308(a)(6) Security Incident Procedures — Response and Reporting (Required). SP 800-66 R2 § 5.1.6. | The chain-anchored receipt trail provides a tamper-evident incident-investigation surface: a regulated entity can reconstruct the sequence of cell operations from an immutable public-chain log without relying solely on operator-internal records. Incident-response procedures, breach-notification under 45 CFR §§ 164.400–414, and reporting workflows remain operator-domain. |
| § 164.308(b)(1) Business Associate Contracts and Other Arrangements (Required). SP 800-66 R2 § 5.1.9. | If a regulated entity acts as a Business Associate by deploying SAIHM to handle ePHI on behalf of a Covered Entity, the entity must execute a HIPAA-compliant BAA with that Covered Entity. SAIHM, as a piece of open-source technology distributed under Apache 2.0, is not itself a Business Associate; the deploying entity is. |
Organizational Requirements (§ 164.314) and Documentation (§ 164.316)
SP 800-66 Rev. 2 Sections 5.4 and 5.5 cover the Organizational Requirements (BAAs, Group Health Plans) and the Policies-and-Procedures and Documentation Requirements. These obligations are operator-domain. SAIHM contributes the following as evidence the regulated entity may incorporate into its documentation:
- This crosswalk, the protocol Internet-Draft, the Apache-2.0 reference implementation source code, and the on-chain audit-anchor trail are publicly inspectable evidence of the technical-control design supporting the regulated entity’s § 164.316 documentation obligation.
- The signed-receipt mechanism produces per-operation evidence the regulated entity may retain to support the six-year retention requirement of § 164.316(b)(2)(i).
SP 800-88 revision note — Rev. 1 vs Rev. 2
SP 800-66 Rev. 2 (February 2024) cites SP 800-88 Revision 1 (Kissel, Regenscheid, Scholl, Stine; 2014; DOI 10.6028/NIST.SP.800-88r1) for media-sanitization guidance, in a single reference within the § 5.2.4 Disposal sample-question set. SP 800-88 Rev. 1 already defines Cryptographic Erase as an acceptable purge sanitization technique (Rev. 1 § 2.5 and Appendix A), so SAIHM’s saihm_forget design aligns directly with the framework SP 800-66 Rev. 2 invokes. NIST published SP 800-88 Revision 2 in September 2025, which elevates Cryptographic Erase as a first-class logical purge technique with expanded assurance guidance; the SAIHM SP 800-88 Rev. 2 crosswalk covers that newer revision in clause-by-clause detail. A regulated entity may cite either revision as the sanitization authority for HIPAA § 164.310(d)(2)(i)/(ii); Rev. 2 is the more current.
SP 800-66 Rev. 2 itself does not use the term “cryptographic erase” verbatim; it defers all media-sanitization detail to SP 800-88 by reference. A reviewer searching SP 800-66 Rev. 2 for the phrase “cryptographic erase” will therefore find no in-document occurrence — the authority routes through SP 800-88.
SP 800-53 / CSF mapping — Appendix D and the CPRT
SP 800-66 Rev. 2 Appendix D (p. 105) states: “So that the information in this appendix can be more easily kept up to date, the mapping table has been removed from the document and placed online in the NIST Cybersecurity and Privacy Reference Tool (CPRT).” The authoritative HIPAA-Security-Rule→SP-800-53-Rev.-5 and Cybersecurity-Framework mapping for each Security Rule citation is therefore maintained at the CPRT entry for framework identifier SP800_66_2_0_0, available at csrc.nist.gov/Projects/cprt/catalog — SP 800-66 2.0.0.
The SP 800-53 Rev. 5 control families most directly relevant to a SAIHM deployment under the HIPAA Security Rule are:
- SC-28 (Protection of Information at Rest) and SC-13 (Cryptographic Protection) — SAIHM AES-256-GCM cell encryption.
- SC-8 (Transmission Confidentiality and Integrity) — ciphertext-before-egress plus operator-interface TLS.
- MP-6 (Media Sanitization) —
saihm_forgetCryptographic Erase. - AU-2 / AU-3 / AU-12 (Audit Events / Record Content / Audit Generation) — signed receipts plus chain anchors.
- IA-2 / IA-5 (Identification and Authentication / Authenticator Management) — ML-DSA-65 wallet-bound signature identity.
- SI-7 (Software, Firmware, and Information Integrity) — ML-DSA-65 cell-signature verification.
A regulated entity asserting SP 800-53 Rev. 5 control implementation via SAIHM should cross-reference the live CPRT entry for the authoritative HIPAA-citation-to-SP-800-53 mapping, since Appendix D content is maintained online rather than in the PDF. The Cybersecurity Framework Subcategory mappings in CPRT currently reference CSF v1.1; SP 800-66 Rev. 2 footnote 152 notes that an update to CSF v2.0 is pending.
Cloud and third-party ePHI — what SP 800-66 R2 expects
SP 800-66 Rev. 2 § 3.2 Step 1 (Prepare for Assessment) calls out cloud and external-service-provider scope explicitly: “Determine whether ePHI is transmitted to external third parties, such as cloud service providers or other service providers.” The risk-assessment scope must include “external service providers who may have remote access to ePHI.”
SAIHM’s encryption-before-egress design materially changes the risk profile of cloud-hosted ePHI: by design, the operator does not hold plaintext, so the external-service-provider exposure is to ciphertext only. This does not remove BAA obligations — a Covered Entity engaging a Business Associate to deploy SAIHM still needs a BAA with that Business Associate — nor does it remove the regulated entity’s risk-analysis obligation; it narrows the technical risk surface for the data-confidentiality dimension of that analysis.
Operators handling ePHI should also consult HHS OCR’s “Guidance on HIPAA & Cloud Computing” (referenced in SP 800-66 Rev. 2 Appendix F) for the regulator’s framing of cloud-service-provider obligations.
Conformance statement
Evidence-of-design statement, not a HIPAA compliance certification. No standalone HIPAA Security Rule certification exists; HIPAA compliance is asserted by the regulated entity itself and is subject to HHS OCR enforcement (audits, complaint investigations, breach reporting under 45 CFR §§ 164.400–414). The assertions below describe how a conformant SAIHM implementation maps to the cited Security Rule implementation specifications; per-deployment conformance depends on operator implementation choices and the regulated entity’s own risk analysis.
- § 164.310(d)(2)(i) Disposal — assisted by a conformant implementation of
saihm_forget(Cryptographic Erase per NIST SP 800-88; per-cell DEK zeroisation; CID blacklist; signed tombstone; on-chain audit anchor). - § 164.310(d)(2)(ii) Media Re-use — assisted by the same mechanism at the cell scope; underlying physical-media reuse is the storage provider’s sanitization domain.
- § 164.312(a)(2)(iv) Encryption and Decryption (Addressable) — assisted by AES-256-GCM cell encryption with HKDF-SHA-256-derived per-cell DEKs; FIPS-140-3-validated cryptographic module is operator-selectable.
- § 164.312(b) Audit Controls — assisted by signed receipts plus on-chain audit anchors; operator-side content-level audit records remain operator-domain.
- § 164.312(c) Integrity — assisted by ML-DSA-65 cell signatures plus AES-256-GCM AEAD; tamper detection at recall time.
- § 164.312(d) Person or Entity Authentication — assisted by wallet-bound ML-DSA-65 signature identity at the protocol layer; SP 800-63B Authenticator Assurance Level conformance is a deployment-time configuration question.
- § 164.312(e)(2)(ii) Encryption (transmission) (Addressable) — assisted by ciphertext-before-egress plus operator-interface TLS.
- Administrative and Organizational requirements (§§ 164.308, 164.314, 164.316) — operator-domain; SAIHM technology evidence may be cited as part of the regulated entity’s documentation but does not by itself satisfy these requirements.
Holder wallet-custody responsibility. SAIHM’s wallet-bound identity model places custody of the holder’s cryptographic key material on the holder (or, in a deployment, on the regulated entity acting as Covered Entity or Business Associate). Wallet-key loss results in permanent loss of access to cells; wallet-key compromise results in identity-spoofing risk. Key generation, backup, rotation, hardware-security-module (HSM) policy, and recovery procedures are operator-domain and must be documented in the regulated entity’s policies-and-procedures under § 164.316 and reflected in its risk analysis under § 164.308(a)(1)(ii)(A). SAIHM does not provide a custodial recovery path; this is a design property, not a defect, and regulated entities should structure their internal controls accordingly.
Scope clarification. This crosswalk addresses the HIPAA Security Rule (Subpart C of 45 CFR Part 164) only. The HIPAA Privacy Rule (Subpart E) governs uses and disclosures of PHI more broadly and is not in scope here. The HIPAA Breach Notification Rule (Subpart D, 45 CFR §§ 164.400–414) governs notification of unsecured-PHI breaches and is operator-domain. Throughout this crosswalk, “ePHI” refers to electronic PHI as defined at 45 CFR § 160.103.
Why SAIHM is well-aligned with the HIPAA Security Rule for AI ePHI memory
- Disposal and Media Re-use are Required — SAIHM is designed to provide a cell-scoped Cryptographic Erase. Regulated entities asking “how do we prove ePHI was destroyed” can point to the per-cell DEK zeroisation plus the on-chain tombstone anchor as cryptographically grounded, externally inspectable evidence to supplement (not replace) the entity’s own logical-deletion verification procedures.
- Encryption-before-egress narrows the cloud risk surface. The Addressable encryption-at-rest specification (§ 164.312(a)(2)(iv)) is supported by a technology that does not let plaintext leave the holder; the regulated entity still owns the “reasonable and appropriate” reasonableness assessment, but the evidence base for affirming encryption is concrete and inspectable.
- Tamper-evident audit log without trusting the operator. The on-chain audit anchor for every cell operation gives a regulated entity an independent timing log it can compare against operator-internal records during incident investigation under § 164.308(a)(6).
- Post-quantum signatures protect long-horizon ePHI. Medical-record retention horizons frequently exceed the security lifetime of classical RSA / ECDSA key pairs against a future cryptanalytically relevant quantum computer. ML-DSA-65 (NIST FIPS-204) signatures on every receipt are designed to remain verifiable on that longer horizon.
- Wallet-bound identity supports the Required Person-or-Entity Authentication standard. SAIHM’s signature identity binds every operation to a cryptographic possession factor that survives session reset, password rotation, and vendor change.
How to cite SAIHM in a HIPAA Security Rule implementation file
- Cite this crosswalk URL as evidence-of-design for the cited § 164.310(d) Device-and-Media Controls and § 164.312 Technical Safeguards implementation specifications.
- Cite the protocol specification: Internet-Draft
draft-saihm-memory-protocol. - Cite the reference implementation:
npx @saihm/mcp-server(Apache 2.0). - Cite the on-chain audit anchor at COTI V2 mainnet (chain ID 2632500) as the verifiable disclosure / sanitisation / authentication log.
- Cite the dedicated NIST SP 800-88 Rev. 2 crosswalk for the clause-by-clause Cryptographic Erase alignment that underpins § 164.310(d)(2)(i)/(ii).
- Cross-reference the live NIST CPRT entry for SP 800-66 2.0.0 for the authoritative HIPAA-Security-Rule-to-SP-800-53-Rev.-5 mapping rows.
- Document the regulated entity’s own risk analysis under § 164.308(a)(1)(ii)(A), the Addressable-specification reasonableness assessments (§ 164.306(d)), the BAA inventory, and the policies-and-procedures package under § 164.316 separately; SAIHM does not substitute for any of these.
Related crosswalks
- NIST SP 800-88 Rev. 2 — the canonical media-sanitization guideline (Cryptographic Erase) that § 164.310(d) Disposal routes through.
- ISO/IEC 27001:2022 — international information-security management; the Annex A control set frequently mapped to HIPAA Security Rule safeguards by regulated entities operating internationally.
- ISO/IEC 27018:2025 — PII protection in public clouds; companion when ePHI is processed in cloud environments.
- GDPR Article 17 — EU companion regulator framing on the right to erasure (parallel to the § 164.310(d) Disposal specification at the cryptographic-erase level).
- NIST AI RMF 1.0 — AI-specific risk-management framework, where SAIHM is the memory-layer reference for AI agent deployments handling regulated data.