What the Dutch BIO2 baseline requires from cloud platforms selling to the Dutch public sector

Key points:

• BIO2 is now law for Dutch government. The Baseline Informatiebeveiliging Overheid 2 (BIO2) was adopted by the OBDO on 23 September 2025 and became the mandatory duty of care for the government sector when the Cyberbeveiligingswet (Cbw, the Dutch NIS2 law) entered into force on 15 August 2026 (NL Digital Government). It applies to central government, provinces, municipalities and water boards, and by self-regulation to almost every other public body.
• BIO2 binds the government buyer, and its terms land in your contract. The supplier measures (5.19 to 5.23) require the government body to write its security requirements into the contract, demand annual proof from independent third parties that you meet them in design, existence and operation, keep a right to audit, see your sub-processor chain, and agree an exit strategy before signing (BIO2 v1.2, part 2).
• BIO2 does not require ISO 27001 certification, and does not prescribe a hosting location. It is built on ISO 27001 and the 93 controls of ISO 27002:2022, and a certificate simplifies accountability, but the BIO itself says certification is not mandatory. Location rules come from elsewhere.
• Location comes from the cloud policy. The revised Rijksbreed cloudbeleid, adopted on 3 July 2026, limits public cloud storage and processing for central government to EEA countries, requires encryption of non-public data, mandates detailed exit plans and advises against non-EU jurisdiction dependencies for critical and essential entities, with a 4-year transition (Kamerstuk 26643, nr. 1541).
• Architecture is a sales asset. A platform that runs inside the government body's own cloud account or cluster shortens the BIO2 questionnaire, because logs, data, region and exit stay under the buyer's control.

A few months ago a Dutch SaaS founder forwarded me a 140-line security questionnaire from a municipality and asked one question: "Is this the BIO, and do we need to be BIO-certified?" Both answers are short. Yes, most of those lines trace back to the BIO. And no, there is no such thing as a BIO certificate for a vendor.

That confusion is everywhere right now, because the rules changed twice in 2026. BIO2 became a legal duty under the Cyberbeveiligingswet in August, and the central government tightened its cloud policy in July. If you sell cloud services, a SaaS product or a platform to Dutch public bodies, this is the guide I wish that founder had: what BIO2 is, which measures land on suppliers, what evidence buyers will ask for, and where location and sovereignty requirements really come from.

One caveat up front. I quote measure numbers from the BIO2 v1.2 PDF adopted in September 2025. The legally referenced text is BIO2 v1.3 published in the Staatscourant, and where versions differ the ministerial regulation takes precedence. Check the current text on bio-overheid.nl before you answer a tender.

What is the Dutch BIO2 framework and who has to comply with it?

The Baseline Informatiebeveiliging Overheid (BIO) is the mandatory information security framework for all Dutch government organisations: central government, municipalities, provinces and water boards. BIO2 is its second version, adopted by the Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) on 23 September 2025, built on ISO/IEC 27001:2023 and ISO/IEC 27002:2022 (NL Digital Government).

Since the Cyberbeveiligingswet entered into force on 15 August 2026, the BIO2 government measures are a legal duty of care for organisations in the "Overheid" sector (Houthoff). The Cbw is the Dutch implementation of the NIS2 Directive, and the NCSC estimates it brings roughly 8,000 organisations under new cybersecurity obligations. The Rijksinspectie Digitale Infrastructuur (RDI) is the designated supervisor for the government sector (BIO2 v1.2, section 21).

Bodies outside the Cbw are not off the hook. The High Councils of State, the Ministry of Defence, the AIVD, the police and exempt independent administrative bodies (ZBOs) remain bound to BIO2 by decision of the Council of Ministers, which means "the BIO2 effectively applies to all government organisations" (NL Digital Government).

The changes from BIO 1 that affect vendors:

Sources: BIO2 v1.2, Informatiebeveiligingsdienst (IBD).

Does BIO2 apply directly to cloud providers and SaaS vendors?

No. BIO2 places its obligations on the government organisation, not on the vendor. But the government organisation "remains responsible for handling risks related to the outsourced or purchased service", and must include the relevant BIO obligations in its procurement requirements (our translation, BIO2 v1.2, section 23). In practice that means BIO2 reaches you through the tender, the contract and the annual review.

I tell founders they will never be "BIO compliant" in the abstract. Your customer has to show their supervisor that your service fits inside their BIO2 risk management. Your job is to make that easy, cheap and repeatable for them.

That is also why questionnaires feel so different from one municipality to the next. BIO2 dropped the three fixed security levels in favour of a risk analysis per information system. Two buyers with the same product can ask for different things because their risk analyses differ.

Expect BIO2 to reach you in four places:

