Evidence-of-design crosswalk. Not legal advice. Not an ISO-administered or accredited certification body assessment. ISO/IEC 27018 has no standalone certification scheme; conformance is typically asserted as part of an ISO/IEC 27001 ISMS audit by an accredited certification body. Per-deployment conformance depends on operator implementation choices.
SAIHM × ISO/IEC 27018:2025 crosswalk
ISO/IEC 27018:2025 — Information security, cybersecurity and privacy protection — Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors (Third edition, published 2025-08-26) is the international guidelines document for PII-protection controls applicable to cloud-service providers acting as PII processors. The 2025 edition cancels and replaces ISO/IEC 27018:2019 and has been technically revised: the main-body structure now aligns with the four control themes of ISO/IEC 27002:2022 (Clauses 5–8), and the supplementary control set in Annex A has changed from normative (2019) to informative (2025). A new informative Annex B provides the correspondence between the 2025 main body / Annex A and the 2019 Annex A catalogue.
SAIHM’s cell envelope (encryption-before-egress, per-cell data-encryption key, signed on-chain audit anchor) and the saihm_forget cryptographic-erase operation are designed to satisfy the PII-processor obligations the 2025 standard makes operationally explicit, with primary alignment to Clause 8.10 Information deletion and Clause 8.24 Use of cryptography. This crosswalk is intended as an RFP-ready evidence-of-design artefact, subject to operator review.
2025 edition — what changed vs 2019
- Structural realignment. The 18-clause structure of the 2019 edition (clauses 5–18 mirroring ISO/IEC 27002:2013 themes) is replaced by the four control-theme structure of ISO/IEC 27002:2022: 5 Organizational controls, 6 People controls, 7 Physical controls, 8 Technological controls.
- Annex A status change. The PII-processor extended control set, normative in 2019, is informative in 2025; conformance assertions previously framed against the 2019 Annex A should be reformulated against the 2025 main body or asserted explicitly as informative-Annex-A alignment.
- Annex B added. A new informative correspondence table maps the 2019 Annex A control identifiers to the 2025 main body / Annex A locations, to support transition.
- Title. “Code of practice” (2019) is replaced by “Guidelines…” (2025).
Reference: ISO/IEC 27018:2025 official product page (iso.org/standard/27018) and IEC Webstore listing (webstore.iec.ch/en/publication/109374). The Foreword of the 2025 edition states that the text has been aligned with ISO/IEC 27002:2022 and that Annex B has been added.
Clause 8 — Technological controls (primary mappings)
| ISO/IEC 27018:2025 clause | SAIHM mechanism |
|---|---|
| Clause 8.10 — Information deletion. Information stored in information systems, devices, or in any other storage media shall be deleted when no longer required. | saihm_forget(cellId) is designed to perform a cryptographic erase (Cryptographic Erase as defined in NIST SP 800-88 Rev. 2 §3.2; see also the SP 800-88 R2 crosswalk). The per-cell data-encryption key (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 (chain ID 2632500, block explorer mainnet.cotiscan.io). The plaintext becomes computationally infeasible to recover from the ciphertext at the operator’s storage tier. |
| Clause 8.24 — Use of cryptography. Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented. | SAIHM cells are encrypted with AES-256-GCM (FIPS-197 / NIST SP 800-38D), 256-bit key strength. Per-cell DEKs are derived via HKDF-SHA-256 (RFC 5869) from a holder wallet-bound identity key, produced 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). Signatures use ML-DSA-65 (NIST FIPS-204), a NIST-selected post-quantum signature scheme. No ECB mode. Cryptographic-module choice (FIPS-140-3 validation where required) is operator-selectable. |
Clauses 8.1–8.34 collectively cover the technological control surface (identity, access, logging, monitoring, secure development, etc.). The two clauses above are the most direct mappings for the SAIHM cryptographic envelope; per-deployment crosswalks of the remaining 8.x clauses depend on operator choices around the surrounding stack (transport, IAM, observability).
Clauses 5 / 6 / 7 — Organizational, People, Physical
| ISO/IEC 27018:2025 clause group | SAIHM applicability |
|---|---|
| Clause 5 — Organizational controls (5.1–5.37): policies, roles and responsibilities, segregation of duties, supplier relationships, classification of information, threat intelligence, identity management, … | Operator-domain. SAIHM is policy-agnostic at the organisational layer; an operator deploying SAIHM layers its own policy, governance, and supplier-management programme on top. SAIHM constrains specific identity and key-management touchpoints (wallet-bound enrolment, per-cell DEKs) that an operator’s Clause 5 documentation can cite as the technical-control evidence for the corresponding policy assertions. |
| Clause 6 — People controls (6.1–6.8): screening, terms of employment, awareness, disciplinary process, remote working, confidentiality agreements, … | Operator-domain. The SAIHM protocol layer does not constrain people controls. |
| Clause 7 — Physical controls (7.1–7.14): physical security perimeters, physical entry, equipment siting, secure disposal of equipment, … | Operator-domain. SAIHM does not constrain physical controls at the protocol layer. Physical-media destruction (where applicable) is a complementary operator control that does not substitute for — nor is substituted by — SAIHM cryptographic erasure. |
Annex A (informative, 2025) — PII-processor extended control set
The 2025 edition reframes Annex A as informative. This crosswalk references the topical content that the 2019 Annex A catalogue addressed, cross-referenced via Annex B of the 2025 edition. Operators preparing a formal conformance assertion should reference the 2025 Annex A identifiers directly from the published ISO/IEC 27018:2025 standard.
| Annex A topic (2019 identifiers shown for traceability; map to 2025 via Annex B) | SAIHM mechanism |
|---|---|
| Secure erasure of temporary files (2019 A.5.1). | saihm_forget cryptographic erasure is per-cell. Plaintext exists only transiently in holder-process memory during cell composition or recall; the operator’s storage tier never holds plaintext. The DEK-destruction step zeroises the per-cell data-encryption key, after which the corresponding ciphertext cannot be decrypted. |
| PII return, transfer and disposal (2019 A.10.3). | Cell disposal is via saihm_forget (cryptographic erase). The “transfer” element is addressed in part by saihm_share, which grants per-recipient access without itself transferring controllership; a separate controller-to-controller transfer (where required by the operator’s data-processing agreement) is operator-domain. Cell return to the principal is via standard saihm_recall by the holder. All operations emit signed receipts. |
| PII disclosure notification + Recording of PII disclosures (2019 A.6.1, A.6.2). | Every saihm_share and saihm_revoke_share emits a signed receipt and on-chain audit anchor. The chain anchor attests to the occurrence and timestamp of each disclosure event (not the disclosed contents); supervisory authorities can independently verify when disclosures occurred without trusting operator-internal records. Operator-side enumeration of the disclosure contents remains a separate operator-domain obligation. |
| Disclosure of sub-contracted PII processing (2019 A.8.1). | The protocol discloses that encrypted cells persist on operator-selectable decentralized storage networks (see /appendix/storage-nodes); SAIHM pins no specific provider or region. Operator-side disclosures of additional sub-processors are operator-domain and should be enumerated in the operator’s data-processing addendum. |
| Geographical location of PII + Intended destination of PII (2019 A.12.1, A.12.2). | Storage-tier metadata (the decentralized storage tier) is operator-disclosed and recorded in cell metadata accessible via saihm_status. Geographic preference (e.g., EU-only storage) is operator-expressable via storage-provider selection but is best-effort subject to storage-provider availability and is not a guaranteed data-residency control on its own; operators requiring strict residency should layer additional contractual and technical controls. |
| Encryption of PII transmitted over public data-transmission networks (2019 A.11.6). | SAIHM cells are encrypted with AES-256-GCM before egress from the holder process; transit over public networks therefore carries ciphertext only. MCP-tool transport between holder and operator additionally relies on standard TLS at the operator interface. |
| Access to data on pre-used data storage space (2019 A.11.13). | Per-cell DEK design isolates each cell cryptographically; an attacker recovering raw storage-substrate blocks would still face the per-cell encryption envelope. saihm_forget ensures the DEK for an erased cell cannot be re-derived. |
Reference: the 2019 Annex A subsection identifiers are listed for traceability; the 2025 Annex A renumbers some subsections, and Annex B of the 2025 edition provides the formal correspondence table that an operator should cite for a 2025-conformance assertion.
Conformance statement
Evidence-of-design statement, not an accredited certification body assessment. ISO/IEC 27018 conformance is typically asserted as part of an ISO/IEC 27001 information-security management system (ISMS) audit performed by an accredited certification body; no standalone ISO/IEC 27018 certification scheme is administered by ISO. The assertions below describe how a conformant SAIHM implementation maps to the cited clauses; per-deployment conformance depends on operator implementation choices.
- Clause 8.10 (Information deletion) — satisfied by a conformant implementation of
saihm_forget(cryptographic erase per NIST SP 800-88 Rev. 2 §3.2; per-cell DEK zeroisation; CID blacklist; signed tombstone; on-chain audit anchor). - Clause 8.24 (Use of cryptography) — satisfied subject to operator selection of a FIPS-140-3-validated cryptographic module where required (AES-256-GCM, RFC 5869 HKDF-SHA-256, ML-DSA-65; no ECB).
- Clauses 5 / 6 / 7 — operator-domain; SAIHM does not assert direct conformance at the protocol layer.
- Annex A (informative) topics — SAIHM mechanisms are designed to address the topical concerns of the catalogued controls (secure erasure, PII disposal, disclosure logging, sub-processor identification, geographical preference, encryption-in-transit, pre-used storage isolation). Per-deployment alignment with the formal 2025 Annex A identifiers should be verified by the operator against the full standard.
Why SAIHM is well-aligned with ISO/IEC 27018:2025 for AI PII memory
- Cell-scoped erasure. Clause 8.10 requires deletion when information is no longer required; SAIHM offers true per-cell cryptographic erase rather than logical record-removal that can be undone from backups. DEK-destruction provides a mathematically irreversible form of deletion at the cell scope.
- Cryptography programme that survives audit. Clause 8.24 demands defined cryptographic rules and key management; SAIHM’s HKDF-based derivation chain and per-cell DEK design are documented in a public Internet-Draft and a published reference implementation, providing audit-grade traceability.
- Operator-honest-but-curious model. Encryption-before-egress means the operator never holds PII plaintext; this materially shifts the “pre-used storage” and “secure erasure of temporary files” risk profiles in the operator’s favour.
- Independently verifiable timing log. The on-chain audit anchor for share/revoke/forget operations attests to the occurrence and timestamp of each operation and is inspectable by a supervisory authority without trusting either holder or operator records; it addresses the temporal dimension of Annex A’s “Recording of PII disclosures” topic at a higher level of assurance than purely operator-internal logging. Operator-side records remain necessary for disclosed-content enumeration.
- Post-quantum signatures. ML-DSA-65 (FIPS-204) on every receipt protects the disclosure log beyond classical-PKI lifetimes — relevant when PII retention horizons exceed the practical lifetime of RSA / ECDSA key pairs.
How to cite SAIHM in an ISO/IEC 27018:2025 compliance assertion
- Cite this crosswalk URL as evidence-of-design for Clause 8.10 (Information deletion) and Clause 8.24 (Use of cryptography) alignment.
- 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 log.
- For accredited-CB ISMS audits: include SAIHM in the Statement of Applicability and map the relevant ISO/IEC 27001:2022 Annex A controls (notably A.8.10 Information deletion and A.8.24 Use of cryptography) using this crosswalk as the supporting evidence.
- Verify the 2025 Annex A identifiers against the full ISO/IEC 27018:2025 standard before asserting conformance to a specific Annex A control number.
Related crosswalks
- ISO/IEC 27001:2022 — the umbrella ISMS standard under which ISO/IEC 27018 conformance is typically asserted.
- ISO/IEC 42001:2023 — AI management systems standard (the AI-specific peer of 27001).
- GDPR Article 17 (right to erasure) — the EU-regulator companion to Clause 8.10 (Information deletion).
- NIST SP 800-88 Rev. 2 — the canonical media-sanitization guideline for Cryptographic Erase.