Standards and regulatory mapping matrix, plus audit-response evidence pack

Diátaxis quadrant: Reference. Audience: Data Protection Officers, compliance and legal reviewers, and procurement / vendor-assessment teams.

This page maps the controls that humanymous Gate (“Gate” hereafter) implements in the reference build to the specific standards and regulatory articles those controls support. It then gives you a repeatable evidence-pack procedure for responding to a supervisory-authority inquiry or a data-subject access request (DSAR).

Note: In your data-processing relationships, you (the operator) are the data controller. Gate is processing tooling you deploy and configure. This document describes controls Gate provides and how they support your obligations. Gate does not, and cannot, make you compliant — that determination rests with you and your supervisory authority. Read every “supports” and “provides controls for” below in that frame.

Gate in the reference build is a reference implementation, not a production-hardened product. Several anchors that a production deployment would add are called out explicitly as prod-delta (not shipped in the reference). See Production vs reference for the full boundary.

Part 1 — Control-to-requirement traceability matrix

How to read this table

• Control — the mechanism Gate implements.
• Standard / requirement — the specific RFC or regulatory article the control supports. Only standards actually used in the reference build appear here.
• What it supports — the obligation or property the control helps you meet. Bounded language throughout: a control supports, provides controls for, or is evidence toward a requirement; it does not discharge it.
• Where to verify — the endpoint, view, or document that lets an assessor independently confirm the control.

Cryptographic and integrity controls

Note: Work factors above are transcribed as N=2^12 (pseudonym stretch) and N=2^15 (keystore seal). The exact SPDX license of each third-party Go dependency is not asserted here — confirm each from that module’s own LICENSE file before publishing a vendor bill-of-materials.

Note: humanymous Gate is released under the Apache License 2.0 (LICENSE, NOTICE, THIRD_PARTY_LICENSES.md at the repository root). See Support, licensing & open-source notices for the full statement and the third-party dependency bill-of-materials.

GDPR controls

PIPA (Korea)

Warning: Cryptographic erasure (crypto-shred) is irreversible. It destroys the per-subject linkage key so the affected records can no longer be re-identified. The records themselves are never deleted and remain in the verifiable chain, but once the key is shredded the pseudonym-to-subject link cannot be recovered. There is a cancellable hold window (default 5 minutes) before the shred executes; after it commits there is no recovery path.

Recommended production anchors — NOT shipped in the reference

The following are established anchors a production deployment would add. They are prod-delta: they are not implemented in the reference build. Do not represent them as shipped features in a vendor assessment.

Note: Because RFC 3161 timestamping and external WORM anchoring are not shipped, the reference audit log is tamper-evident, not tamper-proof: records written after the last checkpoint remain re-writable until the next checkpoint anchors them (an unanchored in-window residual). The independent witness co-sign stops silent history rewrites of already-anchored records. Present this boundary honestly in any assessment.

Part 2 — Audit-response evidence pack

This checklist turns a supervisory-authority inquiry or a DSAR into a repeatable procedure. Each item names the artifact, how to produce it, and how the recipient can independently verify it. All admin endpoints are served on the admin listener (default 127.0.0.1:8445 (loopback)) under the /__hmn/admin base, behind bearer authentication; the public edge returns 404 for these paths.

Throughout, replace <admin-host> (default localhost:8445), <token> (an admin bearer token with the required role), and other <angle-bracket> placeholders with your values.

Evidence-pack checklist

• RoPA extract — Records of Processing (Art. 30 / PIPA records)
• DPIA — impact assessment adapted from the companion (Art. 35)
• Erasure certificates and their verification — Art. 17 / PIPA destruction
• Integrity reports — audit-chain verification (Art. 32)
• Audit export — filtered decisions and CSV (Art. 30 / Art. 32)
• RBAC and dual-control configuration — separation of duties (Art. 25 / Art. 32)
• Admin-action meta-audit trail — accountability (Art. 32)

1. RoPA extract

Assemble your Records of Processing from the data processing inventory. It enumerates the categories of identifiers processed, how each is pseudonymized, the retention tiers (HOT ≈ 90 days / WARM ≈ 1 year / COLD ≈ 7 years), and the lawful-basis framing. You (the controller) sign off on the final RoPA; the inventory provides the processing-activity content.

2. DPIA

Adapt the DPIA companion into your own assessment. It documents the processing purpose, the risk to data subjects (including false-positive risk and the residual attacker-tier ceiling), and the mitigations Gate provides. The DPIA is your document; the companion is structured input.

3. Erasure certificates and their verification

For a right-to-erasure request, follow the erasure and crypto-shred runbook. The certificate is sealed on execution — when the cancellable hold window elapses and the shred actually runs — not on commit; a cancelled erasure produces no certificate.

There is no admin endpoint that returns the certificate (prod-delta). The /__hmn/admin/erasures endpoint lists only erasures still within their hold window (scheduled but not yet executed); once the shred runs, the certificate is observable only as an erasure.completed audit record in the stream:

