31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
BIO Penetration Testing: What the Dutch Government Security Baseline Expects From Public Bodies and Their Suppliers
The Baseline Informatiebeveiliging Overheid is the single information security standard for all four layers of Dutch government, and BIO 2.0 aligns it with ISO/IEC 27002:2022. Several of its controls can only be evidenced with a penetration test. This guide explains who must comply, where testing is expected, how municipalities account for it through ENSIA, how public bodies buy testing, and how the Cyberbeveiligingswet changes the stakes.
What the BIO is and how BIO 2.0 changed it
The Baseline Informatiebeveiliging Overheid (BIO) is the common information security standard for the Dutch public sector. It replaced four separate baselines (for central government, municipalities, provinces and water boards) with one framework, mandatory for central government from 1 January 2019 and for the other layers shortly after. The BIO takes ISO/IEC 27001 and 27002 as its backbone and adds government-specific measures at three basic security levels (basisbeveiligingsniveaus, BBN 1 to 3), with BBN 2 as the default for most government information systems. The result is a standard that an ISO 27001 auditor recognises immediately, with concrete, testable measures attached to the controls.
BIO 2.0 is the current version. It restructures the baseline along ISO/IEC 27002:2022, which reorganised the familiar 2013 control set into four themes (organisational, people, physical and technological) and introduced controls on threat intelligence, configuration management, data leakage prevention and secure coding. BIO 2.0 keeps the basic security levels and the government-specific measures, now hung on the 2022 control numbers. Public bodies and suppliers that mapped their evidence to the old numbering (12.6.1 for vulnerability management, 14.2.8 for system security testing, 18.2.3 for technical compliance review) now map it to 8.8, 8.29 and 5.36. The obligations did not get lighter; the structure got cleaner.
The BIO is anchored in agreements between the bestuurslagen and, for central government, in the Rijksbrede policy framework. The Cyberbeveiligingswet, the Dutch transposition of NIS2, gives the duty of care a statutory basis for the public bodies it covers, and the BIO is the government's stated instrument for meeting it. Compliance stops being a matter of interbestuurlijke agreement and becomes a matter of law.
Who must comply with the BIO
All four layers of government, and through them a large part of the Dutch software and hosting market.
Central government (Rijk)
Ministries, executive agencies, inspectorates and shared service organisations. The CIO Rijk framework requires BIO compliance for every information system, with the departmental CISO accountable and the Algemene Rekenkamer reviewing information security as part of the annual accountability audit.
Provinces
The twelve provinces, their executive bodies and the shared services they run together. Provinces account for BIO compliance to the Provinciale Staten and are subject to the same interbestuurlijke agreements as the other layers.
Municipalities (gemeenten)
All municipalities and their joint arrangements (gemeenschappelijke regelingen) such as regional social services, environmental services and ICT cooperatives. Municipalities account for BIO compliance annually through ENSIA, supported by the Informatiebeveiligingsdienst (IBD) of the VNG.
Water boards (waterschappen)
The 21 water boards, whose operational technology for flood defence, water quality and purification brings OT security into the BIO scope. Water management is also an Annex I sector under NIS2, which places the water boards among the essential entities.
Suppliers under contract
SaaS vendors, hosting providers, software developers and managed service providers that process government information or operate government systems. The BIO applies to them through the contract, and public bodies are expected to verify compliance rather than take it on trust.
Shared infrastructure and chains
Basisregistraties, DigiD and Suwinet connections, the Omgevingswet digital system and other chains in which many public bodies depend on one platform. These chains have their own assessment regimes layered on top of the BIO.
Where the BIO expects penetration testing
The BIO, like ISO 27002, rarely says penetration test. It says test, verify and demonstrate, and the government-specific measures make clear what that means for systems at BBN 2 and above.
Technical compliance review (control 5.36)
Information systems must be regularly checked for compliance with the organisation's security policies and standards. The government-specific measures under this control call for periodic technical verification of internet-facing and critical systems, which in practice means an annual penetration test, with findings handled through a documented process and reported to the system owner. This is the control auditors and the IBD point at first when asking for the latest report.
Management of technical vulnerabilities (control 8.8)
The BIO sets concrete expectations here: vulnerability information must be obtained and evaluated, and patches for vulnerabilities that the NCSC classifies as high probability and high impact must be installed within a short, defined window. Vulnerability scanning covers the known. A penetration test covers the combination: a medium vulnerability on one system that becomes a path to a high-value system through weak segmentation or reused credentials.
Secure development and security testing (controls 8.25 to 8.29)
Systems built or configured for government use must follow a secure development lifecycle, and security must be tested before acceptance. For municipalities and agencies that commission software, the measures translate into acceptance criteria: a penetration test of the new system or major release before go-live, with critical and high findings resolved. Public bodies increasingly write this into the contract rather than hoping for it.
Supplier assurance (controls 5.19 to 5.23)
Security requirements must be agreed with suppliers and monitored. For SaaS and hosting, the BIO expects the public body to obtain assurance that the supplier meets the baseline: a certificate, an assurance report (for example an ISAE 3402 or a third-party memorandum) and, for internet-facing services, a recent penetration test report whose scope covers the service as delivered. The public body remains responsible for testing its own configuration and integrations.
Logging, monitoring and incident response (controls 8.15, 8.16, 5.24 to 5.28)
The BIO requires logging of security-relevant events and monitoring for anomalies, and the Cyberbeveiligingswet adds statutory incident reporting deadlines. A penetration test is the simplest realistic exercise of these controls: did the SOC or the supplier see the test, and how long did it take? A test that passes unnoticed is itself a finding.
BIO accountability by layer of government
The baseline is the same everywhere. How compliance is reported, and who audits the penetration test, differs by layer.
| Layer | Accountability mechanism | Role of the penetration test |
|---|---|---|
| Central government | In-control statements per ministry under the CIO Rijk framework; Algemene Rekenkamer review | Evidence for technical compliance of critical and internet-facing systems; often required per system in the Rijks ICT dashboard |
| Municipalities | ENSIA: annual self-assessment, college statement, IT auditor assurance for DigiD and Suwinet, report to the municipal council | Mandatory input for the DigiD and Suwinet assurance; evidence for the BIO self-assessment on technical compliance |
| Provinces | Self-assessment and reporting to the Provinciale Staten under interprovincial agreements | Evidence for technical compliance; increasingly aligned with the ENSIA format |
| Water boards | Self-assessment under the Unie van Waterschappen agreements; NIS2 supervision as essential entities | Evidence for IT and OT technical compliance; input for the NIS2 effectiveness assessment |
| Suppliers | Contractual: GIBIT or ARBIT terms, certificates, assurance reports | Report handed to each public-sector customer; one platform-level test serves many customers if scoped and documented well |
ENSIA: how municipalities account for the BIO, DigiD and Suwinet
ENSIA (Eenduidige Normatiek Single Information Audit) bundles a municipality's information security accountability into one annual cycle. The penetration test feeds several parts of it.
- The BIO self-assessment, completed in the second half of the year, in which the municipality states per control how it complies; technical compliance claims need a current test report behind them
- The DigiD assessment, in which a Register EDP-auditor issues assurance on the municipality's DigiD connections; a penetration test of each connection and its portal is a fixed requirement of the Logius norm
- The Suwinet assessment, covering the municipality's use of the Suwinet exchange for social services, with its own norm set and auditor assurance that again relies on technical testing of the connected systems
- The college statement (collegeverklaring) that the executive board signs in spring, confirming the DigiD and Suwinet results, and the report to the municipal council by mid-year
- Vertical accountability to the ministries for the BRP, travel documents, BAG, BGT and BRO registrations, which is questionnaire-based but references the same technical controls
- The IBD's annual guidance on the cycle, including which supplier assurance (TPMs) the auditor may rely on for hosted portals and which components remain the municipality's own to test
Buying a penetration test as a public body: procurement realities
Public bodies buy penetration testing under the Aanbestedingswet 2012. Below the European threshold for services, most municipalities and agencies use a multiple-quote procedure (meervoudig onderhandse procedure) or draw on a framework agreement (raamovereenkomst) they or a purchasing cooperative have already tendered; above the threshold, an open European procedure or a dynamic purchasing system (DAS) applies, and the IT-security frameworks several Rijks and regional bodies run are the common route. The practical consequence is that a public body cannot simply call a tester in October when the ENSIA deadline looms. The procurement path has to be in place months earlier, which is why many bodies tender a multi-year framework for security testing with a fixed annual call-off.
The general terms are standardised. Municipalities use the GIBIT (Gemeentelijke Inkoopvoorwaarden bij IT), the VNG's IT purchasing conditions, which require suppliers to comply with the BIO, to cooperate with security testing and to report security incidents. Central government uses the ARBIT (Algemene Rijksvoorwaarden bij IT-overeenkomsten) with comparable clauses. For a penetration test supplier these terms set the rules on confidentiality, data handling, liability and the right of the public body to publish or share the report with its auditor and supervisors. For a software supplier bidding into government, the same clauses are the reason a current, well-scoped penetration test report is now part of almost every tender response.
What public buyers increasingly specify, and should: named and certified testers, a methodology referenced by name (NCSC guidelines, OWASP, PTES, NIST SP 800-115), a report format that maps findings to the BIO control, a retest included in the price, and a delivery date tied to the accountability calendar rather than to the supplier's convenience. A tender that specifies these receives comparable offers. One that asks for a penetration test as a single line item receives offers that range from an automated scan to a red team, and no way to compare them.
The exercise mindset, the Cyberbeveiligingswet and how we test for government
The annual Overheidsbrede Cyberoefening, organised by the Ministry of the Interior, has shifted how public bodies think about security: from a compliance checklist to a question of whether the organisation can detect, respond and recover. A penetration test belongs in that mindset. Scoped as an assumed-breach exercise against the systems that matter (the case management system, the identity platform, the financial systems, the OT at a water board), with the SOC or the supplier's monitoring in the loop, it answers the exercise question with evidence rather than a tabletop assumption. The BIO's logging and incident controls are tested at the same time, which no document review achieves.
The Cyberbeveiligingswet raises the stakes. Central government bodies are essential entities under NIS2, water boards fall under the water sector in Annex I, and the law provides for designating further public bodies. For designated bodies, Article 21(2)(f) of NIS2 requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, the management body approves those measures and can be held responsible, and significant incidents must be reported within 24 hours (early warning) and 72 hours (notification). A documented, board-approved penetration test programme is how a public body shows effectiveness assessment is in place, and the BIO is the measure set it assesses against.
HackersHub tests for ministries, municipalities, joint arrangements and the suppliers that serve them. We scope against the BIO control set, test from the positions that matter (the internet, a compromised workstation, a supplier connection, a citizen portal), coordinate with the IBD guidance and the ENSIA calendar for municipalities, and deliver a report that cites the BIO 2.0 control and, where relevant, the DigiD or Suwinet norm per finding. The lead tester is OSCP-certified and named, the retest is included, and the report is written to be handed to your IT auditor, your council or your supervisor without rework.
Frequently asked questions
Planning your BIO testing programme or ENSIA cycle?
We test against the BIO 2.0 control set, align with the ENSIA and Logius calendar, and deliver a report your auditor, council or supervisor can use as it stands. Talk to an expert.