Wat is een ISMS? Verbind beveiligingswerk met bedrijfsbesluiten

Beveiligingswerk kan er druk uitzien zonder gecoördineerd te zijn. Engineering patcht systemen, HR handelt vertrekkende medewerkers af, inkoop beoordeelt leveranciers en het management keurt uitzonderingen goed. Een managementsysteem voor informatiebeveiliging verbindt die activiteiten met gemeenschappelijke doelstellingen en een expliciet besluitvormingsproces.

Voor een CEO is de belangrijke vraag niet of het bedrijf genoeg beveiligingsdocumenten heeft. Het gaat erom of de directie kan uitleggen wat bescherming nodig heeft, welke risico's ertoe doen, wie verantwoordelijk is en waarom het huidige beschermingsniveau aanvaardbaar is. Een ISMS maakt die antwoorden herhaalbaar terwijl het bedrijf verandert.

Wat een ISMS werkelijk beheert

Een managementsysteem voor informatiebeveiliging is het organisatorische systeem voor het beheersen van informatiebeveiligingsrisico's. Het omvat verantwoordelijkheden, beleid, processen, middelen, beheersmaatregelen en evaluatie. Software kan het ondersteunen, maar software is niet het systeem. Een documentenbibliotheek kan het beschrijven, maar documenten alleen tonen niet aan dat het werkt.

Het doel is drie eigenschappen van informatie te beschermen:

• Vertrouwelijkheid: informatie is alleen beschikbaar voor geautoriseerde personen en systemen.
• Integriteit: informatie blijft juist en volledig en is beschermd tegen ongepaste wijziging.
• Beschikbaarheid: geautoriseerde gebruikers kunnen informatie verkrijgen en ondersteunende diensten gebruiken wanneer dat nodig is.

Deze eigenschappen vertalen zich in zakelijke belangen. Gelekte klantgegevens kunnen het vertrouwen ondermijnen en juridische verplichtingen meebrengen. Onjuiste betaalinstructies kunnen financieel verlies veroorzaken. Een onbeschikbaar supportplatform kan verhinderen dat het bedrijf zijn toezeggingen aan klanten nakomt.

ISO/IEC 27001 bevat erkende eisen voor een afgebakend ISMS. De hoofdstukken 4 tot en met 10 behandelen de context van de organisatie, leiderschap, planning, ondersteuning, uitvoering, evaluatie van de prestaties en verbetering. Een organisatie kan een ISMS opzetten en gebruiken voordat zij certificering nastreeft.

Het managementsysteem legt de verbinding tussen afzonderlijke waarborgen en bedrijfsbesluiten. Een back-up is een beheersmaatregel. Bepalen wat herstelbaar moet zijn, herstelcapaciteit financieren, die testen en handelen naar aanleiding van mislukte tests: dat is werk van het managementsysteem.

Waarom de directie de verbanden nodig heeft

Beveiligingsbesluiten worden al overal in een bedrijf genomen, of het dat nu een ISMS noemt of niet. Iemand kiest een SaaS-aanbieder, keurt geprivilegieerde toegang goed, accepteert een uitgestelde patch of zegt een klant een hersteleis toe. Zonder gedeeld proces kunnen die besluiten op verschillende aannames berusten en is niemand verantwoordelijk voor hun gezamenlijke effect.

Een ISMS geeft de directie een basis om beperkte middelen te prioriteren. Het helpt teams ook om vragen van klanten te beantwoorden vanuit onderhouden registraties, in plaats van hun werkwijze bij elke salesreview te reconstrueren. Dat garandeert geen succesvol inkooptraject, maar maakt de onderliggende claims beter te onderbouwen.

De verbanden moeten praktische vragen beantwoorden:

Deze verbanden zijn vooral van belang bij groei. Informele werkwijzen die werken zolang iedereen elkaar kent, worden onbetrouwbaar wanneer er nieuwe teams, locaties, leveranciers en klanttoezeggingen bijkomen.

Bepaal een reikwijdte die het bedrijf weerspiegelt

Begin bij de bedrijfscontext, niet bij een lijst met beheersmaatregelen. Breng de diensten in kaart die de organisatie levert, de informatie die ze gebruiken, belanghebbenden en hun eisen, en de interne en externe omstandigheden die de beveiliging beïnvloeden.

