Auditklaar ISO 27001 Risicoregister voor ISMS-teams, één downloadbare template

Een ISO 27001 risicoregister is het werkdocument waarin elk geïdentificeerd risicoscenario wordt vastgelegd, inclusief kans en impact, de eigenaar, de behandelbeslissing en het restrisico na toepassing van beheersmaatregelen — direct gekoppeld aan clausule 6.1.3 en de Verklaring van Toepasselijkheid. Wie nog niet begonnen is, start het snelst met een template met die velden kant-en-klaar en vult vandaag nog de activainventaris in.

Samenvatting:

• Een risicoregister is onmisbaar voor auditvaardigheid: het koppelt elk risicoscenario, elke controlbeslissing en elke onderbouwing in een traceerbaar, gestructureerd formaat.
• Een overzichtelijke activainventaris met heldere classificaties en eigenaarschap is een voorwaarde voor geloofwaardige risicoscenario's en consistente scoring.
• Effectieve risicoscenario's identificeren specifieke activa, dreigingen, kwetsbaarheden en impacts op basis van brondata uit logbestanden, CVE's en incidenthistorie — zonder te gissen.
• Een goed ontworpen registerschema bevat unieke risico-ID's, behandelacties met eigenaren en deadlines, restrisico en koppelingen naar technisch bewijs.
• Periodieke beoordeling, eigenaarschapstoewijzing en het bijhouden van versiegeschiedenis zijn essentieel om het register accuraat, bruikbaar en auditklaar te houden.

Inhoudsopgave

• Waarom het risicoregister belangrijk is voor auditvaardigheid
• Een activaregister opbouwen voordat u iets kunt beoordelen
• Risicoscenario's schrijven die de toets der kritiek doorstaan
• Uw registerschema kiezen: kolommen, tools en versiebeheer
• Scoren, prioriteren en behandeling koppelen aan de VvT
• Een uitgewerkt voorbeeld en template om vandaag mee te starten
• Het register levend houden: cadans, eigenaarschap en rapportage
• Uw register afstemmen op het enterprise-risicorapportagemodel van NIST
• Wat auditors daadwerkelijk markeren bij steekproeven in een register
• ISMS Calculator: inspanning en tijdlijnveronderstellingen van uw register valideren
• Primaire bronnen en templates
• Bronnen
• FAQ

Waarom het risicoregister belangrijk is voor auditvaardigheid

Auditors nemen uw woord niet aan dat er een risicoanalyse heeft plaatsgevonden. Ze willen het zien, rij voor rij, en een lijn trekken van een geïdentificeerd risico naar een controlbeslissing naar een gedocumenteerde onderbouwing in de Verklaring van Toepasselijkheid. Het register is dat bewijsspoor. Zonder dit heeft clausule 6.1.3 van ISO/IEC 27001:2022 niets om naar te verwijzen, en wordt de VvT een lijst van beweringen in plaats van een verdedigbare reeks beslissingen.

Het register doet ook echt werk buiten de auditformaliteiten. Het is het mechanisme dat een risicoanalyse omzet in de selectie van beheersmaatregelen. Wanneer een risicoscenario boven uw risicobereidheidsdrempel scoort, moet het register laten zien welke beheersmaatregel is gekozen, waarom, en welk risico daarna resteert. Die redeneeringsketen is precies wat de ISO/IEC 27001-richtlijnen verwachten wanneer ze stellen dat noodzakelijke beheersmaatregelen moeten worden geïdentificeerd voordat Annex A op een overeenkomst wordt gecontroleerd.

Een veelgemaakte fout is het proppen van elk technisch detail in het register zelf: ruwe logfragmenten, uitvoer van kwetsbaarheidsscans, ticketgeschiedenissen. Dat levert een document op dat niemand kan lezen tijdens een directiebeoordeling. Het betere patroon, afgeleid van enterprise-risicopraktijk, scheidt het register in beknopte samenvattingsrijen en een gekoppeld detailrecord voor elk ervan:

