ISO 27001 ISMS-omfattning för NIS2, DORA och GDPR

Maria, informationssäkerhetschef på ett snabbväxande europeiskt fintechbolag, trodde att den uppföljande ISO 27001-revisionen var under kontroll.

Certifikatet var nytt. Tillämplighetsförklaringen (SoA) såg mogen ut. Omfattningsbeskrivningen täckte ”organisationens ledningssystem för informationssäkerhet som stödjer drift av SaaS-plattformen”. Produktionsmiljön i molnet var dokumenterad. Rutinen för incidentrespons fanns på plats. Riskregistret hade ägare, datum och bedömningar av kvarstående risk.

Sedan ställde revisorn en enkel fråga:

”Vilka delar av den här SaaS-plattformen omfattas också av NIS2-registreringen, vilka outsourcade tjänster stödjer DORA-kritiska eller viktiga funktioner för era finansiella kunder, och exakt var behandlas personuppgifter enligt GDPR?”

Det blev tyst i rummet.

Juridik öppnade ett kalkylblad med regulatoriska skyldigheter. Produkt öppnade ett arkitekturdiagram. Dataskyddsombudet (DPO) öppnade registret över behandlingsaktiviteter. Inköp öppnade leverantörslistan. Drift öppnade planen för katastrofåterställning. Inget av detta stämde överens.

ISMS-omfattningen sade ”SaaS-plattform”. NIS2-bedömningen identifierade digitala infrastrukturtjänster i flera medlemsstater. Kundavtalen beskrev plattformen som stöd för reglerad finansiell verksamhet. GDPR-posterna omfattade identitetsdata, telemetri, IP-adresser, betalningsmetadata, supportärenden och analys som tillhandahölls av underleverantör. Planen för katastrofåterställning täckte produktion, men inte kundsupportplattformen som användes för kommunikation vid incidentanmälningar. Leverantörsgranskningen täckte driftleverantören, men inte den hanterade detekteringstjänst som var ansluten till produktionsloggarna.

Detta är ISMS-omfattningsproblemet 2026. ISO 27001-certifiering är fortfarande värdefull, men en snäv ”minsta möjliga omfattning” kan bli en ansvarsrisk när tillsynsmyndigheter, kunder och revisorer förväntar sig att samma ledningssystem ska kunna förklara NIS2-reglerade väsentliga tjänster, DORA-kritiska eller viktiga funktioner och GDPR-gränser för behandling.

För ISO/IEC 27001:2022, NIS2, DORA och GDPR är en svag omfattning inte en administrativ brist. Den är den första dominobrickan. Om omfattningen är fel blir riskbedömningen ofullständig, SoA missvisande, leverantörskontrollerna missar kritiska leverantörer, tidsfristerna för incidentrapportering blir osäkra och ansvarsskyldigheten för dataskydd fragmenteras mellan team.

Varför ISO 27001 ISMS-omfattning nu är en regulatorisk gräns

ISO/IEC 27001:2022 klausul 4.3 kräver att en organisation fastställer ISMS:ets gränser och tillämplighet, med beaktande av interna och externa frågor, krav från intressenter samt gränssnitt och beroenden till andra organisationer ISO/IEC 27001:2022.

Den formuleringen är viktigare 2026 än den var i tidigare certifieringscykler. NIS2, DORA, GDPR, outsourcing till moln, kundavtal, koncerngemensamma tekniktjänster och hanterade tjänsteleverantörer är inte sidonoter. De är indata till ISMS-gränsen.

NIS2 skärper styrningskraven för väsentliga och viktiga entiteter. Direktivet kräver att ledningsorgan godkänner riskhanteringsåtgärder för cybersäkerhet, utövar tillsyn över genomförandet och får utbildning. NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och flerfaktorsautentisering där det är lämpligt.

