Data Protection Impact Assessment — Summary
GDPR Article 35 | April 2026
This page is a summary of the data protection impact assessment prepared by the operator of the HumanKey service. It is information, not a contractual warranty. The summary is under review; this page was last changed on 9 October 2026.
1. Purpose & Scope
HumanKey provides AI bot detection and traffic classification services for website publishers. The service systematically monitors website requests to distinguish between human users and automated agents (AI crawlers, scrapers, bots). This DPIA assesses the privacy impact of that processing.
2. Data Categories
| Category | Processing | Status |
|---|---|---|
| IP Addresses | Pseudonymised (a keyed hash) before storage in the database — the original IP is not kept there | Pseudonymized |
| User-Agent Strings | Truncated to 200 characters for classification only | Reduced PII |
| Page & Referrer URLs | Used for traffic analysis | Potentially personal |
| Visit Metadata | Timestamps, session duration | Non-personal |
| Behavioral Signals | Aggregated session-level interaction patterns (no keylogging) | Pseudonymized |
| Country-Level Location | Derived from IP via geolocation database (country code only) | Potentially personal |
| AI Crawler Identity | Bot name, company, purpose (automated agent data) | Non-personal |
3. Legal Basis
- Account data: Contract performance (Art. 6(1)(b)) — accepting the Terms of Service during registration forms the contract; providing account data is a contractual requirement, and without it we cannot create or operate the account (Art. 13(2)(e))
- Bot detection: Legitimate interest (Art. 6(1)(f)) — protecting content from unauthorized scraping, ensuring accurate traffic metrics, preventing server overload from aggressive crawlers
- Account-holder collaboration: Legitimate interest (Art. 6(1)(f)) — when an account holder invites another person to join their workspace, identifying context about the inviter (such as their display name where available) may be shown to the invitee for identity verification, balanced against the inviter’s reduced expectation of privacy in the act of inviting. The invitation and its preview do not include the inviter's e-mail address.
Consent is not suitable for bot detection because automated agents cannot and do not provide consent, and requiring it would defeat the purpose of the processing.
4. Identified Risks & Mitigations
LOW: False Classification
Human visitor incorrectly classified as bot → no functional impact (no blocking), statistical error only. Mitigated by confidence thresholds and manual review options.
LOW: Data Breach
Exposure of stored IP codes → they are pseudonymised; re-identification requires additional information that is kept separately. Mitigated by encryption at rest and in transit, access controls and automated retention enforcement.
MEDIUM: URL Privacy Leakage
URLs containing identifiers stored in analytics → potential re-identification. Mitigated by publisher documentation and automatic query-parameter stripping at write-time (query strings are removed before the URL is stored; only origin + path is retained).
LOW: Sub-Processor Access
Sub-processors access pseudonymized data → mitigated by data processing agreements and by the transfer mechanism listed for each sub-processor in the Sub-Processors register.
Overall Risk: MEDIUM — No high-risk automated decision-making (Art. 22), no special category data (Art. 9). Risk is elevated due to sub-processors outside the EEA; transfers to them rely on the transfer mechanism listed for each of them in the Sub-Processors register.
5. Safeguards
- Pseudonymization: IP addresses cryptographically hashed before storage in the database (Art. 32(1)(a))
- Data Minimization: User-Agent truncated, no special category data collected
- Storage Limitation: Automated retention enforcement (Free: 7d, Pro: 30d, Business: 90d, Enterprise: 365d)
- Encryption: Industry-standard encryption in transit and at rest
- Access Controls: Authentication, rate limiting, and role-based access
- Monitoring: Error tracking with PII stripping, structured logging, audit trail
- EU Data Residency: Primary data processed and stored within the European Union
- No Automated Blocking: Classification is informational only — no automated decisions affecting individuals
- Bot-classification verification (admin & automated): HumanKey reviews the quality of classification results, including review by HumanKey staff; in addition, certain automated checks may also confirm a classification. Verification labels are stored with a hashed identifier — a hashed admin identifier for manual reviews, or a hashed IP address for automated signals — for audit and detection-quality purposes; no additional personal data is collected and no data is transmitted outside HumanKey. This processing is informational only and does not produce legal or similarly significant effects on end users.
- AI Transparency (EU AI Act Art. 50): Every place where HumanKey's customers or visitors interact with a large language model is described at /legal/ai-transparency. ML scoring output is a calibrated probability score and is explicitly advisory — it informs admin review and in-product insights, but never serves as the sole basis for any legal or financial decision (Art. 22 boundary).
6. Data Subject Rights (Art. 15–22)
| Right | How to Exercise |
|---|---|
| Access (Art. 15) | Dashboard → Settings → Export Data (JSON) |
| Erasure (Art. 17) | Dashboard → Settings → Delete Account — see §6.1 for scope & exemptions |
| Rectification (Art. 16) | Dashboard → Settings → Update Profile |
| Object (Art. 21) | Contact form (30-day response) |
| Portability (Art. 20) | Machine-readable JSON export |
6.1 Right to Erasure — Scope & Exemptions
When an account holder exercises Art. 17 GDPR (Right to Erasure), HumanKey applies a layered erasure mechanism that balances the data subject's right with statutory obligations:
When the account is deleted, its sites, visit data, API keys and analytics are deleted from the Service; copies in backups expire on the database provider's backup cycle. Records the law requires us to keep (for example records needed for tax purposes) are kept only as long as the law requires, then deleted (Art. 17(3)(b) GDPR). In activity logs of other organisations, the e-mail address of a deleted team invitee is replaced with a neutral marker. One record of the accepted Terms versions, linked only to a pseudonymised e-mail address, is kept to establish, exercise or defend legal claims (Art. 17(3)(e) GDPR); see section 8 of the Privacy Policy.
6.2 Embeddable Verified Badge — Processing Assessment
New processing activity introduced for Pro+ customers who opt in to embed our HumanKey Verified Badge on their websites. The badge endpoint at api.humankey.io/api/badge receives an HTTP request from every third-party visitor to the customer's page, including: IP address, User-Agent, and optionally a Referer header (suppressed by the recommended Referrer-Policy: no-referrer). Our application does not store the visitor's IP address or User-Agent from a badge request in its traffic data; badge requests are rate-limited.
Legitimate Interest Assessment (LIA, Art. 6(1)(f)): the controller's legitimate interest in trust signaling and visitor transparency about AI-traffic monitoring is balanced against the visitor's privacy interest. Our application does not store the visitor's IP address or User-Agent from a badge request in its traffic data; the request is processed to serve the image and for rate limiting; no profiling of individual visitors occurs. The opt-in dashboard toggle (default OFF) and the absence of a visit record for a badge request further reduce the visitor's privacy intrusion. The controller concludes that the legitimate interest is not overridden by the rights of the visitor.
7. Sub-Processors
A complete list of sub-processors, their purposes, data locations, and DPA links is maintained at: /legal/sub-processors
Transfers to sub-processors outside the EEA rely on the transfer mechanism listed for each of them in the Sub-Processors register.
8. Review
- The assessment is reviewed when the risk represented by the processing changes (Article 35(11) GDPR).
- Controller: Robert Pałka ChainGuard
9. Supervisory Authority
Polish supervisory authority: Urząd Ochrony Danych Osobowych (UODO)
Website: uodo.gov.pl
Questions? Contact us via our contact form or write to the Polish supervisory authority (UODO).
This summary was prepared with reference to Article 35 GDPR and the WP29 guidelines on data protection impact assessments (WP 248 rev.01). Controller: Robert Pałka ChainGuard.