IT-afdelingen zeggen nee tegen zelf gebouwde tools omdat die tools buiten de gecontroleerde IT-omgeving vallen en daardoor beveiligings-, compliance- en beheersrisico’s met zich meebrengen waar de afdeling verantwoordelijk voor is. Het gaat zelden om dwarsliggen of bureaucratie, maar om echte technische en organisatorische bezwaren die legitiem zijn. In dit artikel beantwoorden we de meest gestelde vragen over IT-beleid rondom tools, shadow IT en de weg naar goedkeuring. Heb je vragen over jouw specifieke situatie? Je kunt altijd contact met ons opnemen voor een vrijblijvend gesprek.
Wat zijn de echte redenen achter een IT-veto op teamtools?
De echte redenen achter een IT-veto op teamtools zijn beveiliging, beheersbaarheid en compliance. IT-afdelingen zijn eindverantwoordelijk voor de stabiliteit en veiligheid van de hele IT-omgeving. Een tool die door een team zelf is gebouwd, is buiten hun zicht ontwikkeld en voldoet vaak niet aan de standaarden die voor de rest van de infrastructuur gelden.
Concreet gaat het om bezwaren zoals:
- Beveiligingslekken: Zelf gebouwde tools worden zelden onderworpen aan een security review. Onveilige afhankelijkheden of hardcoded credentials zijn veelvoorkomende problemen.
- Geen documentatie: Als de maker vertrekt, is de tool een black box. IT kan het systeem dan niet onderhouden of herstellen bij een storing.
- Niet schaalbaar: Wat werkt voor vijf gebruikers, bezwijkt bij vijftig. IT moet ook op langere termijn denken.
- Compliance-risico: In sectoren als financiële dienstverlening of overheid gelden strenge eisen aan audittrails, dataprivacy en toegangsbeheer. Een teamtool voldoet daar zelden standaard aan.
Het veto is dus zelden persoonlijk of politiek. IT-afdelingen zien risico’s die voor het team zelf onzichtbaar zijn, simpelweg omdat het team de tool vanuit functionaliteit benadert en IT vanuit beheer en risico.
Wat is shadow IT en waarom is het zo’n groot risico?
Shadow IT zijn alle systemen, tools en applicaties die medewerkers of teams gebruiken zonder medeweten of goedkeuring van de IT-afdeling. Het risico is groot omdat deze tools buiten het beveiligings- en complianceframework van de organisatie vallen, terwijl ze wel toegang hebben tot bedrijfsdata en -processen.
Shadow IT ontstaat niet uit kwade wil. Teams bouwen of adopteren tools omdat bestaande goedgekeurde oplossingen te traag, te complex of te beperkt zijn voor hun werkwijze. De intentie is productiviteit, maar het resultaat is een blinde vlek in de IT-omgeving.
De risico’s zijn concreet en aanzienlijk:
- Bedrijfsdata wordt opgeslagen op systemen die niet voldoen aan privacywetgeving zoals de AVG.
- Beveiligingsincidenten worden niet ontdekt omdat de tool buiten monitoring valt.
- Bij een audit of incident kan de organisatie haar verantwoordelijkheid niet aantonen.
- Wanneer de tool uitvalt of de maker vertrekt, is er geen fallback.
Voor IT-afdelingen is shadow IT daarom niet alleen een technisch probleem, maar ook een governance-vraagstuk. Organisaties die werken aan een zorgeloze teststrategie nemen shadow IT serieus als onderdeel van kwaliteitsborging in de gehele IT-keten.
Hoe beoordelen IT-afdelingen zelf gebouwde tools intern?
IT-afdelingen beoordelen zelf gebouwde tools op basis van technische kwaliteit, beveiliging, documentatie en integreerbaarheid in de bestaande infrastructuur. De beoordeling volgt doorgaans een intern toetsingsproces waarbij de tool langs een aantal vaste criteria wordt gelegd voordat goedkeuring mogelijk is.
Typische beoordelingscriteria zijn:
- Codebase en architectuur: Is de code leesbaar, gedocumenteerd en onderhoudbaar? Zijn er kwetsbaarheden in gebruikte bibliotheken?
- Authenticatie en autorisatie: Hoe regelt de tool toegang? Sluit het aan op bestaande identity management-systemen?
- Logging en monitoring: Kan IT zien wat de tool doet en ingrijpen bij problemen?
- Data-opslag en -verwerking: Waar wordt data opgeslagen? Voldoet dit aan privacyvereisten?
- Afhankelijkheden en updates: Is de tool afhankelijk van externe services of verouderde pakketten?
Veel zelf gebouwde tools stranden al bij de eerste twee punten. Niet omdat ze slecht zijn gebouwd, maar omdat ze zijn gebouwd met functionaliteit als prioriteit en beveiliging als bijzaak. IT denkt precies andersom.
Wat is het verschil tussen een goedgekeurde tool en een teamtool?
Het verschil tussen een goedgekeurde tool en een teamtool zit niet in de functionaliteit, maar in de mate van controle, transparantie en verantwoordelijkheid. Een goedgekeurde tool is getoetst, gedocumenteerd en opgenomen in het IT-beheerproces. Een teamtool bestaat buiten dat kader.
Concreet betekent dit:
- Een goedgekeurde tool heeft een eigenaar binnen IT die verantwoordelijk is voor updates en incidenten.
- Een goedgekeurde tool voldoet aan beveiligings- en compliancestandaarden die voor de organisatie gelden.
- Een goedgekeurde tool is gedocumenteerd zodat kennis niet verdwijnt als individuen vertrekken.
- Een teamtool heeft vaak maar één of twee mensen die weten hoe het werkt, wat een single point of failure creëert.
Het gaat IT-afdelingen niet om het afkeuren van initiatieven. Het gaat om het verschil tussen een tool die de organisatie kan dragen en een tool die de organisatie kwetsbaar maakt. Een teamtool kan uitgroeien tot een goedgekeurde tool, maar dat vereist bewuste stappen.
Hoe krijg je een zelf gebouwde tool wél goedgekeurd door IT?
Een zelf gebouwde tool krijg je goedgekeurd door IT door het beoordelingsproces proactief te doorlopen: zorg voor documentatie, een security review, aansluiting op bestaande infrastructuur en een duidelijke eigenaar. Wie IT vroeg betrekt in het ontwikkelproces, vergroot de kans op goedkeuring aanzienlijk.
Praktische stappen die het verschil maken:
- Betrek IT vanaf het begin: Vraag al in de ontwerpfase welke eisen gelden. Dit voorkomt dat je achteraf alles moet herbouwen.
- Schrijf documentatie: Beschrijf wat de tool doet, hoe het is gebouwd, welke afhankelijkheden er zijn en hoe het wordt onderhouden.
- Laat een security review uitvoeren: Vraag IT of een externe partij de code te beoordelen op kwetsbaarheden.
- Sluit aan op bestaande systemen: Gebruik de identity management-oplossingen, logging-infrastructuur en datastoragestandaarden die al goedgekeurd zijn.
- Wijs een eigenaar aan: IT wil weten wie verantwoordelijk is als er iets misgaat. Zorg dat die persoon ook na een teamwisseling beschikbaar is.
Bij testautomatisering tools geldt dit extra sterk. Tools die onderdeel zijn van een CI/CD-pipeline raken de kern van het softwareontwikkelproces. IT-goedkeuring voor zulke tools is geen formaliteit, maar een noodzaak voor stabiele softwarekwaliteit.
Wanneer is een zelf gebouwde tool beter dan een commerciële oplossing?
Een zelf gebouwde tool is beter dan een commerciële oplossing wanneer de specifieke behoefte zo uniek is dat geen enkel bestaand product die volledig dekt, of wanneer de integratiekosten van een commercieel product hoger uitvallen dan de bouwkosten van een maatoplossing. Dit is echter de uitzondering, niet de regel.
Situaties waarin een zelf gebouwde tool zinvol kan zijn:
- De tool integreert diep in een proprietary systeem waarvoor geen standaard connectoren bestaan.
- De tool automatiseert een intern proces dat zo organisatiespecifiek is dat commerciële tools onnodig veel overhead meebrengen.
- Het team heeft de technische capaciteit om de tool ook op lange termijn te onderhouden en door te ontwikkelen.
Tegelijkertijd zijn er situaties waarin een commerciële oplossing altijd de betere keuze is: wanneer beveiliging en compliance centraal staan, wanneer het team klein is en verloop kent, of wanneer de tool breed in de organisatie wordt ingezet. Commerciële tools worden onderhouden, geaudit en doorontwikkeld door partijen die daar volledig op zijn ingericht.
De eerlijke vraag die elk team zichzelf moet stellen: bouwen we dit omdat het echt niet anders kan, of omdat het leuker is dan een bestaand pakket configureren? Het antwoord bepaalt of de investering verstandig is en of IT er ooit mee akkoord gaat. Wil je sparren over welke aanpak voor jouw situatie het meest geschikt is? Neem contact met ons op en we denken graag met je mee.
Veelgestelde vragen
Hoe lang duurt het gemiddeld voordat IT een zelf gebouwde tool goedkeurt?
De doorlooptijd van een IT-goedkeuringstraject varieert sterk per organisatie, maar reken gemiddeld op vier tot twaalf weken. Dit hangt af van de complexiteit van de tool, de volledigheid van de aangeleverde documentatie en de beschikbaarheid van het IT-team voor reviews. Wie IT vroeg in het proces betrekt en de documentatie en security review al vooraf regelt, kan deze doorlooptijd aanzienlijk verkorten.
Wat zijn de meest gemaakte fouten bij het aanvragen van IT-goedkeuring voor een teamtool?
De meest voorkomende fout is IT pas benaderen nadat de tool al volledig is gebouwd en in gebruik is genomen. Op dat moment staat de afdeling voor een voldongen feit en is de kans op weerstand veel groter. Andere veelgemaakte fouten zijn: geen duidelijke eigenaar aanwijzen, ontbrekende documentatie over afhankelijkheden en updates, en het niet aantonen hoe de tool aansluit op bestaande beveiligings- en privacystandaarden.
Kan een tool die al als shadow IT in gebruik is alsnog worden goedgekeurd?
Ja, dat is mogelijk, maar het vereist transparantie en bereidheid om de tool te laten toetsen en waar nodig aan te passen. De eerste stap is de tool vrijwillig bij IT te melden en het beoordelingsproces in gang te zetten, inclusief een security review en het opstellen van documentatie. Hoe langer een tool zonder goedkeuring in gebruik blijft, hoe groter het compliance- en beveiligingsrisico dat de organisatie loopt.
Wat doe je als IT een tool afkeurt maar het team er echt van afhankelijk is?
Ga in gesprek met IT om de specifieke bezwaren te begrijpen en bespreek samen welke aanpassingen nodig zijn om aan de eisen te voldoen. In veel gevallen zijn de bezwaren oplosbaar met gerichte technische aanpassingen, zoals het toevoegen van logging, het aansluiten op een bestaand identity management-systeem of het uitvoeren van een security audit. Als de tool fundamenteel niet te repareren is, is het verstandig om samen met IT te zoeken naar een goedgekeurde alternatieve oplossing die de kernbehoefte wel dekt.
Hoe overtuig je IT-afdelingen die standaard nee zeggen zonder inhoudelijke beoordeling?
Presenteer de tool niet als een verzoek om toestemming, maar als een gezamenlijk te beoordelen risicovraagstuk. Kom voorbereid met documentatie, een risicoanalyse en een concreet voorstel voor hoe de tool voldoet aan beveiligings- en compliancevereisten. Door IT de controle te geven over het beoordelingsproces en actief mee te werken aan hun criteria, verander je de dynamiek van weerstand naar samenwerking.
Gelden er andere regels voor testautomatiseringstools dan voor andere teamtools?
Testautomatiseringstools worden vaak strenger beoordeeld omdat ze direct zijn geïntegreerd in de CI/CD-pipeline en daarmee de kern van het softwareontwikkelproces raken. Een kwetsbaarheid of storing in een testautomatiseringstool kan directe impact hebben op de kwaliteit en veiligheid van software die naar productie gaat. IT-afdelingen kijken bij dit type tools extra kritisch naar integraties, toegangsbeheer en de continuïteit van onderhoud.
Is er een manier om de ontwikkeling van een teamtool zo in te richten dat IT-goedkeuring vanzelfsprekender wordt?
Ja, door IT-standaarden vanaf dag één als ontwerpuitgangspunt te nemen in plaats van als afvinklijst achteraf. Gebruik bij de bouw direct de goedgekeurde identity management-, logging- en datastorageoplossingen van de organisatie, schrijf documentatie parallel aan de ontwikkeling en plan een tussentijdse review met IT in. Deze aanpak maakt de tool niet alleen goedkeuringsklaar, maar ook beter onderhoudbaar en robuuster op de lange termijn.