Privacy Policy
Sensitive Data De-identification Service
Data Processing Principles
This service is designed with privacy as a core architectural principle. All data processing follows these guarantees:
- Zero server-side data retention — No uploaded text, documents, images, or PDFs are stored on the server. All processing occurs entirely in memory and data is discarded immediately after the response is returned. Your input may remain visible in the browser until you close the tab or navigate away — this is standard browser behaviour and no data is sent back to the server.
- Internal processing only — All entity detection and redaction happens locally within the deployment environment. No document content is transmitted to external services.
- No external API calls — The service makes no outbound calls with your data. ML model weights are baked into the container image at build time; the runtime environment is configured in offline mode (
HF_HUB_OFFLINE=1) to prevent any outbound model downloads.
What Data Is Processed
| Data Category | Purpose | Retention |
|---|---|---|
| Uploaded content (text, documents, images) | Entity detection and de-identification | Server: none — discarded after response. Browser: until tab is closed. |
| Authentication claims (username, user ID) | Session management and access control | Session duration only (JWT cookie) |
| Request metadata (method, path, status, duration) | Operational monitoring and diagnostics | Log rotation policy (no PII logged) |
| Usage counters (input type, mode) | Prometheus metrics for capacity planning | In-memory only — reset on restart (anonymous aggregates, no user identifiers) |
Legal Basis for Processing (Art. 6 GDPR)
| Processing Activity | Lawful Basis | Justification |
|---|---|---|
| De-identification of uploaded documents | Controller's responsibility | This service acts as a data processor (Art. 28). The lawful basis for processing the personal data contained in uploaded documents is determined by the deploying organisation (the data controller) — typically Art. 6(1)(c) legal obligation or Art. 6(1)(f) legitimate interest in data protection compliance. |
| Authentication and session management | Art. 6(1)(f) — Legitimate interest | Necessary to secure the service, enforce access control, and prevent unauthorised use. Limited to a signed session cookie; no personal data is stored server-side. |
| Operational monitoring (request logs, metrics) | Art. 6(1)(f) — Legitimate interest | Necessary for system reliability, incident detection, and capacity planning. Logs contain only request metadata (method, path, status, duration) — no user identifiers or document content. Usage counters are anonymous aggregates. |
Third-Party Personal Data (Art. 14 GDPR)
Documents uploaded to this service may contain the personal data of individuals other than the user performing the upload (e.g. names, addresses, or identification numbers of third parties). This is inherent to the purpose of the service — the tool exists to detect and remove such data.
Controller obligations: The deploying organisation (data controller) is responsible for ensuring that:
- There is a valid lawful basis (Art. 6) for processing the third-party personal data contained in uploaded documents.
- Data subjects are informed in accordance with Art. 14, unless an exemption applies — for example, Art. 14(5)(b) where providing the information would be impossible or involve disproportionate effort, particularly given that the purpose of the processing is precisely to de-identify the data.
- A Data Protection Impact Assessment (Art. 35) is conducted if processing third-party data at scale, especially where sensitive categories (health, financial, identity documents) are involved.
How this service mitigates risk: No third-party data is retained, stored, or transmitted beyond the requesting user's session. All processing occurs in-memory and data is discarded immediately after the response. The service operates as a data processor (Art. 28) and does not make independent decisions about the personal data it processes.
Reversible Mode & Encryption Keys
When using reversible de-identification, a unique encryption key is generated per request using cryptographically secure random generation (Fernet / AES-128-CBC + HMAC-SHA256). The key is delivered to you in the downloaded key file and is never stored on the server. Only you possess the key needed to restore the original content. If the key file is lost, the original data cannot be recovered.
Technical Safeguards
- No database — The service has no database, no disk cache, and no temporary file storage.
- In-memory processing — All file handling uses in-memory byte streams (BytesIO) that are garbage-collected after each request.
- Stateless sessions — Authentication uses signed JWT cookies with no server-side session store.
- Security headers — OWASP-recommended headers (CSP, HSTS, X-Frame-Options, Referrer-Policy) are enforced on every response.
- Sanitized error responses — Error messages returned to clients never contain internal details or user data fragments.
Your Rights (GDPR)
Under the General Data Protection Regulation, you have the right to:
- Access — Request information about what personal data is processed.
- Rectification — Since no personal data is retained server-side, there is no stored data to rectify.
- Erasure — Since no data is retained, this right is satisfied by design.
- Portability — All output is returned directly to you in the response.
- Object — You may stop using the service at any time.
Last updated: October 2026