Bijgewerkt op 5 min leestijd
Sébastien Nobour
Oprichter van DEVEDANOS
Een gedeelde spreadsheet waarop een heel bedrijfsproces draait. Een persoonlijk cloudopslagaccount om bestanden met een klant uit te wisselen. Een AI-tool waarin iemand een document plakt om er een samenvatting van te krijgen. Geen van deze tools is door het bedrijf gekozen, en toch hangt het werk ervan af.
Dat heet shadow IT. Het NCSC, het nationale centrum voor cyberbeveiliging van het Verenigd Koninkrijk (vergelijkbaar met het Nederlandse Nationaal Cyber Security Centrum en het Belgische Centrum voor Cybersecurity België), kijkt in de eerste plaats naar de reden waarom het ontstaat. Zijn antwoord blijft niet beperkt tot blokkeren.
Het Britse NCSC gaf er in 2023 een definitie van. Shadow IT staat voor “onbekende IT-middelen die binnen een organisatie voor zakelijke doeleinden worden gebruikt”. In het Nederlands spreekt men ook van schaduw-IT.
Volgens het NCSC ontstaat shadow IT “meestal doordat medewerkers moeite hebben om met de goedgekeurde tools of procedures een bepaalde taak uit te voeren”.
Het verschijnsel is wijdverbreid. Gartner, een onderzoeksbureau op het gebied van informatietechnologie, heeft dat in maart 2023 becijferd in zijn voorspellingen over cybersecurity. Volgens Gartner schafte in 2022 41% van de medewerkers technologie aan, paste die aan of maakte die zelf, buiten het zicht van hun IT-afdeling. Het bureau verwachtte 75% in 2027. Die cijfers gaan over bedrijven in het algemeen, niet specifiek over het mkb.
Het NCSC noemt twee voorbeelden: gevoelige bedrijfsgegevens die in persoonlijke cloudopslagaccounts staan, en berichten- of videobeldiensten die het bedrijf niet heeft goedgekeurd en die zonder toezicht worden gebruikt. De spreadsheet en de AI-tool zijn er nog twee, dichter bij de dagelijkse praktijk van een mkb-bedrijf.
Voor een spreadsheet hoeft niets te worden gekocht of geïnstalleerd: het programma staat al op elke computer. Als de tool van het bedrijf niet doet wat het team nodig heeft, bouwt iemand een spreadsheet om het gat te dichten. Het bestand bewijst goede diensten, en wordt daarna onmisbaar.
Het bedrijfsproces draait dan op een bestand dat niemand heeft gekozen, met de fouten die een spreadsheet niet signaleert. Is het de tool van een heel team geworden, dan kunt u het beter omzetten in een webapplicatie dan het verbieden.
Shadow AI is hetzelfde verschijnsel met AI-tools: een AI-assistent die het bedrijf niet heeft gekozen, wordt gebruikt om teksten te schrijven, samen te vatten of te vertalen.
Naar ons idee zit het risico in de documenten die erin worden geplakt. Staan daar persoonsgegevens in, van een klant of van een medewerker, dan weet het bedrijf niet meer aan wie die zijn toevertrouwd.
De AVG regelt dit voor dienstverleners. Volgens artikel 28 schakelt een verwerker geen andere verwerker in, zoals de leverancier van een AI-model, zonder voorafgaande specifieke of algemene schriftelijke toestemming van de verwerkingsverantwoordelijke. Dat artikel gaat over de relatie tussen het bedrijf en zijn verwerkers, niet over het gebruik dat een medewerker zelf van een tool maakt.
Volgens het NCSC wordt risicobeheer heel moeilijk als shadow IT wijdverbreid is, en heeft het bedrijf nog minder zicht op de mogelijke risico’s. Naar ons idee wordt een tool die de IT-afdeling niet kent, door die afdeling ook niet bijgewerkt, niet geback-upt en niet bewaakt.
Het tweede risico betreft de gegevens. Bedrijfsgegevens belanden in persoonlijke accounts, bij leveranciers waarmee het bedrijf geen contract heeft. Naar ons idee gaan die accounts met de medewerker mee op de dag dat hij het bedrijf verlaat.
Het derde is minder zichtbaar. Een tool die naast de officiële tool is gebouwd, laat een behoefte zien die de officiële tool niet dekt. Zolang die tool in de schaduw blijft, weet niemand dat de behoefte bestaat, en verandert de officiële tool niet.
Het NCSC beveelt organisatorische maatregelen en technische oplossingen aan, zoals een inventaris van de IT-middelen en toegangscontrole op het netwerk. Het geeft daarbij twee adviezen. Wie shadow IT ontdekt, moet de medewerkers er niet op afstraffen. En als medewerkers niet-goedgekeurde tools gebruiken, raadt het aan hun een goedgekeurde en ondersteunde dienst te bieden die in die behoefte voorziet.
Naar ons idee ligt daar het duurzame antwoord. Een tool blokkeren neemt de behoefte waaruit die is ontstaan niet weg: het team vindt wel een andere. Vraag het team liever wat het met die tool doet, en wat de officiële tool het niet laat doen. Dekt standaardsoftware die behoefte, dan blijft dat de eenvoudigste keuze. Past geen enkel pakket bij uw manier van werken, dan is het aan de tool om zich aan u aan te passen.
Bij DEVEDANOS ontwikkelen wij uw software op maat, binnen een maand bruikbaar, tegen een vast maandbudget, en stemmen we die continu af op de veranderingen in uw bedrijf. Het budget wordt samen met u opgebouwd, op basis van uw cijfers en doelstellingen: samen bepalen we het bedrag en het probleem dat uw applicatie moet oplossen.
We beginnen met gesprekken met de gebruikers van uw applicatie, om hun behoeften te begrijpen. De gebruikers van uw applicatie werken er al mee vanaf de eerste ontwikkelmaand, en hoe ze ermee werken, bepaalt welke functionaliteiten we daarna ontwikkelen. Onze aanpak gaat uit van dat gebruik: een tool waar de gebruikers niet omheen hoeven te werken.
En om ervoor te zorgen dat wat gisteren werkte, ook morgen werkt, hanteren we een nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.
De broncode, infrastructuur, deployment-pipeline en documentatie zijn uw intellectueel eigendom zodra de eerste maandfactuur is betaald.
Standaardsoftware of maatwerk? Ons artikel over de keuze voor standaardsoftware helpt u de activiteiten te herkennen waarin uw teams zich aan de tool aanpassen, en die waarin de tool zich aan u moet aanpassen.
Hebben uw teams hun eigen tools gebouwd naast die van het bedrijf? Zullen we erover praten?
Een webapplicatie beschermen, in welke taal ze ook is geschreven: beperken waar een kwetsbaarheid toegang toe geeft, direct gewaarschuwd worden, dependencies controleren, elke kritieke patch installeren op de dag dat hij verschijnt.
Moet u de automatische updates van WordPress inschakelen of uitschakelen? Wij raden de updates af die WordPress zelf, zonder enige test, op plugins en thema's toepast. Een hostingprovider die elke update test voordat hij die toepast, kan dat van u overnemen; zonder zo'n provider werkt u één plugin tegelijk bij, en controleert u daarna de site.
Op 21 oktober 2026 dichtte PHP twee kritieke kwetsbaarheden, op dezelfde dag als GitLab en Node.js. Wie loopt risico, wat u dezelfde dag doet, en hoe u de schade van een kwetsbaarheid beperkt.