Statement of Applicability (SoA)
The Statement of Applicability (SoA) is the central document of an information security management system. It lists the security controls of the ISO/IEC 27001:2022 standard (Annex A, 93 controls) and, for each one, states whether it applies to Bunker and where we stand.
We publish it for the same reason as the rest of our security policy, to make our posture verifiable without having to ask for it. A public buyer, a CISO or a DPO can read it before the first conversation.
Status regarding the ISO/IEC 27001 standard
Our ISMS is aligned with the ISO/IEC 27001 standard. Our controls are self-assessed and not certified by a third party to date. ISO 27001 certification is a stated objective. This statement reflects our self-assessment, and not the outcome of a certification audit.
How to read this statement
Each control carries a status, assigned from concrete evidence (infrastructure configuration, code, procedures, contracts), not from intent. We would rather declare a control partial than over-declare it.
| Status | Meaning |
|---|---|
| Implemented | The control is in place and operational in production. |
| Partial | The control is in place for the essentials, but one aspect (formalisation, coverage, scope) remains to be completed. |
| Planned | The control is identified and on our roadmap, not yet deployed. |
| Not applicable | The control does not concern our activity (justified where relevant). |
The scope of this statement is that of the ISMS, namely developing the platform and hosting it in our three datacenters located in France, with no dependency on a hyperscaler (see Scope).
A model designed for resilience
Bunker is designed to be highly resilient at the system level. Losing an entire datacenter is an event that is expected and non-critical by design (multi-datacenter replication and failover), rather than the classic single-site model that must keep running at all costs. Several physical controls of a given site are therefore assessed as compensated by this architecture. The availability objective is met through multi-datacenter design, not through the infallibility of any single site. The security model details this principle.
A.5 Organizational controls
| Control | Status | Our statement |
|---|---|---|
| A.5.1 Policies for information security | Implemented | Formalised ISMS policy, approved by management, with a preview published. |
| A.5.2 Information security roles and responsibilities | Implemented | CISO and DPO named (see Governance). |
| A.5.3 Segregation of duties | Implemented | Segregation of duties formalised between development, operations and change validation. |
| A.5.4 Management responsibilities | Partial | Engineering governance documented (MR review, architecture decisions); a formal ISMS management-responsibility directive to be finalised. |
| A.5.5 Contact with authorities | Planned | Contact with the French DPA via the DPO; ANSSI / CERT-FR point of contact to be formalised. |
| A.5.6 Contact with special interest groups | Partial | Active engagement with upstream open-source communities; security special-interest-group membership to be formalised. |
| A.5.7 Threat intelligence | Implemented | CVE and advisory monitoring across the whole stack, supported by a monitoring agent that tracks vulnerabilities continuously. |
| A.5.8 Information security in project management | Implemented | Security integrated into the CI pipeline: blocking secret scanning, plus IaC and dependency scanning. |
| A.5.9 Inventory of information and other associated assets | Implemented | Infrastructure inventory automatically discovered and version-controlled (GitOps / Infrastructure as Code). |
| A.5.10 Acceptable use of information and other associated assets | Partial | Public terms of use and tooling 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.5.12 Classification of information | Partial | Per-tenant segregation modelled; a confidentiality-level classification scheme and its automated enforcement in progress. |
| A.5.13 Labelling of information | Partial | Assets labelled by tenant and environment; sensitivity-based labelling to be generalised. |
| A.5.14 Information transfer | Partial | Strong technical transfer protections (TLS, encrypted mesh); contractual framing of transfers being completed. |
| A.5.15 Access control | Implemented | Centralised access control, least privilege by default, periodic access review. |
| A.5.16 Identity management | Implemented | Centralised single sign-on (Keycloak, migrating to the sovereign FerrisKey IAM). |
| A.5.17 Authentication information | Implemented | Confidential server-side encrypted sessions, no token exposed to the browser (BFF architecture). |
| A.5.18 Access rights | Implemented | Fine-grained relationship-based authorisation (organization → folder → project → instance), tested in CI. |
| A.5.19 Information security in supplier relationships | Implemented | Subprocessors governed by data processing agreements (DPAs) and standard contractual clauses. |
| A.5.20 Addressing information security in supplier agreements | Implemented | Security requirements written into subprocessor agreements. |
| A.5.21 Managing information security in the ICT supply chain | Partial | Open-source dependencies tracked and updated automatically; a formal software-supply-chain security process to be completed. |
| A.5.22 Monitoring and review of supplier services | Partial | Operational monitoring in place; formalised periodic review to be set to a cadence. |
| A.5.23 Information security for use of cloud services | Implemented | Cloud services operated on our own infrastructure, under our control, with no hyperscaler. |
| A.5.24 Information security incident management planning | Implemented | Formalised incident management procedure. |
| A.5.25 Assessment and decision on information security events | Implemented | Detection via monitoring and alerting, with event triage. |
| A.5.26 Response to information security incidents | Implemented | SRE on-call and response procedure in place. |
| A.5.27 Learning from information security incidents | Implemented | Systematic post-mortems after incidents. |
| A.5.28 Collection of evidence | Partial | Logging, immutable Git history and audit trails available; an evidence-preservation procedure to be formalised. |
| A.5.29 Information security during disruption | Implemented | Multi-datacenter resilience, backups and tested failover/restore (operational DR). |
| A.5.30 ICT readiness for business continuity | Implemented | Consistent with the horizontal-resilience principle, tested by regular restores. |
| A.5.31 Legal, statutory, regulatory and contractual requirements | Partial | GDPR compliance under French law: named DPO, DPA, list of subprocessors, retention periods and non-EU transfer disclosure published; record of processing (Article 30) provided on request. Personal-data breach notification procedure (Art. 33-34 GDPR) being formalised. |
| A.5.32 Intellectual property rights | Implemented | Our own code is licensed, and the licence of every open-source component used is inventoried. |
| A.5.33 Protection of records | Partial | Technical protection of records in place (backups, replication, encryption); an organization-wide retention policy to be formalised. |
| A.5.34 Privacy and protection of PII | Partial | Privacy by design (self-hosted analytics, no third-party tracker, hosting in France), privacy policy and DPO in place; data-subject-rights mechanisms (access, rectification, erasure, restriction, objection) being formalised. |
| A.5.35 Independent review of information security | Planned | External penetration test planned for the ISO 27001 certification path; internal review in place (CVE monitoring, mandatory MR review). |
| A.5.36 Compliance with policies, rules and standards | Partial | Compliance with engineering standards machine-enforced; a periodic ISMS-level compliance review to be set to a cadence. |
| A.5.37 Documented operating procedures | Implemented | Operating procedures documented as runbooks and codified commands. |
A.6 People controls
| Control | Status | Our statement |
|---|---|---|
| A.6.1 Screening | Implemented | Reference and qualification checks on hiring, and verification of French or European citizenship (personnel under EU control). |
| A.6.2 Terms and conditions of employment | Implemented | Security and confidentiality clauses in contracts; onboarding to the least-privilege principle. |
| A.6.3 Information security awareness, education and training | Partial | Continuous team awareness of security; a formalised training programme to be documented. |
| A.6.4 Disciplinary process | Implemented | Non-compliance may lead to disciplinary action (see Non-compliance). |
| A.6.5 Responsibilities after termination or change of employment | Partial | Access revocation and secret rotation on departure done in practice; the offboarding procedure being formalised and made traceable. |
| A.6.6 Confidentiality or non-disclosure agreements | Implemented | Confidentiality clause in all contracts, employees and contractors alike. |
| A.6.7 Remote working | Partial | Operational access via encrypted VPN (WireGuard); a remote-working policy to be formalised. |
| A.6.8 Information security event reporting | Implemented | Internal reporting channel, public security contact and responsible disclosure policy. |
A.7 Physical controls
Bunker owns and operates its three datacenters. Physical security is part of our scope, not delegated to a third-party host. The controls below are therefore applicable (unlike a provider that outsources hosting). Physical hardening rolls out site by site; gaps at a given site are compensated by the multi-datacenter architecture.
| Control | Status | Our statement |
|---|---|---|
| A.7.1 Physical security perimeters | Implemented | Server rooms in premises owned by Bunker, perimeter fully under our control. |
| A.7.2 Physical entry | Partial | Access control and restricted list in place; badge and electronic logging being deployed (main site by June 2027 at the latest). |
| A.7.3 Securing offices, rooms and facilities | Partial | Premises under exclusive control; formalisation of access procedures in progress. |
| A.7.4 Physical security monitoring | Partial | Video surveillance and intrusion detection active at the main site, being deployed at the other sites. |
| A.7.5 Protecting against physical and environmental threats | Partial | Fire detection and cooling in place; full coverage being specified. |
| A.7.6 Working in secure areas | Partial | Access restricted to authorised personnel; formal procedures to be documented. |
| A.7.7 Clear desk and clear screen | Planned | Good practice applied; a formal policy to be established. |
| A.7.8 Equipment siting and protection | Implemented | Equipment installed in our own rooms, under our physical control. |
| A.7.9 Security of assets off-premises | Partial | Production assets concentrated in our datacenters; framing of the rare off-site assets to be formalised. |
| A.7.10 Storage media | Implemented | Encryption at rest on the storage layer (removed media = unusable data) and secure erasure/destruction. |
| A.7.11 Supporting utilities (power, cooling) | Partial | UPS in place; in the event of a prolonged mains outage, the absence of a generator at some sites is compensated by multi-datacenter resilience (site loss tolerated). |
| A.7.12 Cabling security | Partial | Cabling under control in our premises; formalisation in progress. |
| A.7.13 Equipment maintenance | Partial | Maintenance performed by our team; a formal procedure to be documented. |
| A.7.14 Secure disposal or re-use of equipment | Implemented | Secure erasure (crypto-erase) and physical destruction at disposal. |
A.8 Technological controls
| Control | Status | Our statement |
|---|---|---|
| A.8.1 User endpoint devices | Planned | Endpoint management policy to be formalised. |
| A.8.2 Privileged access rights | Implemented | Read-only RBAC by default, administrative rights authoritative in the database (never from a token). |
| A.8.3 Information access restriction | Implemented | Fine-grained relationship-based authorisation and per-tenant network isolation (need-to-know). |
| A.8.4 Access to source code | Partial | Production deployment and releases restricted to the main branch; branch-protection settings to be documented. |
| A.8.5 Secure authentication | Implemented | OIDC / JWT confidential client (BFF), encrypted httpOnly session, anti-replay. Multi-factor authentication (MFA) is handled at the identity-provider level. |
| A.8.6 Capacity management | Implemented | Per-namespace quotas and limits, with saturation and headroom alerting. |
| A.8.7 Protection against malware | Partial | Surface reduction (internal registry, pinned image tags, hardened admission); a dedicated anti-malware image scan to be added to the CI pipeline. |
| A.8.8 Management of technical vulnerabilities | Partial | Automated dependency updates and secret scanning in CI; automated CVE detection (dependency scanning) to be wired into CI. |
| A.8.9 Configuration management | Implemented | All infrastructure and application configuration is declarative in Git (Helm + Terraform), validated in CI. |
| A.8.10 Information deletion | Partial | Automated deletion of ephemeral environments and artifacts; a customer-data deletion workflow to be formalised. |
| A.8.11 Data masking | Planned | Masking / anonymisation to be formalised. |
| A.8.12 Data leakage prevention (DLP) | Planned | A dedicated DLP capability to be evaluated and deployed. |
| A.8.13 Information backup | Implemented | Daily backups (database and persistent volumes), with retention, freshness monitoring, automatic retry, regular restore testing and an off-site copy of the whole set. |
| A.8.14 Redundancy of information processing facilities | Implemented | Multi-datacenter topology, database and application replicas with cross-zone anti-affinity and disruption budgets. |
| A.8.15 Logging | Implemented | Centralised log pipeline (agents → object storage) and structured access logs. |
| A.8.16 Monitoring activities | Implemented | Full observability stack (metrics, logs, traces) and alerting routed to on-call. |
| A.8.17 Clock synchronization | Planned | Synchronisation handled by system default; formalisation and monitoring to be put in place. |
| A.8.18 Use of privileged utility programs | Partial | Strong technical restriction (rootless builders, reduced-surface images, Pod Security Admission at baseline level); a usage policy to be formalised. |
| A.8.19 Installation of software on operational systems | Partial | Provenance controlled (internal registry, pinned tags, security admission); digest pinning and blocking admission to be strengthened. |
| A.8.20 Networks security | Implemented | Default-deny NetworkPolicies per namespace, then explicit allow rules. |
| A.8.21 Security of network services | Implemented | Network services exposed through controlled ingress and an encrypted node mesh. |
| A.8.22 Segregation of networks | Implemented | Per-tenant network isolation: a tenant's workloads cannot reach the host network, the cluster network or metadata. |
| A.8.23 Web filtering / WAF | Partial | A WAF (CrowdSec, virtual patching) fronts the critical edge; coverage to be generalised to the other entry points. |
| A.8.24 Use of cryptography | Implemented | TLS in transit everywhere (forced HTTPS), secrets encrypted at rest (authenticated XChaCha20-Poly1305 envelope encryption and Sealed Secrets), encrypted WireGuard mesh. |
| A.8.25 Secure development life cycle | Implemented | Lifecycle governed by documented architecture decisions, a multi-stage CI pipeline and automated code review. |
| A.8.26 Application security requirements | Implemented | Security requirements explicitly specified (fail-closed, anti-CSRF, anti-replay) and enforced in the authentication code. |
| A.8.27 Secure system architecture and engineering principles | Implemented | Defence-in-depth architecture: confidential client, fine-grained authorisation, encryption at rest, per-tenant isolation, pod hardening. |
| A.8.28 Secure coding | Implemented | Blocking lint, memory-safe language (Rust), coding guardrails (anti-mock tripwires, zeroization, secret redaction in logs). |
| A.8.29 Security testing in development and acceptance | Implemented | Unit, authorization, integration and manifest-security tests run in CI as acceptance gates. |
| A.8.30 Outsourced development | Partial | Development mostly in-house; acceptance criteria for any external contribution to be formalised. |
| A.8.31 Separation of development, test and production environments | Implemented | Distinct clusters and namespaces between qualification and production, with separate credentials and production promotion restricted to the main branch. |
| A.8.32 Change management | Implemented | Changes flow through MRs with CI validation gates and a qualification stage before production; version bumps subject to human review. |
| A.8.33 Test information | Implemented | Test datasets are synthetic (fictional), with no production personal data in test environments. |
| A.8.34 Protection of information systems during audit testing | Planned | Framing of audit testing to be formalised. |
Available on request
This statement gives the overview. The per-control detail (evidence, internal procedures, the record of processing activities under Article 30 of the GDPR, insurance certificates and tender documents) is provided on request to the DPO, as our internal review progresses. Write to [email protected].
Path to certification
Our priority is ISO 27001 certification. The certification path will include an external penetration test (A.5.35) and a third-party audit that will turn our self-assessment into an independent attestation. The French ANSSI SecNumCloud qualification is a longer-term objective, subject to how our resources and our market evolve.
We claim no certification we do not hold. Any change to this status will be published here and on our security page.
Last reviewed: 29 August 2026.
See also
- Information Security Policy (ISMS scope, governance and measures)
- Security model (architecture, defence in depth and the resilience principle)
- Responsible disclosure policy (how to report a vulnerability to us)
- Infrastructure (the datacenters, storage and network behind our services)