• De registerrij vermeldt het scenario, de score, de eigenaar en de beslissing in taal die een directeur in seconden kan scannen.
• Een gekoppeld Risicodetailrecord bevat het bewijs: scanresultaten, logtijdstempels, hersteltickets en testuitkomsten.
• Auditors nemen steekproeven uit het register en raadplegen vervolgens het gekoppelde detailrecord voor elke rij die ze willen verifiëren.
• Directiebeoordelingen blijven kort omdat niemand langs technische ruis hoeft te scrollen om de beslissing te vinden.

Deze splitsing houdt het register bruikbaar voor beide doelgroepen tegelijk: de mensen die actie moeten ondernemen op een risico en de mensen die moeten aantonen dat het beheerd werd.

Een activaregister opbouwen voordat u iets kunt beoordelen

U kunt geen geloofwaardig risicoscenario schrijven zonder te weten welk activum blootgesteld is. Hier lopen de meeste eerste ISMS-bouwers vast: ze proberen risicoregels te schrijven voordat ze een overzichtelijke activainventaris hebben, en het register eindigt vol vage vermeldingen zoals "het netwerk" of "klantgegevens" zonder eigenaar en zonder afbakening.

Begin met het definiëren van classificatie en kritikaliteit voordat u ook maar één activum inventariseert. Bepaal schriftelijk wat een activum "hoog", "gemiddeld" of "laag" kritisch maakt voor uw organisatie. Typische criteria zijn of het activum gereguleerde persoonsgegevens bevat, of het verlies ervan een inkomstengenerend proces zou stoppen, en hoe lang de organisatie de onbeschikbaarheid ervan kan verdragen. Door deze definities eerst vast te leggen, wordt elk activum op dezelfde manier gescoord, ongeacht wie het invoert.

Zodra de criteria er zijn, werkt u een herhaalbare reeks af:

1. Haal bestaande inventarissen eerst op: CMDB-exports, resourcelijsten van cloudaccounts en activatags van endpoint-beheertools geven u snel een basislijst.
2. Interview proceseigenaren bij financiën, HR en operaties om shadow IT en handmatige processen op te sporen die nooit in een CMDB verschijnen.
3. Wijs elk activum een eigenaar toe die verantwoordelijk is voor de risicobeslissingen ervan, niet slechts een beheerder die het toevallig beheert.
4. Tag het vertrouwelijkheidsniveau, de fysieke of logische locatie en het bedrijfsproces dat elk activum ondersteunt.
5. Verwijder duplicaten en archiveer vermeldingen voor buiten gebruik gestelde systemen voordat ze uw risicoscenario's vervuilen.

Praktische activacategorieën omvatten doorgaans informatie-activa (databases, documentopslagplaatsen), software, hardware en infrastructuur, mensen en rollen met bevoorrechte toegang, fysieke locaties en diensten van derden. Leg voor elk ervan voldoende metadata vast om later een risicoscenario te kunnen schrijven: eigenaar, locatie, vertrouwelijkheidsbeoordeling en het bedrijfsproces waaraan het is gekoppeld. Het weglaten van een van deze velden is de voornaamste reden waarom risicoregels te vaag uitvallen om consistent te scoren.

Pro-tip: Voer uw activa-inventarisatie en uw risicoworkshop in dezelfde week uit. Activa die afzonderlijk worden ontdekt, blijven maandenlang ongebruikt liggen omdat niemand ze koppelt aan een actueel risicooverleg.

Problemen met datakwaliteit zijn voorspelbaar. Teams tellen hetzelfde activum dubbel onder twee namen, vergeten een eigenaar toe te wijzen en laten het veld leeg, of importeren een CMDB-dump zonder test- en stagingomgevingen eruit te filteren die geen echte bedrijfsimpact hebben. Los dit op voordat u begint met scoren, want elke risicoregels die volgen erft de kwaliteit van de activagegevens.

Risicoscenario's schrijven die de toets der kritiek doorstaan

Een risicoregisterregel is alleen zo nuttig als de zin die het risico beschrijft. "Ransomware-risico" vertelt een auditor niets. Een gestructureerd scenario doet het werk: benoem het activum, de dreigingsactor, de kwetsbaarheid die wordt misbruikt en de specifieke bedrijfsimpact, uitgedrukt in termen van vertrouwelijkheid, integriteit of beschikbaarheid.

