applatenmaken.com/kennisbank/verantwoordelijkheid
Wie is bij u verantwoordelijk voor de software?
De vraag wie er binnen uw organisatie verantwoordelijk is voor de software, levert vaak een aarzelend antwoord op. IT beheert het, een afdeling gebruikt het, de directie tekende ooit het contract. Sinds de Cyberbeveiligingswet in werking trad, is dat geen organisatorische onduidelijkheid meer maar een bestuurlijk risico. Deze pagina gaat over hoe u het belegt zonder er een reorganisatie van te maken.
Waarom dit sinds deze zomer anders ligt
Beroepsorganisaties waarschuwden deze maand dat bestuurders onvoldoende grip hebben op hun digitale omgeving, juist nu er nieuwe verplichtingen bij komen. Dat is op zichzelf geen nieuw geluid, maar de context is veranderd.
Onder de Cyberbeveiligingswet, van kracht sinds 15 augustus 2026, ligt de zorgplicht bij de organisatie en is het bestuur daarop aanspreekbaar. Dat betekent dat de vraag wie er verantwoordelijk is voor de beveiliging van uw systemen niet meer intern kan blijven zweven: er is een partij die aangesproken wordt, en dat is niet de leverancier.
Het lastige is dat verantwoordelijkheid voor software zich moeilijk in één functie laat vangen. Wie het gebruikt, weet wat het moet doen. Wie het beheert, weet wat het is. Wie erover beslist, weet wat het kost. Zolang die drie niet met elkaar praten, is er niemand die het geheel overziet, en precies dat is wat er in de waarschuwing wordt bedoeld.
- Wat er veranderd is
- De zorgplicht uit de Cyberbeveiligingswet ligt bij de organisatie, en het bestuur is daarop aanspreekbaar.
- Wat vaak ontbreekt
- Eén persoon die het geheel overziet in plaats van drie die elk een deel kennen.
- Wat het niet vraagt
- Een nieuwe functie of een reorganisatie.
- Wat het wel vraagt
- Dat is vastgelegd wie waarover beslist, en dat die persoon de informatie krijgt om dat te kunnen.
De drie rollen die u nodig heeft
In vrijwel elke organisatie die software laat bouwen, zijn dit de rollen die belegd moeten zijn. Ze hoeven niet drie verschillende personen te zijn; in een kleine organisatie kan één iemand er twee doen. Wat niet werkt, is als er nul zijn.
| Rol | Waar die over gaat | Waar u op let |
|---|---|---|
| Eigenaar van het systeem | ✓Wat de software moet doen, welke wijzigingen prioriteit krijgen, wat het mag kosten | !Dat het iemand uit de business is en niet uit IT; anders stuurt de techniek de behoefte |
| Beheerder | ✓Dat het draait, dat updates gebeuren, dat toegang klopt | !Dat er een vervanger is; deze rol is bij uitstek kwetsbaar voor één persoon |
| Bestuurlijk verantwoordelijke | ✓De afweging over risico's, en de verantwoording daarover | !Dat die persoon periodiek informatie krijgt en niet alleen bij incidenten hoort |
| Leverancier | !Bouwen, onderhouden, adviseren | !Dat hij geen van de drie bovenstaande rollen invult, hoe verleidelijk dat ook is |
De laatste regel is de belangrijkste. Een goede leverancier denkt mee en signaleert, maar hij kan niet uw eigenaar zijn: hij weet niet wat uw organisatie belangrijk vindt en heeft een ander belang bij de afweging. Welke rollen u aan uw eigen kant nodig heeft bij een bouwtraject, staat in wie heeft u nodig aan uw eigen kant.
Wat de bestuurlijk verantwoordelijke moet weten
De klacht dat bestuurders geen grip hebben, is meestal geen kwestie van onwil maar van informatie die niet doorkomt. Onderstaande punten zijn wat er minstens één keer per jaar op tafel moet liggen, in gewone taal en op één of twee pagina's.
De laatste twee vragen leveren de meeste ongemakkelijke stiltes op, en zijn daarom het nuttigst om te stellen.
Het doel van die lijst is niet om iemand te betrappen maar om de afweging expliciet te maken. Een organisatie mag besluiten dat een verouderd systeem nog een jaar mee moet omdat vervangen te duur is. Wat niet mag, is dat niemand dat besluit heeft genomen en het gewoon zo is gegroeid.
Hoe u het belegt zonder reorganisatie
De praktische invulling is kleiner dan het onderwerp doet vermoeden. Wijs per bedrijfskritisch systeem één eigenaar aan en schrijf zijn naam op. Dat alleen al lost het merendeel van de onduidelijkheid op, omdat er vanaf dat moment iemand is aan wie de vraag gesteld kan worden.
Zet daarnaast één keer per jaar een vast agendapunt op de bestuursagenda met de vragen hierboven. Niet als project maar als terugkerend punt van een half uur. De waarde zit niet in het overleg maar in de voorbereiding: iemand moet die antwoorden opzoeken, en daarbij komen de gaten vanzelf naar boven.
Leg tot slot vast waar de kennis staat. Niet in de hoofden van twee mensen, maar op een plek die een opvolger kan vinden: welke systemen er zijn, wie ze levert, waar de contracten staan en wat er ooit bewust anders is gedaan. Dat is dezelfde documentatie die u nodig heeft bij een leverancierswissel, zoals beschreven in software in beheer nemen, en bij het uitfaseren van iets ouds, zie een oud systeem uitfaseren.
Of en hoe de bestuurlijke aansprakelijkheid in uw situatie precies uitpakt, is een juridische vraag. Leg die voor aan een jurist. Deze pagina is uitleg en geen juridisch advies.
Veelgestelde vragen
Wie hoort er binnen een organisatie verantwoordelijk te zijn voor software?
Er zijn drie rollen nodig: een eigenaar uit de business die bepaalt wat het systeem moet doen en wat prioriteit krijgt, een beheerder die zorgt dat het draait en dat toegang klopt, en een bestuurlijk verantwoordelijke die de risicoafweging maakt en zich daarover verantwoordt. In een kleine organisatie kan één persoon er twee doen; nul is het probleem.
Waarom is dit sinds augustus 2026 belangrijker geworden?
Omdat de Cyberbeveiligingswet, van kracht sinds 15 augustus 2026, de zorgplicht bij de organisatie legt en het bestuur daarop aanspreekbaar maakt. De vraag wie verantwoordelijk is, kan daardoor niet meer intern blijven zweven. Beroepsorganisaties waarschuwden deze maand dat veel bestuurders die grip nog missen.
Kan mijn softwareleverancier die verantwoordelijkheid niet dragen?
Nee, en dat is verleidelijker dan het klinkt. Een goede leverancier denkt mee, signaleert en adviseert, maar hij weet niet wat uw organisatie belangrijk vindt en heeft een ander belang bij de afweging. Hem tot eigenaar maken betekent in de praktijk dat de techniek bepaalt wat er gebouwd wordt.
Moeten we hier een nieuwe functie voor creëren?
Meestal niet. Voor de meeste organisaties volstaat het om per bedrijfskritisch systeem één eigenaar aan te wijzen en die naam op te schrijven, plus een vast jaarlijks agendapunt op bestuursniveau. Dat is een uur werk en het lost het grootste deel van de onduidelijkheid op.
Wat moet er minstens één keer per jaar op tafel liggen?
Welke systemen bedrijfskritisch zijn, wie ze levert en wat er gebeurt als die wegvalt, welke persoonsgegevens waar staan en wie erbij kan, of u onder de Cyberbeveiligingswet valt, wat het langst openstaande beveiligingsprobleem is, wanneer er voor het laatst een back-up is teruggezet en welke systemen geen updates meer krijgen.
Wat als een verouderd systeem nog jaren mee moet?
Dat mag, mits het een besluit is en geen situatie die zo is gegroeid. Een organisatie kan verantwoord kiezen om vervanging uit te stellen omdat het te duur of te ingrijpend is. Het verschil met nalatigheid zit erin dat iemand die afweging heeft gemaakt, hem heeft vastgelegd en er periodiek op terugkomt.
Hoe voorkom ik dat kennis bij één persoon zit?
Door vast te leggen waar de kennis staat in plaats van bij wie: welke systemen er zijn, wie ze levert, waar de contracten staan en wat er ooit bewust anders is gedaan. Dat is dezelfde documentatie die u nodig heeft bij een leverancierswissel, dus het is werk dat u sowieso een keer moet doen.
Is de beheerder niet gewoon de verantwoordelijke?
De beheerder houdt het draaiend, maar hij bepaalt niet wat het systeem moet doen en hij maakt niet de afweging of een risico aanvaardbaar is. Die twee rollen bij de beheerder leggen betekent in de praktijk dat de technische mogelijkheid de behoefte gaat sturen, en dat er niemand is die kan besluiten om iets niet te doen.