DPIA companion pack and retention/lifecycle guide

Diátaxis quadrant: Explanation. Audience: Data Protection Officers (DPOs), privacy counsel, and supervisory-authority reviewers.

This page is a compliance companion for a Data Protection Impact Assessment (Article 35 GDPR) covering an operator deployment of humanymous Gate. It is written as a risk-and-mitigation register, not a set of assurances. Each processing property below is stated first as the residual risk it carries, then as the mitigation the reference implementation provides, and — where the mitigation is incomplete or deferred — as an explicit limit the controller must accept or close.

humanymous Gate (“Gate”) is a reverse-proxy enforcement layer that terminates TLS, streams a detection bundle into HTML responses, scores each request across layers L1–L7, enforces a verdict (ALLOW / CHALLENGE / DENY) at the edge, and writes every decision to a tamper-evident audit log. This document does not repeat the field-level processing register; read it alongside the data-processing inventory, the standards mapping, the erasure (crypto-shred) runbook, and RBAC and separation of duties.

Important: This document describes a reference implementation, not a production-hardened product. Several controls a DPIA would rely on in production are prod-deltas (identified inline). Gate is processing tooling; determining lawful basis, necessity, proportionality, and the DPIA conclusion for a specific deployment remains the responsibility of the operator acting as data controller.

1. Controller/processor framing

The operator who deploys Gate in front of an origin application is the data controller for the traffic it inspects. Gate is the processing tooling the controller configures and operates; it fronts the origin and does not control it. Gate does not transmit personal data to humanymous or any third party — all processing described here is in-process on infrastructure the operator runs.

The controller is accountable for the Article 30 record of processing activities, the Article 35 DPIA itself, the lawful-basis determination, data-subject communications, and the retention schedule. This companion supplies the technical facts those instruments require; it does not substitute for them.

TODO(verify): The Article 6 lawful basis for bot-detection processing (for example, legitimate interests under Art. 6(1)(f) with a balancing test, or another basis) is a controller determination and is not fixed by the reference implementation. State the chosen basis and, where legitimate interests is relied on, attach the legitimate-interests assessment.

2. Purpose, necessity, and proportionality

2.1 Purpose

The processing purpose is distinguishing automated clients from human users at the request boundary, so the controller can block, challenge, or allow traffic before it reaches the origin application. The detection covers non-browser clients, naive and stealth-patched automation frameworks, real-engine automation, and — as a design boundary, not a solved case — anti-detect tooling combined with human click-farms.

2.2 Necessity

Necessity turns on whether the purpose can be met with less personal-data processing. The signals Gate evaluates (static client attributes, fingerprint material, client-integrity checks, behavioral timing, and network/protocol characteristics such as TLS and HTTP/2 fingerprints and header ordering) are the inputs that let the engine separate automation from humans across layers L1–L7. A cross-check-first, defense-in-depth design is used specifically so that no single identifier is decisive and low-false-positive verdicts can be reached deterministically.

The proportionality-relevant design choices in the reference are:

• Data minimization by pseudonymization at rest. Raw identifiers are never stored in the audit log in clear (Section 3).
• Monitor mode. The controller can run detection without enforcement, observing verdicts before any traffic is blocked or challenged — allowing the necessity and false-positive profile to be measured on the controller’s own deployment before enforcement is turned on.
• Route-scoped strictness. Enforcement strength is set per route at startup (for example, stricter defaults on sign-in and checkout paths), rather than applying the maximum posture uniformly.

2.3 Proportionality and the false-positive residual

Proportionality must account for the impact on legitimate human users who are wrongly challenged. The reference is designed for low false positives, and its hard rules are tiered by confidence: several are near-zero-false-positive automation tells, while at least one heuristic rule (no interaction over a window) can catch some humans and therefore issues a CHALLENGE rather than a DENY. The proportionate posture is that lower-confidence signals challenge (a recoverable proof-of-work interstitial) rather than block. The controller should document the residual risk that a human is challenged, and the accessibility of that challenge, as part of the balancing test. See also Will this break my app?.

Note: The reference challenge is a minimal interstitial. A full WCAG 2.2 AA challenge experience is a prod-delta and an operator responsibility; the accessibility of the production challenge is a proportionality input the DPIA should record.

2.4 Behavioral biometrics, and how GPC/DNT are treated

Two points an adopter must resolve for their jurisdiction, both stated candidly here:

