Asset Management Policy
This policy describes how Bunker records its assets, governs their use and controls their configuration. On that dimension, it implements the principles of our information security policy and covers controls A.5.9, A.5.10, A.5.11 and A.8.9 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 covers the assets that carry the ISMS: hardware installed in our three datacenters, hypervisors and compute nodes, clusters and namespaces, managed services, code repositories and deployment charts, accounts and secrets, endpoints and internal tooling. It applies to employees, contractors and the automated systems that create or destroy resources.
Principles
- The inventory is derived, not retyped. A hand-maintained inventory drifts; ours is discovered from the live infrastructure and version-controlled.
- Configuration is declarative. The target state of an asset is described in Git; what is not there is not meant to exist in production.
- An asset has an owner. Every asset belongs to an identified person or team, accountable for its use and its life cycle.
- An asset is returned. Hardware, access and secrets are returned or revoked when a person leaves or an engagement ends.
- An asset is disposed of properly. Media are encrypted at rest, then wiped or destroyed before leaving our premises.
Measures
| Area | Measure |
|---|---|
| Inventory | Infrastructure inventory automatically discovered from the hypervisors and version-controlled (GitOps / infrastructure as code): nodes, resources and capacities are recorded from the live estate (A.5.9). |
| Configuration | All infrastructure and application configuration is declarative in Git (Helm + Terraform) and validated in continuous integration (A.8.9). |
| Labelling | Assets labelled per tenant and per environment, including ephemeral namespaces labelled per pipeline; sensitivity-based labelling to be generalised (A.5.13, partial). |
| Acceptable use | Public terms of use and tooling guardrails (per-namespace quotas and limits, security admission, least privilege); internal acceptable-use policy to be documented (A.5.10, partial). |
| Return | Access revocation and secret rotation on departure are performed in practice; the asset return procedure is tied to offboarding and is being formalised (A.5.11, planned; A.6.5, partial). |
| Disposal | Encryption at rest on the storage layer (a removed drive is unusable), then secure erasure (crypto-erase) and physical destruction at end of life (A.7.10, A.7.14). |
| Endpoints | User endpoint management policy still to be formalised (A.8.1, planned). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy and the maintenance of the asset inventory.
- Each team lead identifies the assets within their scope and validates their use.
- Everyone holding a company asset takes care of it, returns it on departure and reports its loss or theft without delay to [email protected].
Status and roadmap
The asset inventory and configuration management are in place and operational (A.5.9, A.8.9). The inventory is derived from the live infrastructure and the target state of every component lives in Git. Three items remain open, and we declare them as such:
- A.5.10, acceptable use of assets: public terms of use and technical guardrails in place; internal acceptable-use policy to be documented.
- A.5.11, return of assets: planned, tied to the offboarding procedure being formalised (A.6.5, partial).
- A.8.1, user endpoints: planned, endpoint management policy to be formalised.
Information classification by confidentiality level and its automated enforcement also remain in progress (A.5.12, A.5.13, partial). Per-tenant segregation is modelled, sensitivity-based labelling is still to be generalised.
Review
This policy is reviewed at least once a year and whenever our asset estate or our configuration management chain changes significantly.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.5.9, A.5.10, A.5.11 and A.8.9)
- Infrastructure (the datacenters, storage and network this inventory records)
- Change Management Policy (the flow through which declarative configuration reaches production)
- Security model (the resilience and defence layers these assets carry)
- Information Security Policy (the ISMS framework this policy derives from)