Spør et infrastrukturteam hvordan NIS2-compliance-bevis ser ut, og du får som regel en policy-pakke: en informasjonssikkerhetspolicy, en hendelsesresponsplan, et leverandørspørreskjema, alt signert og versjonert. De dokumentene betyr noe, men de er ikke bevis. De beskriver hva du har til hensikt å gjøre. Bevis er journalen over hva du faktisk gjorde - hvem endret brannmurregelen, når, på hvilken autoritet, og hva konfigurasjonen var før. Assessorer ber om det andre, og gapet mellom de to er der de fleste team blir ukomfortable.

En rask oppsummering av hva vi har med å gjøre. NIS2, formelt direktiv (EU) 2022/2555, hadde en gjennomføringsfrist 17. oktober 2024, og nasjonale lover har landet på egne tidsplaner siden. Det utvidet omfanget godt utover de gamle NIS-kategoriene, trakk leverandørkjeder inn eksplisitt, og knyttet forpliktelser til ledelsen personlig fremfor til en abstrakt organisasjon. Hvis du leverer noe til en enhet innenfor omfanget, forvent at deres forpliktelser lander på pulten din som kontraktsspråk, uansett om du selv er direkte omfattet.

Hva direktivet faktisk ber om

Artikkel 21 lister risikostyringstiltakene: policyer for risikoanalyse og sikkerhet i informasjonssystemer, hendelseshåndtering, forretningskontinuitet og backup, sikkerhet i leverandørkjeden, sikkerhet i anskaffelse og utvikling, prosedyrer for å vurdere effektivitet, grunnleggende cyberhygiene og opplæring, kryptografi, tilgangskontroll og ressursstyring, og multifaktorautentisering. Les den listen som et sett spørsmål du vil bli bedt om å besvare med journaler. Hvert punkt ender i samme oppfølging fra en assessor: vis meg. Vis meg backupen du gjenopprettet, tilgangen du tilbakekalte, endringen du godkjente.

Artikkel 23 er den som endrer ingeniørarbeidet fremfor papirarbeidet. Et tidlig varsel innen 24 timer etter at du ble oppmerksom på en betydelig hendelse. En fullere varsling innen 72 timer, inkludert en innledende vurdering av alvorlighetsgrad og påvirkning. En sluttrapport innen en måned. De klokkene starter når du blir oppmerksom, noe som gjør deteksjonstidslinjen din til en del av selve beviset. Hvis du ikke kan si når du visste, kan du ikke demonstrere at du varslet i tide - og en hendelsestidslinje rekonstruert fra hukommelsen en uke senere overbeviser ingen.

NIS2-compliance-bevis er en journal

Her er den praktiske formen på hva en assessor ber om. En liste over systemer innenfor omfanget og hvem som eier hvert av dem. En journal over endringer i sikkerhetsrelevant konfigurasjon over en gitt periode. Bevis på at tilgang ble gitt, gjennomgått og fjernet, med datoer. Bevis på at backup ikke bare ble tatt, men gjenopprettet. Og for hver betydelig hendelse, en tidslinje du kan forsvare: deteksjon, eskalering, inndemming, varsling. Alt datert, tilskrivbart en navngitt identitet, og produsert fra noe annet enn en persons hukommelse.

Den pinlige sannheten er at nesten alt dette allerede finnes et sted i ethvert selskap. Det ligger i et ticket-system, en chat-kanal, tre konsoller, én ingeniørs terminalhistorikk og et regneark. Compliance-arbeid blir da arkeologi: to uker der noen rekonstruerer hva som skjedde fra artefakter som aldri var designet til å være bevis. Det er dyrt, det er demoraliserende, og det produserer et dokument ingen helt stoler på - inkludert personen som satte det sammen.

Egenskapen som gjør en logg til bevis

En logg blir bevis når den er append-only og manipulasjonssikker. Distinksjonen betyr mer enn den høres ut. En tabell en administrator kan oppdatere, er en journal over hva den administratoren vil du skal tro. Det en assessor vil ha er en sekvens der enhver endring i en tidligere oppføring er oppdagbar, uten å måtte stole på den som drifter systemet - inkludert oss. Den egenskapen er det som gjør «her er loggene våre» til noe en tredjepart kan stole på fremfor bare motta.

Sencais revisjonsspor er append-only og hash-kjedet. Hver oppføring bærer sin egen hash og hashen til oppføringen før den, slik at journalene danner en kjede fremfor en haug. CSV-eksporten inneholder begge verdiene, entry_hash og prev_hash, noe som betyr at revisoren din ikke trenger å ta oss på ordet for noe. De kan regne ut kjeden på nytt selv, offline, med et skript de skrev, og se om den holder. Hvis en enkelt oppføring hadde blitt endret eller fjernet, slutter den nye utregningen å stemme fra det punktet og fremover.

Spørsmål om leverandørkjeden du vil bli stilt

Artikkel 21 setter sikkerhet i leverandørkjeden på listen, og artikkel 20 gjør ledelsen personlig ansvarlig for å godkjenne og føre tilsyn med disse tiltakene, som er grunnen til at disse spørsmålene nå kommer med reell tyngde bak seg. Forvent å bli spurt hvilke underleverandører som håndterer dataene dine, i hvilke jurisdiksjoner de opererer, hvordan du ville oppdaget et kompromiss som stammer fra en av dem, og hvor raskt du kunne fjernet en. Hvis du ikke kan liste opp leverandørene dine i dag, kan du ikke svare på noe av dette - og et ufullstendig inventar er den raskeste veien til å stryke på denne delen.

Dette er der isolasjon per organisasjon og en reell rollemodell slutter å være produktfunksjoner og blir revisjonssvar. Hvem kan opprette infrastruktur, hvem kan bare se den, hvem inviterte hvem og når, og hvilke av de invitasjonene som faktisk ble akseptert fremfor bare sendt - dette er spørsmål med datoer knyttet til seg. Det samme gjelder konfigurasjonen som faktisk beskytter deg: brannmurregler, nettverksgrenser og DNS-oppføringer, hver med en journal over hvem som endret dem hos leverandøren, og når.

Hvordan forberede seg uten en compliance-avdeling

Start med å skrive ned spørsmålene du ville slitt med å svare på i et rom med en assessor. Som regel er det fire: hva kjører vi, hvem kan røre det, hva endret seg forrige kvartal, og hvordan beviser vi noe av det. Fiks deretter journalføringen, ikke rapporteringen. Et system som fanger opp svarene mens arbeidet skjer, koster nesten ingenting der og da; å rekonstruere dem etterpå koster uker, hver eneste gang. NIS2 skapte ikke det gapet - det gjorde det bare dyrt å opprettholde.

Ingenting av dette gjør compliance behagelig. Det endrer formen på det. Bevis du kan eksportere, overlevere til en revisor og la dem verifisere uavhengig, er en helt annen samtale enn en mappe med skjermbilder og et løfte om at ingenting ble redigert. Det er linjen vi bygde for: infrastrukturen din på ett sted, endringer journalført mens de skjer, og en eksport designet for å sjekkes av noen hvis eneste jobb er å tvile på den.