Information Classification Policy
This policy describes how Bunker inventories its information assets, protects them according to their sensitivity, governs their transfer and organises their deletion. On that dimension, it implements the principles of our information security policy and covers controls A.5.9 to A.5.14 and A.8.10 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 all information within the ISMS scope (data entrusted by customers, credentials and secrets, operational logs, source code, documentation and internal company information). It also covers the assets that carry that information (instances, volumes, databases, backups, repositories and the team's workstations).
Of all our policies, this is the one whose maturity is most uneven. The technical protections are in place, while the classification scheme is still being formalised. This page states where we stand, without rounding up.
Principles
- The inventory is authoritative: what is not declared in our infrastructure repositories has no place in production. The inventory is discovered automatically, not maintained by hand.
- Most protective level by default: until the sensitivity-based classification scheme is published, all customer data is treated as confidential.
- The tenant is the first boundary: per-customer segregation is our operational unit of classification, enforced technically rather than declared on a document.
- Minimisation: we do not collect information we have no use for, and our test environments use no personal production data; their datasets are synthetic.
- Transfer protects the information and not just the pipe: a transfer is encrypted in transit and directed to a third party whose role is contractually framed.
- Deleted data must be deleted everywhere: deletion covers replicas and backups, within the retention periods we publish.
Measures
| Area | Measure |
|---|---|
| Inventory | Infrastructure inventory automatically discovered and version-controlled (GitOps / Infrastructure as Code), reviewed at every change through merge requests (A.5.9). |
| Acceptable use | Public terms of use and guardrails enforced by tooling; internal acceptable-use policy to be documented (A.5.10, partial). |
| Return of assets | Return of equipment and access when a person leaves, tied to the offboarding procedure being formalised (A.5.11, planned). |
| Classification | Per-tenant segregation modelled and enforced technically; a confidentiality-level classification scheme and its automated enforcement in progress (A.5.12, partial). |
| Labelling | Assets labelled by tenant and by environment (qualification, production); sensitivity-based labelling to be generalised (A.5.13, partial). |
| Transfer | Strong technical protections (TLS in transit, encrypted mesh, hosting exclusively in France); contractual framing of transfers being completed (A.5.14, partial). |
| Deletion | Automated deletion of ephemeral environments and artifacts; customer-data deletion workflow to be formalised (A.8.10, partial). |
| Test data | Synthetic test datasets, no personal production data outside production (A.8.33). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy and the publication of the classification scheme.
- The DPO (Robin Straub) rules on the qualification of personal data, retention periods and data-subject requests.
- Each team lead ensures that assets within their scope are declared in the inventory and correctly labelled.
- Anyone handling sensitive information applies the most protective level when in doubt, and reports any disclosure or loss to [email protected].
Status and roadmap
The asset inventory is in place (A.5.9). It follows directly from our GitOps model, where infrastructure is described in Git and validated in continuous integration.
The other controls in this area are partial or planned, and we declare them as such. The sensitivity-based classification scheme and its automated enforcement are in progress (A.5.12); sensitivity labelling is still to be generalised beyond tenant and environment (A.5.13); contractual framing of transfers is being completed (A.5.14); the internal acceptable-use policy remains to be documented (A.5.10); return of assets depends on the offboarding procedure being formalised (A.5.11); the customer-data deletion workflow has yet to be formalised (A.8.10). Two adjacent measures are planned, namely data masking and anonymisation (A.8.11) and a data leakage prevention capability (A.8.12).
What these gaps do not call into question is that data remains segregated per tenant, encrypted in transit and protected at rest on the storage layer. What is missing is formalisation and generalisation, not the absence of protection.
Review
This policy is reviewed at least once a year, when the classification scheme is published, and whenever our processing activities or retention periods change significantly.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.5.9 to A.5.14 and A.8.10)
- Access Control Policy (who accesses which information, and on what need-to-know basis)
- Cryptography Policy (protection of data in transit and at rest)
- Backup guide (retention, restore and the lifecycle of customer data)
- Information Security Policy (the ISMS framework this policy derives from)