• Behavioral timing is biometric-adjacent and component-scoped. Layer 4 evaluates mouse-movement and keystroke timing dynamics (dwell/flight, velocity, trajectory) when the full client detection path (Core / WASM bundle) is in use. Depending on jurisdiction and how it is used, timing-dynamics profiling can attract heightened scrutiny (GDPR Article 9 special-category analysis, or PIPA sensitive-data duties). Controllers who deploy only the Gate reverse proxy must remove “interaction timings” / mouse-keystroke dynamics from their Article 13 notice unless they also run a client path that actually collects them — the Gate’s injected loader does not reproduce the Core behavioral sample stream. Where the full path is enabled, the reference collects timing features as an input to the security verdict; it is not used to uniquely identify a person and is stored only as aggregate features under audit pseudonymization. There is currently no built-in toggle to disable behavioral collection — consent-gated collection is a prod-delta.
• GPC / DNT are read as a privacy-posture signal, not honored as a tracking opt-out. A session presenting Global Privacy Control or Do-Not-Track (or Brave shields, ad-block, tracking protection) is treated as a human/FP-mitigation signal — it lowers suspicion and damps fingerprint-noise scoring — but it does not exempt the session from any server-authoritative hard rule: HR-19 (residential-proxy rotation) is deliberately never gated on a client-reported privacy flag, precisely so a proxy scraper cannot post adBlock:true to disarm it. It is not honored as an opt-out of the detection processing itself, because bot detection is security processing (typically legitimate interests / strictly-necessary), not advertising/tracking to which GPC/DNT legally attach. If your lawful-basis analysis concludes the processing is not strictly necessary for your context, you must add your own consent/opt-out gate; the reference does not do this for you.

3. Pseudonymization design and its limits

3.1 Design

Raw identifiers — IP address, JA4/TLS fingerprint, HTTP/2 fingerprint, User-Agent, SNI, and device fingerprint — are not stored in the audit log in clear. Each is stored only as a per-subject-key-derived pseudonym: a 64-hex value produced by an scrypt key-derivation stretch (N = 2^12), where the subject key is the session identifier. This is pseudonymization within the meaning of Article 4(5) GDPR and Recital 26.

Risk addressed: An adversary (or an over-broad internal read) who obtains the audit log alone does not obtain the underlying identifiers in usable form, and cannot trivially correlate records across subjects, because the derivation is keyed per subject.

3.2 Limit — pseudonymous is not anonymous

Pseudonymized records remain personal data (Article 4(5), Recital 26). They are re-identifiable by design when combined with the keying material. The DPIA must treat the audit log as personal data throughout its lifecycle, not as anonymized data outside GDPR scope.

3.3 Limit — low-entropy identifiers remain re-derivable if the subject key leaks

Pseudonymization protects against exposure of the stored value, not against a brute-force pre-image search when the subject key is known. Because the key derivation is keyed by the subject (session) key, an attacker who obtains that key — or the sealed keystore that protects it — can re-derive the pseudonym for a guessed identifier and confirm a match. For a high-entropy identifier this is impractical; for a low-entropy identifier such as an IPv4 address, the guess space is small enough that a match is confirmable. In other words: the pseudonym does not add meaningful entropy to an already-low-entropy input against an adversary who holds the key.

Mitigations:

• The keying material and vault are held in a keystore sealed with scrypt (N = 2^15) and AES-256-GCM (see Section 6). The scrypt stretch raises the cost of offline attack on the sealed material.
• Cryptographic erasure (crypto-shred) — destroying the per-subject linkage key — destroys exactly the key that makes re-derivation possible. After crypto-shred, the low-entropy re-derivation path in this section no longer applies to that subject, because the key required to derive or confirm the pseudonym no longer exists. Records remain in the chain but are no longer linkable to the subject (Section 5, Section 7).
• Re-identification through the intended path (the vault) is itself gated and audited (Section 4).

Warning: Cryptographic erasure (“crypto-shred”) is irreversible. Destroying the per-subject linkage key permanently removes the ability to re-identify that subject’s records; the records themselves are retained and remain integrity-verifiable, but the linkage cannot be restored. Loss of the keystore unseal secret (HMN_UNSEAL) is functionally equivalent to a mass crypto-shred of all subjects, because the sealed identity material can no longer be opened. Back the unseal secret up out-of-band.

4. Re-identification — custodial keystore control (not dual-control)

Re-identification — turning a stored pseudonym back into the underlying identifier — is not a product API. Gate does not expose a re-identification endpoint and does not perform re-identification in-process. Anyone who holds the sealed keystore and HMN_UNSEAL can resolve pseudonyms offline, alone, with no second approver and no audit record of that offline act.

