Software laten ontwikkelen voor gemeenten: waar moet je aan voldoen?.
Gemeenten stellen hoge eisen aan software: toegankelijkheid, privacy, security en interoperabiliteit. Wat zijn de vereisten en hoe bouw je software die daaraan voldoet?
Software voor de overheid is een ander speelveld
Als een gemeente software laat bouwen, gelden er andere regels dan voor een commercieel bedrijf. Niet omdat gemeenten moeilijk doen, maar omdat ze een publieke verantwoordelijkheid hebben. Ze verwerken gevoelige burgerdata, moeten toegankelijk zijn voor iedereen en worden gecontroleerd door toezichthouders.
Dat betekent dat je als softwareleverancier aan strengere eisen moet voldoen. In dit artikel zet ik de belangrijkste vereisten op een rij.
Digitale toegankelijkheid (WCAG)
Gemeenten zijn wettelijk verplicht om hun digitale diensten toegankelijk te maken voor iedereen — inclusief mensen met een visuele, auditieve, motorische of cognitieve beperking. De standaard hiervoor is WCAG 2.1, niveau AA.
In de praktijk betekent dat:
- Semantische HTML — Correcte heading-structuur, labels bij formuliervelden, alt-teksten bij afbeeldingen.
- Toetsenbordnavigatie — Alles moet bereikbaar zijn zonder muis. Tab-volgorde, focus-indicatoren, skip-links.
- Kleurcontrast — Voldoende contrast tussen tekst en achtergrond. Minimaal 4,5:1 voor normale tekst.
- Screenreader-compatibiliteit — ARIA-labels, live regions, correcte rollen en states.
- Responsief design — Werken op alle schermformaten, inclusief vergrote weergave tot 200%.
Lees het uitgebreide artikel over digitale toegankelijkheid voor de volledige checklist.
AVG / GDPR compliance
Gemeenten verwerken persoonsgegevens van burgers: namen, adressen, BSN-nummers, inkomensgegevens, zorgdata. De AVG stelt strenge eisen aan hoe die data wordt verwerkt en beschermd:
- Verwerkersovereenkomst — Als leverancier ben je verwerker. Er moet een verwerkersovereenkomst zijn die precies beschrijft welke data je verwerkt, hoe, en voor hoe lang.
- Data minimalisatie — Alleen de data verzamelen die strikt noodzakelijk is voor het doel.
- Recht op inzage en verwijdering — Burgers moeten hun data kunnen inzien en laten verwijderen. De software moet dat ondersteunen.
- Dataportabiliteit — Data moet in een gangbaar formaat geëxporteerd kunnen worden.
- Privacy by design — Privacy is geen checkbox achteraf, maar een ontwerpprincipe dat vanaf het begin wordt meegenomen.
- DPIA — Voor verwerkingen met hoog risico moet een Data Protection Impact Assessment worden uitgevoerd.
Informatiebeveiliging (BIO)
Gemeenten vallen onder de Baseline Informatiebeveiliging Overheid (BIO). Dit is het normenkader voor informatiebeveiliging bij de overheid, gebaseerd op ISO 27001. De BIO stelt eisen aan:
- Toegangsbeheer — Wie heeft toegang tot welke data? Role-based access control, multi-factor authenticatie, audit logging.
- Encryptie — Data versleuteld opslaan en transporteren. TLS voor communicatie, encryptie-at-rest voor gevoelige data.
- Logging en monitoring — Alle toegang tot gevoelige data loggen. Afwijkingen detecteren en rapporteren.
- Penetratietests — Periodieke pentests door een onafhankelijke partij om kwetsbaarheden te identificeren.
- Incidentrespons — Een procedure voor het afhandelen van beveiligingsincidenten, inclusief meldplicht bij de Autoriteit Persoonsgegevens.
Standaarden en interoperabiliteit
Gemeentelijke software moet samenwerken met andere overheidssystemen. Dat betekent dat je je moet houden aan standaarden:
- StUF en ZGW-API's — Standaard Uitwisselingsformaat voor communicatie tussen gemeentelijke systemen. Steeds meer wordt vervangen door ZGW (Zaakgericht Werken) API's.
- DigiD-koppeling — Als burgers inloggen, moet dat via DigiD. Dat vereist een SAML-integratie en certificering door Logius.
- Open standaarden — De overheid hanteert het "pas-toe-of-leg-uit" principe voor open standaarden. JSON, REST, OAuth2, OpenAPI zijn de norm.
- Gemeentelijk Gegevensmodel (RSGB/RGBZ) — Datamodellen die beschrijven hoe gemeentelijke gegevens gestructureerd zijn.
Inkoop en aanbesteding
Afhankelijk van de omvang van het project kan een aanbestedingsprocedure verplicht zijn. Dat heeft gevolgen voor hoe je als leverancier in beeld komt:
- Onder de drempel — Voor projecten onder de Europese aanbestedingsdrempel kan de gemeente meervoudig onderhands aanbesteden. Dat is een eenvoudiger proces.
- Boven de drempel — Boven de drempel is een openbare of niet-openbare aanbesteding verplicht. Dat is een formeel proces met vaste regels.
- GIBIT — Gemeentelijke Inkoopvoorwaarden bij IT. De standaardvoorwaarden die gemeenten hanteren voor IT-inkoop.
Hoe ik hiermee omga
Ik heb ervaring met het bouwen van software die aan overheidseisen voldoet. Concreet betekent dat:
- WCAG AA als standaard — Toegankelijkheid is geen nice-to-have, het is een eis. Ik bouw het in vanaf het begin.
- Privacy by design — Data minimalisatie, versleuteling, inzage- en verwijdermogelijkheden zijn onderdeel van de architectuur.
- Security-first — Input validatie, output encoding, parameterized queries, CSRF-bescherming, secure headers. De OWASP Top 10 is mijn checklist.
- Documentatie — Technische documentatie, API-specificaties en deployment-instructies zodat de gemeente niet afhankelijk is van één leverancier.
- Open source waar mogelijk — Ik gebruik open-source technologieën en lever broncode op, zodat er geen vendor lock-in ontstaat.
Software voor gemeenten bouwen is niet moeilijker dan commerciële software. Het vereist alleen meer discipline op het gebied van toegankelijkheid, privacy en security.
Wil je meer weten?
Ben je een gemeente of overheidsinstelling die maatwerk software wil laten bouwen? Ik help je graag met een inventarisatie van de eisen en een voorstel dat daaraan voldoet. Neem contact op voor een vrijblijvend gesprek.
/Gerelateerde artikelen
AVG / GDPR voor webapplicaties
Wat moet je regelen om AVG-compliant te zijn?
Digitale toegankelijkheid (WCAG)
Waarom je software toegankelijk moet zijn en wat de EU-wetgeving betekent.
Veiligheid en pentests
Hoe wij security inbouwen en waarom onze software pentests doorstaat.