Twee gemeenten kopen vergelijkbare software en krijgen een heel ander project. De ene legt vooraf vast welke standaarden gelden, wanneer een deellevering is goedgekeurd en in welk formaat de data straks naar buiten komt. De andere komt daar pas bij de oplevering achter.
GIBIT 2025 is de nieuwste versie van de Gemeentelijke Inkoopvoorwaarden bij IT, de voorwaarden waarmee gemeenten software inkopen. De VNG publiceerde ze in maart 2026; het document zelf draagt de datum 12 februari 2026. Ze bepalen onder meer hoe kwaliteit wordt aangetoond, welke documentatie je krijgt, wat er met je data gebeurt en hoe je afscheid neemt van een leverancier.
Hieronder lees je wat de voorwaarden regelen, wat er verandert ten opzichte van GIBIT 2023 en welke eisen je zelf helder maakt voordat de bouw begint.
GIBIT 2025 in het kort
De voorwaarden horen bij een grotere toolbox, met daarin ook de Gemeentelijke ICT-kwaliteitsnormen, checklists, rekenbladen en een overeenkomstengenerator voor een conceptovereenkomst. De VNG vernieuwde die generator op 18 maart 2026 en zette alle onderdelen bij elkaar op de projectpagina.
De voorwaarden tellen 46 artikelen in vier delen: een algemeen deel over invoering, acceptatie, onderhoud, documentatie, data en exit; een deel over privacy, beveiliging en archivering; een deel over dienstverlening op afstand, oftewel software als dienst; en een nieuw hoofdstuk over open source.
Twee dingen zijn meteen van belang. Er is geen overgangsperiode: lopende contracten onder GIBIT 2023 blijven geldig en voor nieuwe contracten adviseert de VNG altijd GIBIT 2025. En je past de voorwaarden situatiegericht en proportioneel toe, passend bij het risicoprofiel van de inkoop. Die keuzes liggen bij jou en sturen het project.
Wat er verandert ten opzichte van GIBIT 2023
De VNG verwerkte 406 voorstellen uit de consultatie en vernieuwde langs zes thema's: sanctiebeleid, algoritmische toepassingen, digitale grondrechten en ethiek, data en datagebruik, open source en cloud. De volledige lijst met wijzigingen staat op de site van de VNG.
Voor een softwareproject vallen vier veranderingen op:
- Een eigen hoofdstuk over open source (artikelen 40 tot en met 46), met Common Ground als uitgangspunt en publicatie van de broncode in een repository.
- Een software bill of materials (artikel 25): een uitputtende lijst van de onderdelen waaruit de software bestaat, inclusief licenties en herkomst.
- Aparte artikelen over algoritmische toepassingen en AI systemen (artikelen 13 en 14), met eisen aan uitlegbaarheid, nauwkeurigheid en menselijk toezicht.
- De Gemeentelijke ICT-kwaliteitsnormen gelden niet meer onverkort. Artikel 8 koppelt de eisen aan wat in de overeenkomst is gespecificeerd.
Die laatste verandering is de meest praktische: waar eerder een vangnet gold, bepaal je nu zelf welke normen gelden. Bij projecten voor de overheid verschuift het werk daarmee naar de fase waarin je de opdracht beschrijft.
De eisen die je vooraf zelf helder maakt
Artikel 8 zegt dat de software voldoet aan de interoperabiliteitseisen, normen en standaarden die in de overeenkomst zijn gespecificeerd, zoals de Gemeentelijke ICT-kwaliteitsnormen. Dat is een apart document van de VNG met negen gebieden: architectuur, interoperabiliteit, informatiebeveiliging en privacy, dataportabiliteit, digitale toegankelijkheid, archivering, infrastructuur, documentatie en elektronisch factureren.
Het zijn minimumeisen. Je mag verder gaan, bijvoorbeeld door een standaard verplicht te stellen die in de normen alleen wordt aanbevolen, zolang je daar expliciet om vraagt in de overeenkomst. Twee beperkingen werken de andere kant op: een norm geldt alleen voor zover die relevant is voor de functie en het werkingsgebied van de software, en alleen in de versie die gold bij het sluiten. Nieuwe versies horen in het onderhoud thuis.
Maak daarom vóór de uitvraag concreet:
- Welke koppelingen er moeten komen, met welke systemen en via welke standaarden. De normen verwijzen onder meer naar de GEMMA referentiecomponenten, de verplichte open standaarden van het Forum Standaardisatie en de gemeentelijke API standaarden. Hoe zulke koppelingen werken, staat op onze pagina over software integratie.
- In welk formaat data eruit moet kunnen, met een beschrijving van het datamodel erbij.
- Welke eisen gelden voor digitale toegankelijkheid en archivering, en welke bewaartermijnen de software ondersteunt.
- Welke beveiligingsnorm geldt. Die keuze hoort bij je eigen informatiebeveiligingsfunctie; voor het project telt dat de norm vóór de bouw vastligt, omdat hij doorwerkt in inrichting en beheer.
PIANOo geeft bij de toolbox een toegankelijke toelichting.
Kwaliteit aantonen: plan, testen en acceptatie
Artikel 6 vraagt om een invoeringsplan waarvan de leverancier penvoerder is. Ontbreekt dat plan bij ondertekening, dan stellen partijen het alsnog op, in de regel binnen drie maanden na het eerste verzoek. Erin staan de koppelingen met hun specificaties, de relatie met het applicatielandschap, de deelleveringen, het tijdschema, de conversie en migratie van data, de opleidingen en de omgevingen voor ontwikkelen, testen en productie.
Daarna komt het bewijs. De leverancier voert vooraf de preventieve testen uit die in de afgesproken normen staan en levert het testrapport binnen vijf werkdagen. Heeft hij voor standaardsoftware al een derdenverklaring of een geldige certificering, dan kan die stap vervallen. Daarna toetst de acceptatieprocedure of het in jouw omgeving werkt.
Drie punten daaruit verdienen een plek in je planning:
- Elke deellevering wordt binnen vijf weken getest, met een testverslag dat beide partijen ondertekenen. Daarna volgt een integrale toets op de samenhang.
- Bestaat de levering mede uit koppelingen, dan hoort een ketentest bij de acceptatie. Daarin toets je of het applicatielandschap na de livegang nog klopt.
- Wordt de levering voor de tweede keer afgekeurd, dan kun je ontbinden, herstel laten uitvoeren of voorwaardelijk accepteren.
Let op artikel 9.13: neem je de software in productie, dan geldt dat als acceptatie. Een pilot die stilletjes uitgroeit tot productiegebruik kost je dus je positie. Acceptatiecriteria toetsbaar maken hoort bij het werk dat wij onder QA en testen scharen.
Documentatie, data en broncode: wat je in eigen hand houdt
Documentatie is in artikel 15 een opleverproduct met eisen. Die voor eindgebruikers is in het Nederlands, beschrijft de gemaakte instellingen en is geschikt om de software mee te testen en te beheren. Blijkt ze onjuist of onvolledig, dan werkt de leverancier haar kosteloos bij.
Voor data legt artikel 22 vast dat je er kosteloos bij kunt: inzien, downloaden of via koppelingen ophalen, in een algemeen leesbaar formaat en met een beschrijving van het datamodel. Vernietiging gebeurt op jouw verzoek, met een verklaring. Na afloop mag de leverancier pas vernietigen nadat hij je twee keer, met minstens 30 dagen ertussen, de kans gaf de data op te halen.
Bij maatwerk gaat artikel 21 verder dan veel teams verwachten. De rechten op maatwerksoftware liggen bij de opdrachtgever en de broncode wordt overgedragen. Spreek je niets anders af, dan wordt dat maatwerk als open source beschikbaar gesteld onder de European Union Public Licence versie 1.2 of hoger, in een repository die na acceptatie openbaar wordt en daarna de enige bron van waarheid is. Wie maatwerk software laat bouwen voor een gemeente, richt het ontwikkelproces daar vanaf dag één op in.
Nieuw is de software bill of materials uit artikel 25: een volledige lijst van de onderdelen waaruit de software bestaat, met onderscheid tussen eigen code, derdenprogrammatuur en toegeleverde onderdelen, inclusief licenties, herkomst, toeleveringsketen en de locaties van de verwerkte data. De lijst is vertrouwelijk en mag met het CSIRT worden gedeeld.
Exit en continuïteit regel je bij de start
Artikel 29 maakt van de exit een lopend onderwerp. Op verzoek van een van beide partijen stellen jullie een exitplan op, dat je in de regel jaarlijks bijwerkt en desgewenst een keer simuleert. Het beschrijft de overstap naar een nieuwe leverancier, het technisch ontvlechten van de software, het gestructureerd aanleveren van data en de vraag hoe je oude gegevens blijft raadplegen als de dienst stopt. Eindigt het contract door toerekenbaar tekortschieten van de leverancier, dan is dat werk kosteloos.
Neem je software als dienst af, dan komen daar drie zaken bij. De leverancier beschikt jaarlijks over een derdenverklaring of certificering over zijn informatiebeveiligingsprocessen, en bij kritieke bevindingen levert hij binnen drie maanden een verbeterplan dat hij ook uitvoert. Voor continuïteit kun je extra afspraken maken, zoals escrow van data. En er gelden terugvalwaarden zodra je zelf niets afspreekt: 98% beschikbaarheid per maand op werkdagen tussen 09.00 en 17.00 uur, een maximaal dataverlies van 28 uur en een hersteltijd van 16 werkuren in 85% van de gevallen. Voor een proces dat de hele dag doorloopt zijn dat magere waarden.
Wat GIBIT 2025 betekent voor de inrichting van je project
De voorwaarden vragen vooral om werk aan de voorkant. Vertaal ze naar je uitvraag en je projectplan:
- Eén lijst met eisen waarin per koppeling, formaat en norm staat wat geldt, inclusief het werkingsgebied.
- Acceptatiecriteria per deellevering, met de ketentest als apart moment in de planning.
- Documentatie, de software bill of materials en het exitplan als opleverproducten met een datum.
- Eén eigenaar en genoeg beschikbaarheid van je eigen mensen. Gebrekkige medewerking komt in de voorwaarden voor rekening van de opdrachtgever.
Vraag je leverancier vervolgens om concrete dingen: welke standaarden hij aantoonbaar ondersteunt en met welk testrapport, hoe hij de broncode en de repository inricht, welke servicewaarden hij haalt en hoe de exit er technisch uitziet.
Wij bouwen al ruim dertig jaar software met 30+ engineers in Nijmegen en Sarajevo, werken volgens ISO 9001 en ISO 27001 en leverden 100+ projecten op, van MRO software voor de luchtvaart tot een platform voor subsidieadministratie en RFID in de supply chain. In die omgevingen telden aantoonbaarheid, documentatie en overdraagbaarheid altijd al mee; onze cases laten zien hoe dat werkt. Plan een gesprek en we kijken mee naar de eisen, de acceptatiecriteria en de koppelingen.
Veelgestelde vragen
Wat is GIBIT 2025?
GIBIT 2025 is de nieuwste versie van de Gemeentelijke Inkoopvoorwaarden bij IT, in maart 2026 gepubliceerd door de VNG. De voorwaarden tellen 46 artikelen in vier delen en horen bij een toolbox met kwaliteitsnormen, checklists en een overeenkomstengenerator. Gemeenten gebruiken ze bij de inkoop van software.
Gelden de voorwaarden ook voor lopende contracten?
Nee. Bestaande contracten onder GIBIT 2023 blijven geldig en er is geen overgangsperiode. Voor nieuwe contracten adviseert de VNG altijd GIBIT 2025, bij voorkeur via de vernieuwde overeenkomstengenerator. Bij verlengingen loont het om na te gaan welke versie van toepassing is.
Zijn de Gemeentelijke ICT-kwaliteitsnormen nog verplicht?
Ze gelden niet meer onverkort. Artikel 8 verbindt de eisen aan wat in de overeenkomst is gespecificeerd, en een norm telt alleen voor zover die past bij de functie en het werkingsgebied van de software. Benoem de normen die je verlangt dus expliciet in de opdrachtdocumentatie en controleer op gibit.nl welke versie actueel is.
Wat betekent GIBIT 2025 voor maatwerksoftware en broncode?
De rechten op maatwerksoftware liggen bij de opdrachtgever en de broncode wordt overgedragen. Spreek je niets anders af, dan wordt dat maatwerk als open source beschikbaar gesteld onder de European Union Public Licence 1.2 of hoger, in een repository die na acceptatie openbaar wordt. Die repository geldt daarna als enige bron van waarheid voor de code.
