Wet openbaarheid bestuur software
Begin direct met het invoeren van een capacitatiemodel voor alle medewerkers die met publieke informatieverzoeken werken. Dit model moet drie niveaus kennen: basiskennis van de procedure, specialistische vaardigheden voor complexe zaken, en juridische verdieping voor bezwaar- en beroepsprocedures. Gemeenten die dit implementeren zien hun behandeltermijnen gemiddeld met 40% dalen, terwijl de noodzaak voor juridische vervolgstappen aanzienlijk afneemt.
De kern van effectieve naleving ligt in het standaardiseren van uw informatiehuishouding. Implementeer een metadata-standaard conform ISO 15489 en zorg dat elk document bij de creatie al wordt voorzien van de juiste categorieën voor openbaarheid, vertrouwelijkheid en bewaartermijn. Dit voorkomt dat uw organisatie achteraf moet reconstructeren waarom bepaalde stukken al dan niet gedeeld mogen worden. Automatiseer dit proces tot op het niveau van documentmanagementsystemen en voeg validatieregels toe die onvolledige metadata blokkeren.
Investeer in een aparte portaalomgeving voor externe informatieverzoeken, los van uw reguliere website. Maak hierbij gebruik van een gestructureerd webformulier dat verzoekers leidt door de relevante beleidsterreinen. Voeg een zoekfunctie toe die actieve publicaties ontsluit, zoals vergunningen, raadsvoorstellen en onderzoeksrapporten. De ervaring leert dat 60% van de verzoeken hiermee wordt opgelost zonder dat er een formeel traject nodig is. Koppel dit portaal aan een zaaksysteem dat automatische bevestigingen, termijnbewaking en geanonimiseerde publicatie van besluiten genereert.
Stel een vaste adviescommissie in die fungeert als interne toetsingsinstantie voor weigeringsgronden. Deze commissie, bestaande uit juridisch specialisten en domeindeskundigen, beoordeelt binnen vijf werkdagen of uitzonderingsgronden terecht zijn ingeroepen. De commissie legt haar oordeel vast in een openbaar register, niet alleen voor de betreffende aanvraag, maar ook als leidraad voor toekomstige vergelijkbare situaties. Dit vermindert de kans op willekeur en inconsistentie, en vormt een sterke positie richting bezwaarprocedures.
Technische specificaties van WOB-software: welke datavelden zijn verplicht voor ontsluiting?
Implementeer minimaal de volgende metadata-velden als verplichte kern bij elke publicatie: uniek documentnummer (UUID), datum van indiening, type verzoek (originel of vervolg), behandelende afdeling (afdelingscode conform COA), en de wettelijke beslistermijn (vervaldatum). Zonder deze vijf velden is een zaak niet rechtsgeldig te ontsluiten via een API. Voeg daarnaast een verplicht veld 'vertrouwelijkheidsniveau' toe (waarde: openbaar, beperkt, of intern), omdat dit direct de zichtbaarheid in het portaal stuurt. Een veelgemaakte fout is het vrijgeven van volledige e-mailthreads zonder het veld 'correspondentiepartij' in te vullen; dit breekt de link met het originele verzoek.
Voor de feitelijke inhoudspecificatie is het verplicht om drie datavelden te onderscheiden: 'documenttype' (bijv. advies, besluit, notitie), 'documentstatus' (definitief, concept, gearchiveerd) en 'relatiecode' (koppeling aan het moederdossier). Deze drie velden moeten voldoen aan de TMLO-standaard (Toegankelijk Metadata Model voor Overheden) versie 2.1. Let op: bij het exporteren naar CSV of JSON dient elke waarde een unieke URI te hebben volgens het BAG-patroon; anders faalt de validatie tegen de nationale API-specificatie. Tevens is het datavelden 'bewaartermijn' (in jaren, berekend vanaf de dag van afhandeling) technisch verplicht om automatische vernietiging in het DMS te triggeren. Vergeet niet dat een lege waarde in het veld 'openbaarmakingsgrondslag' (artikel 5.1, 5.2 of 5.4) een automatische afwijzing genereert in de validatiemodule van de gemeentelijke index.
De praktische implementatie vereist dat verplichte velden niet alleen in het scherm, maar ook in de exportlaag van het zaaksysteem worden afgedwongen; een backend-validatie die alleen front-end controleert, levert datalekken op. Gebruik voor de velddefinitie een JSON-schema met 'required' en 'additionalProperties: false' in de uploadendpoint. Specifiek voor persoonsgegevens is het veld 'betrokkene_ID' (pseudoniem volgens de AVG-richtlijn) verplicht bij elk verzoek dat natuurlijke personen betreft; anders blokkeert de routeringsservice de publicatie. Tenslotte: het veld 'link naar originele verzoektekst' (URL of UUID) is juridisch verplicht bij vervolgverzoeken; het ontbreken hiervan maakt de ontsluiting onvolledig en herroepbaar.
Stappenplan voor het implementeren van WOB-software binnen een gemeentelijke organisatie
Begin met een nulmeting van alle huidige informatieverzoeken: categoriseer ze naar type (verzoek om documenten, databanken, of gemengd) en meet de gemiddelde doorlooptijd per afdeling. Dit levert een concrete basislijn op, bijvoorbeeld dat 60% van de verzoeken juridisch getoetst moet worden binnen drie weken. Zet deze cijfers om in een KPI-dashboard, want zonder meetbare startdata is elke vervolgstap natte vingerwerk.
Stel een projectteam samen dat niet alleen uit juristen en ICT'ers bestaat, maar ook uit een archivaris, een communicatieadviseur en een medewerker van de frontoffice. Dit team inventariseert vervolgens welke informatiesystemen (zaaksystemen, DMS, e-mailarchieven) daadwerkelijk gescheiden moeten worden gezocht. Uit de praktijk blijkt dat gemeenten gemiddeld 5 tot 7 databronnen hebben die relevant zijn, waarbij verouderde netwerkschijven de grootste risicofactor vormen.
Kies voor een oplossing die werkt met open standaarden zoals CMIS of OData, en eis dat de leverancier een proof-of-concept levert op minimaal drie afdelingen met afwijkende workflows. Test daarbij specifiek op de zoekfunctionaliteit voor metadata zoals afzender, datum en type document, want een volle-tekstzoektocht alleen schiet tekort bij handgeschreven notulen of gedigitaliseerde PDF's. Laat je niet verleiden door mooie demopraatjes; een korte test met échte raadsvoorstellen weegt zwaarder dan een uitgebreide presentatie.
Richt een helder autorisatieprotocol op: Bepaal per rol (behandelaar, teamleider, bestuurder) welke metadata zichtbaar mag zijn en welke documenten definitief uit de zoekresultaten gefilterd worden. Implementeer dit technisch afdwingbaar in het systeem, niet alleen als gedragscode. Gemeenten die dit overslaan, lopen direct tegen bezwaren aan van burgers die via een verzoek specifieke vertrouwelijke bijlagen opvragen.
Train het personeel niet alleen op de Nederlandse interface, maar vooral op het herkennen van uitzonderingen zoals persoonlijke beleidsopvattingen en onevenredige benadeling. Gebruik hiervoor casuïstiek uit de eigen organisatie, bijvoorbeeld van een recente aanvraag over milieurapportages. Een kort e-learningmodule van twee uur, gevolgd door een praktijksimulatie met foutenevaluatie, blijkt effectiever dan een dagvullende workshop.
Implementeer een vaste handlingprocedure voor verzoeken die binnenkomen via het contactformulier, post én e-mail. Zorg dat het systeem automatisch een ontvangstbevestiging genereert met zaaknummer en een verwachte beslisdatum. Plan daarnaast een wekelijkse controle in op onvolledige aanvragen; dit voorkomt dat de wettelijke termijn van 14 dagen (met mogelijke verlenging tot 28 dagen) onbedoeld overschreden wordt. Log elke handeling, zodat achteraf gecontroleerd kan worden wie welke actie uitgevoerd heeft.
Draai parallel aan de livegang een pilot van zes weken op één afdeling, bijvoorbeeld Burgerzaken, en vergelijk de doorlooptijd en het aantal juridische bezwaren met het voorgaande halfjaar. Pas eventuele kinderziektes aan voordat je opschaalt naar alle diensten. Meet hierbij niet alleen snelheid, maar ook de consistentie van beoordelingen; het systeem mag geen willekeurige verschillen tussen behandelaars introduceren.
Plan na de uitrol een formele evaluatie na drie maanden met een externe auditor. Laat deze specifiek onderzoeken of het systeem voldoet aan de artikelen 3 en 4 van de Algemene verordening gegevensbescherming, aangezien oneigenlijke toegang tot persoonsgegevens bij dit type toepassingen een reëel risico vormt. Stel een halfjaarlijkse rapportage verplicht voor het college, met concrete cijfers over zoekacties, geweigerde documenten en behandeltermijnen per afdelingshoofd.
Veelgestelde vragen:
Wat is de Wet openbaarheid bestuur software precies en waarom zou een gemiddelde inwoner zich daar druk om maken?
De Wet openbaarheid bestuur software (Wobbe, of beter: de Wet open overheid, WOO, die de Wob opvolgde) verplicht overheidsorganen om documenten en informatie actief of op verzoek openbaar te maken. Wanneer het over software gaat, betekent dit dat broncode, algoritmes en datamodellen die de overheid gebruikt voor publieke taken – bijvoorbeeld een systeem dat uitkeringen berekent of een algoritme dat prioriteert bij woningtoewijzing – onder het regime van openbaarheid kunnen vallen. Voor een inwoner is dit belangrijk omdat beslissingen die uw leven raken steeds vaker door of met behulp van software worden genomen. Als u de broncode niet kunt inzien, kunt u niet controleren of er sprake is van vooringenomenheid, fouten of onrechtmatige uitsluiting. De wet dwingt de overheid om niet alleen het eindbesluit, maar ook de onderliggende logica te delen, tenzij er zwaarwegende belangen zijn zoals privacy van derden of bedrijfsgevoelige informatie. Simpel gezegd: het is uw juridische sleutel tot het begrijpen van de "black box" die mede over uw lot beslist.
Ik ben een ICT-leverancier die software aan gemeenten verkoopt. Moet ik nu mijn broncode afstaan als een burger daarom vraagt? En wat betekent dat voor mijn intellectueel eigendom?
De vraag of u broncode moet afstaan hangt af van de constructie. De WOO richt zich primair op het bestuursorgaan, niet op u als leverancier. Een gemeente moet beoordelen of een verzoek om openbaarmaking van software betrekking heeft op een "document" in de zin van de wet. Als de broncode in een document staat of als het systeem als onderdeel van een besluitvormingsproces wordt gebruikt, kan de gemeente verplicht zijn om die openbaar te maken. Maar er zijn uitzonderingen: artikel 5.1, tweede lid, onder i, van de WOO beschermt bedrijfs- en fabricagegegevens die vertrouwelijk aan de overheid zijn meegedeeld. In de praktijk betekent dit dat de gemeente een belangenafweging moet maken: het algemeen belang van transparantie tegen uw commerciële belang. Wat u kunt doen: beding in uw contract dat u de gemeente mag bijstaan bij het beoordelen van verzoeken en dat u vertrouwelijkheid kunt claimen op delen van de code die uw unieke algoritmes bevatten. U moet niet de volledige broncode afstaan, maar vaak volstaat een toelichtende beschrijving of een geanonimiseerde versie. Van belang is dat u zich tijdig meldt bij de gemeente zodra een verzoek binnenkomt, anders riskeert u dat de gemeente zonder uw inbreng een beslissing neemt die uw eigendomsrechten schaadt.
Kunt u een concreet voorbeeld geven van hoe een burger met succes openbaarmaking van een software-onderdeel heeft afgedwongen? En wat was de uitspraak?
Een bekend voorbeeld is de zaak rond het "SyRI-systeem" (Systeem Risico Indicatie) dat gebruikt werd om fraude in de sociale zekerheid op te sporen. In 2020 oordeelde de rechtbank Den Haag dat het systeem in strijd was met artikel 8 van het Europees Verdrag voor de Rechten van de Mens, omdat er onvoldoende transparantie was over de werking ervan. Burgers en belangengroepen hadden al jaren gevraagd om openbaarmaking van de onderliggende modellen en dataprocessen, maar die werd geweigerd op grond van onder meer de inlichtingen- en veiligheidsbelangen. De rechter bepaalde dat de inzet van zo'n systeem voorafgaande wetgeving en publieke controle vereiste. Na de uitspraak werd het systeem stilgelegd. Er volgden later meerdere WOO-verzoeken die gedeeltelijk werden toegewezen, maar de kern is: u kunt niet alleen documenten opeisen, u kunt ook de rechtmatigheid van het gebruik van de software zelf aanvechten. De rechterlijke toetsing dwingt de overheid om uit te leggen welke gegevens zij gebruikt en waarom. Dat is een indirecte manier om software-openbaarheid te bereiken: via de rechtszaal.
Wat is het verschil tussen actieve openbaarmaking en een verzoek om openbaarmaking van software? Moet de overheid nu zelf alle code op internet zetten?
Actieve openbaarmaking betekent dat de overheid uit eigen beweging informatie publiceert, zonder dat iemand erom vraagt. Bij software geldt dit voor sommige categorieën, zoals algoritmes die worden gebruikt voor rechtspositionele beslissingen (bijvoorbeeld belastingaanslagen). De wetgever heeft in de WOO bepaald dat bepaalde documenten "bij koninklijk besluit" verplicht actief openbaar moeten worden gemaakt. Voor software is dat nog niet breed uitgewerkt; het is meer een ontwikkeling die via jurisprudentie en beleid groeit. Een verzoek om openbaarmaking is gericht op concrete documenten – denk aan een Word-bestand met de functionele specificatie, een PDF van een auditrapport of een Excel-sheet met de datacategorieën. De overheid hoeft niet de hele codebase actief te publiceren, maar wel te reageren op individuele verzoeken. In de praktijk wordt er vaak een "open source" pad gekozen: gemeenten zoals Amsterdam en Utrecht publiceren delen van hun software op GitHub, niet zozeer omdat de wet dat eist, maar omdat het de controleerbaarheid vergroot en de kosten van onderhoud verlaagt. Dus: actief is eerder uitzondering, reactief is de regel. Maar de trend is dat er steeds meer wordt verwacht dat code van publieke systemen als open source beschikbaar komt, tenzij er een actieve weigeringsgrond is.
Wanneer mag een overheidsorgaan een verzoek om openbaarmaking van software weigeren? Welke uitzonderingen zijn er en hoe kan ik als burger daar tegen procederen?
De WOO kent absolute en relatieve uitzonderingsgronden. Absoluut zijn bijvoorbeeld de persoonlijke beleidsopvattingen in documenten (die zijn niet openbaar tenzij het om milieugegevens gaat). Relatief zijn: de veiligheid van de staat, bedrijfs- en fabricagegegevens, de eerbiediging van de persoonlijke levenssfeer, en het goed functioneren van het bestuur. Bij software zijn de meest gebruikte weigeringen: (1) bedrijfsgevoelige informatie omdat de code commercieel exploitabel is, (2) privacy omdat de software persoonsgegevens verwerkt, en (3) de goede werking van de overheid omdat openbaarmaking van kwetsbaarheden in de code misbruik mogelijk zou maken (bijvoorbeeld bij beveiligingssoftware). Belangrijk is dat deze gronden niet automatisch van toepassing zijn; het bestuursorgaan moet per document toetsen of openbaarmaking echt in verhouding staat tot het doel van de uitzondering. U kunt tegen een weigering bezwaar maken bij het orgaan zelf, daarna beroep instellen bij de rechtbank, en in hoger beroep bij de Afdeling bestuursrechtspraak van de Raad van State. De rechter toetst of de weigering zorgvuldig is gemotiveerd. In de praktijk wint u vaak als de overheid niet specifiek kan uitleggen waarom een bepaalde regel of functie in de code nu precies geheim moet blijven – een algemene verwijzing naar "risico's" is onvoldoende. Verzamel daarom uw argumenten op basis van concrete passages in de documenten, en vraag om een deskundigenoordeel als de overheid zegt dat openbaarmaking "de veiligheid zou schaden". U kunt ook een klacht indienen bij de Nationale ombudsman als overheid traag reageert.
