Auditgereede ISO 27001-risicobeoordeling voor NIS2 en DORA

De koffie op Sarahs bureau was koud.

Als CISO van een snelgroeiende fintech was zij gewend aan druk. Het bedrijf had net een grote bancaire partner binnengehaald, en de due-diligencevragenlijst op haar scherm had een formaliteit moeten zijn. De eerste vragen waren bekend: lever de ISO/IEC 27001:2022 Verklaring van Toepasselijkheid aan, deel het meest recente risicoregister, licht de risicobeoordelingsmethodologie toe.

Daarna veranderde de vragenlijst van toon.

Toon aan hoe uw risicobeheerprogramma DORA adresseert. Licht uw voorbereiding op de NIS2-richtlijn toe, inclusief managementverantwoordelijkheid en risicobeperkende maatregelen voor de toeleveringsketen. Lever bewijs aan dat kritieke ICT-leveranciers worden beoordeeld, gemonitord en gedekt door incidentresponsplannen en bedrijfscontinuïteitsplannen.

Op maandagochtend stond hetzelfde onderwerp op de agenda van het risicocomité van het bestuur. De ISO 27001-certificeringsaudit was over acht weken. DORA-druk kwam van klanten uit de financiële sector. NIS2-classificatievragen speelden rond een in de cloud gehoste servicelijn die naar de EU uitbreidde. Inkoop zei dat leveranciersbeoordelingen bestonden, maar het bewijs stond verspreid over e-mail, contractmappen en een leveranciersspreadsheet. Juridische zaken zei dat de regelgevingsmapping nog liep. Engineering zei dat het risicoregister grotendeels gereed was.

Het bestuur stelde de enige vraag die ertoe deed:

Kunnen wij aantonen dat onze risicobeoordeling en ons risicobehandelingsplan toereikend zijn?

Dat is het werkelijke probleem voor SaaS-, fintech-, managed-service-, cloud- en digitaleplatformbedrijven. Niet of er een risicoregister bestaat. Niet of Annex A-beheersmaatregelen in een spreadsheet zijn gekopieerd. Het gaat erom of de organisatie onder audit- en klantdruk kan aantonen dat haar ISO 27001-risicobeoordelingsproces herhaalbaar, risicogebaseerd, door risico-eigenaren goedgekeurd, gekoppeld aan behandelacties, verbonden met wettelijke verplichtingen en operationeel levend is.

Goed uitgevoerd kunnen één ISO 27001-risicobeoordeling en één risicobehandelingsplan ISO/IEC 27001:2022-certificering, NIS2 Article 21-maatregelen voor cyberbeveiligingsrisicobeheer, DORA-vereisten voor ICT-risicobeheer, GDPR-verantwoordingsplicht, leveranciersassurance, paraatheid voor incidenten en bestuursrapportage ondersteunen.

Slecht uitgevoerd wordt het een spreadsheet die auditors binnen dertig minuten uit elkaar halen.

Deze gids laat zien hoe Clarysec auditgereed bewijs voor ISO 27001-risicobeoordeling en risicobehandeling opbouwt met behulp van de Zenith Blueprint: de 30-stappenroadmap van een auditor, Clarysec-beleid en Zenith Controls: de gids voor geïntegreerde compliance.

Waarom ISO 27001-risicobeoordeling nu een complianceknooppunt is

Het EU-regelgevingslandschap convergeert rond een eenvoudig uitgangspunt: cyberbeveiligingsrisico’s moeten worden bestuurd, gedocumenteerd, getest en toegewezen aan eigenaren.

ISO/IEC 27001:2022 werkt al op die manier. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, belanghebbenden, ISMS-toepassingsgebied en procesinteracties begrijpt voordat risico’s worden beoordeeld. Clausules 6.1.2 en 6.1.3 vereisen een gedefinieerd proces voor informatiebeveiligingsrisicobeoordeling en -behandeling. Clausules 8.2 en 8.3 vereisen dat de organisatie risicobeoordelingen uitvoert en het risicobehandelingsplan implementeert, met behoud van gedocumenteerde informatie.