DORA förändrar omfattningsdiskussionen för finansiella entiteter. Förordningen gäller från den 17 januari 2025 och fastställer enhetliga krav på IKT-riskhantering, rapportering av IKT-relaterade incidenter, testning av digital operativ resiliens, informationsdelning och hantering av IKT-tredjepartsrisk. DORA Article 6 kräver ett dokumenterat ramverk för IKT-riskhantering. DORA Article 8 kräver identifiering, klassificering och dokumentation av IKT-stödda verksamhetsfunktioner, informationstillgångar och IKT-tillgångar, inklusive beroenden. DORA Article 28 kräver hantering av IKT-tredjepartsrisk.

GDPR tillför personuppgiftsdimensionen. Förordningen gäller automatiserad eller strukturerad behandling av personuppgifter, inklusive behandling vid etableringar inom EU och viss behandling hos personuppgiftsansvariga eller personuppgiftsbiträden utanför EU som erbjuder varor eller tjänster till personer i unionen eller övervakar deras beteende. GDPR Article 30 kräver register över behandlingsaktiviteter, Article 32 kräver säkerhet i behandlingen och Article 33 anger förväntningar på anmälan av personuppgiftsincidenter.

En försvarbar ISMS-omfattning skrivs därför inte runt avdelningar. Den skrivs runt reglerade tjänster, kritiska eller viktiga funktioner, behandling av personuppgifter, stödjande tillgångar och tredjepartsberoenden.

Misstaget: att behandla ISO 27001, NIS2, DORA och GDPR som separata program

Ett vanligt mönster syns i många organisationer:

• Säkerhetsfunktionen tar fram ISO 27001-omfattningen.
• Juridik bedömer NIS2-tillämplighet.
• Risk- eller regelefterlevnadsfunktionen hanterar DORA-skyldigheter.
• Dataskyddsfunktionen underhåller GDPR-registret över behandlingsaktiviteter.
• Inköp äger leverantörslistan.
• Drift äger verksamhetskontinuitet och katastrofåterställning.

Varje team kan göra ett rimligt arbete. Problemet är att den reglerade verkligheten skär genom dem alla.

En molnbaserad kundidentitetstjänst kan samtidigt stödja tjänsteleverans enligt NIS2, DORA-reglerad kundverksamhet och behandling av personuppgifter enligt GDPR. En leverantör av hanterad detektering kan vara en säkerhetsleverantör, ett beroende för incidentrespons, ett personuppgiftsbiträde eller underbiträde för loggdata och en central indata till beslut om regulatorisk rapportering. En supportplattform kan betraktas som ”icke-produktion”, men ändå hantera kommunikation vid personuppgiftsincidenter och kunders begäranden om bevismaterial.

ISMS är den bästa platsen för att integrera dessa skyldigheter eftersom ISO 27001 tvingar fram en disciplinerad fråga: vad finns innanför gränsen, vad finns utanför, och varför?

Clarysecs Zenith Blueprint: en revisors 30-stegs färdplan Zenith Blueprint behandlar detta i fasen ISMS Foundation & Leadership, Step 2: Stakeholder Needs and ISMS Scope:

”När sammanhanget är förstått och intressenternas krav är identifierade kräver klausul 4.3 att ni fastställer ISMS:ets gränser och tillämplighet för att fastställa dess omfattning. ISMS-omfattningen är en avgörande definition som anger vad som ingår i ert ledningssystem för informationssäkerhet (och vad som inte gör det).”

Zenith Blueprint lyfter också fram en punkt som många omfattningsbeskrivningar fortfarande missar:

”Om ni outsourcar er IT-infrastruktur till en molnleverantör innebär det inte att den undantas från omfattningen; ni inkluderar i stället hanteringen av den relationen och molntillgångarna som en del av omfattningen.”

Outsourcing flyttar utförandet. Den tar inte bort ansvarsskyldigheten.

Fyrgränsmodellen för ISO 27001-omfattning 2026