• What dual-control actually covers. Product dual-control (distinct second role) applies to erasure, permanent/CIDR bans, and the kill switch — not to re-identification. See RBAC and separation of duties.
• Necessity test (organizational). Because re-identification is a custodial offline capability of the key material, the controller must control who holds the keystore and the unseal secret, not a second click in the console. Necessity is demonstrated by key-custody policy and operational access control, not by a dual-control product gate.
• No meta-audit of offline resolve. The product cannot prove “who re-identified whom” for offline keystore use. Do not claim an audited re-identification trail that the reference does not emit.

Residual risk: A single actor with keystore + HMN_UNSEAL can re-identify every un-shredded subject without product dual-control. Mitigation is organizational custody of the sealed identity (split knowledge of passphrase, HSM/KMS in production, access logging outside Gate). The DPIA must record who holds vault access — not invent a dual-control product path.

5. Tamper-evident, not tamper-proof — the in-window residual

5.1 Property

The audit log is an append-only hash chain with a per-record HMAC, anchored by an Ed25519 Signed Tree Head (STH) issued every 32 records (a Merkle checkpoint pattern), and co-signed by an independent local witness. It is tamper-evident: alteration is detectable on verification. It is not tamper-proof: the term “tamper-proof” is not claimed.

5.2 Risk — the unanchored in-window residual

Records written after the last signed checkpoint and before the next are re-writable until the next checkpoint anchors them. Within that window there is a residual in which history could, in principle, be rewritten before it is sealed.

5.3 Mitigations

• The local witness co-sign stops silent history rewrites by a writer that does not also hold the witness key: co-signing the tree head means a rewrite cannot be re-anchored without the witness material. In the reference the witness runs in the same process as the writer, and with -keystore its seed lives in the same sealed keystore under the same HMN_UNSEAL. It defends against writer malfunction and partial compromise — not against an actor who holds the full keystore.
• Frequent checkpoints (every 32 records) bound the size of the unanchored window.
• Public verifiability. Hash linkage and Ed25519 STHs verify with published public keys (GET /__hmn/admin/keys, boot log). Live Integrity / SelfVerify also checks the HMAC layer when the node holds the key; public-key-only offline Verify may return hmac-unchecked. Classes: hash-break, hmac-invalid, hmac-unchecked, seq-gap, linkage-break, checkpoint-mismatch, empty-chain, witness-invalid, node-missing.

Residual accepted: The in-window (post-last-checkpoint) residual and the co-located witness are accepted, documented limitations of the reference. The DPIA should record them as known integrity limits, not as external multi-party consensus.

Note: A standalone offline verifier process, RFC 3161 trusted timestamps, and external WORM/object-lock anchoring are prod-deltas (Section 7.3). They are recommended production anchors, not shipped features of the reference.

6. Safeguards summary (technical and organizational measures, Article 32)

The following measures are what the DPIA can cite as the reference’s technical and organizational controls on the administrative plane:

• RBAC with four roles — Auditor, Operator, Approver, DPO — with capabilities scoped per role (see RBAC and separation of duties).
• Separation of duties. Read, operate, approve, and DPO-erasure capabilities are held by distinct roles; no single role holds all.
• Dual-control on the highest-impact actions: permanent/CIDR bans and the kill switch must be committed by a distinct Approver; erasure must be committed by a distinct DPO (a generic Approver cannot approve erasure).
• Meta-audited reads and actions. Administrative access and privileged actions are written to the audit log; the actor identity is server-derived, and any actor value supplied in a request body is ignored — so the accountability trail cannot be spoofed by the caller.
• Deny-by-default admin plane. The admin API runs on a separate listener; the console and admin routes return 404 on the public edge, and missing or invalid bearer credentials return 404 rather than a distinguishable auth error. Bearer comparison is constant-time.
• Sealed keystore. The signing seed (Ed25519 STH key), HMAC key, and vault snapshot are sealed with scrypt (N = 2^15) and AES-256-GCM under the operator-held unseal secret.

Warning: The kill switch is fleet-wide. Activating it demotes hard-rule enforcement to monitor mode across the entire fleet — detection stops and traffic flows to the origin — while manual bans continue to enforce. Its scope and dual-control (a distinct Approver) must be understood before use; record it in the DPIA as a control with fleet-wide blast radius.

Note: In the reference, admin authentication is bearer tokens with dev defaults; real KMS/HSM key custody, ACME certificates, and mTLS/SSO admin authentication are prod-deltas. The DPIA should record the production key-custody and admin-auth model the operator will actually deploy.

7. Retention and data lifecycle

7.1 Retention tiers

The reference declares HOT / WARM / COLD age labels for documentation and a Tier(age) helper used in tests. They are not enforced at runtime: no production caller prunes, compresses, or relocates the WAL by tier; the Ledger Retention card is hardcoded HTML, not a read of /admin/policy. There is no WORM media or object-lock integration in the reference.

