Wat zijn de eisen aan software voor gemeenten vanuit de overheid?

Software voor gemeenten moet voldoen aan een combinatie van wettelijke verplichtingen, beveiligingsnormen en technische standaarden. De belangrijkste eisen komen voort uit de Baseline Informatiebeveiliging Overheid (BIO), de Algemene Verordening Gegevensbescherming (AVG), de Common Ground-beweging en de verplichte open standaarden van het Forum Standaardisatie. Gemeenten die software aanschaffen of laten bouwen, moeten al deze kaders meenemen in hun afwegingen. Dit artikel geeft je per vraag een helder antwoord.

Welke wettelijke eisen gelden er voor gemeentelijke software?

Gemeentelijke software moet voldoen aan meerdere wettelijke kaders tegelijk. De belangrijkste zijn de AVG voor gegevensbescherming, de BIO voor informatiebeveiliging, de Wet open overheid (Woo) voor transparantie en de Archiefwet voor bewaarplicht. Daarnaast gelden de verplichte open standaarden van het Forum Standaardisatie en de richtlijnen rondom aanbestedingen via de Aanbestedingswet.

Wat dit in de praktijk betekent: elke applicatie die persoonsgegevens verwerkt, moet aantoonbaar veilig zijn ingericht. Denk aan toegangsbeheer, logging, encryptie en verwerkersovereenkomsten. De Woo verplicht gemeenten bovendien om informatie actief openbaar te maken, wat eisen stelt aan de exporteerbaarheid en structuur van data in systemen. De Archiefwet schrijft voor hoe lang bepaalde documenten bewaard moeten worden en in welk formaat.

Dit is geen checklist die je eenmalig afwerkt. Wetgeving verandert, en software die vandaag compliant is, kan dat over twee jaar niet meer zijn als er geen actief beheer plaatsvindt.

Wat is de Baseline Informatiebeveiliging Overheid en wat betekent die voor software?

De Baseline Informatiebeveiliging Overheid (BIO) is het verplichte normenkader voor informatiebeveiliging bij alle overheidsorganisaties in Nederland, waaronder gemeenten. De BIO is gebaseerd op de internationale ISO 27001- en ISO 27002-standaarden en beschrijft welke beveiligingsmaatregelen een gemeente minimaal moet treffen voor haar systemen en data.

Voor software betekent dit concreet dat systemen moeten voldoen aan eisen rondom:

• Toegangsbeheer en authenticatie (wie mag wat zien en doen?)
• Logging en monitoring (wat gebeurt er in het systeem en wanneer?)
• Patchbeheer en kwetsbaarhedenbeheer (hoe snel worden beveiligingslekken gedicht?)
• Dataclassificatie (welke informatie is gevoelig en hoe wordt die behandeld?)
• Continuïteit en herstel (wat gebeurt er als een systeem uitvalt?)

Leveranciers van software aan gemeenten moeten kunnen aantonen dat hun product aan de BIO voldoet. Dat gebeurt via een zogenaamde ISAE 3402-verklaring, een TPM (Third Party Mededeling) of een DPIA gecombineerd met een beveiligingsaudit. Gemeenten mogen dit gewoon opvragen, en goede leveranciers leveren het proactief aan.

Hoe beïnvloedt de AVG de softwarekeuzes van gemeenten?

De AVG verplicht gemeenten om persoonsgegevens alleen te verwerken als daar een wettelijke grondslag voor is, en om die verwerking aantoonbaar veilig en transparant in te richten. Dit heeft directe gevolgen voor welke software een gemeente mag kiezen en hoe die software geconfigureerd moet worden.

In de praktijk betekent de AVG dat gemeenten bij elke softwareaanschaf een Data Protection Impact Assessment (DPIA) moeten uitvoeren als de software persoonsgegevens verwerkt. Dat is bij vrijwel alle gemeentelijke systemen het geval. Uit die DPIA volgen concrete eisen aan de software: waar worden gegevens opgeslagen, wie heeft toegang, hoe lang worden gegevens bewaard en hoe worden ze verwijderd?

Cloudoplossingen waarbij data buiten de EU wordt opgeslagen, zijn in veel gevallen problematisch. Gemeenten moeten kunnen garanderen dat persoonsgegevens niet zomaar bij derde partijen terechtkomen. Dit maakt de keuze voor leveranciers die data binnen de EU verwerken en een verwerkersovereenkomst kunnen tekenen, een harde eis, geen nice-to-have.

Wat is Common Ground en moeten gemeenten daaraan voldoen?

Common Ground is een beweging binnen de Nederlandse gemeentelijke overheid die streeft naar een andere manier van omgaan met data en applicaties. In plaats van data op te slaan in grote, monolithische systemen, pleit Common Ground voor het scheiden van data en applicaties via gestandaardiseerde API's. Gemeenten zijn niet wettelijk verplicht om aan Common Ground te voldoen, maar de beweging heeft brede steun van de VNG en wordt steeds meer de norm.

