Incident management policy

How we detect, report, handle and learn from information security events and incidents in our SaaS products and internal systems. It applies to all employees and to everyone who operates these systems.

Annex A controls: 5.5, 5.6, 5.24, 5.25, 5.26, 5.27, 5.28, 6.8.

Definitions

An event is anything that may affect the confidentiality, integrity or availability of information: a monitoring alert, a suspicious email, a lost laptop, a customer report.
An incident is an event that harms, or is likely to harm, information or a service: an outage customers notice, data exposed to someone unauthorised, data lost or corrupted, or an account, device or server controlled by someone else.
A personal data breach is an incident in which personal data is destroyed, lost, altered, disclosed or accessed without authorisation (GDPR article 4).

Roles (5.24)

Role	In an incident
Employees	Report every observed or suspected event immediately
Information Security Officer	Receives reports, assesses events, leads security incidents, keeps the incident register
Infrastructure	Handles monitoring alerts, leads hosting and infrastructure incidents, secures technical evidence
Project lead	Leads incidents in their product and informs its customers
Management	Decides on notifying authorities and on communication with legal or contractual impact

Every incident has one incident lead, named in the incident issue. The lead coordinates; anyone with the right access does the work.

Reporting events (6.8)

Report an event immediately to the Information Security Officer, through a Mattermost direct message or by phone when it is urgent. When the Information Security Officer cannot be reached, report to Management or Infrastructure.
Report when in doubt. A false alarm costs little; a late report can cost a lot.
Examples: a lost or stolen laptop or phone; a link clicked or a password entered after a phishing email; a secret pushed to Git, pasted in a chat or sent to an outside service; data sent to the wrong recipient; logins or changes in your account that you did not make; a weakness you notice in a product or system; a supplier that reports a breach.
Do not test a weakness or clean up a compromised system yourself: it can destroy evidence. Change a leaked password of your own straight away and mention it in the report. A leaked GitLab token is revoked as described in token rotation.
A phishing email that you did not act on only needs to be flagged as junk.

Events are also detected automatically:

Infrastructure monitoring and uptime checks post alerts to the team’s alert channels in Mattermost (Discord for Appsemble). See monitoring and service status.
Sentry reports application errors to the product’s channels and to the issue owners, and turns high-priority production errors into GitLab issues.
Customers report through the Service Desk of each product.

Procedure (5.25, 5.26)

Detect. An alert, a customer report, a supplier notice or a report from an employee.
Report. The reporter informs the Information Security Officer. An alert is picked up in its channel.
Assess. The Information Security Officer, or Infrastructure or the Project lead for an availability event, decides whether the event is an incident, within one working day and at once for anything that looks serious. An event handled in normal operations, such as a disk alert cleared by a cleanup, needs no incident record. An incident gets a category and a severity (below).
Respond. Contain first: revoke credentials and sessions, block accounts, isolate or stop affected systems. Then remove the cause and recover to a known good state, restoring from backup where needed as in the business continuity policy. Emergency changes follow the change management policy.
Communicate. Inside the team through the incident issue and Mattermost; with customers and authorities as described under authorities and customers.
Record. Every incident has an incident issue (see records).
Evaluate. After recovery, find the root cause and the corrective actions (see learning from incidents).

Categories and severity

Category	Examples
Availability	A SaaS product or internal service is down or degraded, data is lost and restored
Confidentiality	Data is exposed, a device is lost or stolen, a credential leaks, an account is compromised
Integrity	Data or software is changed or corrupted without authorisation

Every incident also records whether personal data is involved, because that decides the GDPR steps.

Severity	When	Issue label
Critical	Most users are severely affected, or exposure of personal or confidential data is confirmed	`Priority::Critical`
Urgent	Several users are severely affected, or exposure of data is suspected	`Priority::Urgent`
High	Limited impact and no data exposed	`Priority::High`

The labels follow the GitLab priority labels: critical and urgent incidents go before all other work.

Authorities and customers (5.5)

Who	When	Informed by	Term
Autoriteit Persoonsgegevens	A personal data breach in data we control, unless it is unlikely to harm the people involved	Information Security Officer	Within 72 hours after becoming aware of it
The customer (controller)	A personal data breach in data we process on the customer’s behalf	Project lead	Without undue delay, as the processing agreement sets
The people whose data is involved	A personal data breach in data we control with a high risk to them	Information Security Officer	Without undue delay
Affected customers	An incident that affects their service	Project lead	As agreed in the contract or SLA
Police	A crime, such as theft of a device, a break-in, extortion or fraud	The person involved, or Management	As soon as possible
NCSC	Voluntarily, when an incident or vulnerability can affect others	Information Security Officer	When useful

Management decides on every notification to an authority, on the advice of the Information Security Officer.
Every personal data breach is recorded in the incident register, also when it is not notified, with the reason.
Outages are also shown on the product’s public status page. Messages to customers state what happened, what it means for them, what we do, and what they should do; never guesses about the cause.
The notifications made, with date and time, are recorded in the incident issue.

Special interest groups (5.6)

The Information Security Officer follows the Digital Trust Center, the Dutch government’s source of security alerts and advice for businesses, and shares what matters in the ISMS security meeting.
Vulnerability feeds for our technology stack are part of the operations security policy.
A vulnerability we find in an open-source project is reported to that project through its security contact, not in a public issue.

Records (5.27, 5.28)

Every incident is a confidential GitLab issue in the project of the affected product, or in dc/dcentralize/general when it spans products, linked to the ISMS incident register. Its description follows this template:

**Event:** what was observed, when, by whom, and how it was reported.
**Assessment:** incident yes / no, category, severity, personal data yes / no; decided by whom and when.
**Incident lead:** @username
**Timeline:** actions and decisions with date and time.
**Communication:** who was informed (customers, authorities, people involved), when and how.
**Evidence:** what was collected, by whom, when, and where it is kept.
**Root cause:** why it happened (ask "why" until the cause is something we can change).
**Corrective actions:** task list with owner and due date, or links to non-conformity issues.

Evidence (5.28)

Before changing an affected system, secure what shows what happened: a snapshot of the server, the relevant logs from central logging, Sentry and the application, and screenshots.
Keep evidence in the confidential incident issue, or in a restricted location named in the issue when it contains personal or confidential data. Record for each item what it is, where it came from, who collected it and when.
Do not edit evidence, and do not wipe or reinstall a compromised device or server until the Information Security Officer confirms that the evidence is secured.

Learning from incidents (5.27)

Within two weeks after recovery, the incident lead completes the root cause and the corrective actions in the issue, together with the people involved. The evaluation looks for causes, not for someone to blame.
An incident caused by a control that did not work, or by a policy that was not followed, is also recorded as a non-conformity, as described in improvement.
Lessons go where they prevent a repeat: monitoring, tests, infrastructure code, or the handbook.
The ISMS security meeting reviews the incidents of the period for trends and new risks, which go to the risk register.

Responsibilities

The Information Security Officer owns this policy and the incident register, and keeps the contacts on this page correct.
Infrastructure maintains the monitoring and alerting that detect events.
Project leads keep the status page and the customer contacts of their product up to date.
Management decides on notifications to authorities and on communication with legal or contractual impact.
Employees report events immediately.

Review: yearly by the Information Security Officer.