Skip to main content

Change Management Policy

This policy describes how a change (to code, configuration or infrastructure) reaches production at Bunker. On that dimension, it implements the principles of our information security policy and covers controls A.5.3, A.8.4 and A.8.32 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 applies to any change that can affect the platform or the data it hosts (application code, database migrations, Helm charts, infrastructure described as code, the continuous integration pipeline definition and dependency version bumps). It covers employees and contractors alike.

Principles​

  • One path to production. No change reaches production other than through the main branch, after passing the continuous integration pipeline.
  • No hand edits on a live system. The target state is declared in Git; what is not in Git is not meant to exist.
  • Segregation of duties. Writing a change, validating it and deploying it are not the same role.
  • Traceability by construction. The Git history, the merge request and the pipeline logs form the audit trail of every change.
  • Verification before production. A change runs first in a disposable qualification environment before it touches the live service.

Measures​

AreaMeasure
Validation flowEvery change goes through a merge request subject to continuous integration validation gates, then through a qualification stage before production (A.8.32).
Verification environmentsEach pipeline deploys an ephemeral qualification environment, isolated in its own namespace, torn down when the merge request closes or when its time to live expires.
Promotion to productionProduction deployment and release publication restricted to the main branch (A.8.4, partial).
ConfigurationInfrastructure and application configuration is declarative in Git (Helm + Terraform) and validated in continuous integration: an infrastructure change follows the same flow as a code change (A.8.9).
Segregation of dutiesFormalised separation between development, operations and change validation (A.5.3).
DependenciesDependency version bumps are proposed automatically and subject to the same acceptance gates as any other change: an update is only integrated if the pipeline is green.
TraceabilityImmutable Git history, pipeline logs and environments labelled per pipeline and per merge request (A.5.28, partial).

Responsibilities​

  • The CISO (François-Guillaume Ribreau) owns this policy and arbitrates changes with a strong security impact.
  • The author of a change documents its intent and expected effect in the merge request.
  • Validating a change falls to someone other than its author, in line with segregation of duties.
  • Any bypass of the flow, including in an emergency, is reported to [email protected] and regularised through a follow-up merge request.

Status and roadmap​

The change management flow and segregation of duties are in place and operational (A.8.32, A.5.3), as is the declarative configuration management that supports them (A.8.9). Access to source code remains partial (A.8.4). Restricting deployment and releases to the main branch is effective, but the branch-protection settings are still to be formally documented.

Two adjacent items remain in formalisation, the evidence preservation procedure beyond the logging and Git history already available (A.5.28, partial) and the periodic compliance review at ISMS level (A.5.36, partial).

Review​

This policy is reviewed at least once a year and whenever our delivery chain or our environments change significantly.

Last reviewed: 31 August 2026.

See also​