Incident Response and Notification
How LeraLink handles security and service incidents, and when and how we tell you.
Last updated: 13 November 2026
What counts as an incident
An incident is an event that harms, or may harm, the confidentiality, integrity or availability of LeraLink or of the data in it. Examples:
- someone reads or changes data they are not allowed to, including across installations;
- someone gains rights they should not have;
- data is lost, corrupted or wrongly deleted;
- the service, or an important part of it, is unavailable;
- a supplier we rely on reports an incident that affects our data.
A personal data breach is an incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (GDPR Article 4(12)). Not every incident is a breach, and every suspected breach is handled as an incident until it is ruled out.
Severity
| Level | Meaning | First action |
|---|---|---|
| Severity 1 | Exposure of data across installations, unauthorised authority, destructive corruption of data, or a complete outage | Affected writes are frozen at once |
| Severity 2 | An important feature unavailable, or processing delayed, without exposure of data | Contained and repaired in the same working session |
| Severity 3 | A limited degradation with a safe workaround | Tracked and repaired through the normal release path |
Phases
1. Detect
Incidents come to light through the internal monitor (every 15 minutes), the independent status page, automated checks, supplier notices, reports from customers and readers, and security researchers under the Coordinated Vulnerability Disclosure policy. We record the time we first knew.
2. Contain
The platform administrator can put one installation, or the whole platform, into read-only mode within minutes. Reading, signing in and the recovery tools keep working; every change to content and settings is refused. Putting one installation into read-only mode does not affect the others. Every change of mode is written to the audit record.
Other containment measures include revoking sessions, disabling a feature for an installation on the server, revoking and replacing credentials, and rolling back a release.
3. Assess
We establish what happened, when, which installations and which kinds of data are affected, how many people, and the likely consequences for them. For a personal data breach, we assess the risk to the people concerned, which decides whether the authority and those people must be told.
4. Recover
We choose the recovery that fits: rolling back the release for a code fault, point-in-time restore for a destructive change to data, or restore from the nightly backup. Before normal operation resumes, we verify reading, sign-in, owners' access and the separation between installations. Backup and Recovery describes the restore paths.
We do not promise a recovery time before the restore path has been verified.
5. Notify
See How and when we notify below.
6. Learn
After the incident we record the timeline, the decisions, the restore point used, the verification and the measures taken to prevent a recurrence. For a significant incident we publish a report (see below).
Evidence
Logs, request references and audit events are preserved. Evidence is not deleted or rewritten. The audit record is append-only and kept under legal hold, so it is never deleted, including during or after an incident.
How and when we notify
| Who | When | How |
|---|---|---|
| Installation customers, where their data is affected by a personal data breach (they are the controller; we are their processor) | Without undue delay, and within 48 hours of becoming aware of it, as set out in the Data Processing Agreement | Email to the installation's owners and to the privacy and security contacts named in the Order Form, and by phone where a number is given and the breach is serious, with updates as we learn more |
| Installation customers, for other incidents affecting their installation | Without undue delay; for a critical (P1) incident, within the response target of the Service Level Agreement | Email to the installation's owners and to the support and security contacts named in the Order Form, and a notice in the installation where relevant |
| Autoriteit Persoonsgegevens, where SSStudio is the controller | Within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to people (GDPR Article 33) | Through the authority's notification procedure |
| Affected people, where SSStudio is the controller | Without undue delay, where the breach is likely to result in a high risk to them (GDPR Article 34) | Directly, by email, in clear language |
| Everyone | During a platform-wide disruption | The status page, status.lera.link, and, when the platform is put into read-only mode, a notice on every installation |
Where an installation customer is the controller, it decides whether to notify the authority and the people concerned. We give it the information it needs to do so and help it, as the Data Processing Agreement requires (GDPR Article 28(3)(f) and Article 33(2)). We do not notify the authority or those people on the customer's behalf unless it asks us to in writing.
What a notification contains
As far as it is known at the time, and supplemented as we learn more (GDPR Article 33(3)):
- what happened and when, and when we became aware of it;
- the kinds of data and the approximate number of people and records concerned;
- the likely consequences;
- what we have done and propose to do, including measures to limit harm;
- what you can do yourself;
- a contact for further information.
Status page
status.lera.link runs independently of LeraLink, on GitHub. It shows the state of the platform as a whole, not of each installation. An incident limited to one installation is communicated to that installation's contacts directly. See Availability and Status.
Incident reports
For every critical (P1) incident, and for other significant incidents, we publish a report under Updates → Incident Reports within 10 business days after it is resolved: what happened, the impact, the cause, what we did and what we changed. A report does not contain personal data or details that would help an attacker.
Report a suspected incident
| What | Where |
|---|---|
| A security vulnerability or suspected incident | security@lera.link (see the Coordinated Vulnerability Disclosure policy) |
| A suspected personal data breach | security@lera.link, with a copy to privacy@lera.link |
| A service outage | support@lera.link, after checking status.lera.link |
| Illegal content | legal@lera.link or Report Content |
Please tell us what you saw, when, and at which address. Do not try to access other people's data to confirm a suspicion.
Our limits
Incident monitoring and incident response run around the clock: monitoring alerts SSStudio, and SSStudio responds to an incident also outside office hours. Customer contact and support are during office hours; there is no 24/7 support desk. The response times we commit to are in the Service Level Agreement.