Audit trail data minimization — raw network identifiers removed, hashed-only records remain

Why this post exists

This is an operator-side transparency post about a change to how our compliance audit trail handles network identifiers. The change does not affect customer billing, account access, or any product behavior visible in dashboards. It does, however, advance one of GDPR's core principles — data minimization under Article 5(1)(c) — in a way that EU DPOs, Heads of Compliance, and Legal Counsel typically want to verify before contracting with a data processor.

What changed in plain language

Every account change we log — account creation, key rotations, plan changes, team membership updates, billing events — is recorded in a compliance audit trail. This trail must exist for legitimate legal reasons (GDPR Article 30 record-keeping plus Polish accounting law requiring five-year retention for financial events).

Until now, each entry could include a network identifier alongside the event. Going forward, only a one-way hashed form of that identifier is stored. The raw form is no longer kept anywhere.

Practical effect for customers:

• Less raw personal data sits in your account's compliance trail. What remains is sufficient to satisfy audit and tax obligations but cannot be reversed to recover the original network details.
• Row continuity is preserved. Compliance auditors and tax authorities can still see that an event occurred, when, and by which account — they just no longer see the raw network detail.
• Older legacy entries. Historical entries from before the hashing change carried a different format. Those entries now carry a clearly labeled marker indicating that the network field has been retired for that row. The marker preserves audit-trail row continuity while making it explicit that the original raw value is no longer retained.

Why the legal framing matters

Under GDPR Article 5(1)(c) — the data minimization principle — personal data must be "adequate, relevant and limited to what is necessary" for the purpose of processing. For audit trails, the necessary information is usually what happened and who did it, not the raw network metadata around it. Retaining the raw form when a hashed form serves the same audit purpose is exactly the kind of disclosure that a sophisticated buyer asks about during procurement.

Under GDPR Article 30 — records of processing activities — the controller must maintain a record of processing operations. We continue to do so. Hashing the network identifier does not reduce the audit value of the record; it only reduces the personal-data surface area.

Under Polish Ustawa o rachunkowości (Accounting Act) Article 74 — financial records must be retained for five years from the end of the fiscal year. We preserve this requirement: rows flagged as financial events are retained for the full statutory period. Our change does not delete any row; it only minimises the network-identifier field within each row.

This three-way alignment (Art. 5(1)(c) minimization + Art. 30 record-keeping + Polish 5-year tax retention) is the kind of detail that creates downstream friction during audits when it is not held simultaneously. We chose to hold all three rather than pick two.

Why we are publishing this

EU mid-market buyers in publishing, e-commerce, and SaaS evaluate their vendors against an increasingly detailed privacy posture. "Does the vendor minimise data that is not strictly necessary for the stated purpose?" is one of the recurring questions in vendor due-diligence questionnaires. Saying yes is one thing; describing the specific change that supports the answer is another.

We publish operator-side transparency posts so that compliance teams evaluating HumanKey can verify these claims directly against the version of the service they are about to procure.

What this does not change

• Detection accuracy is unaffected. Bot detection has always operated on hashed identifiers for analytics purposes; this change is about a different system (the compliance audit trail), not the detection pipeline.
• Billing and account access are unaffected. Audit-trail changes are downstream of the operational service.
• Legal exposure to data subjects under Article 15 (right of access) is unchanged. The hashed identifier remains the canonical reference for any audit-trail entry returned in an access request.

Reference points

• GDPR Article 5(1)(c) — Data minimization principle
• GDPR Article 30 — Records of processing activities
• Polish Ustawa o rachunkowości Article 74 — Five-year retention for financial records
• Our Privacy Notice and DPIA describe the categories of data we process and the retention periods that apply per plan

---

HumanKey is an EU-based, GDPR-native analytics platform for publishers and e-commerce sites. Operator transparency posts cover the compliance and engineering choices that B2B buyers evaluate during procurement.