Een werkbare template ziet er zo uit: [activum] is blootgesteld aan [dreigingsactor] die [kwetsbaarheid] misbruikt, wat resulteert in [verlies van vertrouwelijkheid/integriteit/beschikbaarheid] en [bedrijfsgevolg]. Bijvoorbeeld: de klantfactureringsdatabase is blootgesteld aan een externe aanvaller die een niet-gepatcht databaseserver misbruikt, wat resulteert in verlies van vertrouwelijkheid van betalingsgegevens en meldingsverplichtingen bij de toezichthouder. Die zin geeft u alles wat nodig is om kans, impact en uiteindelijk een behandeleigenaar toe te wijzen.

Geloofwaardige scenario's hebben geloofwaardige bronnen nodig, geen gissingen van een workshop-whiteboard. Haal dreigings- en kwetsbaarheidsdata op uit:

• Interne logbestanden en SIEM-meldingen die tonen wat er daadwerkelijk tegen uw omgeving is geprobeerd.
• Beveiligingsmeldingen van leveranciers en toeleveranciers, met name voor software van derden met bekende CVE-tijdlijnen.
• Gepubliceerde CVE-databases gekoppeld aan uw eigen activainventaris om niet-gepatchte blootstelling te markeren.
• Incidenthistorie van uw eigen organisatie of sector, waar beschikbaar, in plaats van generieke branchebewering.

Onze methodologiegids voor risicoanalyse doorloopt dit scenariobouwproces uitgebreider als u een langere uitgewerkte reeks wilt.

Het toewijzen van kans en impact is waar de kritikaliteit van activa zijn nut bewijst. Een kwetsbaarheid op een testserver met lage kritikaliteit en de identieke kwetsbaarheid op een productie-betalingsgateway mogen nooit op dezelfde risicoscore uitkomen, ook al is de technische fout hetzelfde. Impact moet worden gescoord op basis van de kritikaliteitsclassificatie van het activum die u al heeft gedefinieerd, niet op basis van een generieke ernstigheidsschaal van een kwetsbaarheidsscanner. Kans moet weerspiegelen wat u weet over blootstelling: is het activum via internet bereikbaar, zit het achter netwerksegmentatie, is deze exacte kwetsbaarheidsklasse eerder tegen u misbruikt. Vage kansbeoordelingen ("gemiddeld, waarschijnlijk") zijn de meest voorkomende zwakte die auditors markeren bij steekproeven in een register.

Uw registerschema kiezen: kolommen, tools en versiebeheer

De kolommen die u kiest, bepalen of het register over zes maanden nog bruikbaar is of uitgroeit tot een onbeheerbare spreadsheet. Een aanbevolen schema, gebouwd rond wat auditors daadwerkelijk verwachten te zien, omvat:

• Risico-ID: een stabiele, unieke identificatie die nooit opnieuw wordt gebruikt, zodat historische verwijzingen en RDR-koppelingen geldig blijven.
• Risicobeschrijving: de gestructureerde scenariozin, niet een eenwoordig label.
• Activareferentie: een koppeling terug naar de activaregistervermelding, zodat activagegevens niet worden gedupliceerd.
• CIA-impact: welke van vertrouwelijkheid, integriteit of beschikbaarheid wordt beïnvloed, en hoe.
• Kans- en impactbeoordelingen: gescoord op basis van uw gedefinieerde criteria, niet op een zwevend buikgevoel.
• Risicoscore: de berekende uitkomst van kans maal impact, of uw gekozen weging.
• Bestaande beheersmaatregelen en effectiviteit: wat er al aanwezig is en hoe goed het werkt.
• Behandelactie, eigenaar en streefdatum: de beslissing, wie verantwoordelijk is en wanneer het gereed moet zijn.
• Restrisico: de score die resteert na behandeling, wat het leiderschap eigenlijk moet zien.
• Koppeling naar Risicodetailrecord: waar het technische bewijs zich bevindt.
• Datum laatste beoordeling: bewijs dat de rij wordt onderhouden, niet eenmalig aangemaakt en vergeten.