• The tender (offerteaanvraag). Security requirements are part of the whole package of procurement requirements, based on an explicit risk analysis (measure 5.19.01).
• The contract. Requirements from the tender go explicitly into the contract (5.20.01), with your general terms excluded where possible (5.20.02).
• The annual review. The process owner assesses every year, based on your evidence, whether you still meet the requirements (5.22.01).
• The incident chain. You must be transparent about vulnerabilities and incidents, including data breaches (5.20.05), so the buyer can meet its own legal reporting deadlines (5.24.07).

What does BIO2 require from cloud platforms selling to the Dutch public sector?

BIO2 requires the government buyer to contractually oblige a cloud supplier to prove, every year and through independent third parties, that it meets the agreed security requirements in design, existence and operation; to accept external audits; to disclose and manage its own sub-processors; to report vulnerabilities and incidents; and to support a documented exit. Several technical measures on logging, cryptography and change management then apply to the service you operate.

Here are the BIO2 government measures that most directly land on a cloud platform or SaaS vendor, paraphrased from the Dutch text:

Source for all rows: BIO2 v1.2, part 2.

Two measures catch vendors out. Measure 5.20.03 requires evidence that is independent, covers the scope of the contracted service, and is renewed every year. A shiny ISO 27001 certificate whose scope covers your office but not your production platform does not pass. Measure 5.21.02 requires you to show your chain of sub-suppliers before the contract is signed. If your platform sits on a hyperscaler, a managed database vendor and three observability tools, all of them are in scope.

Does BIO2 require ISO 27001 certification or hosting in the Netherlands?

No to both. The BIO2 framework states that it "does not require NEN-EN-ISO/IEC 27001 certification", although certification simplifies accountability through an independent assessment (BIO2 v1.2, section 19). And BIO2 contains no data location requirement. Location and jurisdiction rules come from the government cloud policy, GDPR and the buyer's own risk analysis.

That said, ISO 27001 and ISO 27002 are on the Forum Standaardisatie "pas-toe-of-leg-uit" list of mandatory standards for the public sector, which means government applies them unless there are explicit reasons not to (BIO2 v1.2, copyright note). So while a certificate is not legally required, a scope-matching ISO 27001 certificate is the cheapest way to satisfy 5.20.03.

Here is how the common evidence options compare against what 5.20.03 asks for:

On location, the big 2026 change is the revised Rijksbreed cloudbeleid, adopted by the Council of Ministers on 3 July 2026 (Kamerstuk 26643, nr. 1541). It applies to all of central government except the High Councils of State and Defence, and other public bodies are advised to follow it. The main tightenings:

• EEA only for public cloud. Storage and processing in public cloud is limited to EEA countries, and data must be encrypted unless it is public.
• Jurisdiction risk must be weighed. Risk analyses must address dependency on suppliers that fall partly under a non-Dutch, non-EU or non-EEA jurisdiction. For critical and essential entities under the Wwke and the Cbw, depending on such a supplier for core tasks is advised against.
• Detailed exit plans. The plan must cover both a planned exit and a sudden unavailability of the service, beyond "hand over the data and delete it".
• Central reporting. Material cloud use, with its risk analysis and exit plan, must be reported to CIO Rijk.
• Use cases taken off public cloud. Email and document management are advised against in public cloud and existing solutions will be migrated; special categories of personal data are advised against too, or need Privacy Enhancing Technologies; state-secret information and TBB levels 1 to 3 stay off public cloud entirely.
• A 4-year transition. Existing cloud use that does not meet the new rules gets four years from adoption, and longer-running existing contracts may be respected.

The letter also announces work with municipalities, provinces and water boards towards a government-wide cloud policy. If you sell to municipalities, assume these rules will reach them too.

The Algemene Rekenkamer's January 2025 report Het Rijk in de cloud counted 1,588 cloud services across ministries and found that for 84 of the 126 most important public cloud services (67%), no risk assessment had been made. That finding is cited as one of the triggers for the revision. Public buyers are now under pressure to document every cloud dependency, and your service is one of them.

For the broader sovereignty picture, our article on the four levels of EU cloud sovereignty explains why BIO, like BSI C5, tests controls but not ownership, and our comparison of European sovereign clouds and hyperscalers for public sector projects scores the providers themselves.

How do the Cyberbeveiligingswet and municipal accountability change the sales cycle?

The Cyberbeveiligingswet turns BIO2 from good practice into a supervised legal duty, so Dutch public buyers now need supplier evidence that holds up in front of the RDI as well as in a procurement file. Expect tighter incident clauses, longer security reviews and annual evidence requests on a fixed calendar.

Three concrete effects I see in deals:

• Incident timelines get contractual. Under the Cbw, essential and important entities must give an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month (Houthoff). BIO2 measure 5.24.07 requires the buyer's incident procedure to meet those legal deadlines, so your notification SLA has to be faster than theirs.
• Accountability cycles drive the calendar. Municipalities report on information security through ENSIA, a single accountability process that covers the BIO and several national registration systems such as DigiD and Suwinet (VNG). If your service touches those systems, your annual evidence feeds their audit.
• Board-level ownership. The Cbw makes the bestuurder of each government body responsible for approving and overseeing cybersecurity measures, and for being trained on them (BIO2 v1.2, section 21). Security questions now reach people who sign off on budgets.

Eurostat reports that 33.2% of Dutch enterprises used AI technologies in 2025, among the highest rates in the EU, and Dutch public bodies are under the same pressure to digitise. The vendors who win are the ones whose evidence pack is ready before the tender opens.

Which architecture choices make BIO2 evidence easier for cloud vendors?

The architecture that makes BIO2 easiest is one where the government body keeps control of the data plane: the service runs in the buyer's own cloud account, in an EEA region they choose, with logs and data they hold, while the vendor operates it through a narrow, audited channel. Multi-tenant SaaS can pass BIO2, but it carries the full evidence burden on the vendor.

Here is how the three common delivery models compare on the measures that cause the most friction:

My view, after watching vendors go through these reviews: if your product is infrastructure-heavy and the buyer has a cloud team, offer a "runs in your account" option. You trade some operational convenience for a much shorter security review, and the exit-strategy and EEA questions mostly answer themselves. Our EU data residency guide for Kubernetes goes into the technical setup.

Whatever model you choose, prepare this pack before the first tender:

• ISO 27001 certificate (or ISAE 3402 / SOC 2 Type II report) whose scope covers the contracted service
• Statement of applicability mapped to ISO 27002:2022 and the BIO2 government measures
• Current sub-processor list with locations and jurisdictions, and a change notification process
• Data location statement: EEA regions, encryption at rest and in transit, key management
• Incident and vulnerability notification procedure faster than 24 hours
• Audit log specification showing the six BIO2 log fields, retention options and immutability
• Written exit plan for planned exit and sudden unavailability
• Change management description: environments, testing, approvals, rollback

How does Qovery help cloud vendors and public bodies meet BIO2 requirements?

Qovery is an Agentic DevOps platform that deploys and operates applications on Kubernetes in your own AWS, GCP, Azure or Scaleway account, or on an existing Kubernetes cluster, including EU-operated and on-premise clusters. Qovery's control plane is separate from the data plane, so application data, secrets and workloads stay in the cloud account you or your public sector customer owns (Qovery security).

For a vendor selling into Dutch government, that gives you the "runs in your account" delivery model without building a DevOps team to support each customer's cloud:

• Region and account per customer. Deploy each public sector customer into its own account or cluster in an EEA region of its choice, which helps with the cloud policy's EEA-only rule and the jurisdiction questions in 5.21.
• Audit logs and RBAC. Deployments and configuration changes are attributed to a user or a named API token and scoped per organisation, project and environment, which supports the actor and action fields BIO2 expects in 8.15.01. Ship your application logs to the buyer's own SIEM.
• Change management by default. Separate environments, environment cloning and preview environments per pull request support 8.31 (no testing in production) and 8.32 (recorded, approved changes with rollback).
• Infrastructure as code. The Qovery Terraform provider gives you a reproducible definition of every environment, which makes the exit plan concrete: the customer keeps the cloud account, the workloads and the definition.
• Scoped access for agents and automation. OPA-based policy tokens restrict what an API token or AI agent can do, which helps when buyers ask how supplier access is limited (8.05.01).

Qovery lists its own security posture, including SOC 2 Type II, on its security page. It does not make you or your customer BIO2 compliant. The risk analysis, the ISMS and the statement of applicability belong to the government body, and your evidence pack belongs to you. Qovery removes the operational cost of offering a single-tenant, in-customer-account deployment model to public buyers.

How do I set this up with Qovery from Claude Code or Cursor?

If you want to test the "runs in the customer's account" model, install the Qovery Agent Skills and let your coding agent deploy a staging copy of your product into a dedicated cloud account in an EU region.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or scoped to the current project only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. Write access, only when you explicitly want it (also enable write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Your agent asks you to approve the install script, and the MCP Server opens an OAuth login so it acts with your own Qovery permissions. Then ask in plain language, for example: "deploy this app to my AWS account in eu-central-1 with Qovery" or "generate Terraform for this environment". The skills deploy; the MCP Server operates what already exists. See the AI agent quickstart and the Claude Code integration.