# List scheduled (in-hold-window) erasures only:
curl -k -H "Authorization: Bearer <token>" \
  https://<admin-host>/__hmn/admin/erasures

# The completed-erasure certificate is an audit record — retrieve it from the audit stream:
curl -k -H "Authorization: Bearer <token>" \
  "https://<admin-host>/__hmn/admin/audit" \
  | jq '.records[] | select(.event_type == "erasure.completed")'

The certificate record is a plain audit record HMAC-chained into the log; it is not independently Ed25519-signed at seal time. It is anchored — and becomes tamper-evident — only when the next Ed25519 STH checkpoint covers it. So the certificate is verifiable as part of the audit chain (via the next checkpoint, public key alone), not as a standalone signature you verify in isolation. The chain and Merkle anchors remain intact after a shred, which the Integrity view confirms independently (see step 4).

Warning: Do not initiate an erasure to produce a demonstration certificate. Crypto-shred is irreversible; the affected subject’s records become permanently non-re-identifiable once the hold window elapses and the shred commits.

4. Integrity reports

Produce a current integrity report over the audit chain:

curl -k -H "Authorization: Bearer <token>" \
  https://<admin-host>/__hmn/admin/integrity

The report verifies the hash chain, per-record HMAC (when a key is supplied), and Ed25519-signed checkpoints, and reports any mismatch by class: hash-break, hmac-invalid, hmac-unchecked, empty-chain, seq-gap, linkage-break, checkpoint-mismatch, witness-invalid, or node-missing. Assessors with published public keys re-verify offline; live Integrity uses the node key material. See Verify the audit log.

5. Audit export

Export the decision records relevant to the inquiry. The audit endpoint supports server-side filters and a cursor:

curl -k -H "Authorization: Bearer <token>" \
  "https://<admin-host>/__hmn/admin/audit?verdict=<ALLOW|CHALLENGE|DENY>&host=<host>&route=<route>&rule=<HR-id>&minRisk=<0-100>&before=<cursor>"

Page through results with the returned nextBefore cursor. Each record carries the verdict, risk score, matched hard rule (if any), and the pseudonymized identifiers — never raw identifiers.

For a human-readable snapshot, the Ledger Overview view has an Export CSV button that downloads audit-feed.csv (text/csv). See the Ledger tour.

Note: Observability in the reference build is the audit stream, the Integrity view/endpoint, the Overview KPIs, Prometheus GET /__hmn/admin/metrics on the admin plane, and edge GET /__hmn/healthz / GET /__hmn/readyz. SIEM shipping of the audit stream is still a prod-delta.

6. RBAC and dual-control configuration

Provide the effective policy, whose config_version is a signed HMAC hash of the effective policy (routes, rate, monitor, kill switch):

curl -k -H "Authorization: Bearer <token>" \
  https://<admin-host>/__hmn/admin/policy

Pair this with RBAC and separation of duties, which documents the four roles and their capabilities:

• Auditor — read only.
• Operator — read + operate (temp bans, lifts).
• Approver — read + approve.
• DPO — read + operate + approve, and the only role that can approve erasure.

Dual-control facts to state in the pack: a permanent or CIDR ban and the kill switch must be committed by a distinct Approver; an erasure must be committed by a distinct DPO (a generic Approver cannot). Temporary bans and lifts are single-Operator.

7. Admin-action meta-audit trail

Every admin access is meta-audited under admin.access, with the actor identity derived server-side (any actor field in a request body is ignored). Filter the audit export for these records to produce the accountability trail:

curl -k -H "Authorization: Bearer <token>" \
  "https://<admin-host>/__hmn/admin/audit?route=control" \
  | jq '.records[] | select(.event_type == "admin.access")'

The audit export has no event-type query parameter (its server-side filters are verdict, host, route, minRisk, before, limit and rule). The rule filter matches the triggered_rules slice, not the event taxonomy, so ?rule=admin.access selects nothing. Meta-audit records carry route_class: "control", so ?route=control narrows to the control plane server-side; isolate admin.access precisely by filtering the exported event_type field client-side, as shown.

Scope and boundaries to state plainly

• You are the controller; Gate is processing tooling. These controls support your obligations; they do not discharge them.
• The reference build is a reference implementation, not production-hardened. RFC 3161 timestamping and external WORM anchoring are recommended production anchors, not shipped.
• The audit log is tamper-evident, not tamper-proof (unanchored in-window residual; witness co-sign stops silent rewrites of anchored history).
• Pseudonymized identifiers are pseudonymous, not anonymous (GDPR Recital 26).
• Cryptographic erasure is irreversible.

Related references

• Data processing inventory — RoPA source content (Art. 30)
• DPIA companion — DPIA input (Art. 35)
• Verify the audit log — integrity verification procedure
• RBAC and separation of duties — roles, capabilities, dual-control
• Erasure and crypto-shred runbook — right-to-erasure procedure
• Hard rules and verdicts — verdict and hard-rule glossary
• Production vs reference — the full prod-delta boundary