Trust

Technical and organisational measures (Article 32 GDPR)

This document describes the measures that protect personal data in filterit, the AI chat and data masking gateway operated by the operator of filterit (the "Operator"; legal identity available on request at contact@filterit.app). It is the text the Data Processing Agreement refers to as the Operator's security measures, and it is written from what the code and the deployment do, not from a template. Where a measure does not exist yet, section 10 says so.

Related: the security page (the architecture in plain words), the privacy policy (section 7 holds the retention table), the incident and breach process, the accuracy page and its method.

1. What the measures protect

The product replaces detected personal data with placeholders before text leaves for a third-party model and restores the values in the answer. Two things therefore need the strongest protection: the mapping between placeholders and original values (the vault) and the keys that encrypt it. A compromise of the vault together with its key is the highest-impact event the design guards against, and the measures below are ordered by that priority.

Detection is not infallible; the measures reduce exposure, they do not promise its absence. The method says what is measured and what is not.

2. Encryption and keys

Key separation: the encryption key, the search key and the audit key are derived from the master secret with HKDF-SHA256 under distinct labels, so a compromise of one derived key does not yield the others.

3. What is never stored

• Original uploaded files and scans: kept on temporary disk for at most 30 minutes (10 minutes for visual redaction sources) and never written to the database.
• Email threads: read live from the provider, processed, discarded. Only the masked draft is stored.
• Unmasked conversation text: the database holds masked, sealed content; the values exist only in the vault, for at most 30 days.
• Personal data in logs: application logs carry placeholders at most; titles, project names, file names and bodies are never logged.

4. Detection that refuses rather than leaks

• When the detection service is unavailable or degraded, the request is refused (HTTP 503) rather than forwarded with weaker detection. The machine-to-machine API behaves the same unless the caller explicitly accepts degraded detection.
• Structured identifiers (Greek tax number, social security number, IBAN and the national identifiers of other EU countries) are validated by format and check digit; a validated identifier bypasses every confidence floor, so a strict policy can never drop it.
• Streaming answers pass through a stateful unmasker that holds back partial placeholders, so an original value cannot leak across chunk boundaries.
• The web search tool sends a query only after the detected values have been removed from it, and records the send in the egress log.
• Every send to an external model leaves one row in a hash-chained, placeholder-only egress log (destination, size, SHA-256 digest, masked preview). The chain is verified when an evidence pack is produced.

5. Access control

• Accounts: email and password with a minimum length of ten characters and a list of common passwords refused, or sign-in with Google. Sessions are signed tokens valid for eight hours. Sign-in, registration, verification and password reset are rate limited per address.
• Organisations: roles (owner, administrator, member) decide who can manage members, API keys, policies and billing; conversations and projects belong to a workspace and are read only with membership.
• Administration panel: a separate application on its own host with its own administrator accounts; every administrator action is written to an audit log. An administrator never sees a value sealed under a customer-held key.
• Production: access limited to the operators, over SSH with keys. Secrets live in an environment file on the server, outside the repository and the images. The database is not reachable from the internet.
• Code: two-factor authentication on the code host; changes reach the main branch only through a pull request that needs an approval, with the required checks of section 7 green.

6. Hosting and infrastructure

• Hosting at Hetzner Online GmbH, Germany (data centre in Falkenstein), on servers operated by the Operator. The sub-processor list is public at /sub-processors.
• Services run as containers with no published ports except the reverse proxy; the proxy terminates TLS and forwards only the application paths. A lint of every deployable compose file fails the build on a published database port, a privileged container or access to the Docker socket.
• The model provider receives masked text only. Detection, OCR, speech-to-text and visual redaction run on the Operator's servers.
• Backups: daily, encrypted (section 2), kept on the server for 14 days; a restore drill is recorded in the operations runbook. A backup older than 26 hours raises an alert.

7. Checks on every change

Every change runs through the continuous integration pipeline before it can be merged:

• Detection quality gate. The gold sets run in hermetic replay. At the deep detection level, one personal datum left uncovered in any category fails the build. The published accuracy table is compared with the fresh run and must match.
• Precision gate. False positives on the adversarial negative set (660 documents without personal data) have a committed ceiling.
• Reference snapshots. A byte-exact reference snapshot of the Greek pipeline and the matrix of 52 national identifier forms must stay identical or change deliberately.
• Secret scanning on every push (gitleaks).
• Vulnerability scanning of the Java and npm dependencies and of the container images (trivy), plus a nightly OWASP dependency check and automatic update proposals (Dependabot). Findings are fixed or recorded with a reason and an expiry.
• Compose security lint, Content Security Policy check of the public pages, readiness of the legal texts (no draft marker, no blank field, one copy of the DPA), and the wording rules.
• Backup guard. A test proves the backup script refuses to write plaintext.

8. Logging and monitoring

• Application logs contain no personal data and no content; errors carry identifiers, not values.
• Web server access logs (which include IP addresses) are kept for 7 days; application logs are rotated by size and kept at most 30 days.
• Metrics and alerts cover service health and backup age.
• The egress log (section 4) and the administrator audit log are the records a customer can ask for.

9. Development and change management

• One repository, protected main branch, pull requests with review, the checks of section 7 required.
• Detection changes are measured before merge (gold sets, negative set, reference snapshot) and the published numbers travel with the version of the method that produced them.
• Material changes to detection, to the placeholder format, to sub-processors or to this document are recorded in the repository history and, where they affect customers, in the sub-processor list and the DPA.
• Development and staging environments hold no production personal data.

10. What does not exist yet

Stated here so that a reviewer does not have to find out:

• No ISO 27001 or SOC 2 certification. A gap assessment is planned; certification is a project of months.
• No completed external penetration test. One is planned. Until then, security rests on the automatic checks above and on responsible disclosure (security.txt, disclosure policy).
• No trusted third-party timestamp on the egress log chain: the chain proves integrity and ordering, not absolute time.
• Reversibility is proven by property tests on the in-memory and on-device vaults; the database-backed vault of the hosted service is covered by design and by unit tests.

11. Review

This document is reviewed at least once a year and after any material change to the architecture. Its version and date are at the top; the change history is in the repository.