Wat Common Ground in de praktijk vraagt van software:

• Systemen communiceren via gestandaardiseerde API's, bij voorkeur op basis van de NL API Strategie
• Data wordt niet dubbel opgeslagen in meerdere systemen, maar centraal beheerd en gedeeld
• Applicaties zijn modulair opgebouwd zodat ze vervangbaar zijn zonder de hele infrastructuur te raken

Voor gemeenten die nu software aanschaffen of laten bouwen, is het verstandig om Common Ground-principes als uitgangspunt te nemen. Systemen die hier niet op aansluiten, worden op termijn moeilijk te integreren met andere gemeentelijke applicaties.

Welke open standaarden zijn verplicht voor overheidssoftware?

Het Forum Standaardisatie beheert de zogenaamde "pas toe of leg uit"-lijst met open standaarden die verplicht zijn voor overheidsorganisaties, waaronder gemeenten. Software die voor gemeenten wordt aangeschaft of ontwikkeld, moet deze standaarden ondersteunen, of de gemeente moet expliciet uitleggen waarom dat niet mogelijk is.

Enkele relevante verplichte standaarden zijn:

• HTTPS en HSTS voor veilige webcommunicatie
• DKIM, DMARC en SPF voor e-mailbeveiliging
• DigiD voor authenticatie van burgers
• SAML en OAuth voor identiteitsbeheer en autorisatie
• StUF en MIM voor gegevensuitwisseling binnen de overheid
• PDF/A voor archivering van documenten

De volledige lijst is te vinden op de website van het Forum Standaardisatie en wordt regelmatig bijgewerkt. Bij aanbestedingen is het gebruikelijk om naleving van deze standaarden als harde eis op te nemen in het programma van eisen.

Hoe toetst een gemeente of software aan alle eisen voldoet?

Een gemeente toetst software aan de geldende eisen door een gestructureerd inkoopproces te doorlopen waarbij de BIO, AVG, open standaarden en Common Ground-principes als toetsingskader dienen. Dit begint bij het opstellen van een programma van eisen en eindigt met een formele acceptatietest voor livegang.

Een praktische aanpak bestaat uit de volgende stappen:

1. Programma van eisen opstellen op basis van de geldende kaders
2. DPIA uitvoeren voordat de software wordt aangeschaft of gebouwd
3. Verwerkersovereenkomst afsluiten met de leverancier
4. Beveiligingsaudit of TPM opvragen bij de leverancier
5. Penetratietest laten uitvoeren op de applicatie voor livegang
6. Acceptatietest doorlopen waarbij alle functionele en technische eisen worden gevalideerd

Gemeenten die dit proces overslaan of inkorten, lopen het risico een systeem in gebruik te nemen dat niet compliant is. Dat levert niet alleen juridische risico's op, maar ook problemen bij audits van de Autoriteit Persoonsgegevens of de gemeentelijke rekenkamer.

Wat zijn de meest gemaakte fouten bij gemeentelijke softwaretrajecten?

De meest gemaakte fouten bij gemeentelijke softwaretrajecten zijn: te laat beginnen met compliance checks, onduidelijke eisen stellen aan leveranciers, te weinig aandacht voor beheer na livegang en het onderschatten van de integratiecomplexiteit met bestaande systemen.

Iets concreter uitgewerkt:

• Te laat beginnen met de DPIA. Een DPIA hoort aan het begin van het traject, niet vlak voor livegang. Als je er laat mee begint, loop je het risico dat je fundamentele ontwerpkeuzes moet herzien.
• Vage eisen in het programma van eisen. "De software moet veilig zijn" is geen eis. "De software moet voldoen aan BIO-niveau hoog en een geldige TPM overleggen" is dat wel.
• Te weinig aandacht voor beheer en updates. Software die op dag één compliant is, blijft dat niet vanzelf. Gemeenten moeten afspraken maken over patchbeleid, nieuwe versies en periodieke audits.
• Integraties worden onderschat. Gemeenten werken met tientallen systemen tegelijk. Nieuwe software die niet goed aansluit op bestaande systemen, zorgt voor handmatige workarounds en fouten in data.
• De werkvloer wordt niet betrokken. Software die technisch klopt maar niet aansluit op hoe mensen werken, wordt niet gebruikt. Draagvlak begint bij de mensen die er dagelijks mee werken.

Gemeenten die deze valkuilen kennen, kunnen ze ook vermijden. Het vraagt om een gestructureerde aanpak waarbij compliance, techniek en organisatie vanaf het begin samen optrekken. Corver Development ondersteunt gemeenten hierin van analyse tot werkende software die écht aansluit op de organisatie.

Benieuwd wat wij voor jouw organisatie kunnen betekenen? Bekijk onze diensten en ontdek hoe wij samenwerken.