För organisationer som påverkas av NIS2, DORA och GDPR rekommenderar Clarysec att ISO 27001 ISMS-omfattning definieras genom fyra sammankopplade gränser.

En svag omfattningsbeskrivning säger bara ”SaaS-plattformen”. En starkare beskrivning anger vilka verksamhetstjänster, system, miljöer, platser, behandlingsaktiviteter, personalgrupper, leverantörsrelationer och ledningsprocesser som ingår.

En mer försvarbar version kan lyda:

”ISMS omfattar styrning, riskhantering, drift och ständig förbättring av informationssäkerheten för företagets SaaS-plattform för betalningsanalys inom EU, inklusive produktions- och icke-produktionsmiljöer i molnet, kundidentitetstjänster, administrativa gränssnitt, supportverksamhet, plattformar för loggning och övervakning, incidentrespons, verksamhetskontinuitet, leverantörshantering och all behandling av personuppgifter som stödjer tjänsten. ISMS omfattar hanteringen av outsourcad molndrift, hanterad detektering och kundsupportverktyg som används för tjänsteleverans, resiliens, säkerhetsövervakning eller GDPR-relaterad kommunikation.”

Den omfattningen är inte bara längre. Den går att granska eftersom den kopplar samman tjänster, tillgångar, behandling och beroenden.

Hur Clarysec-policyer gör omfattning till styrningsspråk

Omfattningen ska inte leva i ett fristående dokument. Den ska vara anpassad till informationssäkerhetspolicy, efterlevnad av rättsliga och regulatoriska krav, riskhantering, dataskydd, leverantörsstyrning, revisionskriterier och kontinuitetsplanering.

Enterprise Informationssäkerhetspolicy Informationssäkerhetspolicy motverkar otydlighet kring undantag:

”Alla undantag från eller begränsningar av denna omfattning ska dokumenteras i ISMS-omfattningsbeskrivningen och motiveras med formellt godkännande från högsta ledningen.”

Denna klausul är viktig när en affärsenhet hävdar att kundsupport ligger utanför plattformen, trots att supportmedarbetare har åtkomst till kundidentifierare och hanterar kommunikation vid incidentanmälningar. Undantag är endast möjliga om de dokumenteras, motiveras och godkänns.

Enterprise Policy för rättslig och regulatorisk efterlevnad Policy för rättslig och regulatorisk efterlevnad gör rättslig kartläggning operativ:

”Alla rättsliga och regulatoriska skyldigheter ska kopplas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.”

Detta är bryggan mellan rättslig tillämplighet och tillämplighetsförklaringen. NIS2 Article 21 ska inte stanna i ett juridiskt PM. DORA-skyldigheter för IKT-tredjepart ska inte bara finnas i inköpsvägledning. Skyldigheter enligt GDPR Article 30 och Article 32 ska inte enbart ligga i integritetsregistret. De behöver utsedda ägare, kontroller och underlag.

Enterprise Riskhanteringspolicy Riskhanteringspolicy breddar omfattningen till tredje parter:

”Denna policy gäller alla organisationsenheter, verksamhetsprocesser, system, personal och tredjepartsengagemang som är involverade i hantering, utveckling, lagring eller förvaltning av informationstillgångar.”

Den formuleringen ligger i linje med NIS2-säkerhet i leveranskedjan, DORA IKT-tredjepartsrisk och GDPR-ansvarsskyldighet för personuppgiftsansvariga eller personuppgiftsbiträden.

Enterprise Policy för dataskydd och integritet Policy för dataskydd och integritet förankrar integritetsomfattningen i behandling:

”Denna policy gäller alla organisationsenheter, all personal och alla system som är involverade i behandling av personligt identifierbar information (PII), inklusive:"

Principen är avgörande. Om ett system behandlar PII kan det inte vara osynligt för ISMS för att det ”bara är support”, ”icke-produktion” eller ”ägs av marknad”.

Enterprise Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning kopplar omfattningen till BIA-resultat:

”Denna policy gäller alla organisationsenheter, informationssystem, verksamhetsprocesser, personal och tredjepartstjänster som klassificeras som kritiska eller väsentliga baserat på resultat från konsekvensanalysen (BIA).”

Den klausulen ligger naturligt i linje med DORA-kritiska eller viktiga funktioner och NIS2-krav på tjänstekontinuitet.

För mindre organisationer håller Clarysecs SME-policyer språket kortfattat samtidigt som samma logik bevaras. SME Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning - SME definierar revisionstäckning som:

”Alla kontroller och system inom omfattningen för ledningssystemet för informationssäkerhet”

SME Policy för dataskydd och integritet Policy för dataskydd och integritet - SME definierar dataskyddsomfattning som:

”Alla system, applikationer eller platser där personuppgifter lagras eller överförs”

SME Riskhanteringspolicy Riskhanteringspolicy - SME håller outsourcade tjänster synliga:

”All information, alla tjänster och alla tillgångar som hanteras internt eller via tredje parter”

Korta klausuler som dessa är kraftfulla eftersom de hindrar en certifieringsgräns från att exkludera reglerade data, molntjänster eller leverantörshanterade tillgångar.

Tillgångsförteckningen är där omfattningen blir verklig

En omfattningsbeskrivning är bara trovärdig om den kan spåras till tillgångar, ägare, leverantörer, dataflöden och underlag.

Zenith Blueprint, i riskhanteringsfasen, Step 9: Identifying Assets, Threats, and Vulnerabilities, instruerar organisationer att lista tillgångar i ISMS-omfattningen och fånga ägare, plats och klassificering. Den ger ett praktiskt exempel:

”Kunddatabas – ägs av IT-avdelningen – driftas på AWS – innehåller personuppgifter och finansiella data (hög känslighet).”

Samma steg lägger till en omfattningspåminnelse som är direkt relevant för NIS2 och GDPR:

”Säkerställ att tillgångar med personuppgifter markeras (för GDPR-relevans) och att kritiska tjänstetillgångar noteras (för potentiell NIS2-tillämplighet om ni verkar i en reglerad sektor).”

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandlar ISO/IEC 27002:2022 kontroll 5.9, förteckning över information och andra tillhörande tillgångar, som en grundläggande kontroll för samordnad regelefterlevnad. Dess attribut klassificerar kontrollen som förebyggande, med stöd för konfidentialitet, riktighet och tillgänglighet, i linje med cybersäkerhetskonceptet Identify, den operativa förmågan till tillgångshantering samt styrnings-, ekosystem- och skyddsdomäner.

Zenith Controls förklarar GDPR- och NIS2-relevansen tydligt:

”Utan en korrekt och aktuell tillgångsförteckning kan organisationer inte bedöma eller införa lämpliga skyddsåtgärder.”

För NIS2 stödjer tillgångsförteckningen identifiering av kritiska system och komponenter som ligger till grund för väsentliga eller viktiga tjänster. För DORA gör DORA Article 8 identifiering av IKT-tillgångar och informationstillgångar central för operativ resiliens. För GDPR stödjer tillgångsförteckningen dataflödeskartläggning, RoPA-kvalitet och hantering av incidentanmälan.

Stödjande ISO-standarder förstärker samma logik. ISO/IEC 27005:2024 stärker tillgångsidentifiering i riskbedömning för informationssäkerhet. ISO 22301:2019 stödjer identifiering av resurser som behövs för verksamhetskontinuitet. ISO/IEC 19770-1:2017 stödjer mognad inom IT-tillgångshantering. ISO/IEC 27017:2015 och ISO/IEC 27018:2019 stödjer molnspecifika kontroller och skydd av PII i publika moln. ISO/IEC 27701:2019 utökar integritetsledningssystem. ISO/IEC 29100:2011 bidrar med integritetsprinciper såsom transparens, minimering och säkerhetsskyddsåtgärder.

