Fråga ett infrastrukturteam hur bevis på NIS2-efterlevnad ser ut, och du får oftast ett policypaket: en informationssäkerhetspolicy, en incidenthanteringsplan, ett leverantörsformulär, allt signerat och versionerat. De dokumenten spelar roll, men de är inte bevis. De beskriver vad du tänker göra. Bevis är journalen över vad du faktiskt gjorde - vem som ändrade brandväggsregeln, när, på vems mandat, och hur konfigurationen såg ut innan. Bedömare frågar efter det andra, och gapet mellan de två är där de flesta team börjar känna sig obekväma.

En snabb sammanfattning av vad vi har att göra med. NIS2, formellt direktiv (EU) 2022/2555, hade en frist för införlivande den 17 oktober 2024, och nationella lagar har landat i sin egen takt sedan dess. Det breddade omfattningen långt bortom de gamla NIS-kategorierna, drog in leveranskedjor explicit, och knöt skyldigheter till ledningsorgan personligen snarare än till en abstrakt organisation. Om du levererar något till en aktör inom tillämpningsområdet, räkna med att deras skyldigheter landar på ditt skrivbord som avtalstext, oavsett om du själv omfattas direkt eller inte.

Vad direktivet faktiskt kräver

Artikel 21 räknar upp riskhanteringsåtgärderna: policyer för riskanalys och informationssystemsäkerhet, incidenthantering, kontinuitet och backup, säkerhet i leveranskedjan, säkerhet vid anskaffning och utveckling, rutiner för att bedöma effektivitet, grundläggande cyberhygien och utbildning, kryptografi, åtkomstkontroll och tillgångshantering, samt multifaktorautentisering. Läs den listan som en uppsättning frågor du kommer att ombes besvara med journalföring. Varje punkt slutar med samma följdfråga från en bedömare: visa mig. Visa mig backupen du återställde, åtkomsten du återkallade, ändringen du godkände.

Artikel 23 är den som förändrar ingenjörsarbetet snarare än pappersarbetet. En tidig varning inom 24 timmar från att du blev medveten om en betydande incident. En fylligare anmälan inom 72 timmar, inklusive en första bedömning av allvarlighetsgrad och påverkan. En slutrapport inom en månad. De klockorna börjar ticka när du blir medveten, vilket gör din tidslinje för upptäckt till en del av själva beviset. Om du inte kan säga när du visste kan du inte visa att du rapporterade i tid - och en incidenttidslinje återskapad ur minnet en vecka senare övertygar ingen.

Bevis på NIS2-efterlevnad är journalföring

Här är den praktiska formen på vad en bedömare frågar efter. En lista över system inom tillämpningsområdet och vem som äger vart och ett. En journal över ändringar i säkerhetsrelevant konfiguration under en angiven period. Bevis på att åtkomst beviljades, granskades och togs bort, med datum. Bevis på att backuper inte bara togs utan också återställdes. Och för varje betydande incident, en tidslinje du kan försvara: upptäckt, eskalering, begränsning, anmälan. Allt daterat, kopplat till en namngiven identitet, och framtaget från något annat än en persons minne.

Den besvärande sanningen är att nästan allt det här redan finns någonstans i varje företag. Det finns i ett ärendesystem, en chattkanal, tre konsoler, en ingenjörs terminalhistorik och ett kalkylblad. Efterlevnadsarbetet blir då arkeologi: två veckor av att någon rekonstruerar vad som hände utifrån artefakter som aldrig var tänkta att vara bevis. Det är dyrt, det är nedslående, och det producerar ett dokument ingen riktigt litar på - inte ens personen som satte ihop det.

Egenskapen som gör en logg till bevis

En logg blir bevis när den är append-only och manipulationsavslöjande. Distinktionen spelar större roll än den låter. En tabell en administratör kan uppdatera är en journal över vad den administratören vill att du ska tro. Vad en bedömare vill ha är en sekvens där varje ändring av en tidigare post är detekterbar, utan att behöva lita på den som driver systemet - oss inräknat. Den egenskapen är det som gör "här är våra loggar" till något en tredje part kan förlita sig på snarare än bara ta emot.

Sencais granskningsspår är append-only och hashkedjat. Varje post bär sin egen hash och hashen från posten före den, så journalen bildar en kedja snarare än en hög. CSV-exporten innehåller båda värdena, entry_hash och prev_hash, vilket betyder att din revisor inte behöver ta vårt ord för något. De kan räkna om kedjan själva, offline, med ett skript de skrivit, och se om den håller. Om en enda post hade ändrats eller tagits bort slutar omräkningen matcha från den punkten och framåt.

Frågor om leveranskedjan du kommer att få

Artikel 21 sätter säkerhet i leveranskedjan på listan, och Artikel 20 gör ledningen personligen ansvarig för att godkänna och övervaka de åtgärderna, vilket är varför de här frågorna nu kommer med verklig tyngd bakom sig. Räkna med att bli tillfrågad vilka underbiträden som rör vid din data, i vilka jurisdiktioner de verkar, hur du skulle upptäcka en kompromettering som härrör från ett av dem, och hur snabbt du skulle kunna ta bort ett. Om du inte kan räkna upp dina leverantörer idag kan du inte svara på något av det - och en ofullständig inventering är det snabbaste sättet att underkännas på den här delen.

Det är här isolering per organisation och en riktig rollmodell slutar vara produktfunktioner och blir svar i en granskning. Vem som kan skapa infrastruktur, vem som bara kan se den, vem som bjöd in vem och när, och vilka av de inbjudningarna som faktiskt accepterades snarare än bara skickades - det här är frågor med datum knutna till sig. Detsamma gäller konfigurationen som genuint skyddar dig: brandväggsregler, nätverksgränser och DNS-poster, var och en med en journal över vem som ändrade dem hos leverantören, och när.

Så förbereder du dig utan en compliance-avdelning

Börja med att skriva ner frågorna du skulle ha svårt att svara på i ett rum med en bedömare. Oftast är det fyra: vad kör vi, vem kan röra vid det, vad ändrades förra kvartalet, och hur bevisar vi något av det. Fixa sedan registreringen, inte rapporteringen. Ett system som fångar svaren medan arbetet sker kostar nästan ingenting då och där; att rekonstruera dem i efterhand kostar veckor, varje gång. NIS2 skapade inte det gapet - det gjorde bara det dyrt att behålla det.

Inget av det här gör efterlevnad trevligt. Det förändrar dess form. Bevis du kan exportera, lämna till en revisor och låta dem verifiera oberoende är ett helt annat samtal än en mapp med skärmdumpar och ett löfte om att inget redigerades. Det är ribban vi byggde för: ditt bestånd på ett ställe, ändringar registrerade när de sker, och en export designad för att kontrolleras av någon vars enda jobb är att betvivla den.