Veel organisaties behandelen informatiebeveiliging als een apart project naast de reguliere IT. Er komt een securityteam, er komt beleid, er komen maatregelen, en die hangen vervolgens los van de processen waarmee de IT-organisatie elke dag draait. Het gevolg is voorspelbaar: na de implementatie verwatert de beveiliging, omdat ze nergens is geborgd. Wat los staat van het dagelijks werk, sterft een stille dood. ITIL 4 biedt het raamwerk om dat te voorkomen. In dit artikel laat ik zien hoe je met ITIL 4 informatiebeveiliging verankert in je serviceprocessen, en hoe dat aansluit op ISO 27001.
Waarom losse maatregelen verwateren
Een beveiligingsmaatregel die niet in een proces zit, leunt op de discipline van individuele mensen. Zolang de juiste persoon eraan denkt, gebeurt het. Vertrekt die persoon, of komt het druk, dan zakt het weg. Dat is geen kwestie van onwil, maar van ontbrekende borging.
Informatiebeveiliging die wel beklijft, zit ingebakken in hoe het werk standaard verloopt. Niet als extra stap die je eraan plakt, maar als vast onderdeel van het proces zelf. En precies dat is wat ITIL 4 mogelijk maakt: het beschrijft de praktijken waarmee een IT-organisatie waarde levert, en in vrijwel elk van die praktijken zit een natuurlijk haakje voor security.
ITIL 4 in het kort
ITIL 4 is het meest gebruikte raamwerk voor IT-servicemanagement. De kern is het Service Value System, dat beschrijft hoe vraag en kansen via gestructureerde activiteiten worden omgezet in waarde. Daarbinnen kent ITIL 4 een set management practices: herkenbare manieren van werken zoals incidentbeheer, wijzigingsbeheer en leveranciersmanagement.
Het krachtige is dat informatiebeveiliging in ITIL 4 geen aparte praktijk is die naast de rest staat, maar een eigenschap die door alle praktijken heen loopt. Je beveiligt niet los van je processen. Je beveiligt via je processen.
Concreet: waar security in je serviceprocessen zit
Laat ik het tastbaar maken aan de hand van een aantal praktijken.
Wijzigingsbeheer (change enablement). Elke wijziging is een potentieel beveiligingsrisico. Door een securitytoets vast onderdeel te maken van de wijzigingsbeoordeling, voorkom je dat veranderingen ongemerkt nieuwe kwetsbaarheden introduceren. De controle zit dan in het proces, niet in het toeval dat iemand eraan denkt.
Incidentbeheer. Een beveiligingsincident is een incident. Door je incidentproces zo in te richten dat security-incidenten herkend, geclassificeerd en geëscaleerd worden, zorg je dat de organisatie er gestructureerd op reageert in plaats van ad hoc. Dat is ook precies wat een auditor wil zien.
Probleembeheer. Waar incidentbeheer de brand blust, zoekt probleembeheer de oorzaak. Toegepast op security betekent dat: niet alleen het incident afhandelen, maar de onderliggende kwetsbaarheid wegnemen zodat het niet terugkomt. Dit is de motor achter structurele verbetering.
Leveranciersmanagement. Een groot deel van je risico zit bij derde partijen. Door beveiligingseisen, afspraken en periodieke evaluaties in je leveranciersproces te beleggen, houd je grip op de keten. Onder NIS2 is dat geen luxe meer maar een verplichting.
Configuratiebeheer. Je kunt niet beschermen wat je niet kent. Een actueel beeld van je assets en hun onderlinge afhankelijkheden is de basis onder vrijwel elke beveiligingsmaatregel. Configuratiebeheer levert dat beeld.
In elk van deze gevallen is de boodschap dezelfde: je bouwt geen apart securityproces, je maakt security een vast bestanddeel van processen die je toch al hebt.
De aansluiting op ISO 27001
Hier komen twee werelden samen die in de praktijk vaak gescheiden worden gehouden. Veel beheersmaatregelen uit ISO 27001 Annex A gaan over precies de operationele processen die ITIL 4 beschrijft: wijzigingsbeheer, capaciteitsbeheer, logging, leveranciersrelaties, het beheer van kwetsbaarheden. Wie zijn serviceprocessen volgens ITIL 4 heeft ingericht, heeft een groot deel van het fundament onder die maatregelen al staan.
Dat scheelt dubbel werk. In plaats van een ISMS dat naast de IT-organisatie hangt, veranker je de normvereisten in de processen waarmee toch al gewerkt wordt. Dat maakt de beveiliging niet alleen robuuster, maar ook beter aantoonbaar, omdat het bewijs ontstaat in het dagelijks werk in plaats van in een apart dossier dat je voor de audit bij elkaar moet sprokkelen.
Van eenmalig naar continu
De laatste winst zit in continue verbetering. ITIL 4 stuurt op het continu evalueren en bijstellen van praktijken, en dat sluit naadloos aan op de PDCA-cyclus die ISO 27001 vraagt. Plannen, uitvoeren, meten, bijsturen: in beide werelden is dat het ritme. Wie ze combineert, hoeft niet twee verbetercycli naast elkaar te draaien, maar heeft er één die beide doelen dient.
Zo wordt informatiebeveiliging geen project met een einddatum, maar een eigenschap van een organisatie die zichzelf blijft verbeteren.
Tot slot
Informatiebeveiliging die los staat van het dagelijks werk, verwatert. Door security te verankeren in je ITIL 4 serviceprocessen maak je beveiliging een vast onderdeel van hoe je organisatie werkt, sluit je aan op de eisen van ISO 27001, en bouw je een verbetercyclus die blijft draaien. Dat is duurzamer, goedkoper en beter aantoonbaar dan een securityteam dat naast de organisatie staat te roepen. De norm beschrijft wat er moet, ITIL 4 zorgt dat het ook echt gebeurt.
Ronald Everduim is zelfstandig ISO-consultant, CISO-adviseur en ITIL 4 Master. Hij combineert IT-governance en informatiebeveiliging bij organisaties in de zorg, overheid, industrie en het bedrijfsleven.