Compliance mapping

Read this first — what a library can and can't do

No software package is "SOC 2 certified" or "ISO 27001 certified." Those certify an organization's management system and a service's operation — people, process, and evidence over time — not source code. HIPAA and PCI-DSS likewise apply to entities handling PHI or cardholder data, not to a dependency.

What Cbox ID does is provide the technical controls those frameworks require, implemented correctly and testably, plus the evidence artifacts (audit logs, an SBOM, a conformance matrix, a threat model) an auditor asks for. It moves a large part of the control burden off your plate — but you, the operator, still own the organizational controls (policies, training, vendor management, retention schedules, incident response, a DPIA, and an actual audit).

So the honest framing: adopting Cbox ID puts the identity-and-access, cryptography, and audit-logging controls of these frameworks "in scope and satisfied" at the technical layer. The tables below map each framework's relevant requirements to the feature that addresses it, and end with what remains yours.

SOC 2 (Trust Services Criteria)

ISO/IEC 27001:2022 (Annex A controls)

NIS2 Directive (Art. 21 measures)

GDPR (data protection by design)

Art. 17, honestly. SubjectEraser::erase() covers the package's own stores and returns a receipt of what it did (Security: erasure); a host adds its own stores to the same pipeline. What it does not do is rewrite the audit trail: every column of an audit entry is inside the hash chain, so past entries keep the subject's opaque id (no longer personal data once the subject row is pseudonymised) and a user.erased tombstone is appended instead. Some entries also hold an IP address or, for invitation and verification events, an email address; retaining those is a decision you document under Art. 17(3)(b)/(e), with a retention period. Platform operators are not subjects and are outside the eraser. Copies outside the package — your SIEM, webhook receivers, backups — are yours to erase.

HIPAA Security Rule (§164.312 technical safeguards)

PCI-DSS v4.0 (relevant requirements)

What remains yours (the organizational controls)

The package cannot supply these — they are process, not code:

• Policies & governance: infosec policy, access-review cadence, onboarding/offboarding, vendor management.
• Data retention & DPIA: define retention for audit logs (and risk data, if you add app-layer risk-scoring); run a Legitimate Interest Assessment / DPIA (GDPR).
• Erasure / subject-rights procedures: who may invoke SubjectEraser, how a request is verified, your own stores registered as erasure steps, and the documented Art. 17(3) decision on what the audit trail retains — see the Art. 17 note above.
• Master-key custody and rotation schedule: where the key lives and who can read it, and when you rotate it. The package supports rotation (a versioned keyring and cbox-id:crypto:rewrap, see master key management); deciding to do it is yours.
• Incident response: a documented plan, breach-notification workflow, and the NIS2/GDPR reporting timelines.
• Independent assurance: a SOC 2 audit, ISO 27001 certification, HIPAA risk assessment, or PCI ROC/SAQ — performed by an assessor against your running system.
• Penetration testing: schedule and act on a recurring third-party test.
• Physical & network controls: hosting, egress control (the complete SSRF answer), backups, key custody of the crypto master key.

Evidence Cbox ID hands your auditor

• This mapping, the standards conformance matrix, and the feature support matrix.
• The security model and threat model.
• A machine-readable CycloneDX SBOM and a passing dependency/license/vuln gate.
• A tamper-evident audit trail exportable as forensic evidence.
• Config that is secure by default (MFA available, deny-by-default, an enforced password policy with a 12-character floor; the app adds the breach screen).