Om te zorgen dat een ICT-product of -dienst aansluit bij de behoefte, wordt gemeenten aanbevolen om gebruik te maken van de Gemeentelijke Inkoopvoorwaarden bij IT, ook wel bekend als GIBIT. Deze uniforme inkoopvoorwaarden helpen gemeenten bij het professionaliseren van de inkoop van ICT-diensten en –producten. Maar worden hiermee ook alle informatiebeveiligingsvraagstukken gedekt?

Eigen inkoopvoorwaarden gemeenten

Als gemeente sta je midden in de informatiesamenleving. Niet voor niets investeren gemeenten al jaren in digitalisering. Voor de kwaliteit van je dienstverlening ben je daarbij als gemeente in grote mate afhankelijk van leveranciers. Zo wordt er jaarlijks voor miljoenen aanbesteed en ingekocht. Voordat er een contract wordt afgesloten met een leverancier is het belangrijk dat er goede afspraken, waaronder over informatiebeveiliging, worden gemaakt én vastgelegd.

Onder het motto ‘samen doen wat samen kan’, hebben gemeenten in 2015 besloten om meer samen te ontwikkelen en hebben toen de Digitale Agenda 2020 vastgesteld. Eén van de speerpunten uit deze agenda is het meer collectief organiseren van ICT-zaken en het professionaliseren van het ICT-opdrachtgeverschap bij gemeenten. Met als doel hiermee te borgen dat gemeenten ICT-producten en –diensten kopen die aansluiten bij hun behoeften. Dit heeft geresulteerd in de realisatie van de Gemeentelijke Inkoopvoorwaarden bij IT (GIBIT) door VNG Realisatie. De GIBIT is opgesteld in nauwe samenwerking met verschillende partijen waaronder ook leveranciers. Hiermee wordt geborgd dat het niet alleen door gemeenten en gemeentelijke samenwerkingsverbanden wordt opgenomen in het inkoopbeleid en gebruikt wordt als kader bij de inkoop van IT, maar dat het ook breed geaccepteerd wordt door leveranciers.

GIBIT en informatiebeveiliging

In eerste instantie omvat de reikwijdte van de GIBIT alle producten en/of diensten die gemeenten en gemeentelijke samenwerkingsverbanden op het gebied van ICT verwerven.

Dit betreft:

•  producten (o.a. software, hardware, IT-systemen, licenties et cetera),
• diensten op project basis (o.a. het leveren, installeren, implementeren, onderhouden van en adviseren over ICT-zaken en/of diensten) en
• diensten van structurele aard (o.a. het onderhouden, op afstand aanbieden en/of hosten van software, clouddiensten, netwerken et cetera).

Daarnaast kunnen delen van de GIBIT gebruikt worden voor een betere borging van bijvoorbeeld informatiebeveiliging, eigendom en overdracht van data en (data)interoperabiliteit. Want ook als je diensten inkoopt, geldt dat de gemeente altijd eindverantwoordelijk is en blijft als het gaat om informatiebeveiliging. Daarom is het belangrijk om al in een vroegtijdig stadium aan mogelijke leveranciers kenbaar te maken welke beveiligingsniveau de gemeente hanteert, welke beveiligingseisen de gemeente heeft en wat zij hierbij verwacht van de leverancier. Op die manier kan hier nooit achteraf discussie over ontstaan. Maar worden op het gebied van informatiebeveiliging ook alle onderdelen meegenomen in de GIBIT? Om dat te achterhalen zet ik in deze blog de belangrijkste artikelen uit de GIBIT op een rij die een relatie hebben met informatiebeveiliging (niet-limitatief). Te beginnen met enkele artikelen uit deel I van de GIBIT:

• Artikel 6: Toe te passen ICT-kwaliteitsnormen, interoperabiliteitseisen en standaarden – dit artikel schrijft voor dat er moet worden voldaan aan de gemeentelijke ICT-kwaliteitsnormen alsook de aanvullend voorgeschreven normen, waaronder normen voor informatiebeveiliging en privacy zoals de Baseline Informatiebeveiliging Overheid (BIO) en Standaard Verwerkersovereenkomst. De leverancier moet de maatregelen uit de BIO, voor zover van toepassing verklaard door de gemeente, accepteren en deze toepassen op de geleverde producten en/of diensten. Ook zijn leveranciers verantwoordelijk om dit bekend te maken en de aan hun opgelegde eisen door te vertalen naar hun toeleveranciers.
  
