Incident Management Policy
This policy describes how Bunker detects, triages, handles and closes an information security incident. On the incident dimension, it implements the principles of our information security policy and covers controls A.5.24 to A.5.28 and A.6.8 of the Statement of Applicability.
Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.
Purpose and scope
This policy applies to any security event affecting the ISMS scope, namely the platform (console, API, nuage CLI), managed services, the hosting infrastructure in our three datacenters and internal tooling. It covers incidents detected by our own monitoring as well as incidents reported from outside, and applies to employees and contractors alike.
Principles
- One incident, one owner: from the moment it opens, a single person drives handling and communication; everyone else assists.
- Triage before acting: an event is classified (incident, false positive, signal to watch) before any remediation, so that the traces explaining the cause are not destroyed.
- Contain first: limiting impact takes precedence over root-cause analysis, which comes after recovery.
- Blameless post-mortem: we fix a system rather than a person.
- No silent fix: an incident affecting customers leads to factual communication, including when it reflects poorly on us.
Measures
| Area | Measure |
|---|---|
| Planning | Formalised incident management procedure, known to the operations team (A.5.24). |
| Detection | Continuous monitoring (metrics, logs, traces) and alerting rules routed to the on-call rotation (A.5.25). |
| Triage | Every event is assessed and classified before escalation; the decision to handle or close is recorded (A.5.25). |
| Response | Reachable on-call rotation and a four-step response procedure: containment, eradication, recovery, closure (A.5.26). |
| Reporting | Internal reporting channel, public contact [email protected] and a published responsible disclosure policy, with acknowledgement within 48 hours (A.6.8). |
| Learning | Systematic post-mortem after an incident, with corrective actions tracked to closure (A.5.27). |
| Evidence | Centralised logs, immutable Git history and usable audit trails; a formal evidence-preservation procedure still to be formalised (A.5.28, partial). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy, decides incident severity and approves the related communication.
- The on-call rotation is the first responder: it contains, escalates when needed and records the sequence of actions as they are taken.
- The DPO (Robin Straub) is involved without delay as soon as an incident touches personal data, to assess notification obligations (GDPR articles 33 and 34).
- Anyone (employee, contractor or external researcher) reports a suspicious event to [email protected], without having to assess its severity first.
Status and roadmap
Planning, detection, triage, response, learning and reporting are in place and operational (A.5.24–A.5.27, A.6.8). Two items remain open, the evidence-preservation procedure (A.5.28, partial) and the personal data breach notification procedure under GDPR articles 33 and 34, currently being formalised (A.5.31, partial). We do not claim a continuously staffed security operations centre. Detection is automated, and human response relies on an on-call rotation.
Review
This policy is reviewed at least once a year, after any major incident and whenever our detection and response arrangements change significantly.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.5.24–28 and A.6.8)
- Responsible disclosure policy (how to report a vulnerability to us and how fast we answer)
- Logging and Monitoring Policy (the detection and the trails response relies on)
- Business Continuity Policy (recovery when an incident affects availability)
- Information Security Policy (the ISMS framework this policy derives from)