Een spreadsheet is oprecht voldoende voor kleinere organisaties met een bescheiden aantal activa en één ISMS-eigenaar die het bestand bijhoudt. Het is snel op te bouwen, gemakkelijk voor auditors om steekproeven uit te nemen en goedkoop te onderhouden. Het schiet tekort zodra meerdere bedrijfseenheden risico's bijdragen, workflowautomatisering voor behandeldeadlines nodig is, of rolgebaseerde toegangscontrole vereist is zodat niet iedereen elke rij kan bewerken. Op dat moment verdient een GRC-platform zijn kosten, voornamelijk dankzij geautomatiseerde herinneringen, audittrails en de mogelijkheid om risico's over afdelingen samen te voegen zonder handmatige consolidatie.

Pro-tip: Als u later migreert van een spreadsheet naar een GRC-tool, houd uw risico-ID-formaat dan van het begin af stabiel. Het hernummeren van rijen tijdens migratie verbreekt elke historische auditverwijzing en RDR-koppeling die u heeft opgebouwd.

Welk formaat u ook kiest, versiebeheer is niet optioneel. Beperk wie het masterregister kan bewerken, log elke wijziging met een tijdstempel en naam van de bewerker, en bewaar eerdere versies opvraagbaar in plaats van overschreven. Auditors vragen regelmatig hoe een specifieke risicoscore in de loop van de tijd is veranderd, en een spreadsheet zonder wijzigingshistorie kan die vraag niet beantwoorden.

Scoren, prioriteren en behandeling koppelen aan de VvT

Drie scoringsmethoden dekken de meeste organisaties. Een eenvoudig kwalitatief model met drie niveaus (laag, gemiddeld, hoog) werkt voor kleine ISMS-programma's waarbij snelheid belangrijker is dan granulariteit. Een numerieke 5×5-matrix, waarbij kans en impact op een schaal van één tot vijf worden vermenigvuldigd, geeft u verfijndere prioritering en is het model dat de meeste auditors gewend zijn te zien. Een hybride model, waarbij een wegingsfactor voor regelgevingsblootstelling of reputatie-impact bovenop de 5×5-basisscore wordt toegevoegd, past bij organisaties met complexe nalevingsverplichtingen bovenop standaard informatiebeveiligingsrisico. Onze risicosjabloon legt uit hoe u de 5×5-versie bouwt met uitgewerkte scoringsvoorbeelden.

De vuistregel: begin met het 5×5-model, tenzij uw organisatie klein genoeg is dat een drieniveauschaal dezelfde beslissingen sneller oplevert. Bouw geen hybride gewogen model totdat de eenvoudigere versie in de praktijk te grof heeft bewezen.

Risicobereidheidsdrempels zetten scores om in acties. Definieer van tevoren de score waarboven een risico moet worden geëscaleerd naar het leiderschap in plaats van op operationeel niveau te worden gesloten. Een gangbaar patroon stelt een numeriek plafond aan risicoscores dat automatische escalatie naar een risicocommissie of executive sponsor triggert, ongeacht wie het heeft geïdentificeerd. Zonder een schriftelijke drempel wordt escalatie een oordeel dat verschilt per persoon die aanwezig is.

Zodra een behandelbeslissing is genomen, is het in kaart brengen naar Annex A de laatste stap — en dat is waar checklistdenken de meeste schade aanricht. ISO/IEC 27001 vereist dat u eerst vanuit de risicoanalyse noodzakelijke beheersmaatregelen identificeert, vervolgens Annex A controleert op een overeenkomst, en in de Verklaring van Toepasselijkheid documenteert waarom eventueel uitgesloten maatregelen niet van toepassing zijn. Praktijknoten van het eigen ISO-commissiecomité benadrukken dat Annex A een referentieset is, geen uitputtende checklist, en dat noodzakelijke beheersmaatregelen ook uit andere normen kunnen komen. Onze gids voor Annex A-beheersmaatregelen legt uit hoe u voorkomt dat u de bijlage als een afvinklijst behandelt. Voor diepgaandere begeleiding bij het documenteren van de behandelbeslissing zelf, het eigenaarschap en deadlines, zie onze gids voor risicobehandeling.

Een uitgewerkt voorbeeld en template om vandaag mee te starten

Abstract schemaadvies heeft zijn grenzen. Hier is één volledige rij, uitgewerkt van identificatie tot restrisico, voor een middelgroot softwarebedrijf.

