NIS2 og dit udviklingsprojekt: Det skal du vide

For virksomheder og organisationer der er omfattet af NIS2, er cybersikkerhed ikke længere bare en god idé. Det er lov, og ansvaret rækker helt ud i forsyningskæden. Det ændrer hvordan et udviklingsprojekt skal sættes op. Sikkerhed kan ikke længere være noget leverandøren “alligevel klarer”, men bliver et krav som I har ansvaret for at stille og følge op på. Denne guide oversætter direktivet til hvad det betyder i praksis når I skal købe og bygge en digital løsning.

Hvilke brancher og størrelser der er omfattet

Det første I skal finde ud af, er om I overhovedet er omfattet, for NIS2 gælder ikke alle. Direktivet retter sig mod enheder hvis funktion er vigtig for samfundet, og deler dem op i to grupper med lidt forskelligt tilsyn.

De udpegede sektorer omfatter bl.a. energi, transport, bankvirksomhed, sundhedsvæsen, drikkevand og spildevand, digital infrastruktur, offentlig forvaltning, post, affald og fødevarer. Sammenlignet med det gamle NIS-direktiv er listen betydeligt bredere, og mange organisationer der tidligere stod udenfor, er nu omfattet. Størrelsen spiller ind som en grov tærskel: Som tommelfingerregel er mellemstore og større virksomheder omfattet mens de allermindste ofte er undtaget. Hvor de præcise grænser går, fastlægges i den danske lov der gennemfører direktivet, NIS 2-loven, så en organisation der ligger i grænselandet, bør tjekke sin egen situation frem for at gætte. Grundspørgsmålet er enkelt at stille: Er vi i en udpeget sektor, og er vi store nok? Er svaret ja til begge, gælder kravene.

Ansvaret for forsyningskæden når I vælger bureau

Det der gør NIS2 særligt relevant i et udviklingsprojekt, er ansvaret for forsyningskæden. Kernen er at I ikke kan lægge sikkerheden over på en anden og vaske jeres hænder. Hyrer I et bureau til at bygge jeres system, bliver det bureau en del af jeres kæde, og dets sikkerhedsmangler kan blive jeres problemer, både i praksis og over for tilsynet.

I praksis betyder det at sikkerhed skal være et kriterium allerede når I vælger leverandør, ikke et spørgsmål bagefter. Ved en teknisk evaluering bør I se på hvordan leverandøren faktisk arbejder med sikkerhed: hvordan den beskytter kode og data, hvordan den håndterer sårbarheder og hændelser, og hvordan den selv stiller krav til sine egne underleverandører. Det skal derefter afspejles i kontrakten, med klare forpligtelser om sikkerhedsarbejde, hændelseshåndtering og retten til at følge op. En leverandør der ikke kan beskrive sit eget sikkerhedsarbejde, er en risiko uanset NIS2, men under direktivet bliver den risiko også et spørgsmål om jeres egen overholdelse af reglerne.

Tidskravene til indberetning af hændelser og hvad systemet skal kunne

En af de mest konkrete nyheder i NIS2 er kravene om hurtig indberetning af hændelser. Alvorlige hændelser skal indberettes til den relevante myndighed inden for snævre tidsvinduer: en tidlig varsling kort efter at hændelsen er opdaget, fulgt af mere udførlig indberetning derefter. De præcise frister følger af den nationale lov, men retningen er klar: Det skal gå hurtigt.

For et udviklingsprojekt er den afgørende indsigt at man ikke kan indberette det man ikke opdager. Et system uden ordentlig logning og overvågning gør det umuligt at vide at en hændelse er sket, endsige at tidsstemple den og indberette den til tiden. Derfor bliver visse egenskaber direkte knyttet til overholdelse af reglerne:

Det meste af dette kendetegner under alle omstændigheder et velbygget system. Det nye med NIS2 er at det går fra ønskeligt til obligatorisk, og at det bør stå i kravene fra begyndelsen fordi det er svært og dyrt at bygge ind bagefter.

Et konkret scenarie

En organisation i en af de udpegede sektorer skulle indkøbe et nyt system og konstaterede at den var omfattet af NIS2. I stedet for at behandle sikkerhed som en teknisk detalje der skulle løses til sidst, blev den løftet ind i kravene og i evalueringen af leverandører helt fra start.

Ved valget blev leverandørernes sikkerhedsarbejde vægtet for alvor: hvordan de håndterede sårbarheder, hvordan de ville bygge logning og overvågning, og hvordan de stillede krav nedad i deres egen kæde. Systemet blev bygget med opdagelse af hændelser og sporbarhed fra bunden, og kontrakten regulerede ansvaret for indberetning og opfølgning. Da en mindre sikkerhedshændelse senere indtraf, kunne den opdages, tidsstemples og indberettes inden for tidsvinduet, noget der ville have været umuligt hvis sikkerheden først var blevet tænkt ind efter lanceringen.

Byg kravene ind fra begyndelsen

NIS2 gør cybersikkerhed til et spørgsmål for hele forsyningskæden og for ledelsen, ikke kun for IT-afdelingen. For et udviklingsprojekt er budskabet konkret: Find ud af om I er omfattet, vægt sikkerhed ved valget af leverandør, skriv det ind i kontrakten, og byg systemer der kan opdage og indberette hændelser til tiden. Gøres det fra start, er det overkommeligt; gøres det for sent, bliver det en dyr omstilling under pres.

Hos Weapp bygger vi med sikkerhed og sporbarhed som udgangspunkt og hjælper gerne kunder med at oversætte krav som NIS2 til en konkret kravspecifikation, som en del af vores services. Er I i tvivl om hvad direktivet betyder for jeres næste projekt? Kontakt os, så tager vi en snak om hvordan kravene bedst vægtes allerede når I vælger bureau.