De reikwijdte bepaalt de grens van het ISMS. Ze moet de gedekte activiteiten, organisatieonderdelen, waar relevant locaties, technologie en raakvlakken met andere delen van het bedrijf benoemen. Een bruikbare eerste reikwijdte kan een klantgericht product en de bijbehorende leveringsprocessen omvatten, in plaats van elke bedrijfsactiviteit.

Een afgebakende reikwijdte kan afhankelijkheden echter niet negeren. Als HR het vertrekproces start voor medewerkers met producttoegang, is dat raakvlak van belang. Als een cloudaanbieder de dienst host, verdwijnt de afhankelijkheid niet door uitbesteding. Als support klantinformatie exporteert, hoort het exportproces in de analyse.

Schrijf een verklaring over de reikwijdte en toets die aan drie vragen:

• Zou een klant begrijpen wat wel en niet is gedekt?
• Hebben we de afhankelijkheden opgenomen die nodig zijn om de gedekte dienst te beschermen?
• Kunnen benoemde eigenaren het systeem binnen deze grens onderhouden?

Klein beginnen is een praktische aanbeveling, geen vrijbrief voor een misleidende grens. Een duidelijke reikwijdte met verantwoordelijke eigenaren is sterker dan een groot register dat niemand bijwerkt. Breid bewust uit wanneer nieuwe diensten of afhankelijkheden dat rechtvaardigen.

Wijs besluiten toe, niet alleen taken

De directie moet richting geven aan en steun bieden voor een ISMS volgens ISO 27001. Het delegeren van coördinatie aan een securityverantwoordelijke draagt de verantwoordelijkheid van de directie voor prioriteiten, middelen en aanvaardbaar risico niet over.

Scheid de verantwoordelijkheden die vaak bij één persoon worden ondergebracht:

Een klein bedrijf kan meerdere verantwoordelijkheden aan één persoon toewijzen. Het moet dan nog steeds vastleggen welke rol die persoon vervult en waar onafhankelijke toetsing nodig is, vooral bij de interne audit.

Leg escalatiedrempels vast. Een teamleider kan binnen afgesproken grenzen een kortdurende operationele uitzondering goedkeuren; een risico dat belangrijke klanttoezeggingen bedreigt, kan goedkeuring van de directie vereisen. Leg de motivering, voorwaarden, vervaldatum en reviewtrigger vast. ‘Geaccepteerd door het management’ volstaat niet als niemand kan aanwijzen wie het besluit nam of welke blootstelling werd geaccepteerd.

Maak van risicobeoordeling een prioriteringsproces

Een risicobeoordeling moet aannemelijke scenario's beschrijven, niet alleen bedrijfsmiddelen benoemen of zwakke plekken opsommen. ‘Klantdatabase’ is een bedrijfsmiddel. ‘Een gecompromitteerd beheerdersaccount maakt grootschalige extractie van klantgegevens mogelijk’ is een risicoscenario met een oorzaak en een gevolg.

Stel een gedocumenteerde beoordelingsmethode en criteria voor risicoacceptatie vast. ISO 27001 vereist geen specifieke scoringsformule. Een praktische aanpak is om categorieën voor waarschijnlijkheid en impact te definiëren in taal die uw besluitvormers begrijpen, inclusief operationele verstoring, financieel verlies, contractuele gevolgen en waar relevant schade voor personen.

Leg voor elk wezenlijk scenario vast:

• De betrokken dienst, informatie en afhankelijkheden.
• De dreiging of gebeurtenis en relevante kwetsbaarheden.
• Bestaande beheersmaatregelen en hun bekende beperkingen.
• Waarschijnlijkheid, impact en de daaruit volgende prioriteit.
• De risico-eigenaar en de voorgestelde behandeling.

Behandeling kan bestaan uit het verminderen van blootstelling met beheersmaatregelen, het vermijden van een activiteit, het delen van aspecten van het risico via contracten of verzekeringen, of het accepteren van het risico binnen goedgekeurde criteria. Een verzekering herstelt geen verloren informatie, en een contract met een leverancier neemt de verantwoordelijkheden van de organisatie niet weg.