Het scenario: het klantenserviceticketplatform, gehost door een externe SaaS-leverancier, is blootgesteld aan een credential-stuffing-aanval die gebruik maakt van zwak wachtwoordbeleid op supportagentaccounts, wat resulteert in verlies van vertrouwelijkheid van supporttickets met persoonsgegevens. Het activum werd gemarkeerd tijdens stakeholderinterviews omdat supportagenten brede leestoegang hebben tot alle klantgegevens. De kans werd hoog beoordeeld omdat er op het moment van beoordeling geen meervoudige verificatie werd afgedwongen; de impact werd hoog beoordeeld omdat het activum gereguleerde persoonsgegevens bevat. De behandelbeslissing was het afdwingen van meervoudige verificatie voor alle agentaccounts binnen 30 dagen, met de IT-beveiligingsverantwoordelijke als eigenaar. Na behandeling daalde het restrisico naar laag, omdat credential-stuffing-aanvallen aanzienlijk moeilijker uit te voeren zijn op accounts die zijn beveiligd met een tweede factor.

Voor lezers die vanaf nul beginnen, is een startersspreadsheettemplate met deze kolommen kant-en-klaar de snelste manier om te beginnen; een auditklare versie voegt de RDR-koppelingskolom en het versiegeschiedenistabblad toe. Teams die later naar een GRC-platform willen migreren, moeten kolomkoppen uitlijnen op het bovenstaande schema, omdat overeenkomende veldnamen een latere import eenvoudig maken in plaats van een handmatige hermapping. Kleine teams kunnen het volledige register op één blad bijhouden; grotere organisaties die risico's over bedrijfseenheden aggregeren, willen uiteindelijk dat het register van elke eenheid opgeteld wordt in een samenvatting op ondernemingsniveau, wat de NIST-afstemmingssectie hieronder nader behandelt.

Het register levend houden: cadans, eigenaarschap en rapportage

Een register dat eenmalig is opgebouwd en nooit opnieuw wordt bekeken, is erger dan geen register, omdat het een vals gevoel van zekerheid geeft. De beoordelingscadans moet een geplande controle combineren — doorgaans kwartaallijks voor de meeste organisaties — met door wijzigingen getriggerde beoordelingen wanneer een nieuw systeem in gebruik wordt genomen, een belangrijke leverancier wijzigt, of een incident een hiaat onthult dat het register heeft gemist.

1. Wijs aan elke risicoregisterregel een benoemde eigenaar toe die verantwoordelijk is voor het actueel houden ervan, niet een afdeling of teamnaam.
2. Koppel elke registerrij aan het bijbehorende Risicodetailrecord en aan eventuele openstaande tickets of hersteltaken die de behandeling bijhouden.
3. Beperk de directiegerichte weergave tot een korte momentopname: risico's boven de bereidheidsdrempel, hun eigenaren en streefdatums, in plaats van het volledige technische register.
4. Volg een beperkte set KPI's: gemiddelde tijd-tot-behandeling voor hoog scorende risico's, het percentage hoge risico's met een benoemde eigenaar en actieve deadline, en de trend in restrisicoscores over opeenvolgende kwartalen.
5. Herscore elk risico waarvan de onderliggende beheersmaatregel wijzigt, in plaats van te wachten op de volgende geplande beoordelingscyclus.

Deze KPI's zijn van belang omdat een register met tientallen openstaande hoge risico's en geen voortgang over drie kwartalen een heel ander verhaal vertelt aan een auditor dan een register dat een gestage daling van restrisicoscores toont. De trendlijn is vaak overtuigender dan welke afzonderlijke rij dan ook.

Uw register afstemmen op het enterprise-risicorapportagemodel van NIST

ISO 27001 schrijft geen specifiek registerformaat voor, en dat is precies waarom afstemming op een gevestigd schema loont. De herziening van december 2025 van NIST van de publicaties over cyberbeveiliging en enterprise-risicobeheer beveelt aan dat cyberbeveiligingsrisicoregisters minimaal het risicoscenario, de dreigings- en kwetsbaarheidskoppeling, kans, impact, behandelbeslissing, risico-eigenaar en restrisico vastleggen — wat bijna veld voor veld overeenkomt met het eerder in dit artikel aanbevolen schema.

