NIS2 2024/2690-kortlægning til ISO 27001 for cloududbydere
Kl. 08:17 en tirsdag modtager Maria, CISO hos en europæisk managed service provider, den alarm, enhver MSP frygter. Én privilegeret konto til fjernadministration har udløst alarmer om umulig rejseaktivitet. To kundetenants viser unormale administrative handlinger. SOC’et har allerede etableret en kritisk hændelsesbro.
Kl. 09:00 deltager den administrerende direktør i opkaldet. Spørgsmålene ændrer sig med det samme.
Er vi omfattet af NIS2? Gælder Kommissionens gennemførelsesforordning (EU) 2024/2690 for os? Skal vi sende en tidlig advarsel inden for 24 timer? Hvilke kunder skal underrettes? Kan vi dokumentere, at MFA, logning, segmentering, sårbarhedsstyring, leverandørkontroller og hændelseseskalering fungerede før hændelsen?
Marias virksomhed er ISO/IEC 27001:2022-certificeret. Den leverer cloudstyring, datacentertjenester og managed security-support til kunder, herunder en logistikudbyder og en regional bank. Certifikatet har betydning, men det besvarer ikke i sig selv de driftsmæssige spørgsmål. Det juridiske team har et udkast til en underretningsproces. Den complianceansvarlige har et regneark. Auditoren har bedt om Statement of Applicability, test af hændelseshåndtering, adgangslogfiler for privilegeret adgang, leverandør-due diligence, bevismateriale for delt ansvar i cloud og forudsætninger for forretningskontinuitet.
Det er her, NIS2 ophører med at være en juridisk tekst og bliver et driftsmæssigt kontrolproblem.
For cloud computing-tjenesteudbydere, managed service providers, managed security service providers og datacenterudbydere hæver NIS2 og gennemførelsesforordning 2024/2690 barren fra generelle sikkerhedsintentioner til kontroller, der kan efterprøves gennem bevismateriale. Ledelsesforankring, risikostyring, adgangsstyring, aktivstyring, sårbarhedshåndtering, hændelseshåndtering, leverandørsikkerhed, logning, overvågning, kryptering, forretningskontinuitet og fysisk robusthed skal fungere som ét samlet system.
ISO/IEC 27001:2022 er den bedste rygrad for dette system, men kun hvis organisationen kortlægger NIS2-krav ind i ISMS’et, risikoregisteret, Statement of Applicability, politikkerne og evidensmodellen. Et certifikat på væggen er ikke nok. Det reelle arbejde er at opbygge en revisionsbar kæde fra regulering til risiko, fra risiko til kontrol, fra kontrol til politik og fra politik til driftsbevismateriale.
Hvorfor NIS2 2024/2690 ændrer compliance-samtalen for cloud og MSP
NIS2 anvender en sektor-plus-størrelse-model, men kategorierne for digital infrastruktur og IKT-service management er bevidst brede. Efter NIS2 Article 2 og Article 3, læst sammen med Annex I og Annex II, kan mange organisationer klassificeres som væsentlige eller vigtige enheder, herunder cloud computing-tjenesteudbydere, datacentertjenesteudbydere, managed service providers, managed security service providers, DNS-udbydere, TLD-registre, content delivery networks og tillidstjenesteudbydere. Medlemsstaterne skal etablere og regelmæssigt gennemgå lister over væsentlige og vigtige enheder, med første frist for listen fastsat til 17. april 2025.
Det er væsentligt, fordi cloud-, MSP-, MSSP- og datacenterudbydere indgår i andre organisationers risikokæder. En kompromittering af cloudens kontrolplan kan påvirke tusindvis af kundesystemer. Et nedbrud i et datacenter kan forplante sig til banksektoren, sundhedssektoren, logistik og offentlig administration. Et brud på legitimationsoplysninger hos en MSP kan udvikle sig til en ransomware-hændelse på tværs af flere kunder. En detektionsfejl hos en MSSP kan forsinke inddæmning hos regulerede kunder.
NIS2 Article 20 kræver, at ledelsesorganer godkender foranstaltninger til cybersikkerhedsrisikostyring og fører tilsyn med implementeringen. Article 21 kræver passende og proportionale tekniske, driftsmæssige og organisatoriske foranstaltninger baseret på en all-hazards-tilgang. Grundlaget omfatter risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, sårbarhedshåndtering og offentliggørelse, vurdering af effektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring, MFA eller løbende autentifikation, sikker kommunikation og nødkommunikation.
Article 23 tilføjer trinvise krav om rapportering af væsentlige hændelser, herunder en tidlig advarsel inden for 24 timer, hændelsesunderretning inden for 72 timer, mellemliggende rapporter efter anmodning og en endelig rapport inden for én måned efter underretningen eller efter hændelseshåndteringen, hvis hændelsen fortsat pågår.
Gennemførelsesforordning 2024/2690 gør disse forventninger mere konkrete for relevante digitale udbydere. I praksis vil myndigheder, kunder og auditorer ikke kun spørge, om der findes politikker. De vil spørge, om kontrollerne er kortlagt, ejet, testet og dokumenteret.
ISO/IEC 27001:2022 gør NIS2 til en driftskontekst i ISMS’et
En almindelig fejl i NIS2-beredskab er at begynde med en stor tjekliste og fordele opgaver på IT, jura, SOC, infrastruktur, leverandørstyring og compliance. Det kan skabe aktivitet, men fejler ofte under revision, fordi ingen kan vise, hvorfor kontrollerne blev valgt, hvordan de relaterer sig til risiko, hvem der accepterede restrisiko, og hvilket bevismateriale der dokumenterer effektivitet.
ISO/IEC 27001:2022 giver udbydere strukturen til at undgå denne fejl.
Klausul 4.1 til 4.4 kræver, at organisationen fastlægger interne og eksterne forhold, identificerer interessenter og deres krav, beslutter hvilke krav der skal håndteres gennem ISMS’et, og definerer ISMS-omfanget, herunder grænseflader og afhængigheder. For en cloud- eller MSP-udbyder bør omfanget eksplicit tage højde for NIS2, gennemførelsesforordning 2024/2690, kunders sikkerhedsbilag, DORA-drevne kundekrav, cloudregioner, underleverandører, datacenterafhængigheder, platforme til fjernadministration, privilegerede adgangsveje og forpligtelser til hændelsesunderretning.
Klausul 5.1 til 5.3 kræver lederskab, tilpasning af politikker, ressourcer, kommunikation, tildelte ansvarsområder og ledelsesmæssig ansvarlighed. Det understøtter direkte NIS2 Article 20.
Klausul 6.1.1 til 6.1.3 kræver risikovurdering, risikobehandling, risikoejere, analyse af sandsynlighed og konsekvens, kontroludvælgelse, sammenligning med Annex A, en Statement of Applicability, en risikobehandlingsplan og formel accept af restrisiko. Det er her, NIS2 bliver operationel. Hvert regulatorisk krav bliver en risikodriver, efterlevelsesforpligtelse, kontrolkrav eller evidenskrav.
Clarysec indleder dette arbejde med Zenith Blueprint: en auditors 30-trins køreplan Zenith Blueprint, især fasen for risikostyring.
Fra trin 13, planlægning af risikobehandling og Statement of Applicability, instruerer Zenith Blueprint teams i at opbygge sporbarhed mellem risici, kontroller og regulatoriske drivere:
“Krydshenvis reguleringer: Hvis bestemte kontroller er implementeret specifikt for at efterleve GDPR, NIS2 eller DORA, kan du notere det enten i risikoregisteret eller i SoA-noterne. F.eks. kan kontrol 8.27 (sikker sletning af data) være meget relevant for GDPR’s krav om bortskaffelse af personoplysninger; du kan notere ‘Relevant – understøtter GDPR Art.32 (behandlingssikkerhed)’. Dette kræves ikke af ISO, men det hjælper med at dokumentere, at du har taget disse frameworks i betragtning.”
Trin 14, politikker for risikobehandling og regulatoriske krydshenvisninger, tilføjer den praktiske kortlægningsdisciplin:
“For hver regulering kan du, hvor det er relevant, oprette en simpel kortlægningstabel, der oplister reguleringens centrale sikkerhedskrav og de tilsvarende kontroller/politikker i dit ISMS. Det er ikke obligatorisk i ISO 27001, men det er en nyttig intern øvelse for at sikre, at intet falder mellem to stole.”
Det er forskellen mellem at sige “vi er ISO-certificeret” og at dokumentere “vores ISO/IEC 27001:2022 ISMS adresserer NIS2-gennemførelsesforordning 2024/2690.”
Samlet kontrolkortlægning fra NIS2 til ISO/IEC 27001:2022
Følgende kortlægning er ikke juridisk rådgivning og erstatter ikke analyse af national implementering. Den er en praktisk kontrolarkitektur for udbydere, der har brug for en revisionsbar ISO/IEC 27001:2022-vej til NIS2-beredskab.
| NIS2- og gennemførelsesforordningstema | ISO/IEC 27001:2022 ISMS-mekanisme | Centrale Annex A-kontrolområder | Clarysec-implementeringsbevismateriale |
|---|---|---|---|
| Ledelsesforankring og ledelsesmæssig ansvarlighed | Klausul 4, 5, 6 og 9 definerer kontekst, lederskab, risikoplanlægning og evaluering af performance | 5.1 Politikker for informationssikkerhed, 5.2 Roller og ansvar for informationssikkerhed, 5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav | ISMS-omfang, register over interessenter, bestyrelsesgodkendelse, risikoregister, SoA, referater fra ledelsens gennemgang |
| Styring af cloudtjenester | Risikovurdering, leverandør-due diligence, delt ansvar og kontroludvælgelse | 5.23 Informationssikkerhed ved brug af cloudtjenester, 5.19 Informationssikkerhed i leverandørrelationer, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester | Cloudfortegnelse, risikovurdering af udbyder, matrix for delt ansvar, kontraktklausuler, bevismateriale for cloudlogning |
| Privilegeret adgang hos MSP og MSSP | Risikobehandling for kundemiljøer, administratorplatforme og supportværktøjer | 5.15 Adgangsstyring, 5.16 Identitetsstyring, 5.18 Adgangsrettigheder, 8.2 Privilegerede adgangsrettigheder, 8.5 Sikker autentifikation | PAM-registreringer, MFA-rapporter, fjernadgangslogfiler, konfiguration af bastion host eller Zero Trust-gateway, gennemgang af adgangsrettigheder |
| Datacenterrobusthed | Forretningskonsekvensanalyse, kontinuitetsplanlægning og afhængighedsstyring | 5.30 IKT-beredskab til forretningskontinuitet, 7.1 Perimetre for fysisk sikring, 7.2 Fysisk adgang, 8.13 Sikkerhedskopiering af information, 8.14 Redundans | BIA, RTO- og RPO-registreringer, DR-testrapport, logfiler for fysisk adgang, bevismateriale for test af strøm og køling |
| Hændelsesrapportering og eskalering | Hændelsesproces knyttet til juridiske, kontraktlige og kundemæssige udløsere for underretning | 5.24 Planlægning og forberedelse af styring af informationssikkerhedshændelser, 5.25 Vurdering af og beslutning om informationssikkerhedshændelser, 5.26 Respons på informationssikkerhedshændelser, 5.27 Læring fra informationssikkerhedshændelser | Playbook for tidlig advarsel inden for 24 timer, arbejdsgang for 72-timers underretning, hændelsesregister, efterhændelsesgennemgang |
| Sårbarhedshåndtering og offentliggørelse | Risikobaseret sårbarhedsbehandling, undtagelseshåndtering og evaluering af effektivitet | 8.8 Styring af tekniske sårbarheder, 8.9 Konfigurationsstyring, 8.32 Ændringsstyring, 8.16 Overvågningsaktiviteter | Scanningsresultater, afhjælpnings-SLA’er, godkendelser af undtagelser, patchrapporter, input fra trusselsintelligens |
| Sikkerhed i forsyningskæden | Krav fra interessenter og leverandørrisiko integreret i ISMS’et | 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester | Leverandørniveauinddeling, due diligence-spørgeskemaer, kontraktklausuler, revisionsrettigheder, underleverandørregister, exit-planer |
| Logning, overvågning og undersøgelse | Detektion, bevismateriale, tidskorrelation og understøttelse af hændelseshåndtering | 8.15 Logning, 8.16 Overvågningsaktiviteter, 8.17 Synkronisering af systemtid, 5.25 Vurdering af og beslutning om informationssikkerhedshændelser | SIEM-dækningskort, dokumentation for logopbevaring, registreringer for alarmtuning, registreringer for synkronisering af systemtid, bevismateriale for hændelseskorrelation |
| Netværks- og tenantisolering | Sikker arkitektur, segmentering og begrænsede administrative adgangsveje | 8.20 Netværkssikkerhed, 8.22 Funktionsadskillelse af netværk, 8.23 Webfiltrering, 8.24 Brug af kryptografi | Netværksdiagrammer, firewallregler, cloud security groups, VPC- eller subnetregler, resultater fra segmenteringstest |
Denne kortlægning bliver stærk, når den indlejres i risikoregisteret og Statement of Applicability. En udbyder kan for eksempel oprette et risikoscenarie med navnet “Kompromittering af platform til fjernadministration fører til uautoriserede handlinger i kundemiljøer.” Kontroller omfatter MFA, styring af privilegeret adgang, segmentering, logning, sårbarhedsstyring, leverandørsikkerhed, hændelsesplanlægning og procedurer for kundeunderretning. SoA-noterne kan henvise til NIS2 Article 21, Article 23, gennemførelsesforordning 2024/2690, kundekontrakter og DORA-krav til kunders due diligence, hvor det er relevant.
Cloudstyring: ISO-kontrol 5.23 er et NIS2-anker
For cloududbydere og MSP’er, der bruger cloudtjenester til at levere kundetjenester, er ISO/IEC 27001:2022 Annex A-kontrol 5.23, informationssikkerhed ved brug af cloudtjenester, et af de vigtigste ankre.
Zenith Controls: Cross-Compliance-guiden Zenith Controls sammenfatter kontrol 5.23 som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, knyttet til sikkerhed i leverandørrelationer, ledelsesforankring, økosystemrisiko og beskyttelse. Den dækker styring af cloudtjenester, delt ansvar, vurdering af udbydere, fortegnelser, datalokation, logning, kryptering, identitetsroller, overvågning, kontraktklausuler, leverandørrisiko, cloud-exit og robusthedsplanlægning.
Zenith Blueprint, fasen Kontroller i praksis, trin 23, forklarer den praktiske årsag:
“Cloud er ikke længere en destination, det er standarden. Kontrol 5.23 anerkender denne realitet og kræver, at informationssikkerhed eksplicit adresseres ved valg, brug og styring af cloudtjenester, ikke som en eftertanke, men som et designprincip fra begyndelsen.”
For en MSP skal enhver platform til fjernovervågning og -styring, kundeportal, helpdesk-sagsstyringssystem, sikkerhedstelemetriplatform, backuptjeneste, cloudkatalog og SaaS-administrationskonsol være omfattet af styring. For en datacenterudbyder kan cloudstyring omfatte overvågningsplatforme, besøgsstyringssystemer, integrationer til fysisk adgangsstyring, fjernadministrationssystemer og infrastruktur til kundeportaler.
Clarysecs Enterprise Cloud Usage Policy Cloud Usage Policy gør due diligence før aktivering obligatorisk:
“Al brug af cloud skal gennemgå risikobaseret due diligence før aktivering, herunder vurdering af udbyder, validering af juridisk og regulatorisk efterlevelse samt gennemgang af kontrolvalidering.”
Fra afsnittet “Styringskrav”, politikklausul 5.2.
For mindre udbydere etablerer Cloud Usage Policy-sme Cloud Usage Policy-sme - SME en enkel godkendelsesmodel:
“Al brug af cloudtjenester skal gennemgås og godkendes af direktøren (GM) før implementering eller abonnement.”
Fra afsnittet “Styringskrav”, politikklausul 5.1.
Begge tilgange understøtter den samme NIS2-forventning: risikoen ved cloudafhængigheder skal forstås, før tjenesten bliver en del af leverancekæden.
Hændelseshåndtering: 24-timers uret starter, før rapporten er skrevet
NIS2 Article 23 er ubønhørlig, fordi rapporteringsfristen starter, når der er kendskab til en væsentlig hændelse, ikke når en perfekt rodårsagsanalyse foreligger. Udfordringen for udbydere er hurtigt at afgøre, om en hændelse er væsentlig, hvilke kunder der er påvirket, om personoplysninger er involveret, om der er grænseoverskridende påvirkning af tjenesten, og hvilke kontraktlige frister der er begyndt at løbe.
ISO/IEC 27001:2022 Annex A-kontrol 5.24, planlægning og forberedelse af styring af informationssikkerhedshændelser, er planlægningskontrollen. Zenith Controls sammenfatter den som en korrigerende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, knyttet til Respond- og Recover-begreberne, ledelsesforankring, hændelsesstyring og forsvar. Den omfatter roller, ansvar, eskalationsveje, kommunikationsprotokoller, beredskab til regulatorisk underretning, tilpasning til logning og overvågning, integration med forretningskontinuitet og katastrofeberedskab, læring efter hændelser og kortlægning til NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 og COBIT 2019.
Clarysecs Incident Response Policy-sme Incident Response Policy-sme - SME gør den første beslutning til et tidsbundet krav:
“Direktøren skal, med input fra IT-leverandøren, klassificere alle hændelser efter alvorlighed inden for én time efter underretning.”
Fra afsnittet “Styringskrav”, politikklausul 5.3.1.
Denne klassificering inden for én time understøtter den driftsdisciplin, der kræves for NIS2-analyse af tidlig advarsel inden for 24 timer, GDPR-vurdering af brud på persondatasikkerheden, DORA-kundeeskalering og triage af kontraktlige underretninger.
En udbyders beslutningstræ for hændelser bør besvare fire spørgsmål:
- Er der bekræftet eller mistanke om kompromittering af fortrolighed, integritet eller tilgængelighed?
- Påvirker hændelsen levering af tjenesten, kundemiljøer, regulerede kunder, personoplysninger eller kritiske funktioner?
- Kan den medføre alvorlig driftsforstyrrelse, økonomisk tab eller materiel eller immateriel skade?
- Hvilke underretningsforpligtelser gælder: NIS2, GDPR, DORA-kundeforpligtelser, kontraktlige SLA’er eller nationale myndighedsforventninger?
Beslutningstræet bør testes i tabletop-øvelser før en reel hændelse.
Sårbarhedsstyring: dokumentér risikoreduktion før påvirkning
NIS2 kræver sårbarhedshåndtering og offentliggørelse. For kunder og tilsynsmyndigheder er sårbarhedsstyring et af de nemmeste kontrolområder at måle, fordi det producerer tydeligt bevismateriale: scanningsdækning, patchtidslinjer, godkendelser af undtagelser, analyse af udnyttede sårbarheder og afhjælpningsregistreringer.
ISO/IEC 27001:2022 Annex A-kontrol 8.8, styring af tekniske sårbarheder, sammenfattes i Zenith Controls som en forebyggende kontrol på tværs af fortrolighed, integritet og tilgængelighed, knyttet til Identify og Protect, trussels- og sårbarhedsstyring, ledelsesforankring, økosystem, beskyttelse og forsvar. Den omfatter identifikation af sårbarheder, vurdering, prioritering, patchning, kompenserende kontroller, integration af trusselsintelligens, offentliggørelse af sårbarheder, ansvar for cloud- og applikationssårbarheder, revisionsbevismateriale og afhjælpningsfrister.
Clarysecs Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy giver auditorer en konkret model at teste:
“Organisationen skal klassificere alle detekterede sårbarheder ved hjælp af en standardiseret metode (f.eks. CVSS v3.x) og anvende afhjælpningsfrister, der er tilpasset forretningskritikalitet: 5.2.1 Kritisk (CVSS 9.0-10.0): Øjeblikkelig gennemgang; frist for patchning på maksimalt 72 timer. 5.2.2 Høj (7.0-8.9): Respons inden for 48 timer; frist for patchning på 7 kalenderdage. 5.2.3 Middel (4.0-6.9): Respons inden for 5 dage; frist for patchning på 30 kalenderdage. 5.2.4 Lav (<4.0): Respons inden for 10 dage; frist for patchning på 60 kalenderdage.”
Fra afsnittet “Styringskrav”, politikklausul 5.2.
For en cloududbyder skal dette dække hypervisorkomponenter, container-images, orkestreringslag, kundevendte API’er, CI/CD-pipelines, administrative konsoller og tredjepartsbiblioteker. For en MSP er det centrale spørgsmål, om interne sårbarheder adskilles fra kundeadministrerede sårbarheder, og om kontrakter definerer ansvaret. For en datacenterudbyder kan omfanget omfatte bygningsstyringssystemer, adgangsstyringssystemer, overvågningsplatforme, remote hands-værktøjer og netværksinfrastruktur.
Modellen for delt ansvar skal dokumenteres. En udbyder ejer muligvis ikke hver patch, men skal stadig styre risikoen, underrette kunden, hvor det er relevant, og dokumentere, at ansvarsgrænserne er forstået.
Logning, overvågning og segmentering gør hændelser undersøgelsesegnede
Når en udbyderhændelse får kundepåvirkning, er de første spørgsmål til bevismateriale enkle: hvem loggede ind, hvorfra, med hvilket privilegium, til hvilken tenant, hvad blev ændret, hvilke logfiler findes, og om administrative adgangsveje var segmenteret.
Clarysecs Enterprise Logging and Monitoring Policy Logging and Monitoring Policy kræver, at omfattede systemer genererer de logfiler, som respondere og auditorer har brug for:
“Alle omfattede systemer skal generere logfiler, der registrerer: 6.1.1.1 Brugerautentifikation og adgangsforsøg 6.1.1.2 Privilegerede brugeraktiviteter 6.1.1.3 Konfigurationsændringer 6.1.1.4 Mislykkede adgangsforsøg eller systemhændelser 6.1.1.5 Malwaredetektioner og sikkerhedsalarmer 6.1.1.6 Ekstern kommunikation og udløsning af firewallregler”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.
For SMV’er, der er afhængige af eksterne udbydere, tilføjer Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME et kontraktligt krav:
“Kontrakter skal kræve, at udbydere opbevarer logfiler i mindst 12 måneder og giver adgang efter anmodning.”
Fra afsnittet “Styringskrav”, politikklausul 5.5.1.3.
Segmentering er lige så vigtig. Network Security Policy-sme Network Security Policy-sme - SME angiver:
“Interne netværk skal segmenteres efter funktion (f.eks. økonomi, gæst, IoT, administrative systemer).”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.
Zenith Blueprint, fasen Kontroller i praksis, trin 20, giver den praktiske revisionsprocedure for netværksarkitektur og segmentering. Den instruerer teams i at gennemgå og dokumentere netværkslayout, verificere firewallregler, IPS/IDS- og fjernadgangskonfigurationer, bekræfte at cloud security groups og VPC- eller subnetregler matcher den tilsigtede arkitektur, opliste interne og eksterne netværkstjenester og validere, at følsomme systemer ikke kan nås fra generelle bruger-VLAN’er eller gæstenetværk.
For en MSP må fjernadministrationsværktøjer ikke ligge fladt på kontornetværket. For en datacenterudbyder bør administrationsgrænseflader til strøm, køling, adgangsstyring og kunders netværkstjenester isoleres og overvåges. For en cloududbyder bør adgang til kontrolplanet begrænses gennem identitet, netværk, enheders sikkerhedstilstand og privilegerede arbejdsgange.
Leverandørsikkerhed: udbyderen er også kunde
Cloud-, MSP-, MSSP- og datacenterudbydere er leverandører til regulerede kunder, men de er også kunder hos softwareleverandører, teleoperatører, identitetsudbydere, SaaS-platforme, hardwareleverandører, underleverandører og infrastrukturoperatører.
NIS2 gør sikkerhed i forsyningskæden til et centralt krav. DORA, som finder anvendelse fra 17. januar 2025, gør styring af IKT-tredjepartsrisiko centralt for finansielle enheder. NIS2 Article 4 og Recital 28 anerkender DORA som den sektorspecifikke EU-retsakt for finansielle enheder, hvor krav overlapper. Det fjerner ikke presset fra cloud- og MSP-udbydere. Det øger det, fordi finansielle kunder viderefører DORA-niveaukrav til leverandørkontrakter, revisionsrettigheder, robusthedstest, exit-strategier og forventninger til hændelsesrapportering ind i leverandørkontrakter.
Clarysecs Enterprise Third-Party and Supplier Security Policy Third-Party and Supplier Security Policy kræver kontrolleret tredjepartsadgang:
“Al tredjepartsadgang skal logges og overvåges og, hvor det er muligt, segmenteres gennem bastion hosts, VPN’er eller Zero Trust-gateways.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.2.
Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME udtrykker princippet om mindst privilegium i direkte vendinger:
“Leverandører må kun tildeles adgang til de minimumssystemer og data, der kræves for at udføre deres funktion.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.
Disse klausuler kortlægges naturligt til ISO/IEC 27001:2022 Annex A-kontrollerne 5.19, 5.20, 5.21 og 5.22. De understøtter også styring af GDPR-databehandlere og underdatabehandlere, DORA-gennemgange af tredjepartsrisiko og kunders revisionsspørgeskemaer.
Forretningskontinuitet og datacenterrobusthed: dokumentér forudsætningerne
NIS2 Article 21 omfatter forretningskontinuitet, backupstyring, katastrofeberedskab og krisestyring. DORA Articles 11 til 14 kræver IKT-forretningskontinuitetspolitikker, respons- og genopretningsplaner, forretningskonsekvensanalyse, backuppolitikker, gendannelsesprocedurer, genopretningsmål, test, efterhændelsesgennemgange og krisekommunikation for finansielle enheder.
For cloud- og datacenterudbydere er kontinuitet ikke et ringbind. Det er arkitektur, kapacitet, kontrakter, afhængigheder, bevismateriale for gendannelse og testede forudsætninger.
Clarysecs Enterprise Business Continuity and Disaster Recovery Policy Business Continuity and Disaster Recovery Policy kræver årlig BIA og gennemgang efter væsentlige ændringer:
“Forretningskonsekvensanalyse (BIA) skal udføres mindst årligt for alle kritiske forretningsenheder og gennemgås ved væsentlige ændringer i systemer, processer eller afhængigheder. BIA-output skal definere: 5.2.1. Maksimalt tolerabel nedetid (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Kritiske afhængigheder (systemer, leverandører, personale)”
Fra afsnittet “Styringskrav”, politikklausul 5.2.
I et datacenterscenarie bør BIA dække strømforsyninger, UPS, generatorer, brændstofkontrakter, køling, brandslukning, netværksoperatører, fysiske adgangssystemer, remote hands, overvågning, reservehardware og kundekommunikationskanaler. I et cloudscenarie bør den dække regioner, tilgængelighedszoner, replikering, immutable backups, identitetsafhængigheder, DNS, certifikatudstedere, API-gateways og supportsystemer. I et MSP-scenarie bør den dække værktøjer til fjernadministration, bokse til privilegeret adgang, EDR-konsoller, helpdesk-sagsstyring, dokumentationsrepositories og nødkommunikation.
ISO 22301 kan styrke disciplinen for forretningskontinuitetsstyring, mens ISO/IEC 27005:2022 understøtter risikokriterier, behandlingsplanlægning, overvågning, bevismateriale og løbende forbedring. Det er nyttigt, fordi NIS2-beredskab kræver, at organisationen samler juridiske, kontraktlige, driftsmæssige, leverandørmæssige, teknologiske, finansielle, procesmæssige og menneskelige faktorer i én risikoproces.
Praktisk risikospor for et brud på MSP-fjernadgang
En praktisk workshop kan begynde med ét scenarie:
“Kompromittering af privilegeret fjernadgang medfører uautoriseret adgang til kundesystemer, driftsafbrydelser, mulig eksponering af personoplysninger og regulatoriske underretningsforpligtelser.”
Opret en række i risikoregisteret og fuldfør sporet.
| Felt | Eksempelpost |
|---|---|
| Risikoejer | Leder for Managed Services |
| Aktiver og processer | Platform til fjernadministration, kunders administratorkonti, privilegeret vault, helpdesk-sagsstyring, SIEM, kundemiljøer |
| Trusselshændelse | Tyveri af legitimationsoplysninger, MFA fatigue, tokentyveri, udnyttet RMM-sårbarhed, ondsindet insider |
| Konsekvens | Kundekompromittering, serviceafbrydelse, kontraktbrud, væsentlig NIS2-hændelse, GDPR-brud på persondatasikkerheden, DORA-kundeeskalering |
| Eksisterende kontroller | MFA, PAM, mindst mulige rettigheder, segmentering, logning, sårbarhedsscanning, hændelseshåndteringsplan |
| Påkrævet behandling | Stram conditional access, håndhæv just-in-time administratoradgang, forbedr tenantisolering, øg logopbevaring, test underretningsplaybook |
| ISO/IEC 27001:2022-bevismateriale | Risikovurdering, SoA, gennemgang af adgangsrettigheder, logprøver, sårbarhedsrapporter, tabletop-øvelse, ledelsens gennemgang |
| NIS2-kortlægning | Article 21 risikostyring og Article 23 hændelsesrapportering samt gennemførelsesforordningens driftsmæssige foranstaltninger |
| Kundekortlægning | Kontraktlig underretning, revisionsrettigheder, sikkerhedsbilag, DORA-tilpassede spørgeskemaer, hvor relevant |
| Beslutning om restrisiko | Accepteret af risikoejer efter behandling, gennemgås kvartalsvist |
Opdater derefter Statement of Applicability. Forklar for hver relevant Annex A-kontrol, hvorfor den gælder, og hvilket NIS2-tema den understøtter. Indsaml til sidst bevismateriale før en revision: rapporter om MFA-håndhævelse, lister over privilegerede konti, indstillinger for logopbevaring, RMM-patchstatus, SIEM-alarmer, registreringer af hændelsesklassificering, godkendelser af leverandøradgang og tabletop-resultater.
Hvordan forskellige auditorer tester det samme kontrolmiljø
Et integreret ISMS skal tilfredsstille forskellige assurance-perspektiver uden at skabe separate evidenspakker for hvert framework.
| Auditorperspektiv | Hvad de vil fokusere på | Typisk efterspurgt bevismateriale |
|---|---|---|
| ISO/IEC 27001:2022-auditor | Om NIS2-, DORA- og GDPR-krav er afspejlet i kontekst, omfang, risikovurdering, SoA, intern revision og ledelsens gennemgang | ISMS-omfang, register over interessenter, risikometodik, risikoregister, SoA, behandlingsplan, politikker, intern revisionsrapport, ledelsens gennemgang |
| NIS2-kompetent myndighed eller delegeret vurderingspart | Om foranstaltninger til cybersikkerhedsrisikostyring er passende og proportionale, og om rapportering af væsentlige hændelser fungerer operationelt | NIS2-kortlægning, procedure for hændelsesklassificering, 24- og 72-timers arbejdsgang, bestyrelsestilsyn, teknisk kontrolbevismateriale, leverandørsikkerhedsbevismateriale |
| DORA-kundevurderingspart | Om IKT-tredjepartsrisiko, robusthedstest, hændelsesrapportering, revisionsrettigheder og exit-planlægning opfylder forventningerne i den finansielle sektor | Kontraktklausuler, underleverandørregister, robusthedstest, hændelses-SLA’er, exit-plan, revisionsrapporter, understøttelse af koncentrationsrisiko |
| GDPR-auditor eller DPO-gennemgang | Om risiko for brud på persondatasikkerheden, databehandlerforpligtelser, fortrolighed, integritet og ansvarlighed er adresseret | Fortegnelser over behandlingsaktiviteter, DPA-vilkår, arbejdsgang for vurdering af brud, adgangslogfiler, krypteringsbevismateriale, kontroller for opbevaring og sletning |
| NIST-orienteret vurderingspart | Om identify-, protect-, detect-, respond- og recover-kapaciteter er implementeret og målt | Aktivfortegnelse, adgangskontroller, sårbarhedsdata, SIEM-dækning, response playbooks, genopretningstest, metrikker |
| COBIT 2019- eller ISACA-auditor | Om styringsmål, ansvarsområder, risikoejerskab, kontrolovervågning og assurance-processer er etableret | Styringschartere, RACI, risikovillighed, kontrolejerskab, KPI/KRI-rapportering, assurance-plan, sporing af korrigerende handlinger |
Det er her, Zenith Controls hjælper som en cross-compliance-guide. For kontroller som 5.23, 5.24 og 8.8 forbinder den ISO/IEC 27001:2022-kontrolforventninger med NIS2-, GDPR-, DORA-, NIST SP 800-53-, COBIT 2019-, NIST CSF- og ISO 22301-temaer. Målet er ikke at oprette separate complianceprogrammer. Målet er én evidensarkitektur tagget efter kontrol, risiko, regulatorisk driver og ejer.
Clarysecs implementeringsmønster
For cloud-, MSP-, MSSP- og datacenterudbydere bør arbejdet bevæge sig gennem fem lag.
Først skal omfanget bekræftes. Fastlæg, om organisationen og tjenesterne er omfattet af NIS2, hvilke medlemsstatsregler der gælder, om gennemførelsesforordning 2024/2690 gælder for udbyderkategorien, og om kunder stiller DORA-, GDPR-, NIST- eller sektorspecifikke forpligtelser.
Dernæst skal ISMS-konteksten opbygges. Efter ISO/IEC 27001:2022 klausul 4 og 5 identificeres interessenter, retlige forpligtelser, kundetilsagn, leverandørafhængigheder, servicegrænser og ledelsesmæssige ansvarsområder.
For det tredje udføres risikovurdering og risikobehandling efter ISO/IEC 27005:2022-principper. Saml NIS2, DORA, GDPR, kontrakter, interne politikker og servicerisici i ét register over baselinekrav. Definér risikokriterier, ejere, sandsynlighed, konsekvens, behandlingsmuligheder, kontrolvalg og godkendelser af restrisiko.
For det fjerde kortlægges kontroller ind i Statement of Applicability. Brug Zenith Blueprint trin 13 og 14 til at spore risici til Annex A-kontroller og regulatoriske forventninger. Brug Zenith Controls til at forstå, hvordan kontroller som 5.23, 5.24, 8.8, 5.20 og 5.30 kortlægges på tværs af frameworks og revisionsperspektiver.
For det femte operationaliseres bevismaterialet. Politikker er ikke nok. Clarysecs politikbibliotek giver bindende krav til cloudgodkendelse, leverandøradgang, logning, sårbarhedsafhjælpning, netværkssegmentering, hændelsesklassificering og kontinuitetsplanlægning. Evidenspakken dokumenterer, at kravene fungerer.
Næste skridt: omsæt NIS2-pres til revisionsklar robusthed
NIS2-gennemførelsesforordning 2024/2690 kræver ikke kaos. Den kræver sporbarhed, ejerskab og dokumentation.
Hvis du er cloudtjenesteudbyder, MSP, MSSP eller datacenteroperatør, skal du begynde med dine tjenester, kunder, afhængigheder, hændelsesscenarier og evidensforpligtelser. Gennemfør derefter en struktureret kortlægningsøvelse fra NIS2 til ISO/IEC 27001:2022:
- Bekræft, om din enhed og dine tjenester er omfattet.
- Kortlæg NIS2- og gennemførelsesforordningstemaer ind i dit ISMS-omfang.
- Opdater risikoregisteret og Statement of Applicability.
- Anvend Clarysec-politikker for brug af cloud, leverandørsikkerhed, logning, sårbarhedsstyring, hændelseshåndtering, netværkssikkerhed og kontinuitet.
- Brug Zenith Blueprint Zenith Blueprint trin 13, 14, 20 og 23 til at skabe sporbarhed og driftsbevismateriale.
- Brug Zenith Controls Zenith Controls til at krydskortlægge ISO/IEC 27001:2022-kontroller mod forventninger fra NIS2, DORA, GDPR, NIST og COBIT 2019.
- Test bevismaterialet gennem en revisionssimulation, før en kunde, regulator eller certificeringsauditor beder om det.
Clarysec kan hjælpe dig med at komme videre end tjeklistebaseret compliance og opbygge et integreret ISMS, der kan modstå pres fra NIS2, DORA, GDPR og kunderevisioner. Download de relevante Clarysec-toolkits, book en kortlægningsworkshop eller anmod om en vurdering af revisionsberedskab for at omsætte regulatorisk kompleksitet til juridisk forsvarlig sikkerhedsstyring og operationel robusthed.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
