Two municipalities buy comparable software and end up with very different projects. One records up front which standards apply, when a partial delivery counts as approved, and in which format the data can leave the system. The other meets those questions at handover.
GIBIT 2025 is the latest version of the Gemeentelijke Inkoopvoorwaarden bij IT, the standard conditions Dutch municipalities use when they buy software. VNG, the Association of Netherlands Municipalities, released this version, dated 12 February 2026, in March 2026. For your project, they set how quality is demonstrated, what documentation you receive, what happens to your data, and how you part ways with a supplier.
This article takes the client's side: what the conditions arrange, what changed since GIBIT 2023, and which requirements you make explicit before the build starts.
GIBIT 2025 in short
The conditions are one part of a larger toolbox that also holds the Gemeentelijke ICT-kwaliteitsnormen (the municipal ICT quality standards), checklists, and an agreement generator that assembles a draft contract. VNG rebuilt that generator on 18 March 2026 and collects every component on its GIBIT project page. The source material is all in Dutch.
The conditions run to 46 articles in four parts: a general part on rollout, acceptance, maintenance, documentation, data, and exit, a part on privacy, security, and archiving, a part on remote services that covers software as a service, and a new chapter on open source.
Two points matter for planning right away. There's no transition period: contracts running under GIBIT 2023 stay valid, and for new contracts VNG advises always using GIBIT 2025. And the conditions aren't applied unchanged. You use them proportionally, matched to the risk profile of the purchase, so the client makes choices that steer the project.
What changed compared with GIBIT 2023
VNG processed 406 consultation proposals and renewed the conditions along six themes: sanctions, algorithmic applications, digital fundamental rights and ethics, data use, open source, and cloud. The full list of changes sits on the VNG website.
Four of those changes show up directly in a software project:
- A dedicated open source chapter (articles 40 to 46), built on the Common Ground principles used across Dutch municipal IT, with source code in a public repository.
- A software bill of materials (article 25): a complete list of the components the software is built from, including licenses and origin.
- Separate articles on algorithmic applications and AI systems (articles 13 and 14), with requirements for explainability, accuracy, and human oversight.
- The municipal ICT quality standards no longer apply across the board. Article 8 ties the requirements to what the contract specifies.
That last change is the most practical one: where a safety net used to fill the gaps, you now decide which standards apply. For government projects, the work moves into the stage where you describe the assignment.
The requirements you set before the build starts
Article 8 says the software meets the interoperability requirements, norms, and standards specified in the contract, such as the municipal ICT quality standards. That separate VNG document covers nine areas: architecture, interoperability, information security and privacy, data portability, digital accessibility, archiving, infrastructure, documentation, and electronic invoicing.
These are minimum requirements. You can ask for more, for example by making a recommended standard mandatory, as long as the contract says so explicitly. Two limits work the other way: a standard applies only where it's relevant to the function and scope of the software, and only in the version that applied when the contract was signed. Newer versions belong in the maintenance agreement.
Before you go to market, make these concrete:
- Which integrations are needed, with which systems, and through which standards. The quality standards point to the GEMMA reference components, the mandatory open standards listed by Forum Standaardisatie, and the municipal API standards. Our software integration page shows how those connections get built.
- In which format data has to come out, with a description of the data model.
- Which accessibility and archiving requirements apply, and which retention periods to support.
- Which security standard applies. That choice belongs with your own information security function. For the project, what counts is that it's fixed before the build, because it works through into setup and operations.
PIANOo, the Dutch public procurement expertise center, publishes an introduction to the toolbox.
Proving quality: plan, tests, and acceptance
Article 6 calls for a rollout plan drafted by the supplier. If there's no plan when the contract is signed, the parties produce one anyway, as a rule within three months of the first request. It covers the integrations and their specifications, the relation to the application landscape, the partial deliveries, the schedule, data conversion and migration, training, and the development, test, and production environments.
Then comes the evidence. The supplier runs the preventive tests prescribed by the agreed standards and hands over the test report within five working days. For standard software already covered by a third party statement or valid certification, that step can be skipped. The acceptance procedure then checks whether the software works in your landscape.
Three points from that procedure deserve a place in your schedule:
- Each partial delivery is tested within five weeks, with a test report both parties sign, followed by an integrated test of the whole.
- When the delivery includes integrations, a chain test is part of acceptance. It verifies that the application landscape still behaves correctly after go live.
- If a delivery fails acceptance twice, you can dissolve the contract, have the defects repaired, or accept conditionally.
Watch article 9.13: putting the software into production counts as acceptance, so a pilot that quietly grows into production use costs you that position. Making acceptance criteria testable is part of what we cover under QA and testing.
Documentation, data, and source code
Article 15 turns documentation into a deliverable with requirements. End user documentation is written in Dutch, describes the settings that were configured, and has to be good enough to test and run the software. If it's wrong or incomplete, the supplier updates it free of charge.
For data, article 22 records that you can reach it at no cost: view it, download it, or pull it through integrations, in a commonly readable format and with a description of the data model. Destruction happens at your request, against a statement. After the contract ends, the supplier may only destroy data after giving you two chances, 30 days apart, to collect it.
For custom development, article 21 goes further than many teams expect. The rights rest with the client and the source code is handed over. Unless you agree otherwise, that custom software is released as open source under the European Union Public Licence version 1.2 or higher, in a repository that becomes public after acceptance and is the single source of truth from then on. Anyone having custom software built for a Dutch municipality plans for that from day one.
New in this version is the software bill of materials from article 25: a full list of the components the software is built from, separating the supplier's own code, third party software, and supplied components, including licenses, origin, supply chain, and where data is processed. The list is confidential and may be shared with the CSIRT, the security incident response team.
Exit and continuity, arranged at the start
Article 29 makes the exit a running topic. At the request of either party you draw up an exit plan, update it yearly as a rule, and can simulate it. It describes the move to a new supplier, untangling the software, delivering data in a structured form, and how you keep reading old records once the service stops. If the contract ends because the supplier failed to deliver, that work is free.
Buying software as a service adds three things. The supplier holds an annually renewed third party statement or certification for its information security processes, and critical findings lead to an improvement plan within three months. For continuity you can add arrangements such as data escrow. And fallback values apply as soon as you agree nothing yourself: 98% availability per month on working days between 09.00 and 17.00, a maximum data loss of 28 hours, and a recovery time of 16 working hours in 85% of cases. For a process that runs all day, those are thin numbers.
What GIBIT 2025 means for the way you run the project
Most of the work these conditions ask for sits at the front of the project. Translate them into your tender documents and plan:
- One requirements list stating what applies per integration, format, and standard, with its scope.
- Acceptance criteria per partial delivery, with the chain test as its own milestone.
- Documentation, the software bill of materials, and the exit plan as dated deliverables.
- One owner on your side, plus enough availability from your own people. Under the conditions, poor cooperation is the client's own risk.
Then ask concrete questions: which standards the supplier supports and with which test report, how it sets up source code and the repository, which service levels it meets, and what the exit looks like.
We've built software for more than 30 years with 30+ engineers in Nijmegen and Sarajevo, work to ISO 9001 and ISO 27001, and have delivered 100+ projects, from MRO software for aviation to a subsidy administration platform and RFID in the supply chain. Traceability, documentation, and transferability always counted in that work, as our cases show. Book a call and we'll go through the requirements, the acceptance criteria, and the integrations.
Frequently asked questions
What is GIBIT 2025?
GIBIT 2025 is the latest version of the Gemeentelijke Inkoopvoorwaarden bij IT, the standard IT purchasing conditions for Dutch municipalities, published by VNG in March 2026. It runs to 46 articles in four parts, alongside a toolbox with quality standards, checklists, and an agreement generator.
Does GIBIT 2025 apply to contracts already running?
No. Contracts under GIBIT 2023 stay valid and there's no transition period. For new contracts, VNG advises always using GIBIT 2025, preferably through the rebuilt agreement generator. With extensions, check which version applies.
Are the municipal ICT quality standards still mandatory?
Not across the board. Article 8 ties the requirements to what the contract specifies, and a standard counts only where it fits the function and scope of the software. Name the standards you expect in the tender documents, and check gibit.nl for the current version.
What does GIBIT 2025 mean for custom software and source code?
The rights rest with the client and the source code is handed over. Unless you agree otherwise, that software is released as open source under the European Union Public Licence 1.2 or higher, in a repository that becomes public after acceptance and is the single source of truth.
