ISO 27001: ISMS-omfang for NIS2, DORA og GDPR

Maria, CISO i en hurtigt voksende europæisk fintechvirksomhed, mente, at ISO 27001-overvågningsrevisionen var under kontrol.

Certifikatet var nyt. Erklæringen om anvendelighed fremstod moden. Omfangserklæringen dækkede “virksomhedens ledelsessystem for informationssikkerhed, der understøtter drift af SaaS-platformen.” Produktionsmiljøet i cloud var dokumenteret. Proceduren for hændelseshåndtering fandtes. Risikoregisteret havde ejere, datoer og vurderinger af restrisiko.

Så stillede revisoren ét enkelt spørgsmål:

“Hvilke dele af denne SaaS-platform er også omfattet af NIS2-registreringen, hvilke outsourcede tjenester understøtter DORA-kritiske eller vigtige funktioner for jeres finansielle kunder, og hvor behandles GDPR-personoplysninger helt præcist?”

Der blev stille i lokalet.

Juridisk afdeling åbnede et regneark med regulatoriske forpligtelser. Produktteamet åbnede et arkitekturdiagram. DPO’en åbnede fortegnelserne over behandlingsaktiviteter. Indkøb åbnede leverandørlisten. Drift åbnede planen for katastrofeberedskab. Ingen af dem stemte overens.

ISMS-omfanget sagde “SaaS-platform.” NIS2-vurderingen identificerede digitale infrastrukturtjenester i flere medlemsstater. Kundekontrakter beskrev platformen som understøttende for regulerede finansielle driftsaktiviteter. GDPR-fortegnelserne omfattede identitetsdata, telemetri, IP-adresser, betalingsmetadata, supporttickets og underleverandørbaseret analyse. Katastrofeberedskabsplanen dækkede produktion, men ikke kundesupportplatformen, der blev brugt til kommunikation om brud. Leverandør-due diligence dækkede hostingudbyderen, men ikke Managed Detection and Response-tjenesten, der var forbundet til produktionslogfiler.

Dette er ISMS-afgrænsningsproblemet i 2026. ISO 27001-certificering er stadig værdifuld, men et snævert “minimalt levedygtigt omfang” kan blive en risiko, når tilsynsmyndigheder, kunder og revisorer forventer, at det samme ledelsessystem kan redegøre for NIS2-væsentlige tjenester, DORA-kritiske eller vigtige funktioner og GDPR-behandlingsgrænser.

For ISO/IEC 27001:2022, NIS2, DORA og GDPR er et svagt omfang ikke en administrativ fejl. Det er den første dominobrik. Hvis omfanget er forkert, er risikovurderingen ufuldstændig, SoA’en vildledende, leverandørkontroller overser kritiske udbydere, frister for hændelsesrapportering bliver usikre, og ansvarlighed for databeskyttelse fragmenteres på tværs af teams.

Hvorfor ISO 27001-ISMS’ets omfang nu er en regulatorisk afgrænsning

ISO/IEC 27001:2022, klausul 4.3, kræver, at en organisation fastlægger ISMS’ets grænser og anvendelighed under hensyntagen til interne og eksterne forhold, krav fra interessenter samt grænseflader og afhængigheder til andre organisationer ISO/IEC 27001:2022.

Den formulering har større betydning i 2026 end i tidligere certificeringscyklusser. NIS2, DORA, GDPR, outsourcing til cloud, kundekontrakter, koncernfælles teknologitjenester og Managed Service Providers er ikke sidebemærkninger. De er input til ISMS-afgrænsningen.

NIS2 skærper ledelseskravene for væsentlige og vigtige enheder. Direktivet kræver, at ledelsesorganer godkender foranstaltninger til cybersikkerhedsrisikostyring, fører tilsyn med implementeringen og modtager uddannelse. NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse og udvikling, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring og multifaktorgodkendelse, hvor det er relevant.