De echte bijdrage van het NIST-model is de splitsing tussen het Cybersecurity Risk Register (CSRR) en het Risk Detail Record (RDR). NIST IR 8286A biedt een notionele CSRR-template naast een RDR-schema, expliciet ontworpen om de CSRR bondig te houden voor directiebeoordeling terwijl de technische diepgang die auditors nodig hebben in een gekoppeld record wordt bewaard. NIST IR 8286B breidt dit uit met JSON-schemavoorbeelden voor machineleesbare risicorapportage, wat van belang wordt zodra u risicodata over meerdere bedrijfseenheden aggregeert of een GRC-platform voedt.

Drie praktische voordelen vloeien voort uit het adopteren van deze structuur:

• Een beknopte CSRR is wat directeuren en auditors daadwerkelijk lezen, terwijl het RDR bewijs bewaart zonder de samenvattingsweergave te rommelig te maken.
• Gestandaardiseerde veldnamen die aansluiten op de NIST-schema's maken latere migratie naar een enterprise-aggregatiepijplijn veel minder pijnlijk.
• Het toewijzen van één canonieke risico-ID per scenario, nooit gedupliceerd over bedrijfseenheden, is wat enterprise-niveau samenvoeging mogelijk maakt zonder handmatige afstemming.

U hoeft het volledige NIST JSON-schema niet te adopteren om van dit denken te profiteren. Zelfs een spreadsheet die samenvattingsrijen scheidt van een gekoppeld detailtabblad legt het meeste nut vast.

Wat auditors daadwerkelijk markeren bij steekproeven in een register

Drie tekortkomingen duiken keer op keer op wanneer een register wordt bemonsterd tijdens een audit. De eerste is vage risicobeschrijvingen — vermeldingen zoals "cyberrisico voor IT-systemen" die een auditor niets bieden om terug te traceren naar een specifiek activum of een controlbeslissing. De tweede zijn ontbrekende of verouderde eigenaren — rijen toegewezen aan een rol die niet meer bestaat of een persoon die acht maanden geleden het bedrijf heeft verlaten. De derde zijn behandelacties zonder streefdatum, wat leest als een risico dat iedereen erkent maar niemand heeft toegezegd op te lossen.

De oplossing voor alle drie is dezelfde discipline: schrijf scenario's in volledige zinnen, beoordeel eigenaarschap elk kwartaal ongeacht of er iets anders is veranderd, en laat nooit een behandelactie in het register staan zonder een datum. Een register dat zowel een beveiligingsengineer als een financieel directeur kan lezen zonder vertaling doet zijn werk. Bewaar het technische detail in het gekoppelde record en houd de samenvattingsrij in taal die een niet-technische directeur in één lezing kan opvolgen.

De auditors die ik het snelst door een register heb zien gaan, zijn die waarbij elke rij direct gekoppeld is aan bewijs: een ticket, een scanresultaat, een goedgekeurde uitzondering. Die ene gewoonte bespaart meer audittijd dan elke opmaakkeuze.

— Martin

ISMS Calculator: inspanning en tijdlijnveronderstellingen van uw register valideren

Het register opbouwen beantwoordt wat behandeling behoeft. Het vertelt u niet hoeveel die behandeling zal kosten of hoe lang een ISO 27001-programma realistisch gezien duurt — dat is de leemte die ISMS Calculator opvult. De gratis check van 2 minuten geeft direct een gereedheidsoverzicht voordat u zich vastlegt op een volledige beoordeling, en de ISO 27001 Kostencalculator produceert een realtime, organisatiespecifieke schatting op basis van uw bedrijfsomvang, sector en huidige beveiligingsvolwassenheid — met bewerkbare veronderstellingen die u kunt aanpassen naarmate uw register wordt gevuld.

Als uw register al een dozijn hoge-prioriteit behandelacties met streefdatums vermeldt, helpt de calculator die tijdlijnen te controleren aan de hand van modelreferentievergelijkingen in plaats van de inspanning afzonderlijk te schatten. Het produceert ook een volwassenheidsbeoordeling over de vier Annex A-beheersmaatregel-thema's, zodat u kunt zien waar de dekking van uw register dun is voordat een auditor dat doet, en exporteert de resultaten als een deelbaar PDF-rapport voor de directiebeoordeling. Voor een diepgaandere diagnose zodra uw register in vorm is, gaat de ISO 27001 Gereedheidsanalyse verder dan de initiële check. Begin met de gratis check en zie waar uw huidige inspanningsschatting staat.

