NIS2 en ISO 27001: hergebruik controls, onderzoek de lacunes

Een ISO 27001-programma kan een sterke operationele structuur voor NIS2 bieden: risicobeoordeling, verantwoordelijke eigenaren, controls, bewijs en verbetering. De volgende stap is een beoordeling per eis van wat die structuur werkelijk afdekt.

Voor een CTO is de nuttige vraag niet of de frameworks overlappen. De vraag is of een geïmplementeerde control de relevante dienst beschermt, aan de toepasselijke verplichting voldoet en bewijs oplevert dat die conclusie ondersteunt. Hergebruik de implementatie waar aan die voorwaarden is voldaan; behoud juridische en operationele verschillen waar dat niet zo is.

Begrijp wat elk framework vastlegt

ISO/IEC 27001 specificeert eisen voor een afgebakend managementsysteem voor informatiebeveiliging, oftewel een ISMS. De clausules 4 tot en met 10 behandelen de managementstructuur, waaronder risicobehandeling, evaluatie van prestaties en verbetering. Annex A bevat 93 referentiecontrols in de categorieën organisatorisch, mensen, fysiek en technologisch. De toepasselijkheid van controls is risicogebaseerd en geen eis om elke control op identieke wijze te implementeren. ISO 27002 biedt implementatierichtlijnen.

NIS2 is een Europese richtlijn die via nationaal recht wordt geïmplementeerd. De toepasselijkheid hangt af van sector, omvang, dienst en specifieke opnameregels. Bijlage I en bijlage II noemen relevante sectoren, maar de sector alleen bepaalt niet of een organisatie een essentiële of belangrijke entiteit is. Sommige entiteiten vallen er ongeacht hun omvang onder.

De praktische verschillen zijn:

Certificering wordt uitgevoerd door onafhankelijke certificatie-instellingen, niet door ISO. Zij stelt geen naleving van NIS2 vast, en NIS2 vereist in het algemeen geen ISO 27001-certificering. Handhaving kan toezichtsmaatregelen en sancties omvatten; ISO-certificering heeft een ander assurance-doel.

Begin met overeenkomende grenzen

Vergelijk de gecertificeerde ISMS-scope met de juridische entiteiten en diensten die onder NIS2 vallen. Een certificaat dat een ontwikkelteam dekt, kan productieactiviteiten, een andere dochteronderneming of aanvullende locaties buiten de grens laten.

Maak een scopevergelijking waarin u het volgende vastlegt:

• De juridische entiteiten, landen en diensten die eronder vallen en de grondslag voor opname.
• Relevante systemen, netwerken, locaties en ondersteunende leveranciers.
• De ISMS-scope, de certificaatscope en uitsluitingen.
• Toepasselijke nationale eisen, sectorregels en verantwoordelijke autoriteiten, inclusief toepasselijke registratieplichten, vereiste gegevens over de entiteit, indieningskanalen en verplichtingen om gegevens bij te werken.
• Wie de toepasselijkheidsbeoordeling heeft goedgekeurd en wanneer die opnieuw moet worden bekeken.

Maak onderscheid tussen een scopelacune en een controllacune. Een productieomgeving buiten het ISMS kan al goede toegangscontrols hebben, maar die controls hebben binnen de NIS2-werkstroom nog steeds eigenaarschap, beoordeling en bewijs nodig.

Controleer sectorspecifieke wetgeving voordat u verplichtingen dupliceert. Artikel 4 gaat over de verhouding tot sectorspecifieke rechtshandelingen van de Unie. Voor financiële entiteiten vereist de verhouding tot DORA een rolspecifieke analyse. Raadpleeg voor activiteiten in Duitsland de NIS2-informatie van het BSI in plaats van aan te nemen dat bestaande KRITIS-plichten en NIS2-plichten identiek zijn.

Map geïmplementeerde controls, geen overeenkomende labels

Artikel 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen. De tien minimale maatregelgebieden bieden een vertrekpunt voor mapping, maar een vergelijkbare formulering is een nuttige aanwijzing, geen bewijs van gelijkwaardigheid.

Gebruik het volgende als reviewvragen, niet als automatische verklaringen van dekking:

