Annonce – sponsoreret indhold.

NIS2 krav til software betyder i praksis, at virksomheder omfattet af direktivet skal kunne dokumentere, at deres systemer udvikles, vedligeholdes og opdateres på en sikker og kontrolleret måde. Det gælder også leverandørkæden. Hvis du administrerer ejendomme, driver en boligforening eller udvikler en proptech-løsning til lejekontrakter, fraflytning eller smart home-styring, kan du blive ramt på to måder: direkte, hvis din virksomhed er omfattet, eller indirekte, når kunder og samarbejdspartnere stiller krav til dine leverandører og dig. Denne guide forklarer, hvad kravene betyder for softwaren bag dine systemer, hvordan en sikker udviklingsproces ser ud, og hvad du skal spørge din leverandør om.

NIS2 krav til software: Hvem i boligbranchen bliver omfattet?

NIS2 er EU’s direktiv om net- og informationssikkerhed (direktiv 2022/2555). Det erstatter det oprindelige NIS-direktiv og udvider kredsen af omfattede sektorer markant. I Danmark er direktivet gennemført i dansk ret, og Center for Cybersikkerhed (CFCS) spiller en central rolle sammen med de sektormyndigheder, der fører tilsyn på de enkelte områder.

Ejendomsadministration og boligudlejning er ikke i sig selv en sektor på NIS2’s lister. Alligevel mærker mange i branchen kravene, af flere grunde:

• Forsyning og energi: Boligforeninger og administratorer, der driver eller leverer til fjernvarme, vand, el-infrastruktur eller ladeløsninger, kan være tæt på sektorer, der er omfattet.
• Digitale tjenester: En proptech-virksomhed, der leverer sin løsning som cloud- eller SaaS-tjeneste til andre virksomheder, kan falde ind under reglerne for digitale udbydere eller it-tjenesteydelser. Det afhænger af størrelse og tjenestens karakter.
• Størrelse: Som udgangspunkt gælder direktivet mellemstore og store virksomheder i de omfattede sektorer. Almindeligt kendt er grænsen for mellemstore virksomheder på mindst 50 ansatte eller en vis omsætning og balance. Små virksomheder kan dog også blive omfattet i særlige tilfælde.
• Leverandørkæden: NIS2 kræver, at omfattede virksomheder styrer sikkerheden hos deres leverandører. Er dine kunder omfattet, kommer kravene som kontraktvilkår og leverandørspørgeskemaer, uanset om du selv er omfattet.

Om netop din virksomhed er omfattet, afhænger af en konkret vurdering af sektor, aktivitet og størrelse. Brug Center for Cybersikkerheds vejledninger og den relevante sektormyndighed som udgangspunkt, og få juridisk rådgivning, hvis du er i tvivl. Du bør ikke antage, at du er uden for.

Hvorfor er software så centralt? Fordi en stor del af angrebene mod virksomheder ikke sker via kontoret, men via de systemer, de bruger. En lejerportal med en svaghed i adgangsstyringen, et fraflytningsmodul, der kan manipuleres, eller en smart home-platform med en usikker integration kan give adgang til persondata, nøgler, betalingsoplysninger og i værste fald fysisk adgang til boliger. Her bliver sammenhængen mellem SDLC og NIS2 tydelig: Direktivet kræver sikkerhed i anskaffelse, udvikling og vedligeholdelse af systemer, og en struktureret sikker udviklingsproces er den mest direkte måde at opfylde og dokumentere det på.

Hvad NIS2 konkret kræver af softwareudvikling

NIS2 er et rammedirektiv. Det foreskriver ikke bestemte værktøjer eller teknologier, men angiver risikostyringsforanstaltninger i artikel 21, som omfattede virksomheder skal have på plads. Flere af dem rammer direkte software og udvikling:

• Risikoanalyse og sikkerhedspolitikker: Du skal systematisk vurdere risici for dine net- og informationssystemer, herunder de applikationer, der understøtter forretningen.
• Sikkerhed i anskaffelse, udvikling og vedligeholdelse: Direktivet nævner udtrykkeligt sårbarhedshåndtering og -offentliggørelse. Du skal vide, hvilke sårbarheder dine systemer har, og have en proces for at rette dem.
• Leverandørkæde: Du skal vurdere sikkerhedspraksis hos direkte leverandører og tage højde for deres sårbarheder og udviklingsprocesser.
• Håndtering af hændelser: Der er krav om tidlig varsling, normalt inden for 24 timer efter, at en alvorlig hændelse er opdaget, en mere detaljeret anmeldelse inden for 72 timer og en slutrapport senere. Det forudsætter logging og overvågning i systemerne, som skal bygges ind fra start.
• Kryptografi, adgangskontrol og multifaktorgodkendelse: Det er funktionelle sikkerhedskrav, som skal indgå i design og udvikling.
• Ledelsesansvar: Ledelsen skal godkende og føre tilsyn med sikkerhedsforanstaltningerne og kan holdes ansvarlig. Sikkerhed er derfor ikke noget, man kan overlade til it-afdelingen alene.

Forholdet til andre rammer kan være forvirrende, så her er en kort afklaring:

• ISO 27001 er en frivillig standard for ledelsessystemer for informationssikkerhed. Den indeholder kontroller for sikker udvikling og understøtter dokumentationen af NIS2-kravene, men certificering er ikke det samme som NIS2-compliance.
• Cyber Resilience Act (CRA) er EU’s forordning om cybersikkerhed for produkter med digitale elementer. Den er særligt relevant for producenter af smart home-enheder og tilhørende software. Anmeldelsespligter for sårbarheder og alvorlige hændelser begynder at gælde i 2026, og hovedkravene følger senere.
• GDPR gælder, så snart systemet behandler lejeres personoplysninger, og det gør næsten al boligsoftware. Datatilsynet har vejledning om passende sikkerhed og anmeldelse af brud.

Fælles for dem alle er, at sikkerhed skal dokumenteres, gentages og kunne eftervises. Det er en proces, ikke en engangsindsats.

Hvor risikoen sidder i typiske boligsystemer

For at forstå kravene hjælper det at se på, hvilke systemer en bolig- eller ejendomsvirksomhed typisk arbejder med, og hvor det kan gå galt.

Lejerportaler og administrationssystemer

Her ligger lejernes navne, adresser, CPR-relaterede oplysninger, kontraktdata og betalingshistorik. En klassisk svaghed er mangelfuld adskillelse mellem kunder i multi-tenant-systemer: Én ejendomsadministrator kan ved en fejl i adgangslogikken se en andens lejere. Det er en designfejl, der bør findes i trusselsmodelleringen, ikke af en tilfældig bruger.

Digitale kontrakter og fraflytning

Digitale lejekontrakter, tillæg og fraflytningsaftaler samler følsomme dokumenter og underskrifter. Dokumenternes integritet, sporbarhed og adgangsstyring skal være i orden. Har du ikke styr på det, kan du læse mere om den praktiske side i vores gennemgang af digital underskrift i ejendomsadministration. Sikkerhedsperspektivet er det samme: Du skal kunne stole på, at dokumentet ikke er ændret, og at kun de rette personer har haft adgang.

Smart home og adgangsstyring

Digitale låse, varmestyring, energimålere og sensorer binder software og fysiske enheder sammen. Her er sårbare integrationer, svag opdateringsstyring på enheder og utilstrækkelig kontrol med administrative funktioner de store risici. Hvis en leverandør ikke kan opdatere enhederne sikkert over tid, bliver bygningen en langsigtet risiko.

Integrationer og API’er

Økonomisystemer, bankforbindelser, e-Boks-lignende kanaler, håndværkerportaler og målerdata kobles sammen via API’er. Hver integration er en potentiel angrebsflade, og en svaghed hos én part kan ramme alle de andre.

Faserne i en sikker SDLC-proces

En Secure SDLC (Secure Software Development Lifecycle) bygger sikkerhed ind i hele udviklingsforløbet i stedet for at tilføje det til sidst. Antallet og navnene på faserne varierer fra organisation til organisation, men en gennemtænkt proces dækker som minimum de syv områder nedenfor.

1. Planlægning og sikkerhedskrav

Her afklares systemets formål, forretningsmæssige betydning og den information, det behandler. Herefter fastlægges sikkerhedskravene. Det kan være klassifikation af information, vurdering af kritikalitet, identifikation af lov- og kontraktkrav og krav til logging, adgangsstyring, kryptering og backup. Kravene skrives ind i user stories, backlog og kravspecifikation, så de ikke glemmes i hverdagen. Der defineres også kriterier for sikkerhedstest og godkendelse.

2. Risiko- og trusselsmodellering

Her analyseres, hvordan løsningen kan kompromitteres, og hvilke konsekvenser det får. For boligsystemer kan det være misbrug af brugerrettigheder, manipulation af data, utilstrækkelig adskillelse mellem kunder, sårbare integrationer og manglende kontrol med administrative funktioner. Analysen bruges til at prioritere sikkerhedsforanstaltninger, så indsatsen går til det, der betyder mest.

3. Sikkert design og arkitektur

Kravene og risiciene omsættes til konkrete valg: adgangsmodeller, dataflows, netværksopdeling, kryptering, integrationer, logging og sikker fejlhåndtering. Et design- og arkitekturreview kontrollerer, at de valgte løsninger faktisk håndterer de identificerede risici, før de bliver en fast del af systemet. Ændringer er billigere i designfasen end efter lancering.

4. Sikker udvikling

Udviklerne arbejder efter retningslinjer for sikker kodning, inputvalidering og fejlhåndtering. I praksis indgår typisk:

• retningslinjer for sikker kodning (secure coding guidelines)
• peer review og code review
• statisk kodeanalyse (SAST) og scanning efter eksponerede secrets som adgangsnøgler og adgangskoder i koden
• kontrol med open source-komponenter og biblioteker
• beskyttelse af udviklingsmiljøer og kodearkiver
• krav til brug af AI-assisterede udviklingsværktøjer, fx om hvilke data der må deles med værktøjet, og at AI-genereret kode gennemgår samme kontrol som anden kode

5. Test og sikkerhedskontrol

Sikkerhedstest viser, om løsningen opfylder kravene, og afslører sårbarheder, der skal rettes før release. Afhængigt af risikoen omfatter det SAST, DAST (test af den kørende applikation) og Software Composition Analysis (SCA) af tredjepartskomponenter, test af adgangsstyring og brugerrettigheder, sikkerhedstest af API’er og integrationer, penetrationstest, kontrol af sikkerhedskonfigurationer og verifikation af logging og hændelsesregistrering. Vigtigst er, at fundene vurderes og prioriteres i et dokumenteret forløb.

6. Release og deployment

Før en release skal det være klart, hvilke sikkerhedsfund der skal være håndteret, hvem der kan godkende udgivelsen, og hvordan undtagelser risikovurderes og dokumenteres. Sikker deployment indebærer adskillelse af udvikling, test og produktion, godkendelse af ændringer, beskyttelse af pipelines og kontrol med konfigurationer og secrets.

7. Drift, vedligeholdelse og sårbarhedshåndtering

Arbejdet stopper ikke ved lancering. Løsningen skal overvåges, og nye sårbarheder i egen kode, tredjepartskomponenter og infrastruktur skal håndteres løbende. Det er især her, NIS2’s krav om sårbarhedshåndtering og hændelsesrapportering bliver konkrete: Kan leverandøren hurtigt finde ud af, hvilke kunder en ny sårbarhed rammer, og rette den?

Sådan stiller du krav til din softwareleverandør

De fleste bolig- og ejendomsvirksomheder udvikler ikke selv deres kernesystemer. De køber dem. Så er det leverandørstyring, der afgør, om du lever op til forventningerne. NIS2 stiller krav om, at du tager sikkerhedspraksis hos dine leverandører i betragtning, og det bør afspejles i både udbud, kontrakter og opfølgning.

Spørgsmål til udbud og due diligence

• Har I en dokumenteret sikker udviklingsproces, og kan vi se en beskrivelse af den?
• Hvordan indarbejdes sikkerhedskrav i planlægning og design? Udføres der trusselsmodellering?
• Hvilke typer sikkerhedstest udføres før release (SAST, DAST, SCA, penetrationstest), og hvor ofte?
• Hvordan holdes open source-komponenter og biblioteker opdateret og kontrolleret?
• Hvordan sikres adskillelse mellem kunders data i løsningen?
• Hvordan håndterer I sårbarheder, og hvor hurtigt informeres kunderne?
• Hvordan er jeres udviklingsmiljøer og kodearkiver beskyttet, og hvilke regler gælder for AI-værktøjer?
• Hvilke certificeringer eller uafhængige vurderinger findes, fx ISO 27001, og hvad omfatter de konkret?

Kontraktkrav, der giver mening

• Sikkerhedskrav i kontrakten: Henvis til konkrete krav og ikke blot til “almindelig god praksis”.
• Hændelsesunderretning: Fastlæg tidsfrister for, hvornår leverandøren skal informere dig. Hvis du selv er omfattet af NIS2’s varslingsfrister, skal leverandørens frist være kortere end din egen.
• Sårbarhedshåndtering: Aftal svartider for kritiske sårbarheder og krav til patching.
• Revisions- og dokumentationsret: Du skal kunne få adgang til sikkerhedsrapporter, resultater af penetrationstest (evt. i sammenfattet form) og dokumentation for processen.
• Underleverandører: Krav til oplysning om og styring af underleverandører, herunder hosting og komponenter.
• Databehandleraftale: Den skal være på plads, hvis der behandles personoplysninger. Sikkerhedsforanstaltningerne skal passe til risikoen.
• Exit og dataportabilitet: Du skal kunne komme videre, hvis samarbejdet ophører eller leverandøren får alvorlige sikkerhedsproblemer.

Typiske fejl

• At nøjes med et ja i et spørgeskema uden at bede om dokumentation.
• At forveksle hosting-sikkerhed med softwaresikkerhed. Et sikkert datacenter redder ikke en applikation med svag adgangsstyring.
• At acceptere “vi tager sikkerhed meget alvorligt” som svar uden en beskrevet proces.
• At glemme smart home-enheder og integrationer, når der vurderes risici.
• At lade indkøbet foregå uden dialog med den person, der har ansvar for informationssikkerhed og databeskyttelse.

Hvis du selv udvikler: Sådan kommer en mindre proptech-virksomhed i gang

Udvikler du selv en løsning til boligbranchen, vil dine kunder i stigende grad bede om dokumentation. Du behøver ikke gøre alt på én gang, men du skal starte med noget struktureret.

1. Kortlæg dine systemer og data. Hvilke oplysninger behandler løsningen, hvem bruger den, og hvad sker der, hvis den går ned eller kompromitteres?
2. Skriv de vigtigste sikkerhedskrav ned. Adgangsstyring, logging, kryptering og backup er et godt sted at starte.
3. Indfør en let trusselsmodellering ved nye funktioner og integrationer. Stil spørgsmålet: Hvordan kunne dette misbruges?
4. Automatiser det, der kan automatiseres: scanning af kode og komponenter samt secrets-kontrol i pipelinen.
5. Definér release-kriterier. Hvilke fund blokerer en udgivelse, og hvem godkender undtagelser?
6. Etabler en proces for sårbarheder og hændelser, så du kan reagere hurtigt og informere kunderne.
7. Dokumentér undervejs. Compliance handler om at kunne vise, hvad du gør, ikke kun at gøre det.

Mange mindre virksomheder har gavn af ekstern rådgivning til at etablere processen og tilpasse den til størrelse og risiko. Målet er en proces, der passer til organisationen, så den faktisk bliver brugt.

Konkrete tegn på, at en leverandørs udviklingsproces holder

Når du vælger eller evaluerer et system, kan du bruge følgende tegn som tjekliste. Ingen af dem er en garanti, men samlet giver de et godt billede.

Grønne flag

• Leverandøren kan fremlægge en beskrevet udviklingsproces med sikkerhedsaktiviteter i hver fase og forklare, hvordan den følges i praksis.
• Der foreligger dokumenterede sikkerhedstests, fx resultater eller sammenfatninger af penetrationstest og beskrivelse af, hvordan fund prioriteres og lukkes.
• Leverandøren har en kendt procedure for sårbarheder, herunder en kontaktvej til at rapportere dem, og informerer kunderne aktivt.
• Der er klare release-kriterier og adskilte miljøer til udvikling, test og produktion.
• Leverandøren har overblik over sine tredjepartskomponenter og kan svare på, om en ny sårbarhed rammer systemet.
• Der er regler for AI-værktøjer i udviklingen og beskyttelse af kodearkiver og pipelines.
• Leverandøren er åben om underleverandører og hosting.
• Leverandøren stiller dokumentation til rådighed uden lange forhandlinger og har en ansvarlig for informationssikkerhed, du kan tale med.

Røde flag

• Svar som “det klarer hostingudbyderen” eller “vi har aldrig haft problemer”.
• Ingen kendskab til, hvilke open source-komponenter systemet bruger.
• Penetrationstest, der er flere år gamle, eller som aldrig er udført.
• Ingen aftalt frist for at informere dig om sikkerhedshændelser.
• Sikkerhed beskrives kun som funktioner (to-faktor-login), men ikke som en proces bag udviklingen.
• Manglende mulighed for at se logs eller få dokumentation for, hvem der har haft adgang til dine data.

Næste gang du sidder med en demo af et nyt lejeadministrationssystem, en fraflytningsløsning eller en smart home-platform, så bed om at høre, hvordan sikkerheden er bygget ind i udviklingen, og ikke kun om, hvilke funktioner systemet har. Svaret fortæller meget om, hvor moden leverandøren er.

Ofte stillede spørgsmål

Gælder NIS2 for min boligforening eller ejendomsadministration?

Ikke automatisk. Ejendomsadministration er ikke i sig selv en omfattet sektor, men aktiviteter som energi- og varmeforsyning, digitale tjenester eller it-ydelser kan medføre, at virksomheden er omfattet. Størrelsen har også betydning. Derudover kan du få krav som leverandør eller kunde i en kæde, hvor andre er omfattet. Få en konkret vurdering via Center for Cybersikkerhed, den relevante sektormyndighed eller en juridisk rådgiver.

Er ISO 27001-certificering det samme som at leve op til NIS2?

Nej. ISO 27001 er en frivillig standard, der kan understøtte arbejdet og dokumentationen, men NIS2 er lovgivning med egne krav, fx om ledelsesansvar og rapportering af hændelser. Certificeringens omfang er også afgørende: Dækker den den softwareudvikling, du er afhængig af?

Hvad er forskellen på NIS2 og Cyber Resilience Act?

NIS2 stiller krav til organisationers cybersikkerhed og risikostyring i omfattede sektorer. CRA stiller krav til selve produkterne med digitale elementer, fx smart home-enheder og tilhørende software, gennem hele deres levetid. En producent af smart home-løsninger kan derfor være omfattet af begge dele på samme tid.

Hvad er Secure SDLC, og hvorfor er det relevant for NIS2?

Secure SDLC er en struktureret udviklingsproces, hvor sikkerhed indgår i alle faser fra krav og design over test og release til drift og sårbarhedshåndtering. Det er relevant, fordi NIS2 kræver sikkerhed i udvikling og vedligeholdelse af systemer samt sårbarhedshåndtering. En dokumenteret proces gør det muligt at vise, at kravene faktisk opfyldes.

Hvad kan jeg som lille virksomhed gøre med det samme?

Kortlæg dine systemer og de data, de behandler, bed dine leverandører om dokumentation for deres udviklings- og sårbarhedsprocesser, og få aftalt tidsfrister for hændelsesunderretning i kontrakterne. Hvis du selv udvikler software, så start med sikkerhedskrav, automatisk kode- og komponentscanning og klare kriterier for release.