Maak onderscheid tussen het huidige risico en het restrisico na behandeling. Verlaag een waardering niet alleen omdat een taak is ingepland. Beoordeel opnieuw na implementatie en geschikt bewijs van de werking. Laat het behandelplan en de acceptatie van het restrisico goedkeuren via de vastgestelde bevoegdheid.

Het operationele risicoregister moet een besluitenregister blijven: wat er veranderde, waarom voor een behandeling werd gekozen en wanneer de beoordeling opnieuw moet worden bekeken.

Selecteer beheersmaatregelen en leg hun toepasselijkheid uit

Beheersmaatregelen zijn de maatregelen waarmee risico wordt beïnvloed. Ze omvatten technische waarborgen zoals meerfactorauthenticatie, organisatorische processen zoals leveranciersreviews, persoonsgerichte maatregelen zoals opleiding, en fysieke bescherming van apparaten en gebouwen.

Bijlage A van ISO/IEC 27001:2022 bevat 93 referentiemaatregelen: 37 organisatorische, 8 voor mensen, 14 fysieke en 34 technologische. De selectie is risicogebaseerd; een organisatie implementeert niet automatisch elke beheersmaatregel. ISO/IEC 27002 biedt implementatierichtlijnen en is geen afzonderlijke certificeringseis voor het ISMS.

Bepaal voor ISO 27001 welke beheersmaatregelen nodig zijn voor de risicobehandeling en vergelijk die met bijlage A om na te gaan dat er geen noodzakelijke beheersmaatregelen zijn weggelaten. Beheersmaatregelen kunnen ook nodig zijn vanwege wettelijke of contractuele eisen, en hoeven niet beperkt te blijven tot bijlage A.

De Verklaring van toepasselijkheid legt de noodzakelijke beheersmaatregelen vast, de motivering voor hun opname, de implementatiestatus en de motivering voor het uitsluiten van beheersmaatregelen uit bijlage A. Zij staat los van het risicobehandelplan: de ene legt de toepasselijke set beheersmaatregelen uit, het andere de acties die nodig zijn om risico's te behandelen. Zie de gids over de beheersmaatregelen uit bijlage A voor die referentiestructuur.

Leg voor elke geselecteerde beheersmaatregel een eigenaar vast, het beoogde resultaat, hoe de maatregel werkt en welk bewijs de doeltreffendheid zal aantonen. ‘Toegangsbeveiliging geïmplementeerd’ is minder bruikbaar dan een expliciet proces voor goedkeuring, toekenning, review en intrekking.

Beleid moet regels vastleggen die mensen kunnen volgen. Procedures moeten de uitvoering uitleggen. Geen van beide mag reviews of technische beperkingen beloven die de organisatie niet daadwerkelijk kan volhouden.

Bouw bewijs in de normale bedrijfsvoering in

Bewijs moet ontstaan uit het werk zelf, niet uit het reconstrueren van een verhaal vlak voor een audit. Een toegangsreview kan een gedateerde gebruikerslijst opleveren, besluiten van reviewers, tickets voor intrekking en de bevestiging dat de wijzigingen zijn doorgevoerd. Een hersteloefening kan testomstandigheden, resultaten, waargenomen beperkingen en vervolgacties opleveren.

Een schermafdruk kan een instelling op één moment tonen. Die bewijst niet per se dat de instelling elk relevant systeem dekt of gedurende een hele periode doeltreffend bleef. Reviewers moeten de reikwijdte, datum, bron, volledigheid en de conclusie die het bewijs werkelijk ondersteunt, onderzoeken.

Een praktische set ISMS-bewijs omvat:

Niet elke rij vraagt om een apart document. Een kleine organisatie kan registraties combineren zolang duidelijkheid en traceerbaarheid behouden blijven. Bescherm ook het bewijs zelf: gebruikersexports, incidentregistraties en schermafdrukken kunnen gevoelige informatie bevatten en vragen om passende afspraken over toegang en bewaring.

Uitgewerkt voorbeeld: een klantsupportplatform

