ISO 27001-SoA voor NIS2- en DORA-gereedheid
Het is 08:30 op maandagochtend wanneer Elena, de CISO van een snelgroeiende B2B FinTech SaaS-aanbieder, een bestuursverzoek opent dat als urgent is gemarkeerd. Het bedrijf heeft net ISO/IEC 27001:2022-certificering behaald, maar een grote bancaire prospect in de EU stelt scherpere vragen dan in de gebruikelijke security questionnaire.
De vragen gaan niet alleen over de vraag of het bedrijf gegevens versleutelt, MFA gebruikt of over een penetratietestrapport beschikt. De prospect wil weten of het SaaS-platform zijn DORA-verplichtingen ondersteunt, of de aanbieder binnen de reikwijdte van NIS2 kan vallen als ICT-dienst of afhankelijkheid voor digitale infrastructuur, en of de ISO 27001-Verklaring van Toepasselijkheid elke opgenomen beheersmaatregel, elke uitgesloten beheersmaatregel en elk stuk bewijsmateriaal kan onderbouwen.
Het bestuur stelt de vraag die elke CISO, compliancemanager en SaaS-oprichter steeds vaker hoort:
Kan onze ISO 27001-SoA NIS2- en DORA-gereedheid aantonen?
Elena weet dat het verkeerde antwoord zou zijn om drie afzonderlijke complianceprogramma’s te starten: één voor ISO 27001, één voor NIS2 en één voor DORA. Dat zou leiden tot dubbel bewijsmateriaal, conflicterend eigenaarschap van beheersmaatregelen en een constante inhaalslag voorafgaand aan elke klantbeoordeling. Het betere antwoord is om het bestaande ISMS te gebruiken als operationeel besturingsmodel voor compliance, met de Verklaring van Toepasselijkheid, of SoA, als centraal document voor traceerbaarheid.
De SoA is niet slechts een spreadsheet voor ISO-certificering. In een EU-omgeving voor cyberbeveiliging en operationele weerbaarheid is dit de plaats waar een organisatie aantoont waarom beheersmaatregelen bestaan, waarom uitsluitingen verdedigbaar zijn, wie eigenaar is van elke beheersmaatregel, welk bewijsmateriaal de implementatie ondersteunt en hoe de set beheersmaatregelen NIS2, DORA, GDPR, klantcontracten en interne risicobehandeling adresseert.
Het Enterprise Informatiebeveiligingsbeleid van Clarysec Informatiebeveiligingsbeleid stelt:
Het ISMS moet gedefinieerde scopegrenzen, een risicobeoordelingsmethodologie, meetbare doelstellingen en gedocumenteerde beheersmaatregelen bevatten die in de Verklaring van Toepasselijkheid (SoA) zijn onderbouwd.
Die eis, uit beleidsclausule 6.1.2 in het Informatiebeveiligingsbeleid, vormt de basis voor een auditeerbare aanpak. De SoA moet de brug worden tussen verplichtingen, risico’s, beheersmaatregelen, bewijsmateriaal en managementbesluiten.
Waarom NIS2 en DORA hebben veranderd wat “van toepassing” betekent
Een traditionele ISO/IEC 27001:2022-SoA begint vaak met een eenvoudige vraag: “Welke Annex A-beheersmaatregelen zijn van toepassing op ons risicobehandelingsplan?” Dat is nog steeds juist, maar voor SaaS-, cloud-, managed service-, fintech-, financiële technologie- en kritieke toeleveringsketenaanbieders is het niet langer voldoende.
NIS2 verhoogt de basislijn voor cybersecurityrisicobeheer bij essentiële en belangrijke entiteiten in de EU. De richtlijn bestrijkt sectoren zoals digitale infrastructuur, aanbieders van cloudcomputingdiensten, aanbieders van datacenterdiensten, content delivery networks, managed service providers, managed security service providers, banken en financiëlemarktinfrastructuren. Lidstaten moeten essentiële en belangrijke entiteiten en aanbieders van domeinnaamregistratiediensten identificeren, en veel technologieaanbieders die cyberbeveiligingsregelgeving voorheen als een klantvraagstuk behandelden, vallen nu rechtstreeks binnen de reikwijdte of worden geraakt via contractuele doorleggingseisen.
NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen voor risicoanalyse, beveiligingsbeleid, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, beoordeling van de doeltreffendheid van beheersmaatregelen, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie waar passend. NIS2 Article 23 voegt gefaseerde verwachtingen voor incidentmelding toe, waaronder vroegtijdige waarschuwing, melding, updates en eindrapportage voor significante incidenten.
DORA, de Digital Operational Resilience Act, is van toepassing vanaf 17 januari 2025 en richt zich op financiële entiteiten en hun ICT-risico-ecosysteem. De verordening bestrijkt ICT-risicobeheer, melding van ICT-gerelateerde incidenten, melding van operationele of beveiligingsgerelateerde betalingsincidenten voor bepaalde entiteiten, testen van digitale operationele weerbaarheid, uitwisseling van informatie over cyberdreigingen, ICT-risicobeheer van derde partijen, contractuele afspraken en toezicht op kritieke ICT-dienstverleners van derde partijen.
Voor financiële entiteiten die ook essentiële of belangrijke entiteiten onder NIS2 zijn, functioneert DORA als het sectorspecifieke regime voor gelijkwaardige verplichtingen op het gebied van ICT-risicobeheer en incidentmelding. Voor SaaS-aanbieders, cloudproviders, MSP’s en MDR-aanbieders die financiële klanten bedienen, is de praktische realiteit echter dat DORA-verwachtingen binnenkomen via inkoop, contracten, auditrechten, verplichtingen voor incidentondersteuning, exitplanning, transparantie over onderaannemers en bewijsmateriaal over weerbaarheid.
Dat verandert het gesprek over de SoA. De vraag is niet langer: “Bevat Annex A deze beheersmaatregel?” De betere vraag is:
Kunnen wij aantonen dat de selectie van beheersmaatregelen risicogebaseerd, verplichtingsbewust, evenredig, toegewezen, geïmplementeerd, gemonitord, met bewijsmateriaal onderbouwd en goedgekeurd is?
ISO 27001 als universele vertaallaag voor NIS2 en DORA
ISO/IEC 27001:2022 is waardevol omdat het een managementsysteemnorm is, geen beperkte checklist. De norm vereist dat het ISMS wordt geïntegreerd in organisatieprocessen en wordt afgestemd op de behoeften van de organisatie. Daardoor is ISO 27001 een effectieve universele vertaallaag voor overlappende compliance-eisen.
Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context begrijpt, belanghebbenden identificeert, relevante eisen bepaalt en het ISMS-toepassingsgebied definieert. Voor een FinTech SaaS-aanbieder zoals Elena’s bedrijf kunnen die eisen van belanghebbenden onder meer bestaan uit EU-klanten, financiële klanten die door DORA worden geraakt, blootstelling aan NIS2-sectoren, GDPR-verplichtingen voor verwerkingsverantwoordelijken en verwerkers, uitbestede cloudafhankelijkheden, leveranciersinterfaces en verwachtingen van het bestuur.
Clausules 6.1.1 tot en met 6.1.3 vereisen planning voor risico’s en kansen, een herhaalbaar proces voor informatiebeveiligingsrisicobeoordeling, een risicobehandelingsproces, vergelijking met Annex A en een Verklaring van Toepasselijkheid die opgenomen beheersmaatregelen, implementatiestatus en onderbouwingen voor uitsluitingen identificeert.
Hier wordt de SoA een besluitregister voor beheersmaatregelen. Een beheersmaatregel kan worden opgenomen omdat deze een risico behandelt, aan een wettelijke eis voldoet, een klantcontract invult, een bedrijfsdoelstelling ondersteunt of basisbeveiligingshygiëne vertegenwoordigt. Een beheersmaatregel mag pas worden uitgesloten nadat de organisatie deze bewust heeft beoordeeld, heeft vastgesteld dat deze niet relevant is voor het ISMS-toepassingsgebied, de onderbouwing heeft gedocumenteerd en passende goedkeuring heeft verkregen.
Het Enterprise Beleid inzake risicobeheer van Clarysec Beleid inzake risicobeheer stelt:
Een Verklaring van Toepasselijkheid (SoA) moet alle behandelbesluiten weerspiegelen en moet worden bijgewerkt wanneer de dekking van beheersmaatregelen wordt gewijzigd.
Deze eis, uit beleidsclausule 5.4 in het Beleid inzake risicobeheer, is cruciaal voor NIS2- en DORA-gereedheid. Een nieuwe gereguleerde klant, een nieuwe cloudafhankelijkheid, een nieuwe verplichting voor incidentmelding of een nieuw concentratierisico bij leveranciers kan de toepasselijkheid van beheersmaatregelen wijzigen.
Begin met het compliance-register, niet met de lijst met beheersmaatregelen
Een zwakke SoA begint bij Annex A en vraagt: “Welke beheersmaatregelen hebben we al?” Een sterke SoA begint bij de operationele werkelijkheid van de organisatie en vraagt: “Welke verplichtingen, diensten, risico’s, gegevens, leveranciers en klanten moet het ISMS adresseren?”
ISO/IEC 27005:2022 ondersteunt deze aanpak door de nadruk te leggen op eisen van belanghebbenden, risicocriteria en de noodzaak om rekening te houden met normen, interne regels, wetten, regelgeving, contracten en bestaande beheersmaatregelen. De norm benadrukt ook dat niet-toepasselijkheid of niet-naleving moet worden toegelicht en onderbouwd.
Het mkb-Beleid inzake juridische en regelgevende naleving van Clarysec Mkb-beleid inzake juridische en regelgevende naleving legt hetzelfde operationele principe vast:
De algemeen directeur moet een eenvoudig, gestructureerd nalevingsregister bijhouden met daarin:
Die eis komt uit clausule 5.1.1 van het mkb-Beleid inzake juridische en regelgevende naleving. Voor een kleinere organisatie kan het register eenvoudig zijn. Voor een enterprise moet het gedetailleerder zijn. De logica is dezelfde: verplichtingen moeten zichtbaar zijn voordat ze kunnen worden gekoppeld.
Het Enterprise Beleid inzake juridische en regelgevende naleving van Clarysec Beleid inzake juridische en regelgevende naleving is expliciet:
Alle wettelijke en regelgevende verplichtingen moeten worden gemapt aan specifieke beleidsdocumenten, beheersmaatregelen en eigenaren binnen het Informatiebeveiligingsmanagementsysteem (ISMS).
Dat is beleidsclausule 6.2.1 in het Beleid inzake juridische en regelgevende naleving. Het is de governancebasis voor het gebruik van een ISO 27001-Verklaring van Toepasselijkheid voor gereedheid voor naleving van NIS2 en DORA.
| Registerveld | Voorbeeldinvoer | Waarom dit belangrijk is voor de SoA |
|---|---|---|
| Bron van verplichting | NIS2 Article 21 | Stuurt de opname van beheersmaatregelen voor risicoanalyse, incidentafhandeling, continuïteit, leveranciersbeveiliging, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen en training |
| Onderbouwing van toepasselijkheid | SaaS-aanbieder die EU-klanten in de financiële sector en essentiële sectoren ondersteunt | Laat zien waarom NIS2 wordt meegewogen, ook als de uiteindelijke juridische status afhankelijk is van aanwijzing door een lidstaat |
| Eigenaar van de beheersmaatregel | Hoofd Security Operations | Ondersteunt verantwoordingsplicht en eigenaarschap van bewijsmateriaal |
| Gekoppelde ISO/IEC 27001:2022-beheersmaatregel | A.5.24 tot en met A.5.28 beheersmaatregelen voor incidentbeheer | Koppelt de wettelijke verplichting aan de selectie van Annex A-beheersmaatregelen |
| Bron van bewijsmateriaal | Incidentresponsplan, ticketsteekproeven, post-incident evaluatie, rapportageoefening | Maakt auditsteekproeven eenvoudiger |
| SoA-besluit | Van toepassing | Creëert traceerbaarheid tussen verplichting, risico, beheersmaatregel en bewijsmateriaal |
Stel risicocriteria op die weerbaarheid, privacy, leveranciers en regelgeving weerspiegelen
Veel SoA-onderbouwingen falen omdat het risicoscoremodel te beperkt is. Het meet technische waarschijnlijkheid en impact, maar legt geen regelgevende blootstelling, dienstkritikaliteit, klantschade, leveranciersafhankelijkheid, privacy-impact of systemische operationele verstoring vast.
NIS2 gaat niet alleen over vertrouwelijkheid. De richtlijn richt zich op het voorkomen en beperken van incidentimpact op diensten en dienstontvangers. DORA definieert kritieke of belangrijke functies op basis van de vraag of een verstoring de financiële prestaties, continuïteit van dienstverlening of naleving van regelgeving materieel zou aantasten. GDPR voegt verantwoordingsplicht, integriteit, vertrouwelijkheid, paraatheid voor inbreuken en schade voor betrokkenen toe.
Het mkb-Beleid inzake risicobeheer van Clarysec Mkb-beleid inzake risicobeheer geeft een praktisch minimum:
Elke risico-invoer moet bevatten: beschrijving, waarschijnlijkheid, impact, score, eigenaar en behandelplan.
Dit is clausule 5.1.2 van het mkb-Beleid inzake risicobeheer. Voor gereedheid voor NIS2 en DORA breidt Clarysec dit minimum uit met velden zoals bron van verplichting, geraakte dienst, gegevenscategorie, leveranciersafhankelijkheid, bedrijfseigenaar, regelgevende impact, restrisico, behandelstatus en bron van bewijsmateriaal.
| Risico-ID | Risicoscenario | Verplichtingsdriver | Behandelingsmaatregelen | SoA-onderbouwing |
|---|---|---|---|---|
| R-021 | Uitval van het cloudplatform verhindert dat klanten toegang krijgen tot gereguleerde dashboards voor fraudeanalyse | NIS2 Article 21, DORA-klantafhankelijkheid, contractuele SLA | A.5.29, A.5.30, A.8.13, A.8.15, A.8.16 | Van toepassing omdat continuïteit van dienstverlening, back-up, logging, monitoring en ICT-gereedheid operationele verstoring beperken en weerbaarheidsverplichtingen van klanten ondersteunen |
| R-034 | Beveiligingsincident met persoonsgegevens van EU-betrokkenen wordt niet binnen de vereiste termijnen gedetecteerd, geëscaleerd of gemeld | GDPR-verantwoordingsplicht, NIS2 Article 23, DORA-verplichtingen voor incidentondersteuning | A.5.24 tot en met A.5.28, A.8.15, A.8.16 | Van toepassing omdat gefaseerde incidentafhandeling, bewijsverzameling, leren, logging en monitoring regelgevende en klantgerichte meldingsworkflows ondersteunen |
| R-047 | Zwakte bij een kritieke onderaannemer beïnvloedt veilige dienstverlening aan financiële klanten | NIS2 Article 21 beveiliging van de toeleveringsketen, DORA ICT-risico van derde partijen | A.5.19 tot en met A.5.23, A.5.31, A.5.36 | Van toepassing omdat leveranciersrisico, contractuele eisen, cloudgovernance, complianceverplichtingen en beleidsnaleving vereist zijn voor assurance over ICT-afhankelijkheden |
Let op de formulering. Een sterke onderbouwing zegt niet alleen “geïmplementeerd”. Zij legt uit waarom de beheersmaatregel van toepassing is in de bedrijfs-, regelgevende en risicocontext van de organisatie.
Breng NIS2- en DORA-domeinen in kaart op ISO 27001:2022-beheersmaatregelen
Zodra het compliance-register en de risicocriteria zijn vastgesteld, bestaat het praktische werk uit het koppelen van regelgevende domeinen aan Annex A-beheersmaatregelen. Deze koppeling bewijst op zichzelf geen naleving, maar geeft auditors en klanten een duidelijke index voor het toetsen van bewijsmateriaal.
| Gebied van regelgevende eis | NIS2-verwijzing | DORA-verwijzing | Voorbeelden van ISO/IEC 27001:2022-beheersmaatregelen |
|---|---|---|---|
| Governance en verantwoordingsplicht van management | Article 20 | Article 5 | A.5.1, A.5.2, A.5.31, A.5.35, A.5.36 |
| Risicobeheerkader | Article 21(1) | Article 6 | ISO 27001 clausules 6.1.1 tot en met 6.1.3, A.5.7, A.5.31, A.5.36 |
| Incidentafhandeling en rapportage | Article 23 | Articles 17 to 19 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16 |
| Bedrijfscontinuïteit en weerbaarheid | Article 21(2)(c) | Articles 11 and 12 | A.5.29, A.5.30, A.8.13, A.8.14, A.8.15, A.8.16 |
| Toeleveringsketen en risico van derde partijen | Article 21(2)(d), Article 21(3) | Articles 28 to 30 | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Veilige verwerving en ontwikkeling | Article 21(2)(e) | Article 9 | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 |
| Testen en doeltreffendheid van beheersmaatregelen | Article 21(2)(f) | Articles 24 to 27 | A.5.35, A.5.36, A.8.8, A.8.29, A.8.34 |
| Toegangscontrole en beheer van bedrijfsmiddelen | Article 21(2)(i) | Article 9(4)(d) | A.5.9, A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3 |
| Cryptografie en encryptie | Article 21(2)(h) | Article 9(4)(d) | A.8.24 |
Voor Elena veranderde deze koppeling het gesprek met het bestuur. In plaats van NIS2 en DORA als afzonderlijke projecten te presenteren, kon zij de overlap laten zien: governance, risicobeheer, incidenten, continuïteit, leveranciers, testen, toegangscontrole en cryptografie.
De drie ISO-beheersmaatregelen waarop elke NIS2- en DORA-SoA steunt
In Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt Clarysec drie ISO/IEC 27002:2022-beheersmaatregelen als centraal voor auditgereed SoA-governance voor NIS2 en DORA. Dit zijn ISO-beheersmaatregelen, verrijkt met cross-compliance-kenmerken in de Zenith Controls-gids.
| ISO/IEC 27002:2022-beheersmaatregel | Naam van beheersmaatregel | Kenmerken in Zenith Controls | Waarom dit belangrijk is voor SoA-governance |
|---|---|---|---|
| 5.31 | Wettelijke, statutaire, regelgevende en contractuele eisen | Preventief, CIA, identificeren, juridische zaken en compliance, governance, ecosysteem, bescherming | Stelt de verplichtingenbasis vast die opname van beheersmaatregelen en toewijzing van eigenaren aanstuurt |
| 5.35 | Onafhankelijke beoordeling van informatiebeveiliging | Preventief en corrigerend, CIA, identificeren en beschermen, assurance over informatiebeveiliging, governance, ecosysteem | Biedt assurance dat SoA-besluiten en implementatiebewijsmateriaal een onafhankelijke beoordeling kunnen doorstaan |
| 5.36 | Naleving van beleid, regels en normen voor informatiebeveiliging | Preventief, CIA, identificeren en beschermen, juridische zaken en compliance, assurance over informatiebeveiliging, governance, ecosysteem | Verbindt de SoA met operationele conformiteit, beleidsnaleving en monitoring |
Deze beheersmaatregelen staan niet op zichzelf. Zij verbinden rechtstreeks met beheersmaatregelen voor leveranciersrelaties A.5.19 tot en met A.5.23, beheersmaatregelen voor incidentbeheer A.5.24 tot en met A.5.28, continuïteitsmaatregelen A.5.29 en A.5.30, privacybeheersmaatregel A.5.34, kwetsbaarhedenbeheer A.8.8, configuratiebeheer A.8.9, back-up van informatie A.8.13, logging A.8.15, monitoringactiviteiten A.8.16, cryptografie A.8.24, beheersmaatregelen voor veilige ontwikkeling A.8.25 tot en met A.8.29 en wijzigingsbeheer A.8.32.
De waarde van Zenith Controls is dat het teams helpt voorkomen dat zij de SoA behandelen als een artefact voor één norm. Beheersmaatregel 5.31 ondersteunt juridische en contractuele koppeling. Beheersmaatregel 5.35 ondersteunt interne audit, onafhankelijke beoordeling en managementassurance. Beheersmaatregel 5.36 ondersteunt operationele naleving van beleidsdocumenten, procedures, normen en vereisten voor beheersmaatregelen.
Gebruik de Zenith Blueprint om de SoA op te bouwen, te toetsen en te verdedigen
In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint plaatst Clarysec de opbouw van de SoA in de fase Risicobeheer, stap 13: planning van risicobehandeling en Verklaring van Toepasselijkheid. De Blueprint instrueert organisaties om het SoA-tabblad in het sjabloon “Risk Register and SoA Builder.xlsx” te gebruiken, te bepalen of elk van de 93 Annex A-beheersmaatregelen van toepassing is en het besluit te baseren op risicobehandeling, wettelijke en contractuele eisen, scoperelevantie en organisatiecontext.
De Blueprint stelt:
De SoA is in feite een brugdocument: het verbindt uw risicobeoordeling/-behandeling met de daadwerkelijke beheersmaatregelen die u hebt.
Die zin vat het operationele model samen. De SoA overbrugt verplichtingen, risico’s, beleid, beheersmaatregelen, bewijsmateriaal en auditconclusies.
De Zenith Blueprint instrueert teams ook om regelgeving waar passend te cross-referencen in de SoA-notities. Als een beheersmaatregel is geïmplementeerd voor GDPR, NIS2 of DORA, moet dit in het risicoregister of de SoA-notities zichtbaar zijn. Later, in stap 24, instrueert de Blueprint organisaties om de SoA na implementatie bij te werken en deze te verifiëren tegen het risicobehandelingsplan. In stap 30, voorbereiding op certificering, eindbeoordeling en mock-audit, geeft de Blueprint teams opdracht te bevestigen dat elke toepasselijke Annex A-beheersmaatregel bewijsmateriaal heeft, zoals een beleid, procedure, rapport, plan of implementatieregistratie.
Die volgorde maakt van de SoA een levend compliance-instrument:
- Stap 13 bouwt deze op vanuit risicobehandeling en verplichtingen.
- Stap 24 toetst deze aan de implementatiewerkelijkheid.
- Stap 30 verdedigt deze via een laatste beoordeling van bewijsmateriaal en een mock-audit.
Hoe u opname-onderbouwingen schrijft die auditors kunnen volgen
Een beheersmaatregel moet worden opgenomen wanneer er ten minste één verdedigbare driver bestaat: risicobehandeling, wettelijke eis, contractuele eis, scoperelevantie, basisbeveiligingshygiëne, klantverwachting ten aanzien van assurance of een door het management goedgekeurde weerbaarheidsdoelstelling.
Een bruikbare formule is:
Van toepassing omdat [risico of verplichting] invloed heeft op [dienst, bedrijfsmiddel, gegevens of proces], en deze beheersmaatregel [preventieve, detectieve, corrigerende of weerbaarheidsuitkomst] biedt, onderbouwd met [beleid, registratie, test, rapport of systeemuitvoer].
| Gebied van beheersmaatregelen | Zwakke onderbouwing | Auditgereed onderbouwing |
|---|---|---|
| Incidentbeheer | Geïmplementeerd | Van toepassing omdat NIS2 Article 23 en de DORA-verwachtingen voor de incidentlevenscyclus detectie, classificatie, escalatie, ondersteuning van rapportage, communicatie, oorzaakanalyse, bewijsverzameling en geleerde lessen vereisen voor incidenten die gereguleerde klanten raken |
| Leveranciersbeveiliging | Vereist | Van toepassing omdat cloudhosting, supportleveranciers en MDR-diensten de beschikbaarheid van diensten en vertrouwelijkheid van gegevens beïnvloeden, en NIS2 Article 21 plus DORA-verwachtingen voor ICT-risico van derde partijen due diligence, contractuele beschermingsmaatregelen, monitoring, beoordeling van onderaannemers en exitplanning vereisen |
| Cryptografie | In gebruik | Van toepassing omdat klantgegevens, authenticatiesecrets, back-ups en gereguleerde financiële gegevens waarborgen voor vertrouwelijkheid en integriteit vereisen onder NIS2, DORA, GDPR, klantcontracten en interne risicobehandeling |
| Onafhankelijke beoordeling | Ja | Van toepassing omdat management, klanten en auditors assurance vereisen dat ISMS-beheersmaatregelen, SoA-besluiten, bewijsmateriaal en regelgevende koppelingen periodiek onafhankelijk worden beoordeeld |
Voor een fintech-SaaS-aanbieder kan één SoA-rij er als volgt uitzien:
| SoA-veld | Voorbeeldinvoer |
|---|---|
| Beheersmaatregel | A.5.19 Beheer van informatiebeveiliging in leveranciersrelaties |
| Toepasselijkheid | Ja |
| Onderbouwing | Van toepassing omdat cloudhosting, supporttooling en MDR-diensten invloed hebben op vertrouwelijkheid, beschikbaarheid, incidentdetectie en assurance richting gereguleerde klanten. Ondersteunt NIS2-verwachtingen voor de toeleveringsketen, DORA-verwachtingen voor ICT-risico van derde partijen voor financiële klanten, GDPR-verantwoordingsplicht van verwerkers en contractuele auditeisen. |
| Implementatiestatus | Geïmplementeerd en gemonitord |
| Eigenaar | Hoofd leveranciersmanagement |
| Bewijsmateriaal | Leveranciersregister, due-diligencechecklist, contractuele beveiligingsclausules, registraties van jaarlijkse beoordelingen, SOC- of assurancerapporten, beoordeling van onderaannemers, exitplan voor kritieke aanbieders |
| Gekoppelde risico’s | R-047, R-021, R-034 |
| Gekoppeld beleid | Beleid voor derde partijen en leveranciersbeveiliging, Beleid inzake juridische en regelgevende naleving, Beleid inzake risicobeheer |
| Beoordelingsfrequentie | Jaarlijks, en bij leverancierswijziging, majeur incident, nieuwe gereguleerde klant of uitbreiding van diensten |
Dit is auditgereed omdat het de beheersmaatregel verbindt met context, risico, verplichting, implementatie, eigenaarschap en bewijsmateriaal.
Hoe u uitsluitingen onderbouwt zonder auditblootstelling te creëren
Uitsluitingen zijn geen tekortkomingen. Slecht onderbouwde uitsluitingen zijn dat wel.
ISO/IEC 27001:2022 vereist dat de SoA uitgesloten Annex A-beheersmaatregelen onderbouwt. ISO/IEC 27005:2022 benadrukt dat niet-toepasselijkheid moet worden toegelicht en onderbouwd. Het Enterprise Informatiebeveiligingsbeleid van Clarysec stelt:
De baseline mag worden aangepast; uitsluitingen moeten echter met formele goedkeuring en onderbouwing in de SoA worden gedocumenteerd.
Dit is clausule 7.2.2 van het Informatiebeveiligingsbeleid.
Het mkb-Informatiebeveiligingsbeleid van Clarysec Mkb-Informatiebeveiligingsbeleid stelt:
Elke afwijking van dit beleid moet worden gedocumenteerd, met een duidelijke toelichting waarom de afwijking noodzakelijk is, welke alternatieve beschermingsmaatregelen van kracht zijn en welke datum is vastgesteld voor herbeoordeling.
Die eis komt uit clausule 7.2.1 in het mkb-Informatiebeveiligingsbeleid.
| Gebied van beheersmaatregelen | Onderbouwing voor uitsluiting | Vereiste beschermingsmaatregelen |
|---|---|---|
| Beheersmaatregelen voor veilige ontwikkeling van interne code | Niet van toepassing omdat het ISMS-toepassingsgebied uitsluitend een resellerservice omvat zonder interne softwareontwikkeling, zonder codewijzigingen en zonder CI/CD-pijplijn | Leveranciersassurance, wijzigingsgoedkeuring, intake van kwetsbaarheden, klantcommunicatie en jaarlijkse herbeoordeling |
| Fysieke beveiligingsmonitoring voor eigen faciliteiten | Niet van toepassing omdat de organisatie geen eigen datacenter, serverruimte of kantoorlocatie binnen het ISMS-toepassingsgebied heeft en alle productie-infrastructuur wordt beheerd door geaudite cloudproviders | Due diligence op cloudleveranciers, contractuele beheersmaatregelen, toegangsrechtenbeoordelingen, beoordeling van gedeelde verantwoordelijkheid en bewijsmateriaal uit assurancerapporten van aanbieders |
| Bepaalde on-premises mediabehandelingsactiviteiten | Niet van toepassing omdat binnen de dienst in scope geen verwijderbare media of on-premises opslag worden gebruikt | Endpointbeperkingen, DLP-monitoring waar passend, inventaris van bedrijfsmiddelen en periodieke validatie |
Voor NIS2 en DORA vereisen uitsluitingen extra zorgvuldigheid. Een SaaS-bedrijf moet logging, monitoring, back-ups, incidentbeheer, toegangscontrole, leveranciersbeveiliging of kwetsbaarhedenbeheer zelden uitsluiten. Zelfs wanneer een beheersmaatregel niet aan één specifiek risico is gekoppeld, kan deze nog steeds noodzakelijk zijn als basisbeveiliging, klantassurance, contractuele verwachting of wettelijke verplichting.
Het mkb-Beleid inzake risicobeheer van Clarysec herinnert teams er ook aan hoe geaccepteerd risico moet worden behandeld:
Accepteren: onderbouw waarom geen verdere actie nodig is en registreer het restrisico.
Die clausule, 6.1.1 in het mkb-Beleid inzake risicobeheer, is precies de denkwijze die nodig is voor uitsluitingen en restrisicobesluiten.
Incidentmelding: toon de workflow aan, niet alleen het bestaan van beleid
NIS2 Article 23 vereist gefaseerde melding van significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur na kennisname, melding binnen 72 uur, updates wanneer daarom wordt gevraagd en een eindrapport binnen één maand na de 72-uursmelding. DORA vereist dat financiële entiteiten majeure ICT-gerelateerde incidenten detecteren, beheren, classificeren, escaleren, communiceren en melden, getroffen cliënten informeren waar vereist, oorzaakanalyse uitvoeren en beheersmaatregelen verbeteren.
Een SaaS-aanbieder hoeft niet altijd rechtstreeks aan een DORA-autoriteit te rapporteren, maar moet mogelijk wel de rapportagetermijnen van financiële klanten ondersteunen. Daardoor zijn incidentbeheersmaatregelen zeer relevant in de SoA.
Een zwakke SoA zegt: “Incidentresponsbeleid bestaat.”
Een sterke SoA zegt: “Van toepassing omdat de organisatie incidenten die diensten, gegevens of gereguleerde klanten raken moet detecteren, beoordelen, classificeren, escaleren, communiceren, bewijsmateriaal bewaren, regelgevende rapportagetermijnen ondersteunen, getroffen klanten informeren waar contractueel vereist, en van incidenten leren.”
Bewijsmateriaal moet onder meer omvatten:
- Incidentresponsplan en escalatiematrix.
- Criteria voor ernstclassificatie.
- Workflow voor klantmelding.
- Beslisboom voor regelgevende melding waar van toepassing.
- Incidenttickets en tijdlijnen.
- Logboeken en monitoringalerts.
- Registraties van tabletop-oefeningen.
- Post-incident evaluatie en corrigerende maatregelen.
- Procedures voor bewaring van bewijsmateriaal.
Het Enterprise Beleid voor audit en toezicht op naleving van Clarysec Beleid voor audit en toezicht op naleving legt uit waarom dit belangrijk is:
Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of klantverzoeken om assurance.
Die doelstelling komt uit clausule 3.4 in het Beleid voor audit en toezicht op naleving.
Voor kleinere organisaties moet ook de bewaring van bewijsmateriaal expliciet zijn. Het mkb-Beleid voor audit en toezicht op naleving van Clarysec Mkb-beleid voor audit en toezicht op naleving stelt:
Bewijsmateriaal moet ten minste twee jaar worden bewaard, of langer wanneer certificering of klantovereenkomsten dit vereisen.
Dat is clausule 6.2.4 in het mkb-Beleid voor audit en toezicht op naleving.
Eén SoA, meerdere auditgesprekken
De beste SoA dupliceert geen raamwerken. Zij creëert een traceerbaar verhaal over beheersmaatregelen dat verschillende auditors kunnen begrijpen.
| Raamwerk of invalshoek | Wat de auditor of assessor zal vragen | Hoe de SoA helpt |
|---|---|---|
| ISO/IEC 27001:2022 | Waarom is deze Annex A-beheersmaatregel opgenomen of uitgesloten, wat is de implementatiestatus en waar is het bewijsmateriaal? | Koppelt besluiten over beheersmaatregelen aan risico’s, verplichtingen, implementatiestatus, eigenaren en bewijsmateriaal |
| NIS2 | Hoe functioneren governance, risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, toeleveringsketen, encryptie, toegangscontrole, beheer van bedrijfsmiddelen en training in de praktijk? | Koppelt verwachtingen uit Article 21 en Article 23 aan Annex A-beheersmaatregelen en operationele registraties |
| DORA | Hoe worden ICT-risico, incidentbeheer, testen van weerbaarheid, risico van derde partijen, contracten, auditrechten, exitplannen en toezicht door het management met bewijsmateriaal onderbouwd? | Laat zien welke beheersmaatregelen verplichtingen van financiële entiteiten of SaaS-leveranciersassurance ondersteunen |
| GDPR | Kan de organisatie integriteit, vertrouwelijkheid, verantwoordingsplicht, paraatheid voor inbreuken, ondersteuning van rechtmatige verwerking en beheersmaatregelen voor verwerkers aantonen? | Koppelt privacyverplichtingen aan toegangscontrole, cryptografie, logging, leveranciers-, incident-, bewaar- en bewijsbeheersmaatregelen |
| NIST CSF 2.0 | Hoe worden de uitkomsten Govern, Identify, Protect, Detect, Respond en Recover ondersteund door geïmplementeerde beheersmaatregelen? | Gebruikt dezelfde bewijsbasis om functionele dekking van cyberbeveiliging aan te tonen |
| COBIT 2019 en ISACA-audit | Zijn governancedoelstellingen, eigenaarschap van beheersmaatregelen, assuranceactiviteiten, metrieken en verantwoordingsplicht van het management gedefinieerd? | Verbindt SoA-besluiten met eigenaren, prestatiebeoordeling, onafhankelijke beoordeling en corrigerende maatregelen |
Een ISO 27001-auditor begint meestal bij de clausulelogica: scope, belanghebbenden, risicobeoordeling, risicobehandeling, SoA, doelstellingen, interne audit, directiebeoordeling en verbetering. Een NIS2-georiënteerde beoordelaar richt zich op evenredigheid, verantwoordingsplicht van management, training, toeleveringsketen, incidenttermijnen en impact op dienstverlening. Een DORA-georiënteerde klantassessor richt zich op ICT-risico, kritieke of belangrijke functies, majeure ICT-incidenten, testen van weerbaarheid, contractuele clausules, auditrechten, exitplannen, onderuitbesteding en concentratierisico. Een privacybeoordelaar richt zich op GDPR-verantwoordingsplicht en paraatheid voor inbreuken. Een COBIT 2019- of ISACA-achtige auditor toetst governance, metrieken, eigenaarschap, assurance en corrigerende maatregelen.
Daarom kan de SoA niet alleen door het beveiligingsteam worden onderhouden. Juridische zaken, privacy, inkoop, engineering, operations, HR en het uitvoerend leiderschap moeten eigenaarschap nemen.
Veelvoorkomende SoA-tekortkomingen in projecten voor NIS2- en DORA-gereedheid
Clarysec ziet in gereedheidsprojecten telkens dezelfde problemen:
- De SoA markeert beheersmaatregelen als van toepassing, maar er is geen risico, verplichting of zakelijke reden vastgelegd.
- NIS2 en DORA worden in beleidsdocumenten genoemd, maar niet gekoppeld aan beheersmaatregelen, eigenaren of bewijsmateriaal.
- Leveranciersbeheersmaatregelen zijn als geïmplementeerd gemarkeerd, maar er is geen leveranciersregister, criticaliteitsclassificatie, contractbeoordeling of exitplan.
- Incidentbeheersmaatregelen bestaan, maar het proces ondersteunt geen 24-uurs-, 72-uurs-, klant- of eindrapportageworkflows.
- Managementgoedkeuring wordt verondersteld, maar er is geen registratie van risicoacceptatie, SoA-goedkeuring of restrisicobesluit.
- Uitsluitingen zijn uit een sjabloon gekopieerd en sluiten niet aan op het feitelijke cloud-, remote-, SaaS- of fintechbedrijfsmodel.
- Bewijsmateriaal bestaat verspreid over tools, maar geen audittrail verbindt het bewijsmateriaal met de SoA.
- GDPR-verwerking van persoonsgegevens is niet gekoppeld aan beveiligingsmaatregelen, respons op inbreuken, leverancierscontracten of bewaring.
- Interne audit controleert documenten, maar toetst niet of de SoA de werkelijke implementatie weerspiegelt.
- De SoA wordt alleen vóór certificering bijgewerkt, niet na nieuwe klanten, leveranciers, incidenten, auditbevindingen of regelgevingswijzigingen.
Dit zijn geen papierproblemen. Het zijn governanceproblemen.
Praktische checklist voor een auditgereed ISO 27001-SoA
Gebruik deze checklist vóór een ISO 27001-certificeringsaudit, NIS2-gereedheidsbeoordeling, DORA-klantbeoordeling, bestuursvergadering of due-diligenceproces door investeerders.
| Controlepunt | Goed antwoord |
|---|---|
| Scope | Het ISMS-toepassingsgebied weerspiegelt diensten, klanten, gegevens, leveranciers, uitbestede interfaces en gereguleerde afhankelijkheden |
| Belanghebbenden | NIS2, DORA-klanten, GDPR-rollen, toezichthouders, klanten, leveranciers en interne stakeholders zijn geïdentificeerd |
| Compliance-register | Wettelijke, regelgevende, contractuele en klantverplichtingen zijn gekoppeld aan beleid, beheersmaatregelen en eigenaren |
| Risicocriteria | Juridische, operationele, privacy-, leveranciers-, weerbaarheids-, financiële en reputatie-impact zijn opgenomen |
| Risicoregister | Elk risico bevat beschrijving, waarschijnlijkheid, impact, score, eigenaar, behandelplan en restrisico |
| SoA-opname | Elke toepasselijke beheersmaatregel heeft een onderbouwing die is gekoppeld aan risico, verplichting, scope, contract of basisbeveiliging |
| SoA-uitsluiting | Elke uitgesloten beheersmaatregel heeft een specifieke, goedgekeurde, op bewijsmateriaal gebaseerde onderbouwing en een trigger voor herbeoordeling |
| Bewijsmateriaal | Elke toepasselijke beheersmaatregel heeft bewijsmateriaal in de vorm van beleid, procedure, configuratie, rapport, test, ticket, logboek, beoordeling of registratie |
| Managementgoedkeuring | Risico-eigenaren keuren behandelplannen en restrisico’s goed, en het management beoordeelt ISMS-prestaties |
| Onafhankelijke beoordeling | Interne audit of onafhankelijke beoordeling toetst de nauwkeurigheid van de SoA, de kwaliteit van bewijsmateriaal en de implementatiewerkelijkheid |
| Triggers voor bijwerking | SoA-updates vinden plaats na wijzigingen in diensten, leverancierswijzigingen, incidenten, nieuwe klanten, wijzigingen in regelgeving of auditbevindingen |
Maak van de SoA een verdedigbare compliancebrug
Elena’s bestuurspresentatie slaagde omdat zij geen drie losstaande complianceprojecten presenteerde. Zij presenteerde één beheerst, op bewijsmateriaal gebaseerd operationeel model dat is gebouwd op ISO/IEC 27001:2022, met de SoA als brug tussen regelgeving, risico, implementatie van beheersmaatregelen, bewijsmateriaal en toezicht door het management.
NIS2 en DORA maken ISO 27001 niet achterhaald. Zij maken een goed opgebouwde ISO 27001-Verklaring van Toepasselijkheid waardevoller. De SoA kan de centrale plaats worden waar uw organisatie uitlegt waarom beheersmaatregelen bestaan, waarom uitsluitingen verdedigbaar zijn, hoe bewijsmateriaal wordt bewaard, hoe leveranciers worden bestuurd, hoe incidenten worden geëscaleerd en hoe het management weet dat het ISMS werkt.
Uw onmiddellijke actie is eenvoudig:
- Open uw huidige SoA.
- Kies vijf beheersmaatregelen die als van toepassing zijn gemarkeerd en vraag: “Welk risico, welke verplichting of welk contract onderbouwt dit?”
- Kies vijf uitsluitingen en vraag: “Zou dit nog steeds logisch zijn voor een NIS2-, DORA-, GDPR- of ISO/IEC 27001:2022-auditor?”
- Controleer of elke toepasselijke beheersmaatregel actueel bewijsmateriaal heeft.
- Bevestig dat het management restrisico’s en SoA-besluiten heeft goedgekeurd.
- Werk het compliance-register, risicoregister en de SoA bij wanneer diensten, leveranciers, klanten, regelgeving of incidenten wijzigen.
Clarysec helpt organisaties dit te doen via de Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, beleidsets voor enterprises en mkb, tooling voor risicoregisters, SoA-sjablonen, auditvoorbereiding en cross-compliance-koppelingen voor NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 en klantassurance.
Als uw SoA niet kan beantwoorden waarom een beheersmaatregel bestaat, wie eigenaar is, welk bewijsmateriaal dit aantoont en welke verplichting ermee wordt ondersteund, is zij nog niet gereed. Gebruik Clarysec om er een auditgereed brugdocument voor compliance van te maken voordat een toezichthouder, auditor of klant dezelfde vragen als eerste stelt.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