NIS2 en DORA maken dezelfde risicogebaseerde logica urgenter.

NIS2 Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en cyberbeveiligingstraining volgen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen om risico’s voor netwerk- en informatiesystemen te beheren. Die maatregelen omvatten risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, kwetsbaarhedenbeheer, beoordeling van de doeltreffendheid, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en, waar passend, multifactorauthenticatie of beveiligde communicatie.

DORA legt vergelijkbare druk op financiële entiteiten. Articles 5 en 6 vereisen dat het leidinggevend orgaan regelingen voor ICT-risicobeheer definieert, goedkeurt, daar toezicht op houdt en daarvoor verantwoordelijk blijft. DORA verwacht een gedocumenteerd kader voor ICT-risicobeheer dat is geïntegreerd in het algemene risicobeheer, ondersteund door beleid, procedures, protocollen, tools, interne audit, herstelmaatregelen, continuïteit, testen, incidentbeheer en governance van ICT-derden.

De conclusie is praktisch en onvermijdelijk: het risicoregister is niet langer een werkblad van het technische team. Het is governancebewijs.

Clarysecs Enterprise Beleid inzake risicobeheer maakt deze verwachting expliciet:

Er moet een formeel risicobeheerproces worden onderhouden in overeenstemming met ISO/IEC 27005 en ISO 31000, dat risico-identificatie, analyse, evaluatie, behandeling, monitoring en communicatie omvat.

Uit Enterprise Beleid inzake risicobeheer, sectie “Governancevereisten”, beleidsclausule 5.1.

Hetzelfde beleid definieert het auditgereede resultaat:

Een gecentraliseerd risicoregister en risicobehandelingsplan onder versiebeheer moeten worden onderhouden, waarin de actuele risicostatus, dekking van beheersmaatregelen en voortgang van risicobeperking worden weergegeven.

Uit Enterprise Beleid inzake risicobeheer, sectie “Doelstellingen”, beleidsclausule 3.3.

Die formulering, “actuele risicostatus, dekking van beheersmaatregelen en voortgang van risicobeperking”, markeert het verschil tussen een statisch compliancedossier en een verdedigbaar risicoprogramma.

Begin met toepassingsgebied, verplichtingen en risicocriteria

Veel zwakke ISO 27001-risicobeoordelingen beginnen met een checklist van beheersmaatregelen. Dat is de omgekeerde volgorde.

ISO 27001 vereist dat de organisatie context, eisen van belanghebbenden, ISMS-toepassingsgebied, leiderschapsverantwoordelijkheden en risicoplanning vaststelt voordat beheersmaatregelen worden geselecteerd. ISO/IEC 27005:2022 versterkt dit door organisaties te adviseren de basisvereisten van belanghebbenden te identificeren voordat risico’s worden beoordeeld. Die vereisten kunnen voortkomen uit ISO-normen, sectorregelgeving, nationale wetgeving, klantcontracten, intern beleid, eerdere risicobehandelingsactiviteiten en leveranciersverplichtingen.

Voor een SaaS- of fintechbedrijf dat zich op de EU richt, moet het risicoproces beginnen met een inventaris van complianceverplichtingen.

Voor mkb-organisaties bepaalt Clarysecs Beleid inzake juridische en regelgevende naleving - mkb het startpunt:

De algemeen directeur moet een eenvoudig, gestructureerd nalevingsregister onderhouden waarin het volgende is opgenomen:

Uit Beleid inzake juridische en regelgevende naleving - mkb, sectie “Governancevereisten”, beleidsclausule 5.1.1.

Dat eenvoudige register vormt de brug tussen compliance en risicobeheer. Als daarin staat dat GDPR van toepassing is omdat persoonsgegevens uit de EU worden verwerkt, dat NIS2 van toepassing kan zijn omdat de organisatie digitale of beheerde diensten levert, of dat DORA relevant is via klanten uit de financiële sector, dan moeten die verplichtingen invloed hebben op risicocriteria en behandelprioriteiten.

