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. The package ships no erasure primitive. Subjects can deactivate() a user; it cannot delete one, and there is no anonymisation service, command, or endpoint anywhere in src/. Nor is the subject model as opaque as it sounds: alongside whatever your own users table holds, this package stores contact PII in its own tables — platform_operators, account_members, magic_links, invitations, the credential-token tables, otp_challenges, directory_users and directory_groups. None of those are covered by the retention pruner, which sweeps only ephemeral protocol state.

Two further tensions to plan for rather than discover: audit_logs is deliberately never pruned (pruning it breaks chain verification), and an erasure that rewrites a chained audit entry would invalidate every entry after it. Satisfying an erasure request is therefore an operator procedure across those tables, with a documented decision about what the audit trail retains under Art. 17(3)(b)/(e). Budget for it; do not assume the package does it.

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: the package ships no erasure primitive — see the Art. 17 note above for the tables involved and the audit-trail tension.
• Master-key custody and rotation: there is no re-encrypt/rewrap routine, so rotating the crypto master key is not a supported operation today.
• 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).