NIS2 2024/2690 ISO 27001-mapping voor cloudproviders
Om 08:17 op een dinsdag ontvangt Maria, CISO van een Europese managed service provider, de waarschuwing waarvoor iedere MSP vreest. Eén geprivilegieerd account voor beheer op afstand heeft waarschuwingen voor onmogelijk reisgedrag geactiveerd. Twee klanttenants vertonen afwijkende administratieve handelingen. Het SOC heeft al een kritieke incidentbridge geopend.
Om 09:00 sluit de CEO aan bij het overleg. De vragen veranderen onmiddellijk.
Vallen wij binnen de reikwijdte van NIS2? Is Uitvoeringsverordening (EU) 2024/2690 van de Commissie op ons van toepassing? Moeten wij binnen 24 uur een vroegtijdige waarschuwing doen? Welke klanten moeten worden geïnformeerd? Kunnen wij aantonen dat MFA, logging, segmentatie, kwetsbaarhedenbeheer, leveranciersbeheersmaatregelen en incidentescalatie vóór het incident operationeel waren?
Maria’s organisatie is ISO/IEC 27001:2022-gecertificeerd. Zij levert cloudbeheer, datacenterdiensten en managed security-ondersteuning aan klanten, waaronder een logistieke dienstverlener en een regionale bank. Het certificaat is relevant, maar beantwoordt de operationele vragen niet op zichzelf. Het juridische team heeft een conceptproces voor meldingen. De compliancemanager heeft een spreadsheet. De auditor heeft gevraagd om de Verklaring van Toepasselijkheid, testen van incidentrespons, logboeken van geprivilegieerde toegang, leveranciers-due diligence, bewijsmateriaal over gedeelde verantwoordelijkheid in de cloud en aannames voor bedrijfscontinuïteit.
Dit is het moment waarop NIS2 ophoudt alleen een juridische tekst te zijn en een operationeel vraagstuk rond beheersmaatregelen wordt.
Voor cloudcomputingdienstverleners, managed service providers, managed security service providers en datacenterproviders verhogen NIS2 en Uitvoeringsverordening 2024/2690 de lat van algemene beveiligingsintentie naar inspecteerbaar bewijsmateriaal over beheersmaatregelen. Governance, risicobeheer, toegangsbeheersing, beheer van bedrijfsmiddelen, kwetsbaarhedenbeheer, incidentrespons, leveranciersbeveiliging, logging, monitoring, encryptie, bedrijfscontinuïteit en fysieke weerbaarheid moeten als één samenhangend systeem functioneren.
ISO/IEC 27001:2022 is de beste ruggengraat voor dat systeem, maar alleen als de organisatie NIS2-vereisten vertaalt naar het ISMS, het risicoregister, de Verklaring van Toepasselijkheid, beleid en het bewijsmateriaalmodel. Een certificaat aan de muur is niet genoeg. Het echte werk is het opbouwen van een auditbare lijn van regelgeving naar risico, van risico naar beheersmaatregel, van beheersmaatregel naar beleid, en van beleid naar operationeel bewijsmateriaal.
Waarom NIS2 2024/2690 het compliancegesprek voor cloud en MSP verandert
NIS2 hanteert een sector-plus-omvangmodel, maar de categorieën digitale infrastructuur en ICT-dienstbeheer zijn bewust ruim geformuleerd. Op grond van NIS2 Article 2 en Article 3, gelezen in samenhang met Annex I en Annex II, kunnen veel organisaties worden geclassificeerd als essentiële of belangrijke entiteiten, waaronder cloudcomputingdienstverleners, datacenterdienstverleners, managed service providers, managed security service providers, DNS-providers, TLD-registers, content delivery networks en vertrouwensdienstverleners. Lidstaten moeten lijsten van essentiële en belangrijke entiteiten opstellen en periodiek herzien; de eerste deadline voor die lijst is vastgesteld op 17 april 2025.
Dit is relevant omdat cloud-, MSP-, MSSP- en datacenterproviders onderdeel zijn van de risicoketens van andere organisaties. Een compromittering van het cloud-control plane kan duizenden klantsystemen raken. Uitval van een datacenter kan doorwerken in bankwezen, zorg, logistiek en openbaar bestuur. Een inbreuk op MSP-inloggegevens kan uitgroeien tot een ransomware-incident bij meerdere klanten. Een detectiefout bij een MSSP kan de indamming bij gereguleerde klanten vertragen.
NIS2 Article 20 vereist dat bestuursorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en toezicht houden op de implementatie. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen op basis van een all-hazards-benadering. De basis omvat risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, afhandeling en openbaarmaking van kwetsbaarheden, beoordeling van de doeltreffendheid, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, MFA of continue authenticatie, beveiligde communicatie en noodcommunicatie.
Article 23 voegt gefaseerde melding van significante incidenten toe, waaronder een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur, tussentijdse rapportages wanneer daarom wordt gevraagd en een eindrapport binnen één maand na de melding of na incidentenafhandeling wanneer het incident voortduurt.
Uitvoeringsverordening 2024/2690 maakt deze verwachtingen concreter voor relevante digitale providers. In de praktijk zullen autoriteiten, klanten en auditors niet alleen vragen of beleid bestaat. Zij zullen vragen of de beheersmaatregelen zijn gemapt, toegewezen aan eigenaren, getest en onderbouwd met bewijsmateriaal.
ISO/IEC 27001:2022 vertaalt NIS2 naar de operationele ISMS-context
Een veelgemaakte fout bij NIS2-gereedheid is starten met een grote checklist en taken verdelen over IT, juridische zaken, SOC, infrastructuur, leveranciersmanagement en compliance. Dat kan activiteit opleveren, maar faalt vaak onder auditdruk omdat niemand kan aantonen waarom beheersmaatregelen zijn geselecteerd, hoe ze met risico’s samenhangen, wie het restrisico heeft geaccepteerd en welk bewijsmateriaal de doeltreffendheid aantoont.
ISO/IEC 27001:2022 geeft providers de structuur om dat falen te voorkomen.
Clauses 4.1 tot en met 4.4 vereisen dat de organisatie interne en externe onderwerpen vaststelt, belanghebbenden en hun eisen identificeert, bepaalt welke eisen via het ISMS worden behandeld en het ISMS-toepassingsgebied definieert, inclusief interfaces en afhankelijkheden. Voor een cloud- of MSP-provider moet het toepassingsgebied expliciet rekening houden met NIS2, Uitvoeringsverordening 2024/2690, beveiligingsbijlagen van klanten, door DORA gedreven klanteisen, cloudregio’s, onderaannemers, datacenterafhankelijkheden, platforms voor beheer op afstand, paden voor geprivilegieerde toegang en verplichtingen voor incidentmelding.
Clauses 5.1 tot en met 5.3 vereisen leiderschap, beleidsafstemming, middelen, communicatie, toegewezen verantwoordelijkheden en verantwoordingsplicht van het management. Dit ondersteunt NIS2 Article 20 rechtstreeks.
Clauses 6.1.1 tot en met 6.1.3 vereisen risicobeoordeling, risicobehandeling, risico-eigenaren, analyse van waarschijnlijkheid en gevolgen, selectie van beheersmaatregelen, vergelijking met Annex A, een Verklaring van Toepasselijkheid, een risicobehandelingsplan en formele acceptatie van restrisico. Hier wordt NIS2 operationeel. Elke regelgevende eis wordt een risicodriver, nalevingsverplichting, eis aan beheersmaatregelen of eis aan bewijsmateriaal.
Clarysec start dit werk met Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, in het bijzonder de fase Risicobeheer.
Vanaf Step 13, Risicobehandelingsplanning en Verklaring van Toepasselijkheid, instrueert Zenith Blueprint teams om traceerbaarheid op te bouwen tussen risico’s, beheersmaatregelen en regelgevende drijfveren:
“Verwijs regelgeving kruislings: als bepaalde beheersmaatregelen specifiek worden geïmplementeerd om aan GDPR, NIS2 of DORA te voldoen, kunt u dat opnemen in het risicoregister of in de SoA-opmerkingen. Bijvoorbeeld: beheersmaatregel 8.27 (veilige verwijdering van gegevens) kan zeer relevant zijn voor de GDPR-eis om persoonsgegevens te verwijderen; u kunt opnemen: ‘Van toepassing – ondersteunt GDPR Art.32 (beveiliging van de verwerking)’. Dit is niet vereist door ISO, maar het helpt aantonen dat u deze raamwerken hebt meegenomen.”
Step 14, Risicobehandelingsbeleid en regelgevende kruisverwijzingen, voegt de praktische mappingdiscipline toe:
“Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken waarin de belangrijkste beveiligingseisen van de regelgeving en de bijbehorende beheersmaatregelen/beleidslijnen in uw ISMS worden vermeld. Dit is niet verplicht in ISO 27001, maar het is een nuttige interne oefening om te waarborgen dat niets tussen wal en schip valt.”
Dat is het verschil tussen zeggen “wij zijn ISO-gecertificeerd” en aantonen “ons ISO/IEC 27001:2022-ISMS adresseert NIS2-uitvoeringsverordening 2024/2690.”
Uniforme mapping van NIS2 naar ISO/IEC 27001:2022-beheersmaatregelen
De onderstaande mapping is geen juridisch advies en geen vervanging voor analyse van nationale omzetting. Het is een praktische architectuur van beheersmaatregelen voor providers die een auditbare ISO/IEC 27001:2022-route naar NIS2-gereedheid nodig hebben.
| NIS2- en uitvoeringsverordeningsthema | ISO/IEC 27001:2022 ISMS-mechanisme | Belangrijkste Annex A-beheersgebieden | Clarysec-bewijsmateriaal voor implementatie |
|---|---|---|---|
| Governance en verantwoordingsplicht van het management | Clauses 4, 5, 6 en 9 definiëren context, leiderschap, risicoplanning en prestatiebeoordeling | 5.1 Beleidslijnen voor informatiebeveiliging, 5.2 Rollen en verantwoordelijkheden voor informatiebeveiliging, 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen | ISMS-toepassingsgebied, register van belanghebbenden, goedkeuring door het bestuur, risicoregister, SoA, notulen van directiebeoordelingen |
| Governance van clouddiensten | Risicobeoordeling, leveranciers-due diligence, gedeelde verantwoordelijkheid en selectie van beheersmaatregelen | 5.23 Informatiebeveiliging voor het gebruik van clouddiensten, 5.19 Informatiebeveiliging in leveranciersrelaties, 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten | Cloudinventaris, risicobeoordeling van providers, matrix voor gedeelde verantwoordelijkheid, contractclausules, bewijsmateriaal over cloudlogging |
| Geprivilegieerde toegang bij MSP en MSSP | Risicobehandeling voor klantomgevingen, beheerplatformen en supporttools | 5.15 Toegangscontrole, 5.16 Identiteitsbeheer, 5.18 Toegangsrechten, 8.2 Geprivilegieerde toegangsrechten, 8.5 Veilige authenticatie | PAM-registraties, MFA-rapportages, logboeken voor toegang op afstand, configuratie van bastion- of Zero Trust-gateway, toegangsrechtenbeoordelingen |
| Weerbaarheid van datacenters | Business impactanalyse, continuïteitsplanning en afhankelijkheidsbeheer | 5.30 ICT-gereedheid voor bedrijfscontinuïteit, 7.1 Fysieke beveiligingsperimeters, 7.2 Fysieke toegang, 8.13 Informatieback-up, 8.14 Redundantie | BIA, RTO- en RPO-registraties, DR-testrapport, fysieke toegangslogboeken, bewijsmateriaal van testen van stroomvoorziening en koeling |
| Incidentmelding en escalatie | Incidentproces gekoppeld aan juridische, contractuele en klantmeldings-triggers | 5.24 Planning en voorbereiding van informatiebeveiligingsincidentbeheer, 5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, 5.26 Respons op informatiebeveiligingsincidenten, 5.27 Leren van informatiebeveiligingsincidenten | Draaiboek voor vroegtijdige waarschuwing binnen 24 uur, workflow voor melding binnen 72 uur, incidentregister, post-incident evaluatie |
| Afhandeling en openbaarmaking van kwetsbaarheden | Risicogebaseerde behandeling van kwetsbaarheden, afhandeling van uitzonderingen en evaluatie van doeltreffendheid | 8.8 Beheer van technische kwetsbaarheden, 8.9 Configuratiebeheer, 8.32 Wijzigingsbeheer, 8.16 Monitoringactiviteiten | Scanresultaten, remediatie-SLA’s, goedkeuringen van uitzonderingen, patchrapporten, Threat Intelligence-input |
| Beveiliging van de toeleveringsketen | Eisen van belanghebbenden en leveranciersrisico geïntegreerd in het ISMS | 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Informatiebeveiliging opnemen in leveranciersovereenkomsten, 5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten | Leveranciersclassificatie, due-diligencevragenlijsten, contractclausules, auditrechten, onderaannemersregister, exitplannen |
| Logging, monitoring en onderzoek | Detectie, bewijsmateriaal, tijdcorrelatie en ondersteuning van incidentonderzoek | 8.15 Logging, 8.16 Monitoringactiviteiten, 8.17 Kloksynchronisatie, 5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen | SIEM-dekkingskaart, bewijs van logretentie, registraties van afstemming van waarschuwingen, registraties van kloksynchronisatie, bewijsmateriaal voor incidentcorrelatie |
| Netwerk- en tenantisolatie | Beveiligde architectuur, segmentatie en beperkte administratieve paden | 8.20 Netwerkbeveiliging, 8.22 Scheiding van netwerken, 8.23 Webfiltering, 8.24 Gebruik van cryptografie | Netwerkdiagrammen, firewallregels, cloud security groups, VPC- of subnetregels, resultaten van segmentatietesten |
Deze mapping wordt krachtig wanneer zij wordt ingebed in het risicoregister en de Verklaring van Toepasselijkheid. Een provider kan bijvoorbeeld een risicoscenario opnemen met de titel “Compromittering van platform voor beheer op afstand leidt tot ongeautoriseerde handelingen in klantomgevingen.” Beheersmaatregelen omvatten MFA, privileged access management (PAM), segmentatie, logging, kwetsbaarhedenbeheer, leveranciersbeveiliging, incidentplanning en procedures voor klantmelding. In de SoA-opmerkingen kan worden verwezen naar NIS2 Article 21, Article 23, Uitvoeringsverordening 2024/2690, klantcontracten en DORA-eisen voor customer due diligence waar relevant.
Cloudgovernance: ISO-beheersmaatregel 5.23 is een NIS2-anker
Voor cloudproviders en MSP’s die clouddiensten gebruiken om klantdiensten te leveren, is ISO/IEC 27001:2022 Annex A-beheersmaatregel 5.23, Informatiebeveiliging voor het gebruik van clouddiensten, een van de belangrijkste ankers.
Zenith Controls: The Cross-Compliance Guide Zenith Controls vat beheersmaatregel 5.23 samen als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, gekoppeld aan beveiliging van leveranciersrelaties, governance, ecosysteemrisico en bescherming. De maatregel dekt governance van clouddiensten, gedeelde verantwoordelijkheid, providerbeoordeling, inventarissen, gegevenslocatie, logging, encryptie, identiteitsrollen, monitoring, contractclausules, leveranciersrisico, cloudexit en weerbaarheidsplanning.
De fase Controls in Action van Zenith Blueprint, Step 23, legt de praktische reden uit:
“De cloud is geen bestemming meer, maar de standaard. Beheersmaatregel 5.23 erkent deze realiteit en vereist dat informatiebeveiliging expliciet wordt meegenomen in de selectie, het gebruik en het beheer van clouddiensten; niet als bijzaak, maar als ontwerpprincipe vanaf het allereerste begin.”
Voor een MSP moet elk platform voor monitoring en beheer op afstand, klantportaal, ticketingtool, platform voor beveiligingstelemetrie, back-updienst, clouddirectory en SaaS-beheerconsole onder governance vallen. Voor een datacenterprovider kan cloudgovernance van toepassing zijn op monitoringplatforms, bezoekersbeheersystemen, integraties met fysieke toegangscontrole, systemen voor beheer op afstand en klantportaalinfrastructuur.
Clarysec’s Enterprise Cloud Usage Policy Cloud Usage Policy stelt due diligence voorafgaand aan activering verplicht:
“Elk gebruik van cloud moet vóór activering risicogebaseerde due diligence ondergaan, inclusief providerbeoordeling, validatie van juridische naleving en validatie van beheersmaatregelen.”
Uit sectie “Governancevereisten”, beleidsclausule 5.2.
Voor kleinere providers creëert de Cloud Usage Policy-sme Cloud Usage Policy-sme - SME een lichtgewicht goedkeuringsmodel:
“Elk gebruik van clouddiensten moet vóór implementatie of abonnement worden beoordeeld en goedgekeurd door de Algemeen directeur (GM).”
Uit sectie “Governancevereisten”, beleidsclausule 5.1.
Beide benaderingen ondersteunen dezelfde NIS2-verwachting: het risico van cloudafhankelijkheden moet worden begrepen voordat de dienst onderdeel wordt van de leveringsketen.
Incidentrespons: de 24-uursklok start voordat het rapport is opgesteld
NIS2 Article 23 is strikt omdat de rapportagetermijn begint bij bewustwording van een significant incident, niet op het moment waarop een volledige oorzaakanalyse beschikbaar is. De uitdaging voor providers is snel vaststellen of een gebeurtenis significant is, welke klanten zijn geraakt, of persoonsgegevens betrokken zijn, of er grensoverschrijdende impact op de dienstverlening bestaat en welke contractuele termijnen zijn gaan lopen.
ISO/IEC 27001:2022 Annex A-beheersmaatregel 5.24, Planning en voorbereiding van informatiebeveiligingsincidentbeheer, is de planningsmaatregel. Zenith Controls vat deze samen als een corrigerende beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, gekoppeld aan Respond- en Recover-concepten, governance, gebeurtenisbeheer en verdediging. De maatregel omvat rollen, verantwoordelijkheden, escalatiepaden, communicatieprotocollen, gereedheid voor regelgevende meldingen, afstemming met logging en monitoring, integratie met bedrijfscontinuïteit en herstel na verstoringen, leren na incidenten en mapping naar NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 en COBIT 2019.
Clarysec’s Incident Response Policy-sme Incident Response Policy-sme - SME maakt van de eerste beslissing een tijdgebonden eis:
“De Algemeen directeur moet, met input van de IT-provider, alle incidenten binnen één uur na melding classificeren op ernst.”
Uit sectie “Governancevereisten”, beleidsclausule 5.3.1.
Die classificatie binnen één uur ondersteunt de operationele discipline die nodig is voor NIS2-analyse van een vroegtijdige waarschuwing binnen 24 uur, GDPR-beoordeling van een inbreuk in verband met persoonsgegevens, DORA-klantescalatie en triage van contractuele meldingen.
De beslisboom voor incidenten van een provider moet vier vragen beantwoorden:
- Is er een bevestigde of vermoedelijke compromittering van vertrouwelijkheid, integriteit of beschikbaarheid?
- Heeft de gebeurtenis gevolgen voor dienstverlening, klantomgevingen, gereguleerde klanten, persoonsgegevens of kritieke functies?
- Kan de gebeurtenis ernstige operationele verstoring, financieel verlies of materiële of immateriële schade veroorzaken?
- Welke meldingsverplichtingen zijn van toepassing: NIS2, GDPR, DORA-klantverplichtingen, contractuele SLA’s of verwachtingen van nationale toezichthouders?
De beslisboom moet vóór een echt incident worden getest in tabletop-oefeningen.
Kwetsbaarhedenbeheer: toon risicoreductie aan vóór impact ontstaat
NIS2 vereist afhandeling en openbaarmaking van kwetsbaarheden. Voor klanten en toezichthouders is kwetsbaarhedenbeheer een van de eenvoudigst meetbare beheersgebieden, omdat het duidelijk bewijsmateriaal oplevert: scandekking, patchtermijnen, goedkeuringen van uitzonderingen, analyse van uitgebuite kwetsbaarheden en registraties van herstelmaatregelen.
ISO/IEC 27001:2022 Annex A-beheersmaatregel 8.8, Beheer van technische kwetsbaarheden, wordt in Zenith Controls samengevat als een preventieve beheersmaatregel voor vertrouwelijkheid, integriteit en beschikbaarheid, gekoppeld aan Identify en Protect, threat and vulnerability management, governance, ecosysteem, bescherming en verdediging. De maatregel omvat identificatie, beoordeling en prioritering van kwetsbaarheden, patching, compenserende beheersmaatregelen, integratie van Threat Intelligence, openbaarmaking van kwetsbaarheden, verantwoordelijkheden voor cloud- en applicatiekwetsbaarheden, auditbewijsmateriaal en remediatietermijnen.
Clarysec’s Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy geeft auditors een concreet toetsingsmodel:
“De organisatie moet alle gedetecteerde kwetsbaarheden classificeren met behulp van een gestandaardiseerde methodologie (bijv. CVSS v3.x) en remediatietermijnen toepassen die zijn afgestemd op bedrijfskritikaliteit: 5.2.1 Kritiek (CVSS 9.0-10.0): onmiddellijke beoordeling; patchtermijn van maximaal 72 uur. 5.2.2 Hoog (7.0-8.9): respons binnen 48 uur; patchtermijn van 7 kalenderdagen. 5.2.3 Middel (4.0-6.9): respons binnen 5 dagen; patchtermijn van 30 kalenderdagen. 5.2.4 Laag (<4.0): respons binnen 10 dagen; patchtermijn van 60 kalenderdagen.”
Uit sectie “Governancevereisten”, beleidsclausule 5.2.
Voor een cloudprovider moet dit hypervisorcomponenten, containerimages, orchestratielagen, klantgerichte API’s, CI/CD-pijplijnen, beheerconsoles en bibliotheken van derden omvatten. Voor een MSP is de kernvraag of interne kwetsbaarheden worden gescheiden van door klanten beheerde kwetsbaarheden en of contracten de verantwoordelijkheid definiëren. Voor een datacenterprovider kan het toepassingsgebied gebouwbeheersystemen, toegangscontrolesystemen, monitoringplatforms, remote-hands-tooling en netwerkinfrastructuur omvatten.
Het model voor gedeelde verantwoordelijkheid moet worden gedocumenteerd. Een provider is mogelijk niet eigenaar van elke patch, maar moet het risico nog steeds beheren, de klant waar passend informeren en aantonen dat verantwoordelijkheidsgrenzen worden begrepen.
Logging, monitoring en segmentatie maken incidenten onderzoekbaar
Wanneer een providerincident klantimpact krijgt, zijn de eerste vragen over bewijsmateriaal eenvoudig: wie heeft ingelogd, vanaf waar, met welk privilege, in welke tenant, wat is gewijzigd, welke logboeken bestaan en waren administratieve paden gesegmenteerd?
Clarysec’s Enterprise Logging and Monitoring Policy Logging and Monitoring Policy vereist dat gedekte systemen de logboeken genereren die responders en auditors nodig hebben:
“Alle gedekte systemen moeten logboeken genereren die het volgende vastleggen: 6.1.1.1 Gebruikersauthenticatie en toegangspogingen 6.1.1.2 Activiteiten van geprivilegieerde gebruikers 6.1.1.3 Configuratiewijzigingen 6.1.1.4 Mislukte toegangspogingen of systeemgebeurtenissen 6.1.1.5 Malwaredetecties en beveiligingswaarschuwingen 6.1.1.6 Externe communicatie en triggers van firewallregels”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.
Voor mkb-organisaties die afhankelijk zijn van externe providers voegt de Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME een contractuele eis toe:
“Contracten moeten providers verplichten logboeken ten minste 12 maanden te bewaren en op verzoek toegang te verlenen.”
Uit sectie “Governancevereisten”, beleidsclausule 5.5.1.3.
Segmentatie is even belangrijk. De Network Security Policy-sme Network Security Policy-sme - SME bepaalt:
“Interne netwerken moeten naar functie worden gesegmenteerd (bijv. finance, gast, IoT, administratieve systemen).”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.
De fase Controls in Action van Zenith Blueprint, Step 20, geeft de praktische auditprocedure voor netwerkarchitectuur en segmentatie. Deze instrueert teams om de netwerkopzet te beoordelen en te documenteren, firewallregels, IPS/IDS- en configuraties voor toegang op afstand te verifiëren, te bevestigen dat cloud security groups en VPC- of subnetregels overeenkomen met de beoogde architectuur, interne en externe netwerkdiensten te inventariseren en te valideren dat gevoelige systemen niet bereikbaar zijn vanaf algemene gebruikers-VLAN’s of gastnetwerken.
Voor een MSP mogen tools voor beheer op afstand niet plat op het kantoornetwerk staan. Voor een datacenterprovider moeten beheerinterfaces voor stroom, koeling, toegangscontrole en klantnetwerkdiensten geïsoleerd en gemonitord worden. Voor een cloudprovider moet toegang tot het control plane worden beperkt via identiteit, netwerk, apparaatstatus en geprivilegieerde workflows.
Leveranciersbeveiliging: de provider is ook klant
Cloud-, MSP-, MSSP- en datacenterproviders zijn leveranciers van gereguleerde klanten, maar zij zijn ook klanten van softwareleveranciers, telecomcarriers, identiteitsproviders, SaaS-platformen, hardwareleveranciers, onderaannemers en infrastructuurexploitanten.
NIS2 maakt beveiliging van de toeleveringsketen tot een kernvereiste. DORA, dat vanaf 17 januari 2025 van toepassing is, maakt ICT-risicobeheer voor derde partijen centraal voor financiële entiteiten. NIS2 Article 4 en Recital 28 erkennen DORA als de sectorspecifieke rechtshandeling van de Unie voor financiële entiteiten waar vereisten overlappen. Dit neemt de druk op cloud- en MSP-providers niet weg. Het vergroot die druk, omdat financiële klanten vereisten op DORA-niveau, auditrechten, weerbaarheidstesten, exitstrategieën en verwachtingen voor incidentmelding contractueel opleggen aan leveranciers.
Clarysec’s Enterprise Third party and supplier security policy Third party and supplier security policy vereist gecontroleerde toegang van derden:
“Alle toegang van derden moet worden gelogd en gemonitord en, waar haalbaar, worden gesegmenteerd via bastionhosts, VPN’s of Zero Trust-gateways.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.3.2.
De Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME formuleert minimale privileges in directe termen:
“Leveranciers mogen alleen toegang krijgen tot de minimale systemen en gegevens die nodig zijn om hun functie uit te voeren.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.
Deze clausules sluiten vanzelf aan op ISO/IEC 27001:2022 Annex A-beheersmaatregelen 5.19, 5.20, 5.21 en 5.22. Zij ondersteunen ook GDPR-governance voor verwerkers en subverwerkers, DORA-beoordelingen van risico’s van derde partijen en auditvragenlijsten van klanten.
Bedrijfscontinuïteit en datacenterweerbaarheid: bewijs de aannames
NIS2 Article 21 omvat bedrijfscontinuïteit, back-upbeheer, herstel na verstoringen en crisismanagement. DORA Articles 11 tot en met 14 vereisen ICT-bedrijfscontinuïteitsbeleid, respons- en herstelplannen, business impactanalyse, back-upbeleid, herstelprocedures, hersteldoelstellingen, testen, post-incident evaluaties en crisiscommunicatie voor financiële entiteiten.
Voor cloud- en datacenterproviders is continuïteit geen map in de kast. Het gaat om architectuur, capaciteit, contracten, afhankelijkheden, herstelbewijsmateriaal en geteste aannames.
Clarysec’s Enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy vereist jaarlijkse BIA en beoordeling na significante wijzigingen:
“Business Impact Analysis (BIA) moet ten minste jaarlijks worden uitgevoerd voor alle kritieke bedrijfseenheden en worden beoordeeld bij significante wijzigingen in systemen, processen of afhankelijkheden. BIA-output moet het volgende definiëren: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Kritieke afhankelijkheden (systemen, leveranciers, personeel)”
Uit sectie “Governancevereisten”, beleidsclausule 5.2.
In een datacenterscenario moet de BIA stroomfeeds, UPS, generatoren, brandstofcontracten, koeling, brandblussing, netwerkcarriers, fysieke toegangssystemen, remote hands, monitoring, reservehardware en klantcommunicatiekanalen omvatten. In een cloudscenario moet zij regio’s, beschikbaarheidszones, replicatie, onveranderbaarheid van back-ups, identiteitsafhankelijkheden, DNS, certificaatautoriteiten, API-gateways en supportsystemen omvatten. In een MSP-scenario moet zij tooling voor beheer op afstand, kluizen voor geprivilegieerde toegang, EDR-consoles, ticketing, documentatierepositories en noodcommunicatie omvatten.
ISO 22301 kan de discipline voor Business Continuity Management versterken, terwijl ISO/IEC 27005:2022 risicocriteria, behandelplanning, monitoring, bewijsmateriaal en voortdurende verbetering ondersteunt. Dit is nuttig omdat NIS2-gereedheid vereist dat de organisatie juridische, contractuele, operationele, leveranciers-, technologie-, financiële, proces- en mensfactoren consolideert in één risicoproces.
Praktisch risicospoor voor een MSP-inbreuk via toegang op afstand
Een praktische workshop kan beginnen met één scenario:
“Compromittering van geprivilegieerde toegang op afstand leidt tot ongeautoriseerde toegang tot klantsystemen, verstoring van dienstverlening, mogelijke blootstelling van persoonsgegevens en regelgevende meldingsverplichtingen.”
Maak een rij in het risicoregister aan en voltooi de traceerbaarheid.
| Veld | Voorbeeldvermelding |
|---|---|
| Risico-eigenaar | Hoofd Managed Services |
| Bedrijfsmiddelen en processen | Platform voor beheer op afstand, klantbeheeraccounts, kluis voor privileges, ticketing, SIEM, klantomgevingen |
| Dreigingsgebeurtenis | Diefstal van inloggegevens, MFA-fatigue, diefstal van tokens, uitgebuite RMM-kwetsbaarheid, kwaadwillige insider |
| Impact | Compromittering van klanten, dienstuitval, contractbreuk, significant NIS2-incident, inbreuk in verband met persoonsgegevens onder GDPR, DORA-klantescalatie |
| Bestaande beheersmaatregelen | MFA, PAM, principe van minimale privileges, segmentatie, logging, kwetsbaarheidsscans, incidentresponsplan |
| Vereiste behandeling | Conditional access aanscherpen, just-in-time-beheer afdwingen, tenantisolatie verbeteren, logretentie verhogen, meldingsdraaiboek testen |
| ISO/IEC 27001:2022-bewijsmateriaal | Risicobeoordeling, SoA, toegangsbeoordeling, logvoorbeelden, kwetsbaarheidsrapporten, tabletop-oefening, directiebeoordeling |
| NIS2-mapping | Article 21 risicobeheer en Article 23 incidentmelding, plus operationele maatregelen uit de Uitvoeringsverordening |
| Klantmapping | Contractuele melding, auditrechten, beveiligingsbijlage, DORA-afgestemde vragenlijsten waar van toepassing |
| Besluit over restrisico | Geaccepteerd door risico-eigenaar na behandeling, elk kwartaal beoordeeld |
Werk vervolgens de Verklaring van Toepasselijkheid bij. Leg voor elke relevante Annex A-beheersmaatregel uit waarom deze van toepassing is en welk NIS2-thema zij ondersteunt. Verzamel tot slot bewijsmateriaal vóór een audit: rapportages over MFA-afdwinging, lijsten van geprivilegieerde accounts, instellingen voor logretentie, RMM-patchstatus, SIEM-waarschuwingen, registraties van incidentclassificatie, goedkeuringen van leverancierstoegang en tabletop-resultaten.
Hoe verschillende auditors dezelfde beheersingsomgeving toetsen
Een geïntegreerd ISMS moet verschillende assuranceperspectieven ondersteunen zonder voor elk raamwerk afzonderlijke evidence packs te creëren.
| Auditorperspectief | Waar zij op focussen | Typisch gevraagd bewijsmateriaal |
|---|---|---|
| ISO/IEC 27001:2022-auditor | Of NIS2-, DORA- en GDPR-eisen zijn weerspiegeld in context, toepassingsgebied, risicobeoordeling, SoA, interne audit en directiebeoordeling | ISMS-toepassingsgebied, register van belanghebbenden, risicomethodologie, risicoregister, SoA, behandelplan, beleid, intern auditrapport, directiebeoordeling |
| NIS2-bevoegde autoriteit of gedelegeerde beoordelaar | Of maatregelen voor cyberbeveiligingsrisicobeheer passend en evenredig zijn en of melding van significante incidenten operationeel is | NIS2-mapping, procedure voor incidentclassificatie, workflow voor 24 en 72 uur, toezicht door het bestuur, technisch bewijsmateriaal over beheersmaatregelen, bewijsmateriaal over leveranciersbeveiliging |
| DORA-klantbeoordelaar | Of ICT-risico’s van derde partijen, weerbaarheidstesten, incidentmelding, auditrechten en exitplanning voldoen aan verwachtingen in de financiële sector | Contractclausules, onderaannemersregister, weerbaarheidstesten, incident-SLA’s, exitplan, auditrapporten, ondersteuning voor concentratierisico |
| GDPR-auditor of DPO-beoordeling | Of risico’s op inbreuken in verband met persoonsgegevens, verwerkersverplichtingen, vertrouwelijkheid, integriteit en verantwoordingsplicht zijn geadresseerd | Registraties van verwerkingsactiviteiten, DPA-voorwaarden, workflow voor beoordeling van inbreuken, toegangslogboeken, encryptiebewijsmateriaal, beheersmaatregelen voor bewaring en verwijdering |
| NIST-georiënteerde beoordelaar | Of capaciteiten voor identificeren, beschermen, detecteren, reageren en herstellen zijn geïmplementeerd en gemeten | Inventaris van bedrijfsmiddelen, toegangscontroles, kwetsbaarheidsgegevens, SIEM-dekking, responsdraaiboeken, hersteltests, metrieken |
| COBIT 2019- of ISACA-auditor | Of governancedoelstellingen, verantwoordelijkheden, risico-eigenaarschap, monitoring van beheersmaatregelen en assuranceprocessen zijn ingericht | Governancecharters, RACI, risicobereidheid, eigenaarschap van beheersmaatregelen, KPI/KRI-rapportage, assuranceplan, opvolging van corrigerende maatregelen |
Hier helpt Zenith Controls als cross-compliancegids. Voor beheersmaatregelen zoals 5.23, 5.24 en 8.8 verbindt het de verwachtingen van ISO/IEC 27001:2022-beheersmaatregelen met thema’s uit NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF en ISO 22301. Het doel is niet om afzonderlijke complianceprogramma’s te creëren. Het doel is één architectuur voor bewijsmateriaal, gelabeld naar beheersmaatregel, risico, regelgevende drijfveer en eigenaar.
Het Clarysec-implementatiepatroon
Voor cloud-, MSP-, MSSP- en datacenterproviders moet het werk in vijf lagen verlopen.
Eerst: bevestig het toepassingsgebied. Bepaal of de organisatie en diensten binnen de reikwijdte van NIS2 vallen, welke regels van de lidstaat van toepassing zijn, of Uitvoeringsverordening 2024/2690 van toepassing is op de providercategorie en of klanten DORA-, GDPR-, NIST- of sectorspecifieke verplichtingen opleggen.
Ten tweede: bouw de ISMS-context op. Identificeer onder ISO/IEC 27001:2022 clauses 4 en 5 belanghebbenden, wettelijke verplichtingen, klantverplichtingen, leveranciersafhankelijkheden, dienstgrenzen en managementverantwoordelijkheden.
Ten derde: voer risicobeoordeling en risicobehandeling uit volgens de principes van ISO/IEC 27005:2022. Consolideer NIS2, DORA, GDPR, contracten, intern beleid en dienstrisico’s in één register met basisvereisten. Definieer risicocriteria, eigenaren, waarschijnlijkheid, impact, behandelopties, keuzes van beheersmaatregelen en goedkeuringen van restrisico.
Ten vierde: map beheersmaatregelen naar de Verklaring van Toepasselijkheid. Gebruik Zenith Blueprint Steps 13 en 14 om risico’s te herleiden naar Annex A-beheersmaatregelen en regelgevende verwachtingen. Gebruik Zenith Controls om te begrijpen hoe beheersmaatregelen zoals 5.23, 5.24, 8.8, 5.20 en 5.30 zich verhouden tot verschillende raamwerken en auditperspectieven.
Ten vijfde: operationaliseer bewijsmateriaal. Beleid is niet genoeg. De beleidsbibliotheek van Clarysec biedt afdwingbare eisen voor cloudgoedkeuring, leverancierstoegang, logging, kwetsbaarheidsremediatie, netwerksegmentatie, incidentclassificatie en continuïteitsplanning. Het evidence pack toont aan dat deze eisen werken.
Volgende stap: zet NIS2-druk om in auditgereed weerstandsvermogen
NIS2-uitvoeringsverordening 2024/2690 vereist geen chaos. Zij vereist traceerbaarheid, eigenaarschap en bewijs.
Als u cloudserviceprovider, MSP, MSSP of datacenteroperator bent, begin dan met uw diensten, klanten, afhankelijkheden, incidentscenario’s en verplichtingen inzake bewijsmateriaal. Voer vervolgens een gestructureerde mapping van NIS2 naar ISO/IEC 27001:2022 uit:
- Bevestig of uw entiteit en diensten binnen de reikwijdte vallen.
- Map NIS2- en uitvoeringsverordeningsthema’s naar uw ISMS-toepassingsgebied.
- Werk het risicoregister en de Verklaring van Toepasselijkheid bij.
- Pas Clarysec-beleid toe voor cloudgebruik, leveranciersbeveiliging, logging, kwetsbaarhedenbeheer, incidentrespons, netwerkbeveiliging en continuïteit.
- Gebruik Zenith Blueprint Zenith Blueprint Steps 13, 14, 20 en 23 om traceerbaarheid en operationeel bewijsmateriaal te creëren.
- Gebruik Zenith Controls Zenith Controls om ISO/IEC 27001:2022-beheersmaatregelen kruislings te mappen tegen verwachtingen uit NIS2, DORA, GDPR, NIST en COBIT 2019.
- Test het bewijsmateriaal via een auditsimulatie voordat een klant, toezichthouder of certificeringsauditor erom vraagt.
Clarysec kan u helpen verder te gaan dan checklistcompliance en een geïntegreerd ISMS te bouwen dat bestand is tegen auditdruk vanuit NIS2, DORA, GDPR en klanten. Download de relevante Clarysec-toolkits, boek een mappingworkshop of vraag een beoordeling van auditgereedheid aan om regelgevende complexiteit om te zetten in verdedigbare informatiebeveiligingsgovernance en operationele weerbaarheid.
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