De Zenith Blueprint is hierover expliciet in de risicobeheerfase, stap 10, “Risicocriteria en impactmatrix vaststellen”:

Neem ook wettelijke en regelgevende vereisten mee in uw acceptatiecriteria. Sommige risico’s kunnen ongeacht de waarschijnlijkheid onaanvaardbaar zijn op grond van wetgeving.

Uit Zenith Blueprint, risicobeheerfase, stap 10.

De Blueprint geeft ook een praktische regel voor workshops:

“Elk risico dat kan leiden tot niet-naleving van toepasselijke wetgeving (GDPR, enz.) is niet aanvaardbaar en moet worden gemitigeerd.”

Uit Zenith Blueprint, risicobeheerfase, stap 10.

Voor Sarahs fintech verandert dit het scoringsmodel. Een kwetsbaarheid in een leveranciers-API kan een lage waarschijnlijkheid hebben, maar als exploitatie een groot DORA ICT-gerelateerd incident, een significant NIS2-incident, een GDPR-inbreukbeoordeling, het niet halen van een klant-SLA of escalatie naar bestuursniveau kan veroorzaken, is de impact hoog of kritiek. Blootstelling aan compliancerisico’s wordt onderdeel van de risicologica, geen afzonderlijke spreadsheet.

Bouw een risicoregister dat auditors kunnen toetsen

Auditors vragen niet alleen wat uw grootste risico’s zijn. Zij toetsen of uw methode is gedefinieerd, herhaalbaar, traceerbaar en gevolgd.

Zij zullen vragen:

• Hoe hebt u deze risico’s geïdentificeerd?
• Welke bedrijfsmiddelen, diensten, leveranciers, gegevenstypen en processen vielen binnen het toepassingsgebied?
• Welke criteria zijn gebruikt voor waarschijnlijkheid en impact?
• Wie is eigenaar van elk risico?
• Welke bestaande beheersmaatregelen verlagen het risico?
• Waarom is het behandelbesluit gekozen?
• Waar is het bewijs dat de behandeling is uitgevoerd?
• Wie heeft het restrisico goedgekeurd?
• Wanneer wordt het risico opnieuw beoordeeld?

Clarysecs Beleid inzake risicobeheer - mkb legt vast wat minimaal nodig is voor een auditgereed risico-item:

Elk risico-item moet het volgende bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en risicobehandelingsplan.

Uit Beleid inzake risicobeheer - mkb, sectie “Governancevereisten”, beleidsclausule 5.1.2.

Voor enterpriseprogramma’s breidt de Zenith Blueprint in de risicobeheerfase, stap 11, “Het risicoregister opbouwen en documenteren”, de structuur uit. De Blueprint beveelt kolommen aan zoals risico-ID, bedrijfsmiddel, dreiging, kwetsbaarheid, risicobeschrijving, waarschijnlijkheid, impact, risiconiveau, huidige beheersmaatregelen, risico-eigenaar, behandelbesluit, behandelplan of beheersmaatregelen en status.

Een sterk risico-item ziet er als volgt uit:

Dit verschilt wezenlijk van “Risico derde partij, Hoog, mitigeren.” De auditgereede versie koppelt bedrijfsmiddel, dreiging, kwetsbaarheid, gevolg, huidige beheersmaatregelen, eigenaar, regelgeving, bewijs en governance.

Zet risicobehandeling om in een bewijsplan

Een risicobehandelingsplan moet vier operationele vragen beantwoorden:

1. Wat gaan we doen?
2. Wie is eigenaar?
3. Wanneer is het gereed?
4. Hoe tonen we aan dat het risico is verlaagd?

