Kantyra
Kantyra
Kantyra · 24-07-2026 · 15 min leestijd
Bijna elke organisatie die met een ISMS begint, komt op hetzelfde punt uit. Er is al een CMDB met duizenden configuratie-items, netjes bijgehouden door het beheerteam, en de vraag ligt voor de hand. Zetten we die lijst over naar het ISMS? Het antwoord is nee. Wie dat toch doet, zit binnen een week met een register dat niemand onderhoudt en een classificatiekolom die leeg blijft. Het verschil tussen de twee registers begrijpen scheelt je maanden werk. Voor financiële entiteiten die onder DORA vallen ligt het genuanceerder, en daar komen we verderop apart op terug.
Het woord “asset” heeft in de ICT twee betekenissen die toevallig dezelfde term delen.
In de beheerwereld, dus in ITIL en ISO/IEC 20000, is een configuratie-item alles wat je moet kennen om een dienst te kunnen leveren en wijzigen, zoals servers, virtuele machines, netwerkcomponenten, licenties en koppelingen. Het register bestaat om wijzigingen, incidenten en capaciteit te kunnen beheersen. Volledigheid en actualiteit zijn daarbij de belangrijkste kwaliteitseisen.
In de beveiligingswereld, dus in ISO/IEC 27001 en in BIO 2.0, is een bedrijfsmiddel iets waar een eigenaar bij hoort die er een besluit over kan nemen. Beheersmaatregel 5.9 vraagt om een inventaris van informatie en andere gerelateerde bedrijfsmiddelen, met een eigenaar per onderdeel. Die eigenaarseis is niet administratief bedoeld, want zonder eigenaar is er niemand die het restrisico kan aanvaarden.
De twee registers beantwoorden dus verschillende vragen. Je CMDB beantwoordt de vraag wat je hebt staan en hoe het samenhangt. Je ISMS-register beantwoordt de vraag wat je moet beschermen, hoe zwaar, en wie daarover beslist. Dat zijn geen twee versies van dezelfde lijst, maar twee lijsten op een ander abstractieniveau.
Onderzoekers wezen hier al vroeg op. Oppenheim, Stenson en Wilson lieten in hun werk over informatie als bedrijfsmiddel zien dat informatie zich anders gedraagt dan een klassiek activum, omdat informatie niet slijt, tegelijk op meerdere plaatsen kan bestaan en waarde ontleent aan de context waarin ze wordt gebruikt. Een boekhoudkundige of technische inventarisatielogica sluit daar slecht op aan.
Het helpt om bedrijfsmiddelen in vier lagen te ordenen. Elke laag heeft een eigen soort eigenaar en een eigen soort vraag.
Een ISMS werkt op laag 1 tot en met 3. Je CMDB werkt op laag 4 en soms op laag 3, want daar raken de twee registers elkaar. Precies op dat raakvlak leg je de koppeling, en nergens anders.
Een databaseserver is niet vertrouwelijk. De gegevens die erop staan zijn dat wel. Dat klinkt als een woordenspel, maar het is het hele verschil tussen een classificatie die werkt en een classificatie die papier blijft.
De waardering van Beschikbaarheid, Integriteit en Vertrouwelijkheid is geen etiket op zichzelf, maar een schakelaar. Een classificatie is pas zinvol als er iets uit volgt. Denk daarbij aan de volgende gevolgen:
Waardeer je op laag 4, dan waardeer je hardware, en aan hardware valt geen zinnig bedrijfsbelang toe te kennen. Een server heeft pas een beschermingsniveau nodig zodra je weet welke informatie erop staat.
De Amerikaanse overheidsnorm werkt precies zo. FIPS 199 categoriseert langs dezelfde drie eigenschappen als BIV, met de niveaus laag, gemiddeld en hoog, en hanteert daarbij het hoogste-waarde-principe (in het Engels bekend als de high water mark). De categorie van een systeem is gelijk aan de hoogste waardering van alle informatiesoorten die het systeem verwerkt. NIST SP 800-60 werkt dat uit in tabellen die informatiesoorten aan categorieën koppelen. Dat is dezelfde overerving die je in Kantyra van informatie naar applicatie ziet lopen.
Dat principe heeft ook een keerzijde die je moet kennen. Wie het hoogste-waarde-principe klakkeloos toepast, brengt hele omgevingen onder het zwaarste regime omdat er één gevoelige gegevensverzameling in meedraait. Dat is precies de reden waarom NIST in SP 800-53 ruimte laat voor het bijstellen van de maatregelenset, en waarom scheiding van omgevingen vaak goedkoper uitpakt dan alles naar het hoogste niveau tillen. Als één toepassing je hele domein naar het niveau kritiek trekt, is de vraag niet hoe je dat betaalt, maar of die toepassing daar wel thuishoort.
Let daarnaast op het aggregatie-effect. Losse gegevens kunnen ieder afzonderlijk laag scoren, terwijl de verzameling als geheel gevoelig wordt. Een lijst met alleen postcodes is onschuldig, maar dezelfde lijst gekoppeld aan afwezigheidsregistratie is dat niet meer.
Informatieclassificatie is een van de weinige onderwerpen binnen informatiebeveiliging waar wel serieus empirisch onderzoek naar is gedaan, met name uit Zweeds onderzoek naar publieke organisaties. De bevindingen komen opvallend consistent terug, en ze verklaren waarom zoveel classificatietrajecten stranden.
Organisaties classificeren in de praktijk systemen in plaats van informatie, omdat systemen tastbaar zijn en in een lijst staan. Daarmee verdwijnt de koppeling met het bedrijfsbelang en blijft er een technische inventarisatie over. De classificatieschema's zijn bovendien vaak te fijnmazig, met te veel niveaus en te veel dimensies, waardoor de mensen die ze moeten toepassen afhaken. Het werk wordt daarna alsnog gedaan door de beveiligingsfunctionaris of de ICT-afdeling in plaats van door de eigenaar, en juist dat ondermijnt de bedoeling, want een classificatie is een uitspraak over bedrijfsbelang en niet over techniek. Ten slotte wordt classificatie behandeld als een eenmalige oefening voor de auditor, terwijl processen en gegevensstromen jaarlijks veranderen.
De rode draad in die bevindingen is dat classificatie mislukt zodra ze wordt losgekoppeld van de mensen die het belang kennen en van de maatregelen die eruit volgen. Dat is meteen de belangrijkste ontwerpeis voor elk ISMS-register, want elke regel hoort een eigenaar met een naam te hebben, en elke waardering hoort aantoonbaar iets te veranderen aan wat er moet gebeuren.
Dat sluit ook aan bij de Nederlandse bestuurlijke verhoudingen. De CISO is in ons governancemodel niet de risico-eigenaar. De proces- of systeemeigenaar bezit het risico en aanvaardt het restrisico, en het bestuur is uiteindelijk aanspreekbaar. Een classificatie die door de beveiligingsafdeling is ingevuld, legt dus een oordeel vast dat die afdeling helemaal niet mag geven.
Het praktische advies is om geen synchronisatie te bouwen, maar wel een verwijzing te leggen. Er zijn drie varianten, oplopend in kosten en in onderhoudslast.
Bij de eenvoudigste variant leg je in je ISMS per applicatie het CI-nummer uit de CMDB vast als los veld. Een auditor kan die verwijzing volgen, je hebt er geen techniek voor nodig en je bent in een middag klaar. Voor de meeste organisaties is dit genoeg.
Bij de tweede variant doe je een eenmalige import van een deelverzameling. Je exporteert uit de CMDB alleen de configuratie-items van het type applicatie of bedrijfsdienst, en gebruikt die als startlijst. Daarna onderhoud je beide registers los van elkaar, want ze veranderen om verschillende redenen.
De derde variant is een periodieke koppeling, en die is alleen zinvol als je CMDB aantoonbaar actueel is en er per configuratie-item een duidelijke eigenaar in staat. Bij de meeste organisaties is dat niet het geval, en dan importeer je vooral vervuiling.
Belangrijker dan de techniek is de richting van het verkeer, want die loopt twee kanten op. Naar beneden gaat de classificatie. Als een applicatie hoog scoort op beschikbaarheid, moeten de servers eronder het bijbehorende back-up-, patch- en bewakingsregime krijgen, en dat is de reden waarom je de koppeling überhaupt legt. Naar boven gaan de technische feiten, dus welke componenten deze applicatie dragen, waar ze staan en wat de patchstatus is. De eerste richting is de waardevolle, omdat je classificatie dan het beheer aanstuurt in plaats van een papieren oefening te blijven.
Deze drie varianten volstaan voor organisaties die werken vanuit ISO/IEC 27001, BIO 2.0 of de Cyberbeveiligingswet. Val je onder DORA, dan is de eerste variant te licht, en dat leggen we in de volgende paragraaf uit.
De gelaagde logica houdt stand onder de verschillende kaders, maar de as waarlangs je classificeert verschilt per kader. Precies daar gaat het vaak mis, want organisaties bouwen dan drie registers naast elkaar terwijl het onderwerp hetzelfde is.
| Kader | Bovenste laag | Classificatie-as | Wat eruit volgt |
|---|---|---|---|
| ISO/IEC 27001 en BIO 2.0 | Informatie met een eigenaar | BIV-waardering | Maatregelenniveau, hersteltijden, toegangsbeheer |
| Cbw | Essentiële of belangrijke dienst | Risico voor de continuïteit van die dienst | Zorgplicht, evenredigheid, drempel voor de meldplicht |
| DORA | Door ICT ondersteunde bedrijfsfunctie | Kritiek of belangrijk, ja of nee | Meldplicht, testverplichting, eisen aan dienstverleners |
| ITIL en ISO/IEC 20000 | Configuratie-item | Geen bedrijfsclassificatie | Wijzigings-, incident- en capaciteitsbeheer |
De eerste drie rijen gaan over hetzelfde onderwerp, alleen met een andere juridische bril. De vierde rij gaat over iets anders.
De Cyberbeveiligingswet werkt op het niveau van de dienst. Of je onder de wet valt, hangt af van je sector en van de dienst die je levert, en niet van je systemen. De zorgplicht vraagt om passende en evenredige maatregelen op basis van een risicobeoordeling, waarbij het beheer van bedrijfsmiddelen en het toegangsbeleid met zoveel woorden in de maatregelencategorieën staan.
Het woord “evenredig” doet daarbij het werk. Evenredigheid kun je alleen onderbouwen als je weet welk bedrijfsbelang achter een systeem schuilgaat, en dat is nu juist wat een BIV-waardering vastlegt. Zonder classificatie heb je geen verdedigbaar antwoord op de vraag waarom je bij het ene systeem wel een tweede uitwijklocatie hebt ingericht en bij het andere niet. De meldplicht werkt op dezelfde manier, want de drempel hangt af van de gevolgen voor je dienstverlening, en die beoordeel je op procesniveau.
De bestuurlijke kant versterkt het punt over eigenaarschap. Het bestuur moet de maatregelen goedkeuren en toezien op de uitvoering, en is daarop aanspreekbaar. Een classificatie die de beveiligingsafdeling zelf heeft ingevuld, legt dan een oordeel vast dat het bestuur zou moeten dragen.
DORA is de uitzondering op de stelling waarmee dit artikel begint, en dat is de moeite waard om precies te krijgen.
Wie artikel 8 leest, ziet in lid 4 en lid 6 iets wat functioneel gewoon configuratiebeheer is. Je moet alle informatie- en ICT-bedrijfsmiddelen identificeren, ook die op externe locaties, inclusief netwerkbronnen en apparatuur, en je moet de configuratie en de onderlinge verbindingen en afhankelijkheden in kaart brengen en die inventarissen bijhouden. Dat is aanzienlijk concreter dan ISO/IEC 27001, want beheersmaatregel 5.9 zegt niets over configuraties of afhankelijkheden. Wie hieruit concludeert dat DORA vooral een CMDB voorschrijft, heeft dus een punt.
Toch is het dat niet, en de verordening maakt dat zelf duidelijk in haar definities. DORA onderscheidt het ICT-bedrijfsmiddel, dus een software- of hardwaremiddel in de netwerk- en informatiesystemen, van het informatiemiddel, dus een verzameling informatie die het beschermen waard is. Dat is exact de scheiding tussen de lagen die hierboven staat beschreven, en de wetgever heeft haar in de begripsbepalingen vastgelegd in plaats van beide op één hoop te gooien.
Lid 1 is bovendien geen inventarisatievraag. Daar staat dat je de door ICT ondersteunde bedrijfsfuncties moet identificeren, classificeren en documenteren, samen met de rollen en verantwoordelijkheden, en met de informatie- en ICT-bedrijfsmiddelen die die functies ondersteunen, telkens in relatie tot het ICT-risico. Een gemiddelde CMDB levert dat niet, want daarin ontbreekt het volgende:
De scherpe formulering is daarom dat DORA niet om een CMDB vraagt en ook niet om een klassiek bedrijfsmiddelenregister, maar om de combinatie van beide met een aantoonbare koppeling ertussen. Een CMDB alleen is te technisch en mist de functie, de eigenaar en de kritikaliteit. Een klassiek register alleen is te abstract en mist de configuratie en de afhankelijkheden. De technische regelgeving bij de verordening werkt dat verder uit met eisen aan wat de inventaris per bedrijfsmiddel moet bevatten.
Praktisch betekent dat voor financiële entiteiten dat een enkel verwijsveld met het CI-nummer niet volstaat. Je hebt een onderhouden koppeling nodig waarin de kritikaliteit van boven naar beneden overerft naar de technische componenten en waarin de afhankelijkheden zichtbaar blijven. Reken daarbij ook op een derde register dat niets met de eerste twee te maken heeft, namelijk het informatieregister over de contractuele afspraken met ICT-dienstverleners. Dat kent een voorgeschreven datamodel met vaste sjablonen en gaat naar de toezichthouder, dus wie dat in dezelfde tabel als zijn bedrijfsmiddelen probeert te persen, loopt vast.
De praktische uitkomst is dat je één register aanhoudt op proces- en informatieniveau, met per kader een eigen kenmerk op dezelfde regel. Een proces krijgt dus een BIV-waardering, daarnaast een kenmerk of het onder de Cbw meetelt als essentiële of belangrijke dienst, en voor financiële entiteiten een kenmerk of het een kritieke of belangrijke functie is.
Leid die kenmerken niet automatisch uit elkaar af. Een hoge score op vertrouwelijkheid maakt iets nog geen kritieke functie onder DORA, en een kritieke functie hoeft niet hoog te scoren op vertrouwelijkheid. Het zijn juridische kwalificaties met eigen criteria, en software die ze automatisch van elkaar overneemt, levert een verkeerd beeld op dat er wel netjes uitziet.
Een werkbaar ISMS-register telt bij de meeste organisaties tussen de vijftig en honderd bedrijfsmiddelen. Zit je op duizenden regels, dan heb je je CMDB gekopieerd.
De toets per regel is eenvoudig. Is er een persoon met een naam die voor dit bedrijfsmiddel het restrisico kan aanvaarden? En verandert er iets aan de maatregelen door de classificatie die je eraan hangt? Beantwoord je een van beide vragen met nee, dan hoort de regel thuis in je CMDB en niet in je ISMS.
Onder DORA blijft die vuistregel gelden voor de bovenste lagen, maar daar komt de volledige inventaris van ICT-bedrijfsmiddelen bij, en die is per definitie omvangrijker. Het verschil is dat je die twee gescheiden houdt en met elkaar verbindt, in plaats van ze tot één lijst te vermengen.
Deze volgorde is voor een deel van de organisaties bovendien geen vrije keuze. Zowel de Cyberbeveiligingswet als DORA verlangt dat je maatregelen in verhouding staan tot het risico, en die verhouding kun je alleen onderbouwen als je weet welk bedrijfsbelang achter een systeem schuilgaat. Een technische inventarisatie alleen levert die onderbouwing niet, en een classificatie zonder koppeling naar de techniek levert geen aantoonbare uitvoering op. Je hebt ze allebei nodig, maar wel als twee registers die je verbindt.
Normatieve bronnen, rechtstreeks na te slaan:
Onderzoeksliteratuur:
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demo