Audit durability defaults (honest residual): without -audit-wal the chain is in RAM and lost on restart; with -audit-wal it grows without bound. Neither default implements a retention schedule. Mitigation in the reference: none — operators must supply external retention, archival, and deletion policy (prod-delta).

The controller must reconcile any schedule with legal obligations (including PIPA where applicable) under Article 5(1)(e). Crypto-shred removes re-identifiability at any point without deleting records (Section 7.2); it is not a retention engine.

flowchart LR
  W["Decision written · (pseudonymized, hash-chained)"] --> A["WAL or in-memory chain · (no auto-tiering)"]
  A -. "operator retention policy · (prod-delta)" .-> RET["Archived / retired"]
  ER["Crypto-shred · (DPO + dual-control, ~5min hold)"] -. "destroy per-subject linkage key" .-> UN["Record retained, chain intact, · no longer linkable to subject"]
  A -. any age .-> ER

Confirmed in source: Tier(age) has no non-test production callers that enforce storage lifecycle. Do not claim automated HOT→WARM→COLD movement or WORM retirement as shipped.

7.2 Why crypto-shred rather than deletion — WORM compatibility

The right-to-erasure mechanism (Article 17) is cryptographic erasure (crypto-shred): the per-subject linkage key is destroyed, rendering the subject’s records permanently unlinkable, while the records themselves are never deleted and the hash chain and Merkle anchors stay intact and verifiable.

This design is chosen precisely because it is compatible with write-once-read-many (WORM) retention. A conventional delete would break the append-only chain (producing a linkage-break or node-missing integrity failure) and would be impossible on genuinely write-once media. Crypto-shred satisfies erasure by removing the ability to re-identify rather than the record, so the integrity guarantee and any WORM retention obligation are preserved simultaneously.

The erasure workflow provides:

• DPO gating and dual-control. Erasure is committed by a distinct DPO; a generic Approver cannot.
• A cancellable hold window (default ~5 minutes) before execution, cancellable via the erasure-cancel endpoint; a ticker executes due shreds.
• Completion evidence sealed on execution — when the hold window elapses and the shred runs, not at commit; a cancelled erasure produces none. Evidence is an erasure.completed audit record (HMAC-chained; covered by the next STH), not a standalone independently-signed certificate blob (retrieval endpoint remains prod-delta).

See the erasure (crypto-shred) runbook for the operational procedure.

Warning: Crypto-shred is irreversible and its scope is exact: it destroys the linkage key for the identified subject. Once the hold window elapses and the shred executes, the subject’s records cannot be re-identified by any party, including the controller. Confirm the subject and the hold-window state before commit.

7.3 Physical retirement and external anchoring are prod-deltas

Two lifecycle steps a production retention program would require are not implemented in the reference and must not be represented as shipped:

• Physical WORM retirement at COLD expiry — the physical destruction or retirement of records once the COLD tier expires — is a prod-delta.
• External WORM/object-lock anchoring and RFC 3161 trusted timestamps — anchoring the chain to an external immutable store or a trusted timestamp authority — are prod-deltas. They are recommended production anchors that would further constrain the in-window residual described in Section 5, but the reference does not ship them.

The DPIA should record these as planned production controls with a defined owner, not as existing safeguards.

8. Standards and legal mapping

The cryptographic and regulatory anchors this design actually uses are enumerated in the standards mapping. In summary, the reference uses Ed25519 signatures (RFC 8032), a Merkle Signed Tree Head pattern modeled on Certificate Transparency (RFC 6962), scrypt key derivation (RFC 7914), and AES-256-GCM. GDPR articles engaged include Art. 4(5) and Recital 26 (pseudonymization), Art. 5 (principles and accountability), Art. 17 (erasure), Art. 25 (data protection by design and by default), Art. 30 (records of processing), Art. 32 (security of processing), and Art. 35 (DPIA). Where the operator processes personal data of data subjects in Korea, PIPA destruction and record-keeping obligations apply.

RFC 3161 trusted timestamps and S3 Object-Lock/WORM external anchoring are prod-deltas — present them as recommended production anchors, not as controls the reference provides.

9. DPIA risk register (summary)

Related reading

• Data-processing inventory — field-level record of what is processed and stored.
• Standards mapping — cryptographic and regulatory anchors used versus aspirational.
• Erasure (crypto-shred) runbook — operational erasure procedure.
• RBAC and separation of duties — roles, capabilities, and dual-control model.
• Production vs reference — the full prod-delta boundary.