NIS2 och ISO 27001: återanvänd kontroller, granska luckorna

Ett ISO 27001-program kan ge en stark operativ struktur för NIS2: riskbedömning, ansvariga ägare, kontroller, underlag och förbättring. Nästa steg är en bedömning krav för krav av vad strukturen faktiskt täcker.

För en CTO är den användbara frågan inte om ramverken överlappar. Det är om en implementerad kontroll skyddar den relevanta tjänsten, uppfyller den tillämpliga skyldigheten och ger underlag som stöder den slutsatsen. Återanvänd implementeringen där dessa villkor är uppfyllda; bevara de rättsliga och operativa skillnaderna där de inte är det.

Förstå vad respektive ramverk fastställer

ISO/IEC 27001 anger krav på ett avgränsat ledningssystem för informationssäkerhet, ett ISMS. Avsnitt 4–10 behandlar ledningsstrukturen, inklusive riskbehandling, utvärdering av prestanda och förbättring. Bilaga A innehåller 93 referenskontroller inom kategorierna organisatoriska, personrelaterade, fysiska och tekniska kontroller. Kontrollernas tillämplighet är riskbaserad, inte ett krav på att varje kontroll ska implementeras på samma sätt. ISO 27002 ger vägledning för implementeringen.

NIS2 är ett EU-direktiv som genomförs genom nationell lagstiftning. Tillämpligheten beror på sektor, storlek, tjänst och särskilda regler om vilka som omfattas. Bilaga I och bilaga II anger relevanta sektorer, men sektorn ensam avgör inte om en organisation är en väsentlig eller viktig entitet. Vissa entiteter omfattas oavsett storlek.

De praktiska skillnaderna är:

Certifiering utförs av oberoende certifieringsorgan, inte av ISO. Den fastställer inte efterlevnad av NIS2, och NIS2 kräver i regel inte ISO 27001-certifiering. Tillsyn kan omfatta tillsynsåtgärder och sanktioner; ISO-certifiering har ett annat syfte som försäkran.

Börja med att jämföra avgränsningarna

Jämför det certifierade ISMS:ets omfattning med de juridiska personer och tjänster som omfattas av NIS2. Ett certifikat som omfattar ett utvecklingsteam kan lämna produktionsdriften, ett annat dotterbolag eller ytterligare platser utanför avgränsningen.

Skapa en jämförelse av omfattningen som registrerar:

• Juridiska personer, länder och tjänster som omfattas samt grunden för att de ingår.
• Relevanta system, nätverk, platser och stödjande leverantörer.
• ISMS:ets omfattning, certifikatets omfattning och undantag.
• Tillämpliga nationella krav, sektorsregler och ansvariga myndigheter, inklusive tillämpliga registreringsskyldigheter, krävda uppgifter om entiteten, inlämningskanaler och skyldigheter att uppdatera uppgifterna.
• Vem som godkände tillämplighetsbedömningen och när den måste omprövas.

Skilj en lucka i omfattningen från en lucka i kontrollerna. En produktionsmiljö utanför ISMS:et kan redan ha goda behörighetskontroller, men kontrollerna behöver ändå ägarskap, bedömning och underlag inom NIS2-arbetet.

Kontrollera sektorsspecifik lagstiftning innan skyldigheter dupliceras. Artikel 4 behandlar förhållandet till sektorsspecifika unionsrättsakter. För finansiella enheter kräver förhållandet till DORA en rollspecifik analys. För verksamhet i Tyskland, ta del av BSI:s information om NIS2 i stället för att anta att befintliga KRITIS-skyldigheter och NIS2-skyldigheter är identiska.

Mappa implementerade kontroller, inte matchande etiketter

Artikel 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Dess tio minimiområden för åtgärder ger en utgångspunkt för mappningen, men liknande formuleringar är en användbar ledtråd, inte ett bevis på likvärdighet.

Använd följande som underlag för granskning, inte som automatiska förklaringar om täckning:

Uttalandet om tillämplighet (Statement of Applicability) registrerar nödvändiga kontroller och motiveringen för att de inkluderas eller exkluderas. Det kan inte ersätta planen för riskbehandling, iakttagelser från internrevision eller protokoll från ledningens genomgång. Använd dessa artefakter tillsammans för att förklara både utformning och drift.

En policy fastställer förväntningar. En export av konfigurationen kan visa implementeringen. Resultat från behörighetsgranskningar, åtgärdsärenden och testprotokoll kan visa driften. Återanvänd underlag endast där system, period och bedömningens syfte stämmer överens.

Undvik fasta procentsatser för överlappning. Täckningen beror på implementering och rättslig omfattning; en universell siffra kan inte fastställa att man är redo.

Bygg en väg för incidentrapportering som fungerar under press

En hanteringsplan i linje med ISO kan stödja detektion, begränsning, utredning och återställning utan att definiera regulatorisk anmälan. Artikel 23 i NIS2 lägger till rapporteringsskyldigheter för betydande incidenter.

Direktivets rapporteringssteg omfattar i regel:

• En tidig varning utan onödigt dröjsmål och inom 24 timmar från det att entiteten fått kännedom om en betydande incident.
• En incidentanmälan utan onödigt dröjsmål och inom 72 timmar, som uppdaterar den tidiga varningen och ger en första bedömning.
• En slutrapport i regel senast en månad efter att incidentanmälan lämnats. Om incidenten pågår krävs vid den tidpunkten en lägesrapport, och slutrapporten ska då lämnas inom en månad efter att incidenten har hanterats.

En delrapport ska också lämnas om CSIRT-enheten eller den behöriga myndigheten begär det.

Kontrollera tillämpliga nationella och sektorsspecifika regler: direktivet innehåller en annan tidsfrist för anmälan för tillhandahållare av betrodda tjänster. Använd inte ett generiskt tröskelvärde för avbrott som ersättning för de tillämpliga kriterierna för betydande incidenter.

Som en praktisk rekommendation för implementeringen, skapa en driftinstruktion för rapportering som anger ansvarig för bedömningen, eskaleringsväg, behörig inlämnare, ersättare, kanal till myndigheten och vilken information som behövs i varje steg. Registrera tidsstämplar för upptäckt, kännedom, bedömning av om incidenten är betydande och inlämning var för sig.

Öva processen med ofullständig information. Teamet ska kunna lämna den krävda första rapporten utan att vänta på en slutförd forensisk utredning. Bevara inlämnade versioner, kvittenser, stödjande fakta och beslut om huruvida en incident når upp till tröskeln.

Där en annan rapporteringsordning också gäller, samordna utredningen men bedöm varje anmälningsskyldighet separat. En gemensam incidentpost gör inte mottagare, utlösande villkor eller tidsfrister identiska.

Gör styrning och motståndskraft påvisbara

Artikel 20 kräver att ledningsorganen godkänner riskhanteringsåtgärderna för cybersäkerhet och övervakar genomförandet. Den behandlar också utbildning för ledningsorganen. En befintlig ledningens genomgång är ett användbart underlag, men kontrollera om den uttryckligen registrerar relevanta godkännanden, tillsyn, beslut och uppföljning.

Ge ledningen en beslutsklar överblick: berörda tjänster, väsentliga risker, behandlingsalternativ, olösta undantag och resultat av effektivitetsbedömningar. Mötesprotokoll som bara konstaterar att ”säkerhet diskuterades” ger litet belägg för meningsfull tillsyn. Ge varje godkänd åtgärd en ägare och ett granskningsdatum.

Kontinuitet behöver en lika konkret behandling. Artikel 21 omfattar säkerhetskopiering, katastrofåterställning och krishantering; den ställer inget universellt krav på ISO 22301-certifiering. Bestäm det nödvändiga djupet utifrån tjänsten, riskerna och tillämpliga regler.

Testa återställning av data och tjänster, inte bara att säkerhetskopieringsjobb slutförs. Ta med beroenden som identitetstjänster, DNS, leverantörssupport, privilegierade inloggningsuppgifter och kommunikation när den normala miljön är otillgänglig. Registrera uppnådda återställningsresultat och olösta hinder mot de överenskomna målen.