• Artikel 7: Het hebben van een acceptatieprocedure – in dit artikel wordt de acceptatieprocedure beschreven, waarbij de leverancier moet aantonen dat ze de overeengekomen prestatie kunnen leveren. Hiermee wordt preventief en zorgvuldig testen vooraf gestimuleerd. Zo dient er te worden getest of producten/applicaties aan de gestelde (beveiligings)eisen voldoen. Daarnaast kan er met de proces/systeemeigenaar bepaald worden of er aanvullend specifieke informatiebeveiligingstesten (zoals penetratietesten), of wanneer het ICT-voorzieningen betreft met impact op de privacy, specifieke privacy gerelateerde testen uitgevoerd moeten worden.
  
• Artikel 13: Aansprakelijkheid – dit onderwerp leidt vaak tot discussies tussen opdrachtgevers en leveranciers. Want wie is wanneer aansprakelijk? Leveranciers moeten zich realiseren dat hun tekortschieten kan leiden tot grote schades bij gemeenten. Daarom mag van leveranciers worden verwacht dat zij hun bedrijfsvoering zo hebben ingericht dat een (informatiebeveiligings)incident niet direct tot grote schades leidt.
  
• Artikel 15: Geheimhouding – beide partijen moeten alle informatie waarvan zij het vertrouwelijke karakter (behoren te) kennen geheimhouden binnen de minimale geheimhoudingstermijn. Voor persoonsgegevens geldt de bewaartermijn die in de verwerkersovereenkomst wordt opgenomen.
  
• Artikel 18: Toegang tot data en autorisaties – voor gemeenten is het belangrijk dat zij toegang blijven houden tot data die door een leverancier wordt verwerkt (hun eigen data). Bijvoorbeeld omdat deze data ook voor andere doeleinden en in andere processen en systemen wordt gebruikt. Het gebruik van de gegevens door de gemeente zelf is voor eigen rekening en risico. Wel moet de leverancier de gemeente waarschuwen wanneer het verlenen van toegang ertoe leidt dat bepaalde beveiligingsmaatregelen worden omzeild.
  
• Artikel 21: Controlerecht en medewerking bij audits – de leverancier moet meewerken aan een externe audit, bijvoorbeeld een penetratietest, die de gemeente kan laten uitvoeren om te controleren of de leverancier aan de afgesproken beveiligingseisen voldoet. Andersom kan de leverancier ook zelf door middel van certificering aantonen dat de gewenste betrouwbaarheid van de dienst is geborgd, of wanneer er al een onafhankelijke audit heeft plaatsgevonden, de relevante resultaten delen met de gemeente.
  
• Artikel 22: Exitplan en -scenario – dit artikel beschrijft diverse situaties waarbij de gemeente het product en/of de dienst niet langer gebruikt of overstapt naar een ander systeem en wat er (in voorbereiding daarop) moet gebeuren voor een soepele overstap. Zo moet voordat een contract wordt afgesloten in een risicoafweging bepaald worden of de afhankelijkheid van een leverancier beheersbaar is. Een vast onderdeel van het contract is een expliciete uitwerking van deze exit-strategie.

Daarnaast bevat deel II van de GIBIT-artikelen die specifiek betrekking hebben op privacy, beveiliging en archivering. Deze gelden wanneer er persoonsgegevens of andersoortige gegevens worden verwerkt die afkomstig zijn van de opdrachtgever of waarvoor de opdrachtgever verantwoordelijk is. Het gaat hierbij om:

• Artikel 24: Verwerkersrelatie, in de zin van de AVG – wanneer de leverancier persoonsgegevens in opdracht van en voor de gemeente gaat verwerken of kan inzien, is aanvullend een verwerkersovereenkomst nodig. Een verwerkersovereenkomst is niet vrijblijvend maar wettelijk verplicht onder de privacywetgeving. Zie ook mijn eerdere blog ‘Vijf tips bij het opstellen van een verwerkersovereenkomst’. Als gemeente kun je gebruik maken van de Standaard Verwerkersovereenkomst Gemeenten welke is opgesteld voor de VNG.
  
