SAIHM × ISO/IEC 27001:2022 crosswalk
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements (October 2022, 3rd edition) defines the requirements for an Information Security Management System (ISMS). Annex A specifies 93 controls organised in four themes: Organizational (A.5), People (A.6), Physical (A.7), and Technological (A.8).
SAIHM mechanisms become evidence inside an ISMS audit. The mapping below selects the highest-impact controls for AI memory operations.
ISMS clauses (4—10)
| Clause | SAIHM mechanism |
|---|---|
| 4 Context. | SAIHM is a memory layer for AI agents; six crosswalks document context and interested-party scope (holders, operators, regulators, chain participants). |
| 5 Leadership. | Wallet-bound holder identity allocates information-owner responsibility unambiguously. Operator visibility = ciphertext only. |
| 6 Planning. | Cryptographic erasure planned at protocol level; KEK rotation versioned for cryptographic agility; threat model documented. |
| 7 Support. | Apache-2.0 reference implementation, public docs, public protocol spec (I-D draft-saihm-memory-protocol-00). |
| 8 Operation. | Cell lifecycle as protocol; every transition signed + chain-anchored. |
| 9 Performance evaluation. | saihm_status dashboards (PRS, BFSI); on-chain receipts are the audit record. |
| 10 Improvement. | Public governance pair (saihm_governance_propose, saihm_governance_vote); Apache-2.0 PRs. |
Annex A — Organizational (A.5)
| Control | SAIHM mechanism |
|---|---|
| A.5.1 Policies for information security. | SAIHM POLICY and STRATEGY cells on chain; six crosswalks; Apache-2.0 license; protocol spec. |
| A.5.10 Acceptable use of information and other associated assets. | Sharing-contract modes (temporary ≤24h, permanent, syndicate) explicitly bound; revocable. |
| A.5.12 Classification of information. | Cell metadata includes tier, kek-version, holder identity; classification is structural. |
| A.5.14 Information transfer. | Encryption-before-egress; transfer is signed + receipted; sharing contracts gate transfer cryptographically. |
| A.5.15 Access control. | Holder identity binding via wallet + ML-DSA-65 signature; only holder or grantee can decrypt. |
| A.5.16 Identity management. | Wallet-derived identity (canonical HKDF: MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1). Identity is post-quantum. |
| A.5.17 Authentication information. | Authentication is signature-based (ML-DSA-65, NIST FIPS-204), not bearer-token. Key never leaves holder. |
| A.5.23 Information security for use of cloud services. | Operator-honest-but-curious threat model. Ciphertext-only at operator. Independent verification via chain. |
| A.5.32 Intellectual property rights. | Apache-2.0 license. No third-party copyleft. LF IP-transfer ready. |
| A.5.34 Privacy and protection of PII. | Encryption-before-egress + cryptographic erasure (DEK destroy + tombstone). GDPR Art.17 alignment (crosswalk). |
Annex A — Technological (A.8)
| Control | SAIHM mechanism |
|---|---|
| A.8.2 Privileged access rights. | No operator privilege over cell contents. Operator can route storage but not decrypt. |
| A.8.3 Information access restriction. | Per-cell DEK; access requires holder signature or sharing-contract proof. |
| A.8.5 Secure authentication. | ML-DSA-65 post-quantum signatures (FIPS-204). |
| A.8.10 Information deletion. | Cryptographic erasure: saihm_forget destroys the DEK irreversibly, publishes a tombstone, blacklists the CID, anchors the audit receipt on chain. Erasure is not soft-delete and is not reversible by the operator. |
| A.8.11 Data masking. | Ciphertext-only at operator side. Cell contents are masked by encryption from write-time onward. |
| A.8.12 Data leakage prevention. | Encryption-before-egress; no plaintext at operator. Sharing contracts are explicit, time-bound, revocable. |
| A.8.16 Monitoring activities. | Every operation emits a signed receipt anchored on chain. Audit log is tamper-evident. |
| A.8.24 Use of cryptography. | ML-DSA-65 (FIPS-204) signatures; per-cell DEK from HKDF chain; KEK rotation versioned. Cryptographic primitives are public, peer-reviewed, NIST-selected. |
| A.8.25 Secure development life cycle. | Apache-2.0 public source; PRs accepted; protocol spec under IETF Independent Submission review. |
| A.8.28 Secure coding. | Public source under @saihm/mcp-server; cryptographic primitives use NIST-selected algorithms only. |
Statement of Applicability (SoA) drafting tips
- For each Annex A control selected in your ISMS scope, the SoA "implementation status" can reference SAIHM by mechanism + receipt id.
- For A.8.10 (Information deletion) and A.5.34 (Privacy / PII), SAIHM provides cryptographic-grade evidence: DEK destroy + tombstone + CID blacklist + on-chain audit receipt.
- For A.8.24 (Use of cryptography), cite FIPS-204 (ML-DSA-65) and the HKDF chain document.
- For A.5.23 (Cloud services security), cite the operator-honest-but-curious threat model documented in the I-D §6.4.