Neem ter illustratie een softwarebedrijf met 30 medewerkers dat een SaaS-supportplatform gebruikt. Stel dat het platform namen van klanten, contactgegevens, tickethistorie en af en toe diagnostische bijlagen bevat. Medewerkers gebruiken persoonlijke accounts, een externe aanbieder host de applicatie en sommige tickets worden geëxporteerd voor probleemanalyse. Dit zijn aannames voor het voorbeeld, geen voorgeschreven bedrijfsmodel.

De reikwijdte van het ISMS omvat de klantsupport en de bijbehorende afhankelijkheden: identiteiten van medewerkers, de SaaS-leverancier, toegang via endpoints, exports, bewaring en herstelafspraken. De supportmanager is eigenaar van de dienst; IT voert de toegangsbeveiliging uit; inkoop coördineert de leveranciersreview; de directie keurt risico's goed die de gedelegeerde bevoegdheid overstijgen.

De eerste beoordeling levert drie scenario's op:

Stel dat een accountafstemming uitwijst dat een voormalig medewerker nog toegang heeft. De directe actie is de toegang in te trekken en te beoordelen of het account oneigenlijk is gebruikt. De actie van het managementsysteem is vast te stellen waarom de intrekking mislukte. Misschien heeft HR IT wel ingelicht, maar ontbrak de supportapplicatie op de vertrekchecklist.

De corrigerende maatregel werkt vervolgens de applicatie-inventaris bij, voegt het supportplatform toe aan het vertrekproces, wijst de verantwoordelijkheid voor bevestiging toe en controleert latere vertrekken. Alleen het intrekkingsticket sluiten zou de directe situatie aanpakken zonder de oorzaak weg te nemen.

Stel nu dat de SaaS-leverancier zijn lijst met subverwerkers wijzigt. De eigenaar van de leveranciersrelatie toetst de wijziging aan contractuele eisen, beveiligingseisen en relevante privacyeisen. Hij legt vast of de wijziging gevolgen heeft voor de gegevensverwerking, afhankelijkheden of het geaccepteerde risico, en of een specialistische beoordeling nodig is. De wijziging heeft een eigenaar en een reviewroute, in plaats van ongelezen te blijven in een gedeelde mailbox.

De directie krijgt de onopgeloste besluiten voorgelegd: een sterker alternatief financieren, minder informatie in bijlagen verzamelen of een afgebakende resterende blootstelling accepteren. Zo verbindt het ISMS operationele bevindingen met bedrijfskeuzes.

Hanteer een ritme dat veranderingen opmerkt

Plan reviews op basis van risico, de frequentie van veranderingen en verplichtingen. Een wekelijkse review van lacunes tijdens de eerste implementatie en een periodieke directiebeoordeling kunnen nuttige praktische keuzes zijn, maar het zijn geen universele termijnen die ISO 27001 voorschrijft. De norm vereist interne audits en directiebeoordelingen met geplande tussenpozen.

Voeg gebeurtenisgestuurde triggers toe: incidenten, grote releases, overnames, wijzigingen bij leveranciers, nieuwe wettelijke verplichtingen, belangrijke klanttoezeggingen en auditbevindingen. Een kalender alleen mist belangrijke veranderingen tussen geplande vergaderingen.

Monitoring vraagt of beheersmaatregelen en doelstellingen presteren zoals bedoeld. De interne audit beoordeelt of het ISMS aan de eisen voldoet en doeltreffend is geïmplementeerd en onderhouden. De directiebeoordeling gaat in op de geschiktheid, adequaatheid en doeltreffendheid van het systeem en neemt besluiten over wijzigingen en middelen. Deze activiteiten voeden elkaar, maar zijn niet onderling uitwisselbaar.

Het management moet informatie krijgen waarop het kan beslissen: wezenlijke risico's, achterstallige behandelingen, herhaalde tekortkomingen, auditbevindingen, veranderende eisen en beperkingen in middelen. Afgeronde taken tellen zonder naar resultaten te kijken, kan zwakke prestaties verhullen. De gids over ISMS-kengetallen gaat in op bruikbare maatstaven.

Ook incidentbeheer hoort in deze cyclus. Leg meldroutes, beoordelingscriteria, responsverantwoordelijkheden, communicatiebevoegdheden en herstelafspraken vast. Test contactroutes en besluitvorming met oefeningen. Beoordeel welke meldplichten van toepassing zijn in plaats van aan te nemen dat één termijn voor elk incident geldt.