• Artikel 25: Verwerking persoonsgegevens – hieronder valt dat de leverancier op geen enkele manier de persoonsgegevens die zij ter beschikking krijgt voor andere doeleinden mag gebruiken dan voor de uitvoering van de overeengekomen dienst. Ook moet de leverancier kunnen aantonen dat zij passende technische en organisatorische beveiligingsmaatregelen treffen om persoonsgegevens te beveiligen tegen verlies of onrechtmatig gebruik.
  
• Artikel 26: Informatiebeveiligings(niveau) – dit artikel ziet specifiek toe op beveiliging waarbij de leverancier moet voldoen aan de BIO-normen welke deel uitmaken van de gemeentelijke ICT-kwaliteitsnormen (zie artikel 6).
  
• Artikel 27: Meldplicht informatiebeveiligingsincidenten – dit artikel heeft betrekking op de meldplicht voor beveiligingsincidenten. Wanneer de leverancier informatie van de gemeente host op haar systemen, moeten (beveiligings)incidenten direct gemeld worden aan de gemeente. Daarbij moeten de geconstateerde kwetsbaarheden door de leverancier opgelost te worden.
  
• Artikel 32: Waarborging continuïteit – dit artikel heeft betrekking op data-escrow. Dit houdt in dat de gemeente die software gebruikt van een leverancier op haar eigen ICT-infrastructuur of in een Cloud toepassing, de mogelijkheid moet hebben om, bijvoorbeeld in het geval dat de softwareleverancier failliet gaat, te waarborgen dat de software onderhouden en gebruikt kan blijven worden. Dit om bedrijfscontinuïteitsbeheer (BCM) te kunnen waarborgen, zodat ongeacht de omstandigheden de nodige maatregelen getroffen kunnen worden om de continuïteit van de meest (kritische) bedrijfsprocessen te garanderen.

De Informatiebeveiligingsdienst voor gemeenten (IBD) heeft de handreiking ‘Inkoopvoorwaarden en informatiebeveiliginseisen’ opgesteld waarin de informatiebeveiligingseisen die de inkoopvoorwaarden van een gemeente versterken verder zijn uitgewerkt.

Risicoanalyse
Wanneer je als gemeente een dienst of product inkoopt, is het in sommige gevallen nodig om aanvullend ook een risicoanalyse uit te voeren. Het doel hiervan is om de risico’s voor betrokkenen inzichtelijk te maken en (aanvullende) maatregelen te nemen om deze risico’s te verkleinen. Op basis daarvan kan bepaald worden welke (aanvullende) afspraken expliciet in het contract met de leverancier moeten worden opgenomen. Wanneer er ook persoonsgegevens worden verwerkt is het advies aanvullend ook een Data Protection Impact Assessment (DPIA) uit te voeren. Deze beoordeling is zelfs verplicht als het verwerken van de persoonsgegevens een hoog privacy risico oplevert, bijvoorbeeld bij gebruik van camera’s in het kader van toezicht en handhaving of bij de verwerking van bijzondere persoonsgegevens, zoals medische- of strafrechtelijke gegevens.

Kortom: ga er niet standaard van uit dat de GIBIT voor alle situaties binnen je organisatie altijd alles goed afdekt. Voer zelf een risicoanalyse uit om te bepalen waar de nadruk in de voorwaarden en het contract moeten liggen. Het is namelijk altijd mogelijk om aanvullende voorwaarden of een verdieping op een GIBIT-artikel op te nemen tijdens het inkoopproces. Zorg dus ook dat je als CISO tijdig bij het inkoop of aanbestedingsproject wordt betrokken.

Meer informatie?
Ik hoop je met deze blog meer inzicht te hebben gegeven in de GIBIT. Heb je naar aanleiding van deze blog vragen of hulp nodig om binnen jouw gemeente verder te komen op dit vlak, neem dan gerust contact met ons op.