Trust

Security incidents and personal data breaches

This document says what the operator of filterit (the "Operator") does when something goes wrong: how an incident is classified, what happens in the first hours, and when and how customers, the supervisory authority and data subjects are notified. It is the customer-facing part of the Operator's incident process and the commitment the Data Processing Agreement refers to in its breach clause.

Related: the technical and organisational measures, the security page and the vulnerability disclosure policy.

1. Definitions

A security incident is any event that compromises, or could compromise, the confidentiality, integrity or availability of the service or the data in it. A personal data breach (Article 4(12) GDPR) is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

What makes this service different from most: content is stored masked and sealed, and the original values live only in an encrypted vault. The severity of an incident therefore depends above all on one question: was the vault reachable together with a key that opens it? Masked content without the key is pseudonymised data; the vault with its key is the re-identification key for everything.

2. How to report to us

  • Vulnerabilities and suspected incidents: contact@filterit.app, privately, before any publication. The address is also in /.well-known/security.txt (RFC 9116).
  • Customers under a DPA: the same address, marked "security incident". We confirm receipt and give a single point of contact for the incident.
  • We answer every report. We ask that nobody tests against other people's accounts or data.

3. Severity

Level Definition Examples
1, critical Confirmed or likely exposure of decryptable personal data, or of a key that opens the vault Master key disclosed; vault database copied together with the server's secrets; unmasked content sent to the wrong party
2, high Exposure of masked but personal data, or compromise of credentials and tokens Mailbox tokens disclosed; bulk copy of masked records; an administrator account taken over
3, medium A contained security event with no confirmed exposure of personal data A blocked intrusion attempt; a temporary file kept past its lifetime; a dependency vulnerability found exploitable
4, low A deviation from policy or configuration with no data risk A misconfiguration caught before exposure

The level can change as the investigation learns more.

4. The first hours

  1. Record the time of awareness. It starts the 72-hour clock of Article 33 and the 48-hour clock of the DPA.
  2. Contain. Isolate the affected component; rotate every credential that could be involved (the master key and its derived keys, session signing secret, API keys, mailbox tokens, provider keys); revoke sessions; if a mailbox token is involved, revoke it at the provider and disconnect the mailbox; if the model provider is involved, pause outbound calls.
  3. Preserve evidence before remediation overwrites it: logs, the egress log chain, the administrator audit log, the state of the affected systems.
  4. Assess. Which data, how much, masked or decryptable, was a key exposed, how easy is re-identification, what are the likely consequences for the people concerned.
  5. Decide the notifications of section 5 and start them.
  6. Remove the cause (patch, configuration, key rotation with re-encryption), verify the vault's integrity and the enforcement of lifetimes and purges, restore the service, watch for recurrence.

Rotating the master key means re-encrypting the vault under the new key; the step-by-step procedure is in the Operator's internal runbook and a suspected key compromise triggers it immediately, together with the revocation of every session.

5. Notifications

Who When What
Customers under a DPA (as controllers) Without undue delay and in any case within 48 hours of awareness, for any personal data breach affecting their data The nature of the breach, the categories and approximate numbers of data subjects and records, whether the data was masked or decryptable and whether a key was exposed, the likely consequences, the measures taken and proposed, the contact point. Supplemented as the investigation progresses.
Supervisory authority (where the Operator is the controller) Without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Article 33) The content of Article 33(3). Where the information is not complete at once, it is given in phases (Article 33(4)). The reasoning for not notifying, where that is the decision, is recorded.
Data subjects Without undue delay when the breach is likely to result in a high risk to their rights and freedoms (Article 34) In clear and plain language: what happened, which data, what it may mean for them, what we did, what they can do, how to reach us. Not required where the data was unintelligible to the unauthorised party (for example, masked content with no key exposed) or the high risk has otherwise been removed.
The public When an incident affected the service's availability or many users A short status note on the site, without personal data.

Pseudonymisation is taken into account in the risk assessment, in both directions: exposure of masked content alone may be lower risk; exposure of the vault together with a key is high risk because re-identification becomes trivial.

6. Review

Version Date Change
1.0 2026-10-07 First published version. Severity by whether a key was exposed; 48 hours to customers (DPA), 72 hours to the authority (Article 33).