De Verklaring van Toepasselijkheid legt de noodzakelijke controls vast en de redenering voor opname of uitsluiting. Zij is niet uitwisselbaar met het risicobehandelplan, bevindingen uit interne audits of verslagen van de directiebeoordeling. Gebruik die artefacten samen om zowel ontwerp als werking uit te leggen.

Een beleid legt verwachtingen vast. Een configuratie-export kan de implementatie laten zien. Resultaten van toegangsreviews, remediatietickets en testregistraties kunnen de werking aantonen. Hergebruik bewijs alleen waar systeem, periode en beoordelingsdoel overeenkomen.

Vermijd vaste overlappercentages. Dekking hangt af van implementatie en juridische scope; een universeel getal kan niet vaststellen of u gereed bent.

Bouw een meldpad dat onder druk kan werken

Een op ISO afgestemd responsplan kan detectie, inperking, onderzoek en herstel ondersteunen zonder melding aan toezichthouders te definiëren. Artikel 23 van NIS2 voegt meldplichten toe voor significante incidenten.

De meldfasen van de richtlijn omvatten in het algemeen:

• Een vroegtijdige waarschuwing zonder onredelijke vertraging en binnen 24 uur na kennisname van een significant incident.
• Een incidentmelding zonder onredelijke vertraging en binnen 72 uur, die de vroegtijdige waarschuwing bijwerkt en een eerste beoordeling geeft.
• Een eindverslag, doorgaans binnen een maand na indiening van de incidentmelding. Bij een lopend incident is op dat moment een voortgangsverslag vereist, met een eindverslag binnen een maand na de afhandeling van het incident.

Op verzoek van het CSIRT of de bevoegde autoriteit moet ook een tussentijds verslag worden verstrekt.

Controleer de toepasselijke nationale en sectorspecifieke regels: de richtlijn bevat een afwijkende meldtermijn voor verleners van vertrouwensdiensten. Gebruik geen generieke storingsdrempel als vervanging voor de toepasselijke criteria voor significantie.

Een praktische implementatieaanbeveling is een meldrunbook dat de eigenaar van de beoordeling, de escalatieroute, de bevoegde indiener, back-uppersoneel, het kanaal van de autoriteit en de per fase benodigde informatie vastlegt. Registreer de tijdstempels van detectie, kennisname, beoordeling van significantie en indiening afzonderlijk.

Oefen het proces met onvolledige informatie. Het team moet de vereiste eerste melding kunnen indienen zonder te wachten op een afgerond forensisch onderzoek. Bewaar ingediende versies, ontvangstbevestigingen, ondersteunende feiten en beslissingen over de vraag of een incident de drempel haalt.

Waar ook een ander meldregime van toepassing is, coördineert u het onderzoek maar beoordeelt u elke meldplicht afzonderlijk. Een gedeelde incidentregistratie maakt ontvangers, triggers en termijnen niet identiek.

Maak governance en weerbaarheid aantoonbaar

Artikel 20 vereist dat bestuursorganen maatregelen voor het beheer van cybersecurityrisico's goedkeuren en toezicht houden op de implementatie. Het gaat ook over training van het bestuursorgaan. Een bestaande directiebeoordeling is nuttig bewijs, maar controleer of daarin de relevante goedkeuringen, het toezicht, de beslissingen en de opvolging expliciet zijn vastgelegd.

Geef het management een beslisrijp overzicht: getroffen diensten, wezenlijke risico's, behandelopties, openstaande uitzonderingen en resultaten van effectiviteitstoetsen. Notulen waarin alleen staat ‘security besproken’ leveren weinig bewijs op van betekenisvol toezicht. Wijs elke goedgekeurde actie een eigenaar en een reviewdatum toe.

Continuïteit vraagt om een even concrete aanpak. Artikel 21 omvat back-ups, herstel na calamiteiten en crisisbeheer; het legt geen universele eis van ISO 22301-certificering op. Bepaal de benodigde diepgang aan de hand van de dienst, de risico's en de toepasselijke regels.

Test het herstel van gegevens en diensten, niet alleen het voltooien van back-uptaken. Neem afhankelijkheden mee zoals identiteitsdiensten, DNS, ondersteuning door leveranciers, geprivilegieerde inloggegevens en communicatie wanneer de normale omgeving niet beschikbaar is. Leg behaalde herstelresultaten en openstaande blokkades vast ten opzichte van de afgesproken doelen.

