De flesta organisationer misslyckas inte med NIS2 på grund av teknik – utan på grund av bristande operativ samordning mellan styrning och implementation.
NIS2 ser ut som en cybersäkerhetsreglering. I praktiken fungerar den mer som ett organisatoriskt stresstest.
Den del av organisationen som sätts under störst press är utrymmet mellan IT och ledning. Det är precis där de flesta implementationer tyst faller isär.
I ett stort antal genomförda gap-analyser framträder ett tydligt mönster: organisationer som har svårt med NIS2 misslyckas sällan på grund av tekniska brister i brandväggar eller loggning. Utmaningen ligger i stället i att IT och ledning arbetar utifrån olika tolkningar av samma problem – utan ett etablerat och fungerande gränssnitt mellan dem.
I grunden är problemet enkelt. Ledningen äger risken. IT äger implementationen. NIS2 förutsätter att dessa fungerar som ett sammanhängande system. I de flesta organisationer gör de inte det – och det har de aldrig behövt göra förrän nu.
Ledningen tenderar att se NIS2 som en styrningsfråga. Hur rapporterar vi detta? Vad behöver vi godkänna? Hur ser vår ansvarsexponering ut? Det är legitima frågor, men de ligger på en abstraktionsnivå som inte naturligt översätts till tekniska system.
IT tenderar att se NIS2 som en lista av tekniska kontroller. Snabbare patchcykler. Hårdare identitetshantering. Segmentering av nätverk. Granskning av loggflöden. Detta är också legitima uppgifter och representerar faktiskt operativt arbete som landar på redan belastade team.
Båda sidor har rätt. De löser bara olika problem. Och där börjar det gå fel.
Det första som syns är ansvar för risk. Ledningen definierar risk i termer av “operativ kontinuitet” och “regelverksexponering”. IT hanterar den konkreta verkligheten bakom detta: vilka system som inte är patchade, vilka konton som delas, vilka incidentrutiner som inte testats på 18 månader. Översättningen mellan dessa två nivåer sker sällan systematiskt. Risken förstås i toppen men går inte att spåra ner till de kontroller som ska hantera den.
Det andra problemet är ansvarsdiffusion. Kontroller implementeras ofta korrekt, men ingen äger dem över tid. IT bygger dem. Säkerhet övervakar dem. Ledningen godkänner riskbilden. Men vem säkerställer att kontrollen fortfarande fungerar sex månader senare när systemen förändrats? I de flesta organisationer är det ärliga svaret: ingen specifik.
Det tredje mönstret är det vanligaste och mest problematiska: rapportering blir en ersättning för faktisk beredskap. Ledningen ser en kvartalsrapport och tolkar den som bevis på att allt fungerar. IT genererar rapporten från system som bara visar det de kan se – vilket inte alltid är samma sak som vad som faktiskt sker. NIS2 frågar inte om du har rapporter. Den frågar om du kan visa operativ kontroll under verkliga förhållanden, till exempel under en pågående incident med 24-timmarsrapportering. Det är två helt olika saker.
Det fjärde haveriet syns tydligast i incidenthantering. IT bygger detektion och responsförmåga. Ledningen ansvarar för regulatorisk rapportering, kommunikation och beslut med juridiska konsekvenser. Men eskaleringsvägar är ofta otydliga, beslutsmandat aktiveras för långsamt och tidskraven i artikel 23 är ofta missförstådda av dem som måste agera på dem. Jag har sett organisationer där CISO hade en tydlig incidentplan och styrelsen hade godkänt en cybersäkerhetspolicy – men när en verklig incident inträffade gick det inte att koppla ihop dessa tillräckligt snabbt för att möta 24-timmarskravet. Ingen hade misslyckats individuellt. Gränssnittet mellan dem hade gjort det.
Tidigare ramverk tillät IT och ledning att arbeta relativt separat. IT hanterade implementation, ledningen hanterade uppföljning och revisorer verifierade periodiskt. Den uppdelningen fungerade eftersom tidigare regelverk inte ställde hårda realtidskrav på ledningsnivå.
NIS2 tar bort den uppdelningen genom att kräva något de flesta organisationer aldrig designats för: att fungera som ett synkroniserat system under press. Strikta tidskrav vid incidenter kräver snabbhet både tekniskt och organisatoriskt samtidigt.
Ledningsansvar enligt artikel 20 är inte en passiv rapporteringsskyldighet. Ledningsorganet måste formellt godkänna och aktivt övervaka säkerhetsåtgärder. Kraven på operativ motståndskraft innebär att dokumenterade planer måste fungera under störningar – inte bara existera.
Den obekväma sanningen är att problemet inte är teknisk omognad. Det är inte heller styrningsmässig omognad. Det är avsaknaden av ett designat gränssnitt mellan de två. De flesta organisationer har stark IT-kompetens och fungerande styrstrukturer. De har helt enkelt aldrig behövt integrera dem för cybersäkerhet på ett formellt, dokumenterat och testat sätt. Fram till nu har det varit tillräckligt bra.
De som hanterar detta väl gör en sak annorlunda: de behandlar gränssnittet mellan IT och ledning som något som måste designas – inte antas.
Risk kopplas kontinuerligt till specifika tekniska kontroller, så att det alltid finns en spårbar linje från en risk på styrelsenivå till systemet som ska hantera den. Kontroller verifieras regelbundet, inte bara dokumenteras. Incidenter övas med både IT och ledning i samma rum, så att eskaleringsvägar testas innan de behövs. Ansvar byggs in i arbetsflöden snarare än i dokument som ingen läser under press.
I dessa organisationer slutar NIS2 vara ett compliance-projekt. Det blir ett operativt system för hur man hanterar cyberrisk som verksamhet – vilket är exakt vad regelverket var tänkt att skapa.
NIS2 bryter inte organisationer för att det är för krävande. Det blottlägger något som alltid varit sant: IT och ledning var aldrig designade att fungera som ett enhetligt system när det verkligen gäller.
När det blir tydligt är utmaningen inte längre compliance. Det är alignment. Och alignment är ett betydligt svårare problem att lösa än att installera ännu ett säkerhetsverktyg.
