GIBIT, wat moet ik weten en regelen?

Het moment dat het woord “GIBIT” op tafel komt, verandert de dynamiek van een IT-inkoopgesprek vrijwel direct. Leveranciers weten: dit is geen licht contractje. Gemeenten weten: dit is ons fundament. Maar ergens tussen de juridische bepalingen en de technische realiteit ontstaat vaak een ongemakkelijke stilte. Want één vraag blijft meestal hangen:

Hebben we continuïteit écht goed geregeld?

De GIBIT – de Gemeentelijke Inkoopvoorwaarden bij IT – is bedoeld om grip te houden op IT-projecten en leveranciers. Het document is stevig, doordacht en ontstaan vanuit jarenlange ervaring met mislukkingen, afhankelijkheden en onverwachte risico’s. Het beschrijft hoe om te gaan met aansprakelijkheid, beveiliging, intellectueel eigendom en beëindiging van overeenkomsten. Het geeft kaders. Zekerheid. Structuur.

Maar papier alleen laat systemen niet draaien.

De afhankelijkheid die niemand graag bespreekt

Stel je voor: een gemeente werkt al jaren met een zaaksysteem dat diep verweven is met haar dienstverlening. Vergunningen, bezwaren, aanvragen, alles loopt via dat platform. Het contract is netjes opgesteld volgens de GIBIT. Servicelevels zijn afgesproken. Er is een exitregeling opgenomen.

En dan gebeurt het onverwachte. De leverancier komt in zwaar weer terecht. Of wordt overgenomen door een partij met een andere strategie. Of besluit het product uit te faseren.

Op dat moment wordt duidelijk wat er wél en niet geregeld is.

• Kan de gemeente zelfstandig verder?
• Is de kennis overdraagbaar?
• Is de software reproduceerbaar?

Dat zijn geen juridische vragen meer. Dat zijn operationele vragen. En precies daar raakt de GIBIT aan een belangrijk thema: continuïteit.

De belofte van een exit

In vrijwel elke overeenkomst onder de GIBIT staat een exitregeling. Leveranciers moeten meewerken aan overdracht, data beschikbaar stellen en ondersteuning bieden bij migratie. Dat klinkt logisch en geruststellend. Maar een exit werkt alleen als de leverancier nog functioneert. Wat als die medewerking er simpelweg niet meer kan zijn? Wat als er geen ontwikkelteam meer beschikbaar is? Wat als de broncode nooit buiten de organisatie is geweest? Dan blijkt dat continuïteit meer vraagt dan alleen goede intenties.

Escrow als stille zekerheid

Escrow komt zelden als eerste onderwerp op tafel. Het voelt soms als een wantrouwensinstrument. Alsof je bij het aangaan van een samenwerking al rekening houdt met het einde. Toch is dat precies wat professioneel risicomanagement inhoudt.

Bij een escrowregeling wordt afgesproken dat cruciale onderdelen van de software, broncode, documentatie, technische configuraties, worden ondergebracht bij een onafhankelijke derde partij. Niet om direct te gebruiken, maar om beschikbaar te zijn als het echt nodig is.

Het is te vergelijken met bijvoorbeeld een brandverzekering. Je hoopt hem nooit nodig te hebben, maar je bent opgelucht dat hij er is als het misgaat.

Voor gemeenten is dat geen luxe. Publieke dienstverlening stopt niet omdat een softwareleverancier problemen heeft. Burgers verwachten dat systemen werken. Vergunningaanvragen wachten niet tot een faillissementsprocedure is afgerond.

“Maar we werken met SaaS”

Een veelgehoorde reactie is dat escrow minder relevant zou zijn bij SaaS-oplossingen. De software draait immers in de cloud. Updates worden automatisch uitgevoerd. Alles wordt beheerd door de leverancier.

Juist dat maakt de afhankelijkheid groter.

Bij traditionele on-premise software stond er vaak nog iets fysiek binnen de muren van de organisatie. Bij SaaS is alles extern. Als de dienst stopt, is er niets meer. Daarom verschuift escrow mee met de tijd. Het gaat niet alleen meer om losse broncodebestanden, maar ook om infrastructuurdocumentatie, deployment-instellingen en technische beschrijvingen die nodig zijn om een omgeving opnieuw op te bouwen. Continuïteit in de cloud vraagt om een moderne vorm van borging.

De echte vraag achter de GIBIT

Wanneer een gemeente de GIBIT toepast, zegt ze eigenlijk: wij nemen IT serieus. We erkennen dat software geen simpele levering is, maar een langdurige afhankelijkheid. De vraag is dan niet alleen: voldoen we aan de GIBIT? De vraag is: hebben we de risico’s die de GIBIT benoemt ook daadwerkelijk afgedekt?

Intellectueel eigendom moet helder zijn. Niet alleen op papier, maar ook praktisch uitvoerbaar. Een exitregeling moet concreet zijn. Niet alleen een paragraaf, maar een werkbaar scenario. Continuïteit moet aantoonbaar zijn. Niet gebaseerd op vertrouwen alleen, maar ondersteund door maatregelen.

Escrow past precies in dat denken. Het is geen los product naast de GIBIT. Het is een logisch verlengstuk van de gedachte erachter: grip houden op essentiële IT.

Vooraf regelen is professioneel samenwerken

Misschien is dat wel de belangrijkste nuance. Escrow is geen teken van wantrouwen. Het is een teken van volwassen samenwerking. Leverancier en afnemer erkennen samen dat risico’s bestaan, zonder dat dit iets zegt over de kwaliteit of intentie van de ander.

Sterker nog, veel professionele leveranciers zien escrow juist als bevestiging van hun betrouwbaarheid. Ze hebben niets te verbergen. Ze begrijpen dat publieke organisaties hun continuïteit moeten kunnen aantonen.

De GIBIT geeft het kader. Escrow geeft de praktische invulling van continuïteitszekerheid. En uiteindelijk draait het daar om: zekerheid dat dienstverlening blijft draaien, ook als omstandigheden veranderen.Want IT-contracten lopen misschien vier, zes of acht jaar. Maar publieke dienstverlening loopt altijd door. De vraag “GIBIT, wat moet ik regelen?” is daarom eigenlijk een andere vraag: Hoe zorg ik dat mijn organisatie niet stilvalt als het onverwachte gebeurt? Wie die vraag serieus beantwoordt, komt vanzelf uit bij continuïteit. En wie continuïteit serieus neemt, kan escrow moeilijk negeren.

Meer weten over digital escrow en GIBIT? Neem contact met ons op, to be sure.