Houd een zichtbaar verschillenregister bij

Leg voor elke eis de bron en versie, de gemapte controls, de scope, verwijzingen naar bewijs, de reviewer en de onderbouwing van hergebruik vast. Onderscheid onderbouwde dekking, gedeeltelijke dekking, ontbrekende implementatie, ontbrekend bewijs en een beredeneerde beslissing over niet-toepasselijkheid. Het ontbreken van een document betekent niet altijd dat een control ontbreekt, maar vraagt wel om onderzoek.

Elke lacune heeft een eigenaar, een vereiste wijziging, een verwachting over het bewijs, een vervaldatum en een reviewer voor de afsluiting nodig. Geef voorrang aan tekortkomingen die diensten bedreigen of tijdkritische meldingen verhinderen, in plaats van elke documentatietaak als even urgent te behandelen.

Veelgemaakte fouten zijn onder meer alleen Annex A mappen en daarbij governance-eisen over het hoofd zien, een certificaat van een leverancier accepteren zonder de scope te controleren, bewijs van vorig jaar als actueel beschouwen en een taak afsluiten zodra een beleid is gepubliceerd terwijl het proces ongetest blijft. Registratie of certificering mag nooit worden beschouwd als bewijs van operationele implementatie.

Uitgewerkt voorbeeld: een bestaand ISMS uitbreiden

Illustratieve aannames: een managed service provider heeft een ISO 27001-gecertificeerd ISMS dat het belangrijkste operationele team dekt. Uit de toepasselijkheidsbeoordeling blijkt dat een dienst die via een extra juridische entiteit wordt geleverd onder NIS2 valt. Die entiteit gebruikt hetzelfde identiteitsplatform en incidentteam, maar heeft afzonderlijke herstelregelingen.

Het team vergelijkt eerst de grenzen van de diensten. Bestaande authenticatieconfiguraties kunnen beide scopes ondersteunen, maar de reviewer controleert of de beheerders, noodaccounts en serviceaccounts van de extra entiteit zijn meegenomen. Een export van een toegangsreview die alleen het oorspronkelijke team dekt, kan geen volledige dekking bewijzen.

Vervolgens behoudt de incidenteigenaar de bestaande responsprocedure en voegt hij een beoordeling van significante incidenten en een meldpad naar de autoriteit toe. Een tabletop-oefening simuleert een storing bij een leverancier met onzekere impact op klanten. Deelnemers leggen vast wanneer zij kennis kregen van relevante feiten, wie over de significantie besliste en hoe een vroegtijdige waarschuwing zou worden ingediend.

Ten slotte voert de infrastructuureigenaar een hersteloefening uit voor de dienst van de extra entiteit. Uit de test blijkt dat herstelinloggegevens afhankelijk zijn van het onbeschikbare identiteitsplatform. Het lacuneregister wijst een corrigerende maatregel toe en vereist een geslaagde hertest vóór afsluiting.

De resulterende resultaten zijn een scopevergelijking, gereviewde mappings, uitgebreid bewijs van toegangsreviews, verslagen van meldoefeningen, herstelresultaten en goedkeuring door het management van openstaande behandelacties. Gedeelde controls blijven gedeeld; entiteitspecifiek bewijs en entiteitspecifieke beslissingen blijven zichtbaar.

Zet de beoordeling om in onderhouden werk

Het verbonden model van eisen en bewijs in Secani biedt teams een structuur om gedeeld werk en frameworkspecifieke beslissingen te bewaren. Modelleer de diensten en afhankelijkheden, koppel bestaand bewijs aan relevante controls en zet ontbrekende dekking om in taken met een eigenaar. Houd menselijke goedkeuring expliciet voor mappings en conclusies over bewijs, ook bij AI-ondersteunde suggesties. Onze gids over herleidbare mapping tussen frameworks legt uit hoe u de onderbouwing achter hergebruik bewaart.

Begin met één gereguleerde dienst. Breng de scope, de risicobehandeling, de Verklaring van Toepasselijkheid, het incidentrunbook en recent testbewijs samen in een gezamenlijke technische en compliancereview. Stel een gereviewd verschillenregister op en gebruik daarna de normale ISMS-reviewcycli om het bij te houden naarmate diensten, leveranciers en eisen veranderen.