Incident response

1. Scope

This document covers any event that compromises the confidentiality, integrity or availability of the service or of the data it holds. That includes unauthorised access to an account or to our systems, accidental or unlawful destruction, loss, alteration or disclosure of personal data, a compromise at one of our sub-processors, and loss of availability where that loss is likely to affect the rights of individuals.

Not every security incident is a personal data breach, and not every personal data breach requires notification. The assessment in section 3 determines which obligations arise. Where the assessment is finely balanced, we notify.

2. Severity

Every incident is assigned a severity on first assessment. The severity determines the response time and who is involved, and it is revised as more becomes known rather than fixed at the outset.

3. Procedure

1. Detection. Incidents reach us from application and infrastructure monitoring, from error reporting, from a report by a customer or researcher, or from a notification by a sub-processor. Any route is valid and none is treated as less credible than another.
2. Triage. The incident is recorded, given a severity under section 2, and assigned to a named person who is responsible for it until it is closed. That person coordinates the response and keeps the record.
3. Containment. The immediate priority is to stop the incident continuing. Depending on the incident this means revoking sessions, credentials or API keys, disabling the affected feature, blocking a source of traffic, or taking a component out of service. Containment takes precedence over diagnosis.
4. Assessment. We establish what data was involved, how many people are affected, whether the data was actually accessed or merely exposed, and what the consequences for those people could be. This assessment determines which notifications are required under section 4.
5. Notification. Notifications are made in accordance with section 4. The clock for the 72 hour deadline runs from the point at which we become aware of the breach, not from the point at which the investigation is complete.
6. Remediation. The underlying cause is fixed and the fix is verified. Where personal data was altered or destroyed, we restore from backup where restoration is possible.
7. Review. Within 14 days of closing a critical or high severity incident we review what happened, what allowed it, how quickly it was found, and what should change. Actions arising are recorded and tracked to completion.

4. Notification

To the supervisory authority

Where we are the controller and a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, we notify the Swedish Authority for Privacy Protection without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Where notification is made later than 72 hours, it is accompanied by the reasons for the delay. Where the breach is unlikely to result in a risk, we do not notify, and we record the reasoning.

To affected individuals

Where a breach is likely to result in a high risk to the rights and freedoms of natural persons, we communicate it to those individuals without undue delay, in clear and plain language. We are not required to do so where the data was rendered unintelligible to any unauthorised person, where we have taken measures that mean the high risk is no longer likely to materialise, or where individual communication would involve disproportionate effort, in which case we make a public communication instead.

To customers, where we are the processor

Where the breach affects personal data for which a customer is the controller, we notify that customer without undue delay and in any event within 48 hours of becoming aware, so that the customer can meet its own obligations. It is the customer, not us, who decides whether to notify their supervisory authority and their data subjects.

What a notification contains

• The nature of the breach, including where possible the categories and approximate number of data subjects and of records concerned.
• The approximate number of data subjects and of personal data records affected.
• The likely consequences of the breach.
• The measures taken or proposed to address the breach and to mitigate its possible adverse effects.
• The name and contact details of the point of contact for further information.

Where it is not possible to provide all of this information at the same time, it is provided in phases without further undue delay. A partial notification made on time is preferred to a complete notification made late.

5. Sub-processors

Our agreements with sub-processors require them to notify us of a personal data breach affecting data they process for us without undue delay. On receiving such a notification we run the procedure in section 3 as though the incident had arisen in our own systems, and the notification obligations in section 4 apply in the same way.

Where a sub-processor's incident affects the availability of the service but does not involve personal data, we inform affected customers of the disruption and of the expected restoration, without making it a personal data breach notification.

6. Records

We document every personal data breach, including those we assess as not requiring notification. The record contains the facts of the breach, its effects, the assessment of risk, the reasoning behind any decision not to notify, and the remedial action taken. This is required by Article 33(5) and enables the supervisory authority to verify how the obligations were met.

Breach records are retained for five years from the closure of the incident.

7. Contact

Incidents, questions about this document, and requests for information about a specific incident should be directed to:

This document should be read together with our privacy policy and our data processing agreement.