Primaire bronnen en templates

De NIST IR 8286-reeks, inclusief IR 8286A en IR 8286B, publiceert de CSRR- en RDR-schema's waarnaar in deze gids wordt verwezen, naast de NIST-mededeling van december 2025 over de integratie van cyberbeveiliging en enterprise-risicobeheer. De officiële ISO/IEC 27001:2022-standaardpagina dekt de vereisten van clausule 6.1.3 en Annex A waarop dit artikel is gebaseerd. Organisaties die registerrijen koppelen aan incidentresponsbewijzen kunnen ook de incidentresponsegids van Netverge raadplegen voor praktische RDR-koppelingsvoorbeelden.

Bronnen

• NIST herziet publicaties over integratie van cyberbeveiliging en enterprise-risico
• Prioritering van cyberbeveiligingsrisico voor enterprise-risicobeheer (NIST IR 8286B update)
• IR 8286A: Identificeren en schatten van cyberbeveiligingsrisico voor enterprise-risicobeheer (NIST)
• ISO/IEC 27001:2022 - Informatiebeveiligingsbeheersystemen

FAQ

Is een risicoregister wettelijk verplicht?

ISO/IEC 27001 gebruikt de term "wettelijke verplichting" niet voor een risicoregister, maar clausule 6.1.3 vereist een gedocumenteerd risicoanalyse- en behandelproces, en een register is de standaard manier waarop organisaties dat bewijs leveren. Zonder een register is certificering voor ISO 27001 niet haalbaar, omdat auditors een traceerbaar verslag nodig hebben dat risico's koppelt aan controlbeslissingen.

Hoe voert u een ISO 27001-risicoanalyse uit?

Een ISO 27001-risicoanalyse begint met een gevulde activainventaris, identificeert vervolgens dreigingen en kwetsbaarheden per activum om gestructureerde risicoscenario's te bouwen, en scoort elk scenario op kans en impact aan de hand van gedefinieerde criteria. Onze methodologiegids voor risicoanalyse behandelt de volledige reeks van activaclassificatie tot behandelbeslissing uitgebreider.

Is er een gratis ISO 27001-checklist beschikbaar?

Gratis checklists en startertemplates voor ISO 27001-risicoregisters zijn wijd beschikbaar, hoewel de kwaliteit sterk verschilt wat betreft de velden die auditors daadwerkelijk verwachten, zoals eigenaar, streefdatum en restrisico. ISMS Calculator biedt een gratis check van 2 minuten die direct een gapoverzicht geeft zonder dat u zich hoeft te registreren.

Hoe bouwt u een risicoregister van nul op?

Begin met een overzichtelijke activainventaris met eigenaar, classificatie en bedrijfsproceskoppeling voor elke vermelding, omdat risicoscenario's daar niet zonder kunnen. Schrijf vervolgens gestructureerde risicoscenario's met het activum, de dreiging, de kwetsbaarheid en de bedrijfsimpact, scoor elk op kans en impact, en wijs een behandeleigenaar en streefdatum toe aan elke rij die boven uw gedefinieerde risicobereidheidsdrempel scoort.

Wat is het verschil tussen een CSRR en een Risicodetailrecord?

Een Cybersecurity Risk Register (CSRR) bevat beknopte samenvattingsrijen bedoeld voor directie- en auditbeoordeling, terwijl een Risk Detail Record (RDR) het onderliggende technische bewijs bevat — zoals scanresultaten en hersteltickets — gekoppeld aan elke CSRR-rij. Deze splitsing, beschreven in NIST IR 8286A, houdt het register leesbaar terwijl elders auditwaardige details worden bewaard.

Aanbevolen

• ISO 27001 Risicomatrix: 5×5-template voor auditklare informatiebeveiliging
• ISO 27001 Risicobehandeling: een auditklare gids
• Auditklare ISMS-documentatiegids voor ISO 27001