Patch management charter
This charter sets out how Bunker applies patches to the services it manages. It states who patches which layer, through which track, within which target time and with which checks. It extends our vulnerability management policy, which deals with detection, and our change management policy, which describes the flow to production. It relates to controls A.5.7, A.8.8, A.8.19 and A.8.32 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.
This charter describes how we operate and the targets we set ourselves. The contractual commitments are in the General Terms and Conditions of Service (article 9), the Service Level Agreement and the Shared Responsibility Annex. An order form or a service contract may set its own deadlines and windows. Where it differs from this charter, the contract prevails.
Purpose and scope​
The charter applies to the software of managed services and their databases, to the platform that runs them (Kubernetes and the node operating system) and to the dependencies of our own code. It covers corrective releases, security patches and the mitigations applied while a patch is pending. It holds for services hosted in our datacenters and for those we manage on the customer's premises, within the layers we operate.
Principles​
- Every layer has a named owner. The split between Bunker and the customer is written down before the service goes live, layer by layer.
- Two tracks, one flow. The routine track and the security track differ in their target time and go through the same checks.
- The wait for a patch is covered. As long as the vendor has published nothing, a documented mitigation reduces the exposure.
- An update should cost the service nothing. A prior backup, a pinned version and a rolling deployment frame every operation.
- A fix is verified. A vulnerability is closed once the corrected version is deployed and confirmed in production.
Shared responsibilities​
The table below shows who applies patches, layer by layer, depending on where the service runs.
| Layer | Service hosted by Bunker | On the customer's premises, cluster operated by Bunker | On the customer's premises, on its own Kubernetes or virtual machines |
|---|---|---|---|
| Managed service software and its database | Bunker | Bunker | Bunker |
| Kubernetes and the cluster base | Bunker | Bunker, with its Kubernetes infrastructure partner | Customer, Bunker consulted |
| Machines, host operating system, network and storage | Bunker | Customer | Customer |
| Source applications, integrations and the customer's workstations | Customer | Customer | Customer |
For a service hosted in our datacenters, the Shared Responsibility Annex is authoritative. Under it, Bunker keeps the software version and its patches, and the customer reports its compatibility constraints.
For a service managed on the customer's premises, the order form specifies the split. The customer keeps the layers it provides and gives us the operating windows an update needs.
Routine track​
The corrective releases published by a software vendor are deployed after their stability has been checked. Version upgrades are proposed to us automatically as merge requests, which we integrate only if the continuous integration pipeline is green.
Operations that interrupt a service are grouped into planned maintenance. We announce it at least 5 business days in advance and preferably schedule it outside business hours. There is no recurring window, and maintenance is planned when a batch of updates warrants it.
Security track​
A security patch follows the same flow as the others, with a target time and steps of its own.
| Step | Rule |
|---|---|
| Detection | Monitoring of CVEs and security advisories across the whole stack, supported by a monitoring agent, by the reports received on the security channel and by automated dependency updates (A.5.7). |
| Triage | Check of the version actually deployed on each cluster, of the fixed version stated in the vendor's advisory and of the exploitation conditions in our configuration. The CVSS score is one input to that analysis. |
| Rating | A vulnerability is critical when it can be exploited remotely without authentication or is reported as actively exploited (General Terms and Conditions of Service, article 9.2). |
| Remediation | Every available security patch is applied within 72 hours of its publication by the vendor. This time is a target (A.8.8). |
| No patch available | Documented mitigation (restricted exposure, filtering, virtual patching on the public edge, temporary suspension), kept in place until the patch is published. |
| Verification | Closure once the corrected version is deployed and confirmed on the production service. |
The 72-hour time is an operating target, with no guarantee of result. It becomes a commitment when a service contract states it, and the patch is then deployed in the window agreed with the customer.
For a critical vulnerability, the patch or the mitigation may take place without notice and outside the maintenance window, as provided by article 9.3 of the General Terms and Conditions of Service. The on-call may be triggered outside business hours on that ground.
A corrective release that fails the stability check stays out of production. A mitigation then takes over and the CISO arbitrates the postponement.
This 72-hour time concerns the application of a patch. The notification of a personal data breach follows its own rules, set by article 11 of the Data Processing Agreement.
Safeguards of an update​
| Safeguard | Rule |
|---|---|
| Prior backup | A version upgrade that migrates a database schema is preceded by a backup of that database. |
| Pinned version | The target version is designated by a fixed tag rather than a floating one (A.8.19). |
| Change flow | The update goes through a merge request, the continuous integration validation gates and a qualification stage before production (A.8.32). |
| Rehearsal | A major version upgrade whose database migration is irreversible is first run on a copy of the database, for the services that have the tooling. |
| Rolling deployment | Redundant components (replicated database, cluster nodes) are updated one after the other to keep the service up. A single-instance service restarts briefly. |
| Post-deployment check | The version served is verified on the public address of the service, in addition to the deployment status. |
| Emergency | A measure taken directly on production is reported to the security contact and regularised through a follow-up merge request. |
Notice and service levels​
Planned maintenance is announced at least 5 business days in advance. When a protective measure affects its service, the customer is informed as soon as possible (General Terms and Conditions of Service, article 10.2).
Planned maintenance announced within that notice and the patching and mitigation operations of article 9 of the General Terms and Conditions of Service are excluded from the availability calculation (Service Level Agreement, article 4).
Responsibilities​
- The CISO (François-Guillaume Ribreau) owns this charter. He rates critical vulnerabilities and arbitrates urgent patches and postponements alike.
- The SRE on-call handles an exploited or actively exploitable vulnerability as an incident, under our incident management policy.
- The author of an update applies the safeguards of this charter and documents the operation in the merge request.
- The customer reports its compatibility constraints. For a service managed on its premises, it patches the layers it provides.
Status and roadmap​
The change flow every update goes through is implemented (A.8.32). Threat intelligence and the management of technical vulnerabilities remain partial (A.5.7, A.8.8), and the charter inherits their limits:
- 72-hour time. This charter sets it as a target. No indicator measures compliance with it yet.
- Detection. Automated CVE detection is still to be wired into the continuous integration pipeline, and we have no automated feed for actively exploited vulnerabilities.
- Safeguards. They rest on our operating procedures, with no automated check verifying that they are followed. Rehearsal on a copy has tooling for part of the managed services and is still to be generalised.
- Reporting. We do not publish a report of the patches applied per service. A service contract may provide for one.
Review​
This charter is reviewed at least once a year, and whenever the General Terms and Conditions of Service or our delivery pipeline change.
Last reviewed: 11 October 2026.
See also​
- Vulnerability Management Policy (the monitoring and triage upstream of this charter)
- Change Management Policy (the flow through which a fix reaches production)
- Backup Policy (the backups an update relies on)
- Incident Management Policy (how an exploited vulnerability is handled)
- Statement of Applicability (the status of controls A.5.7, A.8.8, A.8.19 and A.8.32)
- Responsible disclosure policy (how to report a vulnerability to us)