Upprätthåll ett synligt register över skillnader

Registrera för varje krav dess källa och version, mappade kontroller, omfattning, referenser till underlag, granskare och motivering för återanvändning. Skilj mellan underbyggd täckning, partiell täckning, saknad implementering, saknade underlag och ett motiverat beslut om att kravet inte är tillämpligt. Att ett dokument saknas betyder inte alltid att kontrollen saknas, men det kräver utredning.

Varje lucka behöver en ägare, en krävd ändring, en förväntan på underlag, ett förfallodatum och en granskare för avslut. Prioritera brister som hotar tjänster eller förhindrar tidskritisk rapportering i stället för att behandla varje dokumentationsuppgift som lika brådskande.

Vanliga misstag är att bara mappa bilaga A och förbise kraven på styrning, att godta en leverantörs certifikat utan att kontrollera dess omfattning, att behandla förra årets underlag som aktuella och att stänga en uppgift när en policy har publicerats men processen fortfarande är otestad. Registrering eller certifiering får aldrig behandlas som bevis på operativt genomförande.

Räkneexempel: att utvidga ett befintligt ISMS

Illustrativa antaganden: en leverantör av förvaltade tjänster har ett ISO 27001-certifierat ISMS som omfattar dess huvudsakliga driftteam. Dess tillämplighetsbedömning visar att en tjänst som drivs genom en ytterligare juridisk person omfattas av NIS2. Den juridiska personen använder samma identitetsplattform och incidentteam, men separata återställningsarrangemang.

Teamet jämför först tjänsternas avgränsningar. Befintliga autentiseringskonfigurationer kan stödja båda omfattningarna, men granskaren kontrollerar om den ytterligare juridiska personens administratörer, nödkonton och tjänstekonton ingår. En export från en behörighetsgranskning som bara omfattar det ursprungliga teamet kan inte bevisa fullständig täckning.

Därefter behåller incidentansvarig den etablerade hanteringsrutinen och lägger till en bedömning av betydande incidenter och en väg för anmälan till myndigheten. En skrivbordsövning simulerar ett leverantörsavbrott med osäker påverkan på kunderna. Deltagarna registrerar när de fick kännedom om relevanta fakta, vem som avgjorde om incidenten var betydande och hur en tidig varning skulle lämnas.

Slutligen genomför infrastrukturägaren en återställningsövning för den ytterligare juridiska personens tjänst. Testet visar att inloggningsuppgifterna för återställning är beroende av den otillgängliga identitetsplattformen. Registret över luckor tilldelar en korrigerande åtgärd och kräver ett godkänt omtest innan avslut.

De resulterande leveranserna är en jämförelse av omfattningen, granskade mappningar, utvidgade underlag från behörighetsgranskningar, protokoll från rapporteringsövningar, återställningsresultat och ledningens godkännande av utestående åtgärder för riskbehandling. Gemensamma kontroller förblir gemensamma; underlag och beslut som är specifika för den juridiska personen förblir synliga.

Gör bedömningen till underhållet arbete

Secanis modell med sammankopplade krav och underlag ger teamen en struktur för att bevara gemensamt arbete och ramverksspecifika beslut. Modellera tjänsterna och beroendena, koppla befintliga underlag till relevanta kontroller och omvandla saknad täckning till uppgifter med ägare. Håll mänskligt godkännande uttryckligt för mappningar och slutsatser om underlag, även för AI-stödda förslag. Vår vägledning om spårbar mappning mellan ramverk förklarar hur motiveringen bakom återanvändningen bevaras.

Börja med en reglerad tjänst. Ta med dess omfattning, riskbehandling, uttalande om tillämplighet, driftinstruktion för incidenter och aktuella testunderlag till en gemensam teknisk granskning och compliancegranskning. Ta fram ett granskat register över skillnader och använd sedan ISMS:ets ordinarie granskningscykler för att hålla det aktuellt när tjänster, leverantörer och krav förändras.