Skip to main content

Business Continuity Policy

This policy describes how Bunker keeps its services available during a disruption and how it restores them after a disaster. On the continuity dimension, it implements the principles of our information security policy and covers controls A.5.29, A.5.30 and A.8.14 of the Statement of Applicability.

Status regarding the ISO/IEC 27001 standard

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 covers the availability of the platform (console, API, nuage CLI), the managed services we operate, and the infrastructure carrying them across our three French datacenters (Essarts-en-Bocage, Saint-Gilles-Croix-de-Vie and Nantes). It addresses technical, power and environmental disruptions, as well as the loss of an entire site.

Principles​

  • Horizontal resilience: losing a datacenter is an event that is expected and non-critical by design rather than a doomsday scenario. This stance is detailed in our security model.
  • Failover is tested: a recovery plan that has never been executed is not a plan. We test the restore and not just the backup.
  • Compensation stated openly: a hardening gap at a given site is treated as a control compensated by the architecture, and declared as such (never hidden).
  • No hyperscaler dependency: recovery relies on no provider outside our control.
  • Degrade rather than fall over: when capacity is short, partial service beats full unavailability.

Measures​

AreaMeasure
RedundancyMulti-datacenter topology across our three sites, database and application replicas with cross-zone anti-affinity (replicas do not share a site) and disruption budgets (A.8.14).
Continuity during disruptionMulti-datacenter failover backed by tested backups and restores, forming our operational recovery arrangement (A.5.29).
ICT readinessArrangements proven by regular restores into a verification environment and not merely described in a document (A.5.30).
Off-site backupsBackups copied to object storage that is geographically separate from the production site (A.8.13, detailed in the backup policy).
Supporting utilitiesUPS units in place; at sites without a generator, an extended mains outage is treated as a tolerated site loss, absorbed by the architecture (A.7.11, partial).
CapacityPer-namespace quotas and limits, with saturation and headroom alerting, so that recovering one site does not saturate the others (A.8.6).
OperationsOperating procedures documented as runbooks and codified commands, usable under stress (A.5.37).

Responsibilities​

  • The CISO (François-Guillaume Ribreau) owns this policy and decides on any deliberate site failover.
  • The on-call rotation executes failover and restore following the runbooks, and reports the gap between the planned and the actual sequence.
  • Each service owner keeps the recovery runbook for their scope up to date; an untested runbook is treated as a non-conformity.
  • Any anomaly observed during a failover test is reported to [email protected] and tracked as a corrective action.

Status and roadmap​

Redundancy, continuity during disruption and ICT readiness are in place and operational (A.5.29, A.5.30, A.8.14). Two limits are acknowledged. First, per-service recovery and data-loss objectives (RTO and RPO) are not yet formalised or published. The daily backup cadence and the monitored freshness threshold are today's practical bound. Second, several physical controls remain partial on a site-by-site basis (physical entry, surveillance, supporting utilities). They are compensated by the multi-datacenter architecture, and hardening continues site by site.

Review​

This policy is reviewed at least once a year, after every failover test and whenever our hosting topology changes significantly.

Last reviewed: 31 August 2026.

See also​