En praktisk omfattningsövning för SaaS- och fintechteam

Börja med en reglerad tjänst, inte hela företaget. Till exempel: ”EU SaaS för betalningsanalys för finansiella institut.”

Bygg sedan en karta från tjänst till tillgång till behandling.

Ett mer detaljerat tillgångsexempel kan se ut så här.

Använd därefter Zenith Blueprint Step 13: Risk Treatment Planning and Statement of Applicability. Guiden instruerar användare att bygga SoA med mallen som listar alla Annex A-kontroller och att besluta om tillämplighet baserat på riskbehandling, rättsliga eller avtalsmässiga krav, omfattningsrelevans och organisatoriskt sammanhang. Den anger:

”För varje kontroll (rad) i SoA-arket, besluta om den är tillämplig på ert ISMS.”

För exemplet ovan bör SoA beakta kontroller för leverantörssäkerhet, molntjänster, incidenthantering, kontinuitet, rättsliga och regulatoriska krav, integritetsskydd, sårbarhetshantering, säkerhetskopior, loggning, övervakning, kryptografi, säker utveckling, säkerhetstestning och ändringshantering.

Ett praktiskt arbetsflöde är:

1. Skapa en flik ”ISMS-omfattningskartläggning” i Riskregister och SoA Builder.
2. Lägg till en rad per reglerad tjänst eller produktlinje.
3. Koppla varje tjänst till tillgångar, datatyper, leverantörer, platser och verksamhetsägare.
4. Markera NIS2-relevans, DORA-relevans och GDPR-relevans för behandling.
5. Lägg till riskscenarier för otillgänglig tjänst, personuppgiftsincident, leverantörsfel, felkonfiguration i moln, kritisk sårbarhet och brister i incidentrapportering.
6. Välj SoA-kontroller baserat på dessa risker och skyldigheter.
7. Dokumentera undantag, kompenserande kontroller och riskacceptans.
8. Inhämta godkännande från högsta ledningen för slutliga gränser och undantag.
9. För in den slutliga gränsen i internrevision, ledningens genomgång och leverantörsövervakning.

Resultatet är inte bara en bättre omfattningsbeskrivning. Det är en försvarbar kedja från reglerad tjänst till tillgång, leverantör, data, kontroll, ägare och bevismaterial.

Kartläggning för samordnad regelefterlevnad: en omfattning, många skyldigheter

Ett väl avgränsat ISO 27001 ISMS blir det operativa lager där förväntningar enligt NIS2, DORA, GDPR, NIST CSF och COBIT kan samordnas.

För ISO/IEC 27002:2022 kontroll 5.31, rättsliga, författningsmässiga, regulatoriska och avtalsmässiga krav, kopplar Zenith Controls krav på regelefterlevnad till integritetsskydd, PII-skydd, bevarande av uppgifter, oberoende granskning och efterlevnad av interna policyer. Den kartläggs naturligt mot GDPR-ansvarsskyldighet, NIS2-efterlevnad i leveranskedjan, DORA IKT-riskhantering och regelefterlevnad, NIST CSF-styrning och COBIT 2019-övervakning av extern efterlevnad.

För ISO/IEC 27002:2022 kontroll 5.34, integritet och skydd av PII, kopplar Zenith Controls integritetsskydd till tillgångsförteckning, molntjänster, klassificering, informationsöverföring, åtkomstkontroll, identitetshantering och granskning av projektändringar. Dess GDPR-kartläggning täcker säkerhet i behandlingen och inbyggt dataskydd. Dess DORA-kartläggning stödjer dataintegritet, säkerhet och konfidentialitet, inklusive personuppgifter som hanteras i IKT-tjänster.

Principen är enkel: skapa inte fyra frånkopplade program för regelefterlevnad. Skapa ett avgränsat ISMS som kan förklara hur skyldigheter uppfylls, beläggs och granskas.

