BIO -- Baseline Informatiebeveiliging Overheid¶
Framework Overview¶
Full name: Baseline Informatiebeveiliging Overheid (BIO) -- Government Information Security Baseline Issued by: Dutch government (CIP framework, published in the Government Gazette / Staatscourant) Current version: BIO2 v1.3 (published March 2026, effective immediately) Based on: NEN-EN-ISO/IEC 27001:2022 and NEN-EN-ISO/IEC 27002:2022 Type: Mandatory self-regulation for Dutch government agencies
BIO is the mandatory information security framework for all layers of Dutch government: central government (Rijksoverheid), provinces, municipalities, and water authorities. It defines minimum security requirements based on ISO 27001/27002 with additional government-specific controls. BIO2 (the current version) aligns with ISO 27002:2022.
Who Must Comply¶
- Dutch central government agencies (ministries, executive agencies)
- All 12 Dutch provinces
- All 342 Dutch municipalities
- All 21 water authorities (waterschappen)
- Suppliers and service providers to Dutch government (via contractual requirements)
Related Framework: BIO Thema-uitwerking Clouddiensten¶
The BIO Thema-uitwerking Clouddiensten (Cloud Services Theme Elaboration) is a separate, voluntary guidance document that helps government organizations formulate controls when using cloud services. It supplements BIO with cloud-specific requirements. CloudTaser addresses controls from both BIO and the cloud theme elaboration.
BIO Control Areas and CloudTaser Mapping¶
BIO2 follows the ISO 27002:2022 structure with government-specific additions. The control numbering below follows the ISO 27002:2022 structure as used in BIO2.
5 -- Organizational Controls¶
| BIO Control | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| 5.1 -- Information security policies | Policies for information security must be defined and approved | CloudTaser's annotation-based configuration provides declarative, version-controlled security policy for secret management. GitOps workflows provide approval trails | Operator |
| 5.2 -- Information security roles | Roles and responsibilities must be defined | The operator controls injection policy, vault controls access policy, eBPF enforces runtime policy. Separation of duties is architecturally enforced | Operator, Wrapper, eBPF |
| 5.10 -- Acceptable use of information | Rules for acceptable use of information and assets must be defined | CloudTaser enforces acceptable use of secrets: they can only be accessed by authorized processes, cannot be written to storage, and cannot be transmitted to unauthorized destinations | eBPF |
| 5.15 -- Access control | Rules for access control must be established | Vault Kubernetes auth binds secret access to pod identity. eBPF enforces process-level access control. Only authorized pods receive secret injection | Operator, Wrapper, eBPF |
| 5.23 -- Information security for cloud services | Information security requirements for cloud services must be defined | CloudTaser directly addresses the core cloud security concern: preventing the cloud provider from accessing government secrets | All |
| 5.31 -- Legal requirements | Legal, statutory, and regulatory requirements must be identified and addressed | CloudTaser provides technical supplementary measures for GDPR Art. 32, Schrems II, NIS2, and the EU Data Act | All |
8 -- Technological Controls¶
| BIO Control | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| 8.1 -- User endpoint devices | Information stored on, processed by, or accessible via endpoint devices must be protected | Not directly addressed (CloudTaser protects server-side secrets in Kubernetes pods) | -- |
| 8.2 -- Privileged access rights | The allocation and use of privileged access rights must be restricted and managed | eBPF blocks all privileged memory access to protected processes: ptrace, /proc/pid/mem, process_vm_readv, kernel module loading. Even root cannot read memfd_secret pages |
eBPF |
| 8.3 -- Information access restriction | Access to information must be restricted according to the access control policy | Vault enforces policy-based access: only pods with correct ServiceAccount + namespace binding access secrets. The operator controls which pods receive injection via annotations | Operator, Wrapper |
| 8.5 -- Secure authentication | Secure authentication technologies and procedures must be established | Vault Kubernetes auth uses short-lived, audience-bound ServiceAccount tokens. Tokens are stripped from the child process environment after authentication | Wrapper |
| 8.7 -- Protection against malware | Protection against malware must be implemented | eBPF blocks code injection via ptrace and process memory write. It prevents secret exfiltration through unauthorized file writes and network sends |
eBPF |
| 8.9 -- Configuration management | Configurations must be established, documented, implemented, monitored, and reviewed | cloudtaser validate verifies correct configuration. cloudtaser audit detects drift. Protection scores provide continuous monitoring |
CLI |
| 8.10 -- Information deletion | Information stored in systems, devices, or media must be deleted when no longer required | Secrets are never written to persistent storage. They exist only in volatile process memory and are automatically destroyed when the process exits. No residual data on disk, in etcd, or in swap | Wrapper |
| 8.11 -- Data masking | Data masking must be used according to the access control policy | CloudTaser protects data masking keys in process memory. If masking keys are stored in the EU vault and injected via CloudTaser, they are inaccessible to the cloud provider | Wrapper |
| 8.12 -- Data leakage prevention | Data leakage prevention measures must be applied | eBPF agent blocks secret exfiltration via write, sendto, sendmsg, sendfile, splice, and io_uring operations from protected processes |
eBPF |
| 8.15 -- Logging | Logs must be produced, stored, protected, and analyzed | eBPF generates security events for all blocked operations. Vault audit log records all secret fetch operations. Events integrate with SIEM via standard log collection | eBPF |
| 8.16 -- Monitoring activities | Networks, systems, and applications must be monitored for anomalous behavior | eBPF agent monitors 20+ attack vectors in real time. Protection scores provide continuous security posture monitoring. cloudtaser audit runs scheduled compliance checks |
eBPF, CLI |
| 8.20 -- Networks security | Networks and network devices must be secured | cloudtaser netpol generates Kubernetes NetworkPolicies restricting pod communication to the vault endpoint. This limits network attack surface |
CLI |
| 8.24 -- Use of cryptography | Rules for effective use of cryptography must be defined and implemented | All vault communication uses TLS 1.2+. Secrets are protected in memory using memfd_secret and mlock. S3 proxy uses AES-256-GCM for data at rest |
Wrapper, S3 Proxy |
| 8.25 -- Secure development lifecycle | Rules for secure development must be established | cloudtaser discover scans for insecure secret references before production deployment. cloudtaser validate verifies configuration in CI/CD pipelines |
CLI |
| 8.28 -- Secure coding | Secure coding principles must be applied | CloudTaser eliminates the most common secret handling vulnerability: storing secrets in Kubernetes Secrets (accessible via etcd). Developers use vault paths instead of hardcoded secrets | Operator, Wrapper |
BIO Cloud Theme Elaboration (Thema-uitwerking Clouddiensten)¶
The cloud theme elaboration adds cloud-specific controls:
| Cloud Control | Description | CloudTaser Mapping | Component |
|---|---|---|---|
| CLD-01 -- Cloud security architecture | Security architecture for cloud deployments must be documented | CloudTaser's architecture (webhook injection, memfd secret delivery, eBPF enforcement) is documented and verifiable via cloudtaser validate |
All |
| CLD-02 -- Cloud data protection | Data processed in the cloud must be protected against unauthorized access by the provider | This is CloudTaser's primary purpose. memfd_secret + eBPF enforcement ensures the provider cannot access secrets |
Wrapper, eBPF |
| CLD-03 -- Cloud key management | Cryptographic keys for cloud data must be managed by the government organization, not the provider | EU-hosted vault under government control. Keys never reach the cloud provider. cloudtaser rotate supports key lifecycle management |
Wrapper, S3 Proxy |
| CLD-04 -- Cloud exit strategy | A viable exit strategy from the cloud provider must exist | CloudTaser is cloud-agnostic. Secrets are in a portable vault, not locked to any provider's proprietary service | Wrapper, Operator |
Component Coverage Matrix¶
| CloudTaser Component | BIO Controls Addressed |
|---|---|
| Operator (webhook injection) | 5.1, 5.2, 5.15, 8.3, 8.28, CLD-04 |
| Wrapper (secret delivery) | 5.15, 8.3, 8.5, 8.10, 8.11, 8.24, CLD-02, CLD-03, CLD-04 |
| eBPF (runtime enforcement) | 5.2, 5.10, 5.15, 8.2, 8.7, 8.12, 8.15, 8.16, CLD-02 |
| S3 Proxy (client-side encryption) | 8.24, CLD-03 |
| DB Proxy (transparent encryption) | 8.24, CLD-03 |
| CLI (audit, validate, discover) | 5.1, 8.9, 8.16, 8.20, 8.25 |
BIO Classification Levels¶
BIO uses three classification levels for government information. CloudTaser's relevance increases with classification level:
| Level | Description | CloudTaser Relevance |
|---|---|---|
| BBN1 (Basis) | Low impact if compromised. Standard government information | CloudTaser provides defense-in-depth. Recommended for workloads on US cloud providers |
| BBN2 (Midden) | Medium impact. Confidential government information | CloudTaser strongly recommended. Protection scores must meet minimum thresholds. eBPF enforcement should be active |
| BBN3 (Hoog) | High impact. Highly confidential / state secret | CloudTaser is essential. Maximum protection score required. Full eBPF enforcement with reactive kill. Consider confidential computing (SEV-SNP) as additional layer |
Gaps and Limitations¶
| BIO Area | Gap | Mitigation |
|---|---|---|
| Physical security (8.12 physical) | CloudTaser does not control physical security of data centers | Use a cloud provider with DigiD-assessed or BIO-compliant data centers for the infrastructure layer. memfd_secret provides defense-in-depth against physical memory access |
| Human resources (6.x) | CloudTaser does not manage HR security processes | Organizational measure, outside product scope |
| Asset management (5.9) | CloudTaser does not perform general IT asset management | Use Kubernetes-native asset inventory. cloudtaser discover covers secret-related assets |
| Incident management (5.24-5.28) | CloudTaser detects incidents but does not replace an incident management process | eBPF events feed into SIEM and incident management tooling. The incident response process is the organization's responsibility |
| Business continuity (5.29-5.30) | CloudTaser does not manage business continuity planning | Vault HA and cloud-agnostic portability support BCP. Planning is the organization's responsibility |
| Endpoint security (8.1) | CloudTaser protects server-side secrets, not endpoint devices | Outside scope. CloudTaser operates in Kubernetes clusters, not on end-user devices |
| BBN3 / state secrets | For BBN3 data, additional measures beyond CloudTaser may be required (e.g., AIVD-certified HSMs, government-operated infrastructure) | CloudTaser provides a strong technical baseline. For BBN3, combine with government-specific HSM requirements and potentially on-premises deployment |
BIO is a government framework
BIO applies to Dutch government agencies, not to commercial enterprises. However, suppliers to the Dutch government are often contractually required to meet BIO requirements. CloudTaser helps suppliers demonstrate that their cloud-hosted services protect government data from the cloud provider.
Audit Evidence¶
CloudTaser produces evidence suitable for BIO audits and ENSIA (Eenduidige Normatiek Single Information Audit) assessments:
# Generate compliance audit report
cloudtaser audit --vault-address https://vault.eu.example.com
# JSON output for audit evidence
cloudtaser audit --vault-address https://vault.eu.example.com -o json
The audit report provides:
- Protected vs. unprotected workload inventory (5.23, CLD-02)
- Protection scores per workload (8.9, 8.16)
- eBPF enforcement coverage per node (8.2, 8.12)
- EU vault connectivity verification (CLD-03)
- Orphaned Kubernetes Secrets in etcd (8.10, CLD-02)
- TLS/mTLS configuration details (8.24)