DORA ændrer omfangsdiskussionen for finansielle enheder. Forordningen finder anvendelse fra 17. januar 2025 og fastsætter ensartede krav til styring af IKT-risiko, rapportering af IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling og styring af IKT-tredjepartsrisiko. DORA Article 6 kræver en dokumenteret ramme for styring af IKT-risiko. DORA Article 8 kræver identifikation, klassificering og dokumentation af IKT-understøttede forretningsfunktioner, informationsaktiver og IKT-aktiver, herunder afhængigheder. DORA Article 28 kræver styring af IKT-tredjepartsrisiko.

GDPR tilføjer personoplysningsaksen. Forordningen gælder for automatiseret eller struktureret behandling af personoplysninger, herunder behandling hos EU-etablerede organisationer og visse dataansvarlige eller databehandlere uden for EU, der tilbyder varer eller tjenester til personer i Unionen eller overvåger deres adfærd. GDPR Article 30 kræver fortegnelser over behandlingsaktiviteter, Article 32 kræver behandlingssikkerhed, og Article 33 fastsætter krav til underretning om brud.

Et juridisk forsvarligt ISMS-omfang skrives derfor ikke omkring afdelinger. Det skrives omkring regulerede tjenester, kritiske eller vigtige funktioner, behandling af personoplysninger, understøttende aktiver og tredjepartsafhængigheder.

Fejlen: at behandle ISO 27001, NIS2, DORA og GDPR som separate programmer

Et almindeligt mønster ses i mange organisationer:

• Sikkerhedsteamet udarbejder ISO 27001-omfanget.
• Juridisk afdeling vurderer NIS2-anvendelighed.
• Risiko- eller compliancefunktionen styrer DORA-forpligtelser.
• Databeskyttelsesfunktionen vedligeholder GDPR-fortegnelserne over behandlingsaktiviteter.
• Indkøb ejer leverandørlisten.
• Drift ejer forretningskontinuitet og katastrofeberedskab.

Hvert team kan udføre fornuftigt arbejde. Problemet er, at den regulerede virkelighed går på tværs af dem alle.

En cloudbaseret kundeidentitetstjeneste kan samtidig understøtte NIS2-tjenestelevering, DORA-regulerede kundedriftsaktiviteter og GDPR-behandling af personoplysninger. En managed detection-udbyder kan være en sikkerhedsleverandør, en afhængighed i hændelseshåndtering, en databehandler eller underdatabehandler af logdata og et centralt input til beslutninger om regulatorisk underretning. En supportplatform kan blive betragtet som “ikke-produktionsmiljø”, mens den stadig håndterer kommunikation om brud på persondatasikkerheden og kunders anmodninger om bevismateriale.

ISMS’et er det bedste sted at integrere disse forpligtelser, fordi ISO 27001 tvinger ét disciplineret spørgsmål frem: Hvad er inden for grænsen, hvad er udenfor, og hvorfor?

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandler dette i fasen ISMS Foundation & Leadership, trin 2: interessentbehov og ISMS-omfang:

“Når konteksten er forstået, og interessentkravene er identificeret, kræver klausul 4.3, at I fastlægger ISMS’ets grænser og anvendelighed for at etablere dets omfang. ISMS-omfanget er en afgørende definition, der fastlægger, hvad der er omfattet af jeres program for sikkerhedsstyring, og hvad der ikke er.”

Zenith Blueprint fremhæver også et punkt, som mange omfangserklæringer stadig overser:

“Hvis I outsourcer jeres IT-infrastruktur til en cloududbyder, udelukker det den ikke fra omfanget; i stedet medtager I styringen af denne relation og cloudaktiverne som en del af omfanget.”

Outsourcing flytter udførelsen. Det fjerner ikke ansvarligheden.

Firegrænsemodellen for ISO 27001-omfang i 2026

For organisationer, der er berørt af NIS2, DORA og GDPR, anbefaler Clarysec at definere ISO 27001-ISMS’ets omfang gennem fire forbundne grænser.

En svag omfangserklæring siger kun “SaaS-platformen.” En stærkere erklæring angiver, hvilke forretningstjenester, systemer, miljøer, lokationer, databehandlingsaktiviteter, personalegrupper, leverandørrelationer og styringsprocesser der er omfattet.

En mere forsvarlig version kan lyde:

“ISMS’et omfatter governance, risikostyring, drift og løbende forbedring af informationssikkerhed for virksomhedens EU-baserede SaaS-platform til betalingsanalyse, herunder produktions- og ikke-produktionsmiljøer i cloud, kundeidentitetstjenester, administrative grænseflader, supportdrift, lognings- og overvågningsplatforme, hændelseshåndtering, forretningskontinuitet, leverandørstyring og alle behandlingsaktiviteter med personoplysninger, der understøtter tjenesten. ISMS’et omfatter styringen af outsourcet cloudhosting, managed detection og kundesupportværktøjer, der anvendes til levering af tjenesten, robusthed, sikkerhedsovervågning eller GDPR-relateret kommunikation.”

Dette omfang er ikke blot længere. Det er mere egnet til revision, fordi det forbinder tjenester, aktiver, behandling og afhængigheder.

Hvordan Clarysec-politikker omsætter omfang til styringssprog

Omfang bør ikke leve i et selvstændigt dokument. Det skal være afstemt med informationssikkerhedspolitikken, juridisk og regulatorisk efterlevelse, risikostyring, databeskyttelse, leverandørstyring, revisionskriterier og kontinuitetsplanlægning.

Enterprise Informationssikkerhedspolitik Informationssikkerhedspolitik forebygger uklarhed om undtagelser:

“Eventuelle undtagelser eller begrænsninger i dette omfang skal dokumenteres i ISMS-omfangserklæringen og begrundes med formel godkendelse fra øverste ledelse.”

Denne klausul er vigtig, når en forretningsenhed hævder, at kundesupport ligger uden for platformen, selv om supportmedarbejdere har adgang til kundeidentifikatorer og håndterer kommunikation om brud. Undtagelse er kun mulig, hvis den er dokumenteret, begrundet og godkendt.

Enterprise Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse gør juridisk kortlægning operationel:

“Alle juridiske og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).”

Dette er broen mellem juridisk anvendelighed og erklæringen om anvendelighed. NIS2 Article 21 må ikke forblive i et juridisk notat. DORA-forpligtelser vedrørende IKT-tredjeparter må ikke kun ligge i indkøbsvejledning. GDPR Article 30- og Article 32-forpligtelser må ikke kun ligge i privatlivsregisteret. De kræver kortlagte ejere, kontroller og bevismateriale.

Enterprise Politik for risikostyring Politik for risikostyring udvider omfanget til tredjeparter:

“Denne politik gælder for alle organisatoriske enheder, forretningsprocesser, systemer, personale og tredjepartsengagementer, der er involveret i håndtering, udvikling, opbevaring eller styring af informationsaktiver.”

Den formulering er i overensstemmelse med NIS2-forsyningskædesikkerhed, DORA IKT-tredjepartsrisiko og GDPR-ansvarlighed for dataansvarlige eller databehandlere.

Enterprise Databeskyttelses- og privatlivspolitik Databeskyttelses- og privatlivspolitik forankrer privatlivsomfanget i behandling:

“Denne politik gælder for alle organisatoriske enheder, alt personale og alle systemer, der er involveret i behandling af personhenførbare oplysninger (PII), herunder:”

Princippet er afgørende. Hvis et system behandler personhenførbare oplysninger (PII), kan det ikke være usynligt for ISMS’et, fordi det “kun er support,” “ikke-produktionsmiljø” eller “ejes af marketing.”

Enterprise Politik for forretningskontinuitet og katastrofeberedskab Politik for forretningskontinuitet og katastrofeberedskab knytter omfanget til BIA-resultater:

“Denne politik gælder for alle organisatoriske enheder, informationssystemer, forretningsprocesser, personale og tredjepartsydelser, der er klassificeret som kritiske eller væsentlige på baggrund af resultater fra forretningskonsekvensanalyse (BIA).”

Denne klausul flugter naturligt med DORA-kritiske eller vigtige funktioner og NIS2-tjenestekontinuitet.

For mindre organisationer holder Clarysecs SMV-politikker formuleringen kort, samtidig med at den samme logik bevares. SMV Politik for revision og efterlevelsesovervågning Politik for revision og efterlevelsesovervågning - SME definerer revisionsdækning som:

“Alle kontroller og systemer inden for omfanget af ledelsessystemet for informationssikkerhed (ISMS)”

SMV Databeskyttelses- og privatlivspolitik Databeskyttelses- og privatlivspolitik - SME definerer privatlivsomfanget som:

“Ethvert system, enhver applikation eller enhver lokation, hvor personoplysninger opbevares eller transmitteres”

SMV Politik for risikostyring Politik for risikostyring - SME holder outsourcede tjenester synlige:

“Alle oplysninger, tjenester og aktiver, der administreres internt eller gennem tredjeparter”

Korte klausuler som disse er stærke, fordi de forhindrer en certificeringsgrænse i at udelukke regulerede data, cloudtjenester eller leverandørstyrede aktiver.

Aktivfortegnelsen er dér, omfanget bliver reelt

En omfangserklæring er kun troværdig, hvis den kan spores til aktiver, ejere, leverandører, dataflows og bevismateriale.

Zenith Blueprint instruerer i risikostyringsfasen, trin 9: identifikation af aktiver, trusler og sårbarheder, organisationer i at registrere aktiver i ISMS-omfanget og angive ejer, lokation og klassificering. Den giver et praktisk eksempel:

“Kundedatabase – ejet af IT-afdelingen – hostet på AWS – indeholder personlige og finansielle data (høj følsomhed).”

Samme trin tilføjer en afgrænsningspåmindelse, der er direkte relevant for NIS2 og GDPR:

“Sørg for, at aktiver med personoplysninger markeres (af hensyn til GDPR-relevans), og at kritiske tjenesteaktiver noteres (af hensyn til potentiel NIS2-anvendelighed, hvis I er i en reguleret sektor).”

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandler ISO/IEC 27002:2022 kontrol 5.9, fortegnelse over information og andre tilknyttede aktiver, som en grundlæggende tværgående efterlevelseskontrol. Dens attributter klassificerer kontrollen som forebyggende, understøttende for fortrolighed, integritet og tilgængelighed, tilpasset Identify-cybersikkerhedskonceptet, den operationelle kapacitet for aktivstyring samt domænerne governance, økosystem og beskyttelse.

Zenith Controls forklarer GDPR- og NIS2-relevansen klart:

“Uden en nøjagtig og ajourført aktivfortegnelse kan organisationer ikke vurdere eller implementere passende beskyttelsesforanstaltninger.”

For NIS2 understøtter aktivfortegnelsen identifikation af kritiske systemer og komponenter, der ligger til grund for væsentlige eller vigtige tjenester. For DORA gør DORA Article 8 identifikation af IKT-aktiver og informationsaktiver central for operationel robusthed. For GDPR understøtter aktivfortegnelsen kortlægning af dataflows, kvalitet i RoPA og håndtering af brud.

Understøttende ISO-standarder styrker den samme logik. ISO/IEC 27005:2024 styrker identifikation af aktiver i informationssikkerhedsrisikovurdering. ISO 22301:2019 understøtter identifikation af ressourcer, der er nødvendige for forretningskontinuitet. ISO/IEC 19770-1:2017 understøtter modenhed i IT-aktivstyring. ISO/IEC 27017:2015 og ISO/IEC 27018:2019 understøtter cloudspecifikke kontroller og beskyttelse af PII i offentlige clouds. ISO/IEC 27701:2019 udvider styring af privatlivsinformation. ISO/IEC 29100:2011 bidrager med privatlivsprincipper såsom gennemsigtighed, dataminimering og sikkerhedsforanstaltninger.

En praktisk afgrænsningsøvelse for SaaS- og fintechteams

Start med én reguleret tjeneste, ikke hele virksomheden. For eksempel: “EU-baseret SaaS til betalingsanalyse for finansielle institutioner.”

Byg derefter et kort fra tjeneste til aktiv til behandling.

Et mere detaljeret eksempel på aktiver kan se sådan ud.

Brug derefter Zenith Blueprint trin 13: planlægning af risikobehandling og erklæring om anvendelighed. Vejledningen instruerer brugere i at opbygge SoA’en ved hjælp af skabelonen, der oplister alle Annex A-kontroller, og beslutte anvendelighed baseret på risikobehandling, juridiske eller kontraktlige krav, relevans for omfanget og organisatorisk kontekst. Den fastslår:

“For hver kontrol (række) i SoA-arket skal I beslutte, om den er anvendelig for jeres ISMS.”

For eksemplet ovenfor bør SoA’en tage højde for kontroller for leverandørsikkerhed, cloudtjenester, hændelsesstyring, kontinuitet, juridiske og regulatoriske krav, databeskyttelse, sårbarhedsstyring, backups, logning, overvågning, kryptografi, sikker udvikling, sikkerhedstestning og ændringsstyring.

En praktisk arbejdsgang er:

1. Opret en fane med navnet “ISMS Scope Mapping” i risikoregisteret og SoA Builder.
2. Tilføj én række pr. reguleret tjeneste eller produktlinje.
3. Knyt hver tjeneste til aktiver, datatyper, leverandører, lokationer og forretningsejere.
4. Markér NIS2-relevans, DORA-relevans og GDPR-behandlingsrelevans.
5. Tilføj risikoscenarier for utilgængelig tjeneste, brud på persondatasikkerheden, leverandørsvigt, fejlkonfiguration i cloud, kritisk sårbarhed og manglende hændelsesrapportering.
6. Vælg SoA-kontroller baseret på disse risici og forpligtelser.
7. Dokumentér undtagelser, kompenserende kontroller og risikoaccept.
8. Indhent øverste ledelses godkendelse af endelige grænser og undtagelser.
9. Overfør den endelige afgrænsning til intern revision, ledelsens gennemgang og leverandørovervågning.

Resultatet er ikke kun en bedre omfangserklæring. Det er en forsvarlig kæde fra reguleret tjeneste til aktiv, leverandør, data, kontrol, ejer og bevismateriale.

Tværgående efterlevelseskortlægning: ét omfang, mange forpligtelser

Et velafgrænset ISO 27001-ISMS bliver det operationelle lag, hvor forventninger fra NIS2, DORA, GDPR, NIST CSF og COBIT kan forenes.

For ISO/IEC 27002:2022 kontrol 5.31, juridiske, lovbestemte, regulatoriske og kontraktlige krav, knytter Zenith Controls efterlevelsesforpligtelser til databeskyttelse, PII-beskyttelse, opbevaring af registreringer, uafhængig gennemgang og intern overholdelse af politikker. Den kortlægges naturligt til GDPR-ansvarlighed, NIS2-efterlevelse i forsyningskæden, DORA IKT-risikostyring og efterlevelse, NIST CSF-governance og COBIT 2019-overvågning af ekstern efterlevelse.

For ISO/IEC 27002:2022 kontrol 5.34, privatliv og beskyttelse af PII, forbinder Zenith Controls databeskyttelse med aktivfortegnelse, cloudtjenester, klassificering, informationsoverførsel, adgangsstyring, identitetsstyring og projektændringsgennemgange. Dens GDPR-kortlægning dækker behandlingssikkerhed og databeskyttelse gennem design. Dens DORA-kortlægning understøtter dataintegritet, sikkerhed og fortrolighed, herunder personoplysninger, der håndteres i IKT-tjenester.

Princippet er enkelt: Opret ikke fire adskilte efterlevelsesprogrammer. Opret ét afgrænset ISMS, der kan forklare, hvordan forpligtelser opfyldes, dokumenteres og revideres.

Omfang for hændelsesrapportering: hvor grænser påvirker regulatoriske frister

Forkert omfang bliver smertefuldt synligt under hændelser.

NIS2 Article 23 kræver trinvis rapportering af væsentlige hændelser, herunder en tidlig advarsel inden for 24 timer, en hændelsesunderretning inden for 72 timer, mellemliggende rapporter efter anmodning og en slutrapport inden for én måned. Kommunikation til berørte modtagere kan også være påkrævet.

DORA kræver, at finansielle enheder opdager, håndterer, klassificerer og rapporterer større IKT-relaterede hændelser ved hjælp af kriterier som berørte kunder eller modparter, varighed, nedetid, geografisk udbredelse, datatab, kritikalitet af berørte tjenester og økonomisk påvirkning. Kunder skal informeres uden unødig forsinkelse, når en større IKT-hændelse påvirker deres finansielle interesser.

GDPR-underretning om brud på persondatasikkerheden afhænger af, om et brud fører til hændelig eller ulovlig destruktion, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger.

Hvis supportplatformen, logmiljøet, identitetstjenesten, kundeunderretningskanalen eller managed detection-udbyderen ligger uden for ISMS-omfanget, ved hændelsesteams muligvis ikke, om en hændelse udløser NIS2, DORA, GDPR, kundekontraktlig rapportering eller dem alle. Den usikkerhed bruger rapporteringsfristen.

Et modent omfang omfatter hændelsesrelevante afhængigheder: detektionsværktøjer, loglagre, efterforskningsrepositories, kundekommunikationskanaler, supportværktøjer, backupmiljøer, incident bridges og leverandører, der deltager i triage eller genopretning.

Hvordan revisorer og tilsynsmyndigheder vil teste jeres ISMS-omfang

Et stærkt omfang tåler stikprøver. Et svagt omfang kollapser, når revisorer sammenholder dokumenter med virkeligheden.

Zenith Controls giver nyttige revisionsforventninger for ISO/IEC 27002:2022 kontrol 5.9. Revisorer efter ISO/IEC 19011-stil anmoder tidligt om fortegnelsen for at afgrænse andre evalueringer og stikprøvekontrollere fysiske aktiver, softwareaktiver og cloudaktiver. Revisorer efter ISO/IEC 27007-stil spørger, hvordan og hvornår fortegnelsen opdateres, og leder efter sammenhænge til indkøb, ændringsstyring og udfasning. Revisorer efter NIST SP 800-53A-stil verificerer, at fortegnelsesdetaljer omfatter aktivtype, ejer, lokation, netværksadresse hvor relevant og status, samt at cloudaktiver, virtuelle aktiver og mobile aktiver er medtaget.

For kontrol 5.31 bemærker Zenith Controls, at certificeringsrevisorer forventer et efterlevelsesregister eller en liste over love og kontrakter, der er refereret i SoA’en og risikobehandlingsplaner. COBIT-revisorer ser efter efterlevelsesejere, vurderinger og rapportering til øverste ledelse. ISACA ITAF-revisorer udtager stikprøver af bevismateriale for at bekræfte, at organisationen ikke blot kender sine forpligtelser, men aktivt sikrer, at de opfyldes.

For kontrol 5.34 gennemgår revisorer privatlivspolitikker, datafortegnelser, DPIA’er, træningslogfiler, bevismateriale for kryptering, adgangsstyring, DSAR-stikprøver, bevismateriale for databeskyttelse gennem design og hændelsesregistreringer, der involverer PII. En omfangserklæring, der udelukker et system, som behandler personoplysninger, vil hurtigt blive udfordret.

Bestyrelsesspørgsmålet: Hvad kan ikke udelukkes?

Øverste ledelse spørger ofte, om en forretningsenhed, lokation, leverandør eller et system kan forblive uden for ISMS-omfanget. Nogle gange er svaret ja. Men ikke hvis undtagelsen forhindrer organisationen i at opfylde juridiske, regulatoriske, kontraktlige eller tjenestesikkerhedsmæssige forpligtelser.

Brug denne undtagelsestest, før en afgrænsningsbegrænsning godkendes:

• Understøtter enheden, systemet eller leverandøren en NIS2-reguleret tjeneste?
• Understøtter den en DORA-kritisk eller vigtig funktion for organisationen eller dens regulerede kunder?
• Indsamler, opbevarer, transmitterer, logger, understøtter eller sletter den personoplysninger?
• Leverer den sikkerhedsovervågning, identitet, backup, hændelseshåndtering eller genopretning for en tjeneste inden for omfanget?
• Leverer den bevismateriale, der er nødvendigt for hændelsesklassificering eller regulatorisk underretning?
• Kræver en kundekontrakt, at den er dækket af ISMS’et?
• Vil kompromittering af den påvirke fortrolighed, integritet, tilgængelighed, juridisk efterlevelse eller tjenestekontinuitet inden for det angivne omfang?

Hvis svaret er ja, kræver undtagelsen stærkt bevismateriale, kompenserende styring, risikoaccept og formel godkendelse fra øverste ledelse. I mange tilfælde bør den ikke udelukkes.

Et moderne ISO 27001-ISMS-omfang bør omfatte:

1. Dækkede forretningstjenester og produktlinjer.
2. Dækkede juridiske enheder, organisatoriske enheder og lokationer.
3. Kundesegmenter og jurisdiktioner, der udløser forpligtelser.
4. Kritiske eller vigtige funktioner og BIA-baserede væsentlige tjenester.
5. Informationsaktiver, IKT-aktiver og cloudmiljøer.
6. Behandlingsaktiviteter med personoplysninger og PII-repositories.
7. Udviklings-, test-, support-, overvågnings- og hændelsesprocesser.
8. Leverandører og outsourcede tjenester, der understøtter tjenester inden for omfanget.
9. Grænseflader og afhængigheder til koncernselskaber eller eksterne udbydere.
10. Eksplicitte undtagelser med begrundelse, risikoaccept og godkendelse fra øverste ledelse.

Sådan bliver ISO 27001-omfanget en governanceposition på bestyrelsesniveau, ikke en genvej til certificering.

Gør jeres ISMS-omfang klar til revision, før revisoren definerer det for jer

Det værste tidspunkt at opdage et omfangsproblem er under certificering, tilsynsgennemgang, kunders due diligence eller en aktiv hændelse.

Et snævert certifikat kan opfylde et indkøbsafkrydsningsfelt, men det vil ikke modstå seriøs gennemgang, hvis det udelukker de tjenester, IKT-funktioner, leverandører og behandlingsaktiviteter med personoplysninger, der skaber regulatorisk eksponering. I 2026 vil de organisationer, der består revisioner med sikkerhed, være dem, der kan vise ét sammenhængende kort fra reguleret tjeneste til aktiv, leverandør, personoplysninger, kontrol, ejer og bevismateriale.

Start med tre konkrete handlinger:

1. Brug Zenith Blueprint Zenith Blueprint fase: ISMS Foundation & Leadership, trin 2, til at omskrive jeres ISMS-omfang omkring tjenester, funktioner, behandling og afhængigheder.
2. Brug Zenith Controls Zenith Controls til at kortlægge aktivfortegnelse, juridiske forpligtelser og PII-beskyttelse på tværs af revisionsforventninger efter ISO 27001, NIS2, DORA, GDPR, NIST og COBIT 2019.
3. Afstem politikomfanget ved hjælp af Clarysecs Informationssikkerhedspolitik Informationssikkerhedspolitik, Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse, Politik for risikostyring Politik for risikostyring, Databeskyttelses- og privatlivspolitik Databeskyttelses- og privatlivspolitik og Politik for forretningskontinuitet og katastrofeberedskab Politik for forretningskontinuitet og katastrofeberedskab.

Hvis jeres nuværende ISMS-omfang stadig lyder som en afdelingsbetegnelse, skal det genopbygges som en efterlevelsesgrænse. Download Clarysec-værktøjspakkerne, kortlæg én reguleret tjeneste fra ende til ende, og omsæt jeres ISO 27001-omfang til revisionsklart bevismateriale for NIS2, DORA og GDPR.