Pak na een incident of non-conformiteit het directe probleem aan, onderzoek de oorzaken, voer een corrigerende maatregel in en evalueer de doeltreffendheid daarvan. Herhaalde bevindingen zijn een reden om procesontwerp of middelen te heroverwegen, niet om dezelfde herinnering nogmaals te sturen.

Houd het ISMS, certificering en wettelijke verplichtingen uit elkaar

Het ISMS is het systeem dat de organisatie gebruikt. ISO 27001 is een norm waaraan dat systeem kan worden getoetst. Certificering wordt verleend door een onafhankelijke certificatie-instelling, niet door ISO of Secani, en geldt voor de vermelde reikwijdte.

Certificering kan een nuttig zekerheidsmechanisme zijn wanneer klanten of andere belanghebbenden die verlangen. Het is geen bewijs dat elke bedrijfsactiviteit is gedekt, dat elke beheersmaatregel altijd werkt of dat er geen incidenten kunnen plaatsvinden. Controleer de reikwijdte en status in plaats van een certificaat als bedrijfsbrede beveiligingsgarantie te behandelen.

Wettelijke toepasselijkheid vereist een afzonderlijke analyse. Artikel 32 AVG vereist passende technische en organisatorische beveiligingsmaatregelen op basis van de relevante risico's. NIS2 regelt via nationale uitvoering het toezicht door het bestuur, maatregelen voor risicobeheer en de melding van incidenten voor entiteiten die eronder vallen.

Een ISMS kan bewijs en verantwoordelijkheden ordenen die zulke verplichtingen ondersteunen, maar certificering toont geen naleving van de AVG of NIS2 aan. Evenmin klopt het te zeggen dat een ISMS nooit wettelijk verplicht kan zijn: toepasselijke nationale of sectorspecifieke regels moeten worden gecontroleerd.

Vermijd drie voorspelbare implementatiefouten

Sjablonen ongewijzigd overnemen. Sjablonen kunnen een opzet bieden, maar eigenaren moeten elke toezegging toetsen aan de werkelijke praktijk. Een beleid dat reviews vereist die niemand uitvoert, creëert een onbeheerde lacune.

Een grens trekken die niemand kan onderhouden. Een ambitieuze inventaris is niet nuttig als eigenaarschap en afhankelijkheden onduidelijk zijn. Begin met een verdedigbare dienstgrens en breid daarna uit volgens een expliciet plan.

Certificering als eindstreep zien. Het systeem moet blijven werken bij personeelswisselingen, wijzigingen bij leveranciers, incidenten en nieuwe producten. Begroot voor uitvoering, review en verbetering, niet alleen voor de eerste documentatie.

Een verwante waarschuwing betreft niet-beoordeelde automatisering. Automatisch verzamelde registraties en door AI gegenereerde samenvattingen kunnen het werk ondersteunen, maar mensen moeten nog steeds de relevantie bepalen, lacunes beoordelen en conclusies goedkeuren.

Maak het eerste besluit van de directie concreet

Kies één representatieve dienst en vraag de eigenaar om een verklaring over de reikwijdte, een afhankelijkhedenkaart, eerste risicoscenario's, huidige beheersmaatregelen en onopgeloste besluiten mee te brengen. Spreek af wie risico's mag accepteren, welke middelen beschikbaar zijn en wanneer de voortgang wordt besproken. Zo ontstaat een beheersbaar vertrekpunt zonder te doen alsof de hele organisatie al is gedekt.

Het workspacemodel van Secani ondersteunt deze werkwijze door diensten en ondersteunende doelobjecten te modelleren, bewijs te verbinden met eisen, beheersmaatregelen en besluiten, en eigenaren en reviewverantwoordelijkheden toe te wijzen. Teams kunnen ontbrekend bewijs of onduidelijk eigenaarschap omzetten in taken. Door AI ondersteunde suggesties blijven conceptwerk voor menselijke review, waarbij bronnen en goedkeuringen traceerbaar blijven.

Het volgende gesprek met de directie moet daarom specifiek zijn: welke dienst beschermen we als eerste, welke blootstelling vraagt nu om een besluit en welk bewijs zal laten zien dat het besluit heeft gewerkt?