ISO/IEC 27001:2022 clausule 6.1.3 vereist dat de organisatie behandelopties selecteert, noodzakelijke beheersmaatregelen bepaalt, deze vergelijkt met Annex A om omissies te voorkomen, een Verklaring van Toepasselijkheid opstelt, een risicobehandelingsplan formuleert en goedkeuring verkrijgt van risico-eigenaren voor het plan en de restrisico’s. Clausule 8.3 vereist vervolgens implementatie van het risicobehandelingsplan en bewaarde gedocumenteerde informatie over de resultaten.

Het Enterprise Beleid inzake risicobeheer maakt dit praktisch:

De risicomanager moet waarborgen dat risicobehandelingen realistisch en tijdgebonden zijn en zijn gekoppeld aan ISO/IEC 27001 Annex A-beheersmaatregelen.

Uit Enterprise Beleid inzake risicobeheer, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.2.

Het mkb-beleid verduidelijkt ook dat acceptatie geen sluiproute is:

Accepteren: motiveer waarom geen verdere actie vereist is en registreer het restrisico.

Uit Beleid inzake risicobeheer - mkb, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Acceptatie moet worden gerechtvaardigd aan de hand van criteria, worden goedgekeurd door de juiste eigenaar en worden gevolgd. Onder NIS2 en DORA kan een niet-goedgekeurd restrisico een governancefout worden.

Een volledig risicobehandelingsplan moet deze velden bevatten:

Voor Sarahs R-042 wordt het risicobehandelingsplan een actielijst voor geïntegreerde compliance.

Dit plan is krachtig omdat het een directe lijn legt van één risicoscenario naar ISO 27001-beheersmaatregelen, NIS2-verplichtingen, DORA-artikelen, eigenaren en bewijs.

Laat de Verklaring van Toepasselijkheid harder werken

De Verklaring van Toepasselijkheid wordt vaak behandeld als een certificeringsartefact. Zij moet meer zijn dan dat.

ISO/IEC 27001:2022 clausule 6.1.3 vereist dat de SoA de noodzakelijke beheersmaatregelen, de motivering voor opname, de implementatiestatus en de motivering voor uitsluitingen bevat. De richtlijnen in ISO/IEC 27005:2022 versterken de noodzaak om geselecteerde beheersmaatregelen te vergelijken met ISO/IEC 27001 Annex A om omissies te voorkomen.

In een auditgereed programma vormt de SoA de brug tussen risicobehandeling en bewijs voor geïntegreerde compliance. Als een risicobehandelingsplan MFA, logging, leveranciersmonitoring, back-upherstel, veilige ontwikkeling, incidentescalatie of cloudexitplanning vereist, moet de SoA laten zien dat de relevante Annex A-beheersmaatregelen zijn opgenomen, gemotiveerd, geïmplementeerd of gepland en onderbouwd met bewijs.

Dit helpt ook een veelvoorkomende auditbevinding te voorkomen: het risicoregister zegt het ene, het risicobehandelingsplan zegt iets anders en de SoA zwijgt. Wanneer deze artefacten niet op elkaar aansluiten, verliezen auditors snel vertrouwen.

ISO 27001-risicobehandeling koppelen aan NIS2, DORA en GDPR

ISO 27001 vervangt NIS2, DORA of GDPR niet. Het biedt een gestructureerd mechanisme om bewijs voor deze regimes te produceren.

De sleutel is om mapping in het risicoproces in te bouwen in plaats van die er later aan vast te schroeven.

Deze mapping is vooral belangrijk waar regelgeving overlapt. DORA is het sectorspecifieke regime voor ICT-weerbaarheid voor veel financiële entiteiten, terwijl NIS2 rechtstreeks relevant kan blijven voor bepaalde aanbieders, coördinatie of entiteiten buiten de reikwijdte van DORA. Een fintech kan DORA nodig hebben als primair kader voor ICT-weerbaarheid, terwijl een managed service provider die die fintech ondersteunt zelf direct onder NIS2-verplichtingen kan vallen.

Het risicoregister moet beide kanten van die afhankelijkheid kunnen laten zien.

Gebruik Zenith Controls als kompas voor geïntegreerde compliance

Clarysec gebruikt Zenith Controls als gids voor geïntegreerde compliance om te voorkomen dat ISO-beheersmaatregelen, regelgevingsartikelen en auditvragen in gescheiden werelden leven. Het creëert geen afzonderlijk beheersmaatregelenkader. Het koppelt beheersmaatregelgebieden uit ISO/IEC 27001:2022 en ISO/IEC 27002:2022 aan andere normen, auditverwachtingen en complianceperspectieven.

Voor ISO 27001-risicobeoordeling en risicobehandeling zijn deze referenties bijzonder belangrijk:

De les voor geïntegreerde compliance is eenvoudig. Als wettelijke verplichtingen niet in de risicobeoordelingsmethode zitten, is uw scoring onvolledig. Als de scoring onvolledig is, kunnen behandelprioriteiten verkeerd zijn. Als prioriteiten verkeerd zijn, worden de SoA en bestuursrapportage onbetrouwbaar.

De Zenith Blueprint maakt hetzelfde punt in de risicobeheerfase, stap 14, “Beleid voor risicobehandeling en regelgevende kruisverwijzingen”. De Blueprint adviseert organisaties een mappingtabel te maken met belangrijke regelgevende beveiligingsvereisten en bijbehorende beheersmaatregelen of beleidsdocumenten in het ISMS. Dit is niet verplicht voor ISO 27001-certificering, maar het is zeer nuttig om aan te tonen dat beveiliging wordt beheerd binnen de wettelijke en contractuele context.

Wat verschillende auditors zullen vragen

Een certificeringsauditor, NIS2-beoordelaar, DORA-georiënteerde klant, GDPR-beoordelaar, NIST-assessor of COBIT-practitioner kan hetzelfde bewijs onderzoeken, maar andere vragen stellen.

Daarom is bewijsarchitectuur belangrijk. Hetzelfde risico-item moet traceerbaar zijn van bedrijfsdoelstelling naar bedrijfsmiddel, dreiging, kwetsbaarheid, beheersmaatregel, eigenaar, regelgevende driver, behandelactie, testresultaat en managementbesluit.

Clarysec-beleid is ontworpen om die architectuur te ondersteunen. Het Enterprise Beleid inzake risicobeheer vermeldt onder de sectie “Referentienormen en -raamwerken”:

Article 5: vereist een gedocumenteerd kader voor ICT-risicobeheer, volledig afgedekt door de structuur van dit beleid, inclusief SoA-mapping en KRI’s.

Dit verandert het beleid van een statisch document in auditbewijs dat laat zien dat ICT-risicogovernance bewust is ontworpen met DORA in gedachten.

Veelvoorkomende bevindingen die risicoprogramma’s ondermijnen

Wanneer Clarysec bewijs voor ISO 27001-risicobeoordeling en risicobehandeling beoordeelt, komen dezelfde bevindingen telkens terug.

Ten eerste negeren risicocriteria wettelijke, regelgevende, contractuele, leveranciers- en privacy-impact. Dit leidt tot zwakke scoring. Een datalek rond persoonsgegevens of het falen van een kritieke leverancier kan als Gemiddeld worden beoordeeld omdat de waarschijnlijkheid laag is, terwijl GDPR-, NIS2-, DORA- of klantimpact het risico Hoog of Kritiek zou moeten maken.

Ten tweede zijn risico-eigenaren generiek. “IT” is geen risico-eigenaar. Een risico-eigenaar moet een rol of persoon zijn die verantwoordelijk is voor behandelbesluiten, budget, timing en restrisico.

Ten derde zijn risicobehandelingsplannen niet tijdgebonden. “Monitoring verbeteren” is geen plan. “Waarschuwingen voor geprivilegieerde sessies in de SIEM uitrollen voor productiebeheerdersaccounts uiterlijk 30 juni, eigenaarschap bij de SOC-manager, getest via een gesimuleerde beheerdersaanmelding, met bijgevoegd waarschuwingsbewijs” is wel een plan.

Ten vierde staat de SoA los van de risicobehandeling. Als het behandelplan leveranciersmonitoring, back-uptesten, incidentescalatie, MFA of logging vereist, moet de SoA de relevante beheersmaatregelen en implementatiestatus weerspiegelen.

Ten vijfde is restrisico niet goedgekeurd. ISO 27001 vereist goedkeuring door risico-eigenaren van het risicobehandelingsplan en de restrisico’s. NIS2 en DORA maken dit nog belangrijker omdat managementverantwoordelijkheid expliciet is.

Ten zesde wordt leveranciersrisico behandeld als inkoopadministratie. Onder NIS2 Article 21(2)(d) en DORA Articles 28 en 30 moeten leveranciersrisico’s en ICT-risico’s van derde partijen onderdeel zijn van risicobeheer, geen jaarlijkse vragenlijst die geïsoleerd wordt opgeslagen.

Ten zevende ontbreekt bewijs voor doeltreffendheid. ISO 27001 clausule 6.1.1 vereist dat geplande acties op doeltreffendheid worden geëvalueerd. NIS2 omvat een beoordeling van de doeltreffendheid in Article 21(2)(f). DORA verwacht testen en herstelmaatregelen. Een beheersmaatregel die bestaat maar nooit wordt getest, is zwak bewijs.

Het mkb-Beleid inzake risicobeheer - mkb formuleert de verwachting duidelijk:

De algemeen directeur en risicocoördinator moeten waarborgen dat risicobeheeractiviteiten gereed zijn voor audits. Het risicoregister en gerelateerde acties zijn onderworpen aan interne en externe audit.

Uit Beleid inzake risicobeheer - mkb, sectie “Handhaving en naleving”, beleidsclausule 8.2.1.

Rapportage aan het bestuur zonder bestuurders te overspoelen

NIS2, DORA en ISO 27001 wijzen allemaal richting managementverantwoordelijkheid, maar besturen hebben niet elke risicoregel nodig. Zij hebben rapportage nodig die besluitvorming ondersteunt.

Een goed risicopakket voor het bestuur moet het volgende tonen:

• Hoge en kritieke risico’s per domein
• Achterstallige behandelacties
• Regelgevende risico’s rond NIS2, DORA, GDPR of contracten
• Leveranciersrisico’s die kritieke of belangrijke diensten raken
• Trends in incidenten en bijna-incidenten
• Restrisico’s die op acceptatie wachten
• Testresultaten voor de doeltreffendheid van beheersmaatregelen
• Materiële wijzigingen in toepassingsgebied, leveranciers, technologie of wetgeving
• Interne-auditbevindingen en corrigerende maatregelen

Clarysec beveelt doorgaans maandelijkse operationele risicobeoordelingen en kwartaalgewijze managementbeoordelingen aan. Maandelijkse beoordelingen richten zich op de oplevering van behandelacties. Kwartaalgewijze beoordelingen richten zich op acceptatie, financiering, prioritering, regelgevende blootstelling en strategische risicobesluiten.

Dit ritme ondersteunt ook voortdurende verbetering. Risicobeoordelingen moeten worden bijgewerkt wanneer incidenten optreden, kwetsbaarheden ontstaan, nieuwe bedrijfsmiddelen worden geïntroduceerd, technologie verandert, leveranciers veranderen, wetgeving wijzigt, klantverplichtingen wijzigen of de risicobereidheid verandert.

Het Clarysec-implementatiepad

Een geïntegreerd risicoprogramma voorkomt losstaande spreadsheets voor ISO, NIS2, DORA, GDPR en klantassurance. Het praktische pad is:

1. Bevestig het ISMS-toepassingsgebied, diensten, bedrijfsmiddelen, leveranciers, jurisdicties en klantverplichtingen.
2. Bouw of actualiseer het nalevingsregister met behulp van het Beleid inzake juridische en regelgevende naleving - mkb waar passend.
3. Definieer de risicomethodologie, acceptatiecriteria, waarschijnlijkheidsschalen, impactschalen en regels voor regelgevende impact.
4. Bouw het risicoregister met behulp van de risicobeheerfase van de Zenith Blueprint en Clarysecs aanpak voor Risk Register en SoA Builder.
5. Identificeer op bedrijfsmiddelen gebaseerde en op scenario’s gebaseerde risico’s, waaronder scenario’s rond leveranciers, cloud, privacy, continuïteit, incidenten, kwetsbaarheden, veilige ontwikkeling en toegang.
6. Scoor risico’s aan de hand van criteria die wettelijke, regelgevende, contractuele, operationele, privacy-, leveranciers- en financiële impact omvatten.
7. Selecteer behandelopties: mitigeren, vermijden, overdragen of accepteren.
8. Koppel noodzakelijke beheersmaatregelen aan ISO/IEC 27001:2022 Annex A en ISO/IEC 27002:2022-richtlijnen.
9. Maak of actualiseer de Verklaring van Toepasselijkheid.
10. Koppel behandelingen aan NIS2 Article 21, ICT-risicobeheer en verwachtingen voor derde partijen onder DORA, GDPR-verantwoordingsplicht en contractuele klantverplichtingen.
11. Verzamel bewijs, valideer de doeltreffendheid van beheersmaatregelen en verkrijg goedkeuring van restrisico’s.
12. Bereid een auditpakket voor, geordend naar risico, beheersmaatregel, regelgeving en bewijsartefact.
13. Voed resultaten terug in managementbeoordeling, interne audit, corrigerende maatregelen en voortdurende verbetering.

Dit is geen papierwerk om het papierwerk. Het is het besturingssysteem voor verdedigbare cybergovernance.

Bouw een auditgereed risicobehandelingspakket

Sarahs verhaal loopt goed af omdat zij ISO 27001, NIS2 en DORA niet langer als afzonderlijke complianceprojecten behandelde. Zij gebruikte ISO 27001-risicobeoordeling als centrale motor, verankerde regelgevende verplichtingen in risicocriteria, koppelde behandelacties aan Annex A en EU-vereisten en verzamelde bewijs dat klanten, auditors en het bestuur konden begrijpen.

Uw organisatie kan hetzelfde doen.

Gebruik Zenith Blueprint: de 30-stappenroadmap van een auditor om risicocriteria te definiëren, het risicoregister op te bouwen, het risicobehandelingsplan te maken en regelgevende vereisten via kruisverwijzingen te koppelen.

Gebruik Zenith Controls: de gids voor geïntegreerde compliance om ISO/IEC 27001:2022 Annex A-beheersmaatregelgebieden te verbinden met governance, naleving van wettelijke vereisten, assurance en auditperspectieven.

Gebruik Clarysecs Beleid inzake risicobeheer, Beleid inzake risicobeheer - mkb en Beleid inzake juridische en regelgevende naleving - mkb om eigenaarschap, registers, behandelbesluiten en auditgereed bewijs te standaardiseren.

De snelste praktische volgende stap is om uw top tien risico’s langs vijf vragen te leggen:

1. Is de regelgevende impact zichtbaar?
2. Is het risicobehandelingsplan tijdgebonden en toegewezen aan een eigenaar?
3. Is elke behandeling gekoppeld aan Annex A en de SoA?
4. Is de relevantie voor NIS2, DORA, GDPR of klanten gedocumenteerd waar van toepassing?
5. Is er bewijs dat de beheersmaatregel werkt?

Als het antwoord nee is, kan Clarysec helpen uw risicoregister om te zetten in een verdedigbaar programma voor geïntegreerde risicobehandeling waarop auditors, toezichthouders, klanten en besturen kunnen vertrouwen.