Incidentrapporteringsomfattning: där gränser påverkar regulatoriska klockor

Felaktig omfattning blir smärtsamt tydlig under incidenter.

NIS2 Article 23 kräver stegvis rapportering av betydande incidenter, inklusive en tidig varning inom 24 timmar, en incidentanmälan inom 72 timmar, mellanrapporter när sådana begärs och en slutrapport inom en månad. Kommunikation till berörda mottagare kan också krävas.

DORA kräver att finansiella entiteter detekterar, hanterar, klassificerar och rapporterar större IKT-relaterade incidenter med kriterier såsom berörda kunder eller motparter, varaktighet, avbrottstid, geografisk spridning, dataförluster, kritikalitet hos berörda tjänster och ekonomisk påverkan. Kunder ska informeras utan onödigt dröjsmål när en större IKT-incident påverkar deras finansiella intressen.

GDPR-anmälan av personuppgiftsincident beror på om en incident leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till personuppgifter.

Om supportplattformen, loggmiljön, identitetstjänsten, kanalen för kundavisering eller leverantören av hanterad detektering ligger utanför ISMS-omfattningen kanske incidentteamen inte vet om en händelse utlöser NIS2, DORA, GDPR, rapportering enligt kundavtal eller allt detta samtidigt. Den osäkerheten förbrukar rapporteringstiden.

En mogen omfattning inkluderar incidentrelevanta beroenden: detekteringsverktyg, logglager, forensiska lagringsplatser, kanaler för kundkommunikation, supportverktyg, säkerhetskopieringsmiljöer, incidentbryggor och leverantörer som är involverade i triagering eller återställning.

Hur revisorer och tillsynsmyndigheter testar er ISMS-omfattning

En stark omfattning klarar stickprov. En svag omfattning faller samman när revisorer jämför dokument mot verkligheten.

Zenith Controls ger användbara revisionsförväntningar för ISO/IEC 27002:2022 kontroll 5.9. Revisorer med ISO/IEC 19011-ansats begär tillgångsförteckningen tidigt för att avgränsa andra utvärderingar och göra stickprovskontroller av fysiska tillgångar, programvara och molntillgångar. Revisorer med ISO/IEC 27007-ansats frågar hur och när förteckningen uppdateras och söker kopplingar till inköp, ändringshantering och avveckling. Revisorer med NIST SP 800-53A-ansats verifierar att inventeringsdetaljer omfattar tillgångstyp, ägare, plats, nätverksadress där det är tillämpligt och status, samt att molnbaserade, virtuella och mobila tillgångar ingår.

För kontroll 5.31 noterar Zenith Controls att certifieringsrevisorer förväntar sig ett register över regelefterlevnadskrav eller en lista över lagar och avtal, refererad i SoA och riskbehandlingsplaner. COBIT-revisorer söker efter ägare av regelefterlevnad, bedömningar och rapportering till högsta ledningen. ISACA ITAF-revisorer tar stickprov av underlag för att bekräfta att organisationen inte bara känner till sina skyldigheter, utan aktivt säkerställer att de uppfylls.

För kontroll 5.34 granskar revisorer integritetspolicyer, dataförteckningar, DPIA:er, utbildningsloggar, krypteringsunderlag, åtkomstkontroller, DSAR-stickprov, underlag för inbyggt dataskydd och incidentposter som involverar PII. En omfattningsbeskrivning som exkluderar ett system som behandlar personuppgifter kommer snabbt att ifrågasättas.

Styrelsefrågan: vad kan inte exkluderas?

Högsta ledningen frågar ofta om en affärsenhet, plats, leverantör eller ett system kan ligga utanför ISMS-omfattningen. Ibland är svaret ja. Men inte om undantaget hindrar organisationen från att uppfylla rättsliga, regulatoriska, avtalsmässiga eller tjänstesäkerhetsrelaterade skyldigheter.

Använd detta undantagstest innan någon gränsbegränsning godkänns:

• Stödjer enheten, systemet eller leverantören en NIS2-reglerad tjänst?
• Stödjer den en DORA-kritisk eller viktig funktion för organisationen eller dess reglerade kunder?
• Samlar den in, lagrar, överför, loggar, stödjer eller raderar personuppgifter?
• Tillhandahåller den säkerhetsövervakning, identitet, säkerhetskopiering, incidentrespons eller återställning för en tjänst inom omfattningen?
• Tillhandahåller den bevismaterial som behövs för incidentklassificering eller regulatorisk rapportering?
• Kräver ett kundavtal att den omfattas av ISMS?
• Skulle en kompromettering påverka konfidentialitet, riktighet, tillgänglighet, efterlevnad av rättsliga krav eller tjänstekontinuitet inom den angivna omfattningen?

Om svaret är ja kräver undantag starkt bevismaterial, kompenserande styrning, riskacceptans och formellt godkännande från högsta ledningen. I många fall bör undantag inte göras.

En modern ISO 27001 ISMS-omfattning bör omfatta:

1. Verksamhetstjänster och produktlinjer som omfattas.
2. Juridiska personer, organisationsenheter och platser som omfattas.
3. Kundsegment och jurisdiktioner som driver skyldigheter.
4. Kritiska eller viktiga funktioner och BIA-baserade väsentliga tjänster.
5. Informationstillgångar, IKT-tillgångar och molnmiljöer.
6. Aktiviteter för behandling av personuppgifter och PII-lagringsplatser.
7. Utvecklings-, test-, support-, övervaknings- och incidentprocesser.
8. Leverantörer och outsourcade tjänster som stödjer tjänster inom omfattningen.
9. Gränssnitt och beroenden till koncernbolag eller externa leverantörer.
10. Uttryckliga undantag med motivering, riskacceptans och godkännande från högsta ledningen.

Det är så ISO 27001-omfattning blir en styrningsposition på styrelsenivå, inte en genväg till certifiering.

Gör er ISMS-omfattning redo för revision innan revisorn definierar den åt er

Den sämsta tidpunkten att upptäcka ett omfattningsproblem är under certifiering, tillsynsgranskning, kunders leverantörsgranskning eller en pågående incident.

Ett snävt certifikat kan uppfylla en kryssruta i inköp, men det håller inte för seriös granskning om det exkluderar de tjänster, IKT-funktioner, leverantörer och den behandling av personuppgifter som skapar regulatorisk exponering. År 2026 kommer de organisationer som klarar revisioner med trygghet att vara de som kan visa en sammanhängande karta från reglerad tjänst till tillgång, leverantör, personuppgifter, kontroll, ägare och bevismaterial.

Börja med tre konkreta åtgärder:

1. Använd Zenith Blueprint Zenith Blueprint Phase: ISMS Foundation & Leadership, Step 2, för att skriva om er ISMS-omfattning runt tjänster, funktioner, behandling och beroenden.
2. Använd Zenith Controls Zenith Controls för att kartlägga tillgångsförteckning, rättsliga skyldigheter och PII-skydd mot revisionsförväntningar enligt ISO 27001, NIS2, DORA, GDPR, NIST och COBIT 2019.
3. Anpassa policyomfattningen med Clarysecs Informationssäkerhetspolicy Informationssäkerhetspolicy, Policy för rättslig och regulatorisk efterlevnad Policy för rättslig och regulatorisk efterlevnad, Riskhanteringspolicy Riskhanteringspolicy, Policy för dataskydd och integritet Policy för dataskydd och integritet och Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning.

Om er nuvarande ISMS-omfattning fortfarande ser ut som en avdelningsetikett, bygg om den till en efterlevnadsgräns. Ladda ner Clarysec-verktygslådorna, kartlägg en reglerad tjänst från början till slut och gör er ISO 27001-omfattning till revisionsklart bevismaterial för NIS2, DORA och GDPR.