Overslaan en naar de inhoud gaan
(advertentie)

Oude IT-besluiten liggen onder nieuw vergrootglas

autonomie
- Shutterstock

De afgelopen week ontstond plots veel aandacht voor de rol van Amerikaanse technologie in de Nederlandse overheid. De Volkskrant berichtte dat het btw-systeem van de Belastingdienst is uitbesteed aan een Amerikaanse leverancier. NRC schreef over de betrokkenheid van het Amerikaanse Kyndryl bij de vernieuwing van de IT-infrastructuur van Defensie. 

Tegelijkertijd wordt op lokaal niveau gewerkt aan een nieuw raamcontract met Microsoft voor gemeenten, vooruitlopend op het aflopen van het huidige contract in 2027.

Geen nieuwe ontwikkelingen

Opvallend is dat veel van de genoemde ontwikkelingen helemaal niet nieuw zijn. De aanbesteding voor het btw-systeem begon bijvoorbeeld al in 2020 en leidde in 2025 tot een contract. Het defensietraject waarin Kyndryl een rol speelt, loopt sinds 2021.

Waar dergelijke trajecten eerder vooral werden beoordeeld op uitvoerbaarheid en het kostenplaatje, verschuift de aandacht nu steeds meer naar digitale afhankelijkheid en (gebrek aan) controle. Amerikaanse leveranciers waren destijds een logische uitkomst van aanbestedingen gericht op schaal en stabiliteit, maar inmiddels worden die keuzes anders bekeken.

Het lijkt dan ook aannemelijk dat meer van dit soort besluiten opnieuw tegen het licht zullen worden gehouden, want velen zijn nog niet eens geïnventariseerd. Zo vertelde een beleidsmedewerker van CIO Rijk in een interview met iBestuur over licentiemanagement dat de overheid onvoldoende zicht heeft op haar eigen digitale fundament. Met de dreigingen die destijds speelden, moest je volgens hem ‘met één klik op de knop alle componenten’ van bepaalde technologie kunnen vinden.

En juist dat cruciale overzicht ontbreekt grotendeels bij de overheid. Software- en hardwarelicenties zijn volgens hem in de afgelopen jaren niet langer alleen een kostenkwestie, maar een veiligheidsvraagstuk geworden. Het probleem was volgens hem dat er niet genoeg capaciteit is om dit allemaal inzichtelijk te krijgen.

Meer besluiten onder de loep

Toch zijn er inmiddels ook wel wat stappen ondernomen. Een jaar na dat interview liet de rijksoverheid onderzoeken hoeveel wordt uitgegeven aan licenties van grote technologiebedrijven zoals Microsoft, Oracle en SAP, na zorgen in de Tweede Kamer over afhankelijkheid en vendor lock-ins. Het onderzoek is echter nog altijd niet afgerond. Het is goed denkbaar dat in de komende periode nog veel meer projecten, contracten en licentieafspraken met grote internationale leveranciers opnieuw onder de loep komen omdat de vragen eromheen zijn veranderd.

Plaats een reactie

U moet ingelogd zijn om een reactie te kunnen plaatsen.

Vincent Hoek | 2 maart 2026, 16:40

Wel meteen een mooi moment voor wat gewetensvragen, want het heeft ook best wat centjes gekost om die grote partijen te licenseren. Oppassen voor emotie en knee jerk reacties dus, want niets is moeilijk voor degenen die het niet zelf hoeven te doen.
Welke applicaties en platformen worden eigenlijk als legacy geclassificeerd en op basis van welke criteria (leeftijd, ondersteuningsstatus, technische schuld)? Wie is de functioneel eigenaar en wie is de technisch beheerder van elk geïdentificeerd systeem? Is er een actueel applicatieportfolio met lifecycle-status per component (actief, uitfasering, end-of-life)? Wie is binnen de organisatie formeel verantwoordelijk voor de data die in elk legacy-systeem wordt voortgebracht, verwerkt en opgeslagen? Is de datavoortbrengingsketen per systeem gedocumenteerd: van bron, via verwerking, tot consumptie en archivering? Best handig, ook qua blast range beperking/digital footprint bepaling. Zijn er data-eigenaren aangewezen conform een vastgesteld governance-framework en hoe is de accountability eigenlijk geformaliseerd? Welke datakwaliteitsafspraken (SLA's, KPI's) bestaan er voor data die uit legacy-systemen wordt ontsloten? Welke interfaces, koppelingen en datastromen bestaan er tussen legacy-systemen onderling en met moderne platformen? Zijn er single points of failure geïdentificeerd in de huidige afhankelijkheidsketens? Welke middleware, ETL-processen of integratielagen zijn eigenlijk noodzakelijk om al die legacy-systemen operationeel te houden? Je wilt niet het onderste blikje uit de stapel trekken. Dus in hoeverre zijn er ongedocumenteerde afhankelijkheden (shadow IT, scripts, handmatige processen)? Welke leverancierscontracten zijn er dan echt gekoppeld aan legacy-systemen en wat zijn de opzegtermijnen en lock-in bepalingen?Is er vendor lock-in op data-formaten, API's of propriëtaire technologie? Wie draagt de verantwoordelijkheid, wanneer een leverancier end-of-support aankondigt? Voldoen die legacy-systemen aan de actuele BIO-, AVG/GDPR- en sectorale compliancevereisten? Is er een DPIA (Data Protection Impact Assessment) uitgevoerd voor systemen die persoonsgegevens verwerken? Wat is het risicoprofiel per legacy-systeem in termen van beschikbaarheid, integriteit en vertrouwelijkheid? Is de operationele kennis over legacy-systemen geborgd, of berust deze bij een beperkt aantal individuen en bestaat er al een exitstrategie of migratiepad per systeem? Is contractueel vastgelegd dat de inhurende organisatie eigenaar blijft van alle data, metadata en afgeleide inzichten? Hoe wordt geborgd dat externe partijen geen eigenstandige data-governance uitoefenen over de voortbrengingsketen en welke auditrechten heeft de organisatie op data die door of via ingehuurde partijen wordt verwerkt?
De inhurende organisatie is en blijft eigenaar van de gehele datavoortbrengingsketen, dus elke externe partij opereert binnen een mandaat dat expliciet is afgebakend.
Geen governance zonder eigenaarschap, geen uitbesteding zonder controle.
Prachtig moment om de datavoortbrengingsketen onder de röntgenfoto te leggen, maar wel doordacht graag ... er wordt gewerkt.

Melden als ongepast

Door u gemelde berichten worden door ons verwijderd indien ze niet voldoen aan onze gebruiksvoorwaarden.

Schrijvers van gemelde berichten zien niet wie de melding heeft gedaan.

(advertentie)

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in