ISO-normen, frameworks en best practices zijn niet meer weg te denken uit de IT. Ze duiken op in aanbestedingen, audits, due diligence trajecten en managementpresentaties. Organisaties investeren er tijd en geld in, vaak met de verwachting dat “compliant zijn” automatisch leidt tot betere kwaliteit, hogere veiligheid of volwassen IT. Dat klinkt logisch, maar het klopt maar deels. IT-standaarden helpen, maar ze garanderen niets. Het verschil tussen naleving en kwaliteit wordt structureel onderschat.
De kern van het probleem is dat standaarden bedoeld zijn als referentiekader, niet als kwaliteitskeurmerk. Ze beschrijven wat je minimaal geregeld zou moeten hebben, niet hoe goed je het daadwerkelijk uitvoert. Toch worden ze in de praktijk vaak ingezet als einddoel in plaats van als hulpmiddel. Zodra het certificaat binnen is, overheerst het gevoel dat het “nu wel goed zit”. Dat is precies waar het misgaat.
ISO-normen en frameworks zijn primair ontworpen om structuur aan te brengen. Ze dwingen organisaties na te denken over processen, verantwoordelijkheden, risico’s en documentatie. Dat is waardevol. Zonder zo’n kader verzandt IT al snel in ad-hoc beslissingen en impliciete aannames. Standaarden maken zichtbaar wat anders onuitgesproken blijft. Ze helpen bij herhaalbaarheid, overdraagbaarheid en verantwoording.
Wat ze niet doen, is kwaliteit afdwingen. Een proces kan volledig ISO-proof zijn en toch slecht werken. Procedures kunnen keurig beschreven zijn, terwijl ze in de praktijk worden omzeild of mechanisch gevolgd zonder begrip. Risicoanalyses kunnen netjes zijn ingevuld, terwijl de echte risico’s buiten beeld blijven. Een norm toetst of iets bestaat en of het logisch is ingericht, niet of het effectief is in de context van jouw organisatie.
Daar komt bij dat standaarden per definitie generiek zijn. Ze moeten toepasbaar zijn op ziekenhuizen, softwarebedrijven, overheden en fabrieken tegelijk. Dat betekent dat ze abstract blijven. Ze zeggen dat je risico’s moet beheersen, maar niet welke risico’s voor jou cruciaal zijn. Ze schrijven voor dat je incidenten moet registreren, maar niet of je daarvan leert. Ze vragen om beleid, maar niet of dat beleid wordt begrepen of gedragen.
Compliance wordt daardoor vaak verward met volwassenheid. Een organisatie kan perfect voldoen aan alle eisen en tegelijk kwetsbaar zijn. Bijvoorbeeld omdat de focus ligt op auditbare zaken en niet op werkelijke beheersing. Documentatie krijgt dan meer aandacht dan gedrag. De audit wordt het doel, niet de verbetering die daarachter zou moeten zitten.
Dit zie je vooral wanneer standaarden worden “geïmplementeerd” als project. Er komt een consultant, er worden documenten geschreven, processen uitgetekend en na maanden volgt de audit. Na het certificaat verdwijnt de energie. De standaard leeft niet in de organisatie, maar ligt vast in SharePoint. Formeel klopt het, praktisch niet.
Frameworks zoals ITIL, COBIT of NIST lopen tegen hetzelfde probleem aan. Ze bevatten veel waardevolle inzichten en best practices, maar zijn geen handleiding voor succes. Ze veronderstellen volwassenheid die er vaak nog niet is. Zonder kritisch denkvermogen en contextbewustzijn worden ze gereduceerd tot checklist. Dat leidt tot over-engineering aan de ene kant en schijnveiligheid aan de andere.
Een ander probleem is dat standaarden vooral kijken naar afzonderlijke domeinen. Informatiebeveiliging, service management, privacy, continuïteit. In werkelijkheid lopen die voortdurend door elkaar. Een beveiligingsincident is vaak ook een procesfout, een cultuurprobleem of een ketenrisico. Standaarden knippen die werkelijkheid op, terwijl risico’s zich niets aantrekken van die indeling.
Juist in moderne IT-omgevingen met cloud, outsourcing en complexe leveranciersketens wordt dat zichtbaar. Een organisatie kan intern alles netjes op orde hebben en toch afhankelijk zijn van partijen die nauwelijks worden meegenomen in het volwassenheidsbeeld. De standaard vraagt misschien om leveranciersmanagement, maar toetst zelden hoe diepgaand dat werkelijk is. De zwakste schakel zit vaak buiten het auditkader.
Daarmee zijn standaarden niet nutteloos. Integendeel. Ze zijn een uitstekend startpunt. Ze helpen om blinde vlekken te identificeren en gesprekken te structureren. Ze maken verwachtingen expliciet en bieden een gemeenschappelijke taal tussen IT, management en auditors. Maar ze werken alleen als ze worden gebruikt als middel, niet als doel.
Echte kwaliteit ontstaat pas wanneer organisaties verder kijken dan de norm. Dat vraagt om reflectie. Waarom doen we dit? Wat proberen we te beschermen? Welke aannames maken we? Waar zitten onze echte afhankelijkheden? Dat soort vragen staat niet letterlijk in een standaard, maar bepaalt wel of naleving betekenis heeft.
Volwassen IT kenmerkt zich door het vermogen om van regels af te wijken wanneer dat logisch is, en om regels te volgen wanneer dat zinvol is. Niet omdat de norm het zegt, maar omdat het bijdraagt aan betrouwbaarheid, veiligheid en continuïteit. Dat vereist eigenaarschap, vakmanschap en een cultuur waarin verbeteren belangrijker is dan afvinken.
Audits kunnen daarbij helpen, mits ze worden gezien als spiegel en niet als examen. Een goede audit legt spanningen bloot, stelt lastige vragen en daagt uit om keuzes te onderbouwen. Een slechte audit beloont vooral wie het papierwerk op orde heeft. Organisaties krijgen vaak precies het gedrag dat ze belonen.
De verwarring tussen compliance en kwaliteit is begrijpelijk. Certificaten zijn tastbaar. Volwassenheid is dat niet. Het eerste is makkelijk te communiceren, het tweede vraagt nuance. Toch zit daar de echte waarde. Niet in het logo op de website, maar in het vermogen om IT bewust, adaptief en verantwoord in te zetten.
IT-standaarden garanderen geen kwaliteit. Ze bieden hooguit een kader waarbinnen kwaliteit kan ontstaan. Wie dat verschil niet onderkent, loopt het risico veel energie te steken in naleving en weinig in verbetering. En dat is misschien wel het grootste risico van allemaal.