Rozsah ISMS podle ISO 27001 pro NIS2, DORA a GDPR

Maria, ředitelka informační bezpečnosti v rychle rostoucím evropském fintechu, měla za to, že dozorový audit ISO 27001 je pod kontrolou.

Certifikát byl čerstvý. Prohlášení o použitelnosti působilo vyspěle. Prohlášení o rozsahu pokrývalo „firemní systém řízení bezpečnosti informací podporující provoz SaaS platformy“. Produkční cloudové prostředí bylo zdokumentované. Postup reakce na incidenty existoval. Registr rizik obsahoval vlastníky, termíny a hodnocení zbytkových rizik.

Potom auditor položil jednoduchou otázku:

„Které části této SaaS platformy jsou současně v rozsahu klasifikace podle NIS2, které externě zajišťované služby podporují kritické nebo důležité funkce podle DORA pro vaše finanční zákazníky a kde přesně se zpracovávají osobní údaje podle GDPR?“

V místnosti nastalo ticho.

Právní oddělení otevřelo tabulku regulačních povinností. Produktový tým otevřel architektonický diagram. Pověřenec pro ochranu osobních údajů otevřel záznamy o činnostech zpracování. Oddělení nákupu otevřelo seznam dodavatelů. Provoz otevřel plán obnovy po havárii. Nic z toho se neshodovalo.

Rozsah ISMS říkal „SaaS platforma“. Posouzení NIS2 identifikovalo služby digitální infrastruktury v několika členských státech. Zákaznické smlouvy popisovaly platformu jako podporu regulovaných finančních operací. Záznamy podle GDPR zahrnovaly identitní údaje, telemetrická data, IP adresy, platební metadata, tikety podpory a analytiku zajišťovanou subdodavateli. Plán obnovy po havárii pokrýval produkční prostředí, nikoli však platformu zákaznické podpory používanou pro komunikaci při porušení zabezpečení. Prověrka dodavatelů pokrývala poskytovatele hostingu, nikoli však řízenou detekční službu napojenou na produkční logy.

Toto je problém vymezení rozsahu ISMS pro rok 2026. Certifikace ISO 27001 má stále hodnotu, ale úzký „minimální životaschopný rozsah“ se může stát rizikem odpovědnosti, pokud orgány dohledu, zákazníci a auditoři očekávají, že tentýž systém řízení vysvětlí základní služby podle NIS2, kritické nebo důležité funkce podle DORA a hranice zpracování podle GDPR.

U ISO/IEC 27001:2022, NIS2, DORA a GDPR není slabě vymezený rozsah administrativním nedostatkem. Je to první kostka domina. Pokud je rozsah nesprávný, posouzení rizik je neúplné, SoA je zavádějící, dodavatelská opatření míjejí kritické poskytovatele, lhůty pro hlášení incidentů jsou nejisté a odpovědnost za ochranu soukromí se tříští mezi týmy.

Proč je rozsah ISMS podle ISO 27001 nyní regulační hranicí

ISO/IEC 27001:2022 kapitola 4.3 vyžaduje, aby organizace určila hranice a použitelnost ISMS s ohledem na interní a externí záležitosti, požadavky zainteresovaných stran a rozhraní a závislosti vůči jiným organizacím ISO/IEC 27001:2022.

Tato formulace má v roce 2026 větší význam než v dřívějších certifikačních cyklech. NIS2, DORA, GDPR, cloudový outsourcing, zákaznické smlouvy, skupinové technologické služby a poskytovatelé řízených služeb nejsou poznámky pod čarou. Jsou vstupy do vymezení hranice ISMS.

NIS2 zvyšuje nároky na správu a řízení u základních a důležitých subjektů. Vyžaduje, aby řídicí orgány schvalovaly opatření k řízení rizik v oblasti kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení. NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a vývoje, posouzení účinnosti, kybernetické hygieny, kryptografie, bezpečnosti v oblasti lidských zdrojů, řízení přístupu, správy aktiv a vícefaktorové autentizace, je-li to vhodné.

DORA mění diskusi o rozsahu u finančních subjektů. Použije se od 17. ledna 2025 a stanoví jednotné požadavky na řízení rizik v oblasti ICT, hlášení incidentů souvisejících s ICT, testování digitální provozní odolnosti, sdílení informací a řízení rizik třetích stran v oblasti ICT. DORA Article 6 vyžaduje dokumentovaný rámec řízení rizik ICT. DORA Article 8 vyžaduje identifikaci, klasifikaci a dokumentaci obchodních funkcí podporovaných ICT, informačních aktiv a ICT aktiv, včetně závislostí. DORA Article 28 vyžaduje řízení rizik třetích stran v oblasti ICT.

GDPR přidává osu osobních údajů. Vztahuje se na automatizované nebo strukturované zpracování osobních údajů, včetně zpracování provozovnami v EU a určitými správci nebo zpracovateli mimo EU, kteří nabízejí zboží nebo služby osobám v Unii nebo monitorují jejich chování. GDPR Article 30 vyžaduje záznamy o činnostech zpracování, Article 32 vyžaduje zabezpečení zpracování a Article 33 stanoví očekávání ohledně oznamování porušení zabezpečení.

Obhajitelný rozsah ISMS se proto nepíše podle organizačních útvarů. Vymezuje se podle regulovaných služeb, kritických nebo důležitých funkcí, zpracování osobních údajů, podpůrných aktiv a závislostí na třetích stranách.

Chyba: zacházet s ISO 27001, NIS2, DORA a GDPR jako s oddělenými programy

V mnoha organizacích se opakuje běžný vzorec:

• Bezpečnost připraví rozsah ISO 27001.
• Právní oddělení posoudí použitelnost NIS2.
• Rizika nebo compliance řídí povinnosti podle DORA.
• Ochrana soukromí udržuje záznamy o činnostech zpracování podle GDPR.
• Nákup vlastní seznam dodavatelů.
• Provoz vlastní kontinuitu činností a obnovu po havárii.

Každý tým může odvádět kvalitní práci. Problém je v tom, že regulovaná realita prochází napříč všemi těmito oblastmi.

Cloudová služba zákaznické identity může současně podporovat poskytování služby podle NIS2, zákaznické operace regulované DORA a zpracování osobních údajů podle GDPR. Poskytovatel řízené detekce může být bezpečnostním dodavatelem, závislostí reakce na incidenty, zpracovatelem nebo dílčím zpracovatelem logů a klíčovým vstupem pro rozhodnutí o regulačním oznámení. Platforma podpory může být považována za „neprodukční“, a přesto zpracovávat komunikaci o porušení zabezpečení osobních údajů a požadavky zákazníků na důkazy.

ISMS je nejvhodnějším místem pro integraci těchto povinností, protože ISO 27001 klade jednu disciplinovanou otázku: co je uvnitř hranice, co je mimo ni a proč?

Zenith Blueprint: 30krokový plán auditora od Clarysec Zenith Blueprint řeší tuto oblast ve fázi ISMS Foundation & Leadership, krok 2: potřeby zainteresovaných stran a rozsah ISMS:

„Jakmile je pochopen kontext a identifikovány požadavky zainteresovaných stran, kapitola 4.3 vyžaduje, abyste určili hranice a použitelnost ISMS a tím stanovili jeho rozsah. Rozsah ISMS je zásadní definice, která určuje, co je zahrnuto do vašeho programu řízení bezpečnosti (a co zahrnuto není).“

Zenith Blueprint také zdůrazňuje bod, který mnohá prohlášení o rozsahu stále opomíjejí:

„Pokud outsourcujete svou IT infrastrukturu poskytovateli cloudových služeb, nevylučuje ji to z rozsahu; naopak do rozsahu zahrnete řízení tohoto vztahu a cloudová aktiva.“

Outsourcing přesouvá provedení. Nemaže odpovědnost.

Čtyřhraniční model pro rozsah ISO 27001 v roce 2026

Organizacím dotčeným NIS2, DORA a GDPR doporučuje Clarysec definovat rozsah ISMS podle ISO 27001 prostřednictvím čtyř propojených hranic.

Slabé prohlášení o rozsahu říká pouze „SaaS platforma“. Silnější prohlášení uvádí, které obchodní služby, systémy, prostředí, lokality, činnosti zpracování údajů, skupiny pracovníků, dodavatelské vztahy a řídicí procesy jsou zahrnuty.

Obhajitelnější verze může znít takto:

„ISMS pokrývá správu, řízení rizik, provoz a neustálé zlepšování bezpečnosti informací pro platební analytickou SaaS platformu společnosti v EU, včetně produkčních a neprodukčních cloudových prostředí, služeb zákaznické identity, administrátorských rozhraní, provozu podpory, platforem protokolování a monitorování, reakce na incidenty, kontinuity činností, řízení dodavatelů a všech činností zpracování osobních údajů podporujících službu. ISMS zahrnuje řízení outsourcovaného cloudového hostingu, řízené detekce a nástrojů zákaznické podpory používaných pro poskytování služby, odolnost, bezpečnostní monitorování nebo komunikaci související s GDPR.“

Takový rozsah není pouze delší. Je lépe auditovatelný, protože propojuje služby, aktiva, zpracování a závislosti.

Jak politiky Clarysec převádějí rozsah do jazyka správy a řízení

Rozsah nemá žít v samostatném dokumentu. Musí být sladěn s politikou bezpečnosti informací, právním a regulačním souladem, řízením rizik, ochranou soukromí, řízením dodavatelů, auditními kritérii a plánováním kontinuity.

Enterprise politika bezpečnosti informací politika bezpečnosti informací předchází nejasnostem kolem výjimek:

„Veškerá vyloučení nebo omezení tohoto rozsahu musí být zdokumentována v prohlášení o rozsahu ISMS a odůvodněna formálním schválením vrcholového vedení.“

Toto ustanovení je důležité, když obchodní jednotka tvrdí, že zákaznická podpora je mimo platformu, přestože pracovníci podpory přistupují k zákaznickým identifikátorům a zajišťují komunikaci při porušení zabezpečení. Vyloučení je možné pouze tehdy, je-li zdokumentováno, odůvodněno a schváleno.

Enterprise politika právního a regulačního souladu politika právního a regulačního souladu převádí právní mapování do provozní roviny:

„Veškeré právní a regulační povinnosti musí být mapovány na konkrétní politiky, kontroly a vlastníky v rámci systému řízení bezpečnosti informací (ISMS).“

Toto je most mezi právní použitelností a Prohlášením o použitelnosti. NIS2 Article 21 nemá zůstat v právním memorandu. Povinnosti DORA pro třetí strany v oblasti ICT nemají zůstat pouze v pokynech pro nákup. Povinnosti GDPR Article 30 a Article 32 nemají sedět pouze v registru ochrany soukromí. Potřebují namapované vlastníky, kontroly a důkazy.

Enterprise politika řízení rizik politika řízení rizik rozšiřuje rozsah na třetí strany:

„Tato politika se vztahuje na všechny organizační jednotky, obchodní procesy, systémy, pracovníky a zapojení třetích stran podílející se na nakládání, vývoji, ukládání nebo správě informačních aktiv.“

Toto znění je v souladu se zabezpečením dodavatelského řetězce podle NIS2, riziky třetích stran v oblasti ICT podle DORA a odpovědností správce nebo zpracovatele podle GDPR.

Enterprise politika ochrany dat a soukromí politika ochrany dat a soukromí ukotvuje rozsah ochrany soukromí ve zpracování:

„Tato politika se vztahuje na všechny organizační jednotky, pracovníky a systémy zapojené do zpracování osobních informací (PII), včetně:“

Princip je rozhodující. Pokud systém zpracovává PII, nemůže být pro ISMS neviditelný jen proto, že je „pouze podpůrný“, „neprodukční“ nebo „vlastněný marketingem“.

Enterprise politika kontinuity činností a obnovy po havárii politika kontinuity činností a obnovy po havárii váže rozsah na výsledky BIA:

„Tato politika se vztahuje na všechny organizační jednotky, informační systémy, obchodní procesy, pracovníky a služby třetích stran klasifikované jako kritické nebo nezbytné na základě výsledků analýzy dopadů na činnost organizace (BIA).“

Toto ustanovení přirozeně odpovídá kritickým nebo důležitým funkcím podle DORA a kontinuitě služeb podle NIS2.

U menších organizací zachovávají SME politiky Clarysec stručné znění, ale ponechávají stejnou logiku. SME politika monitorování auditu a souladu politika monitorování auditu a souladu - SME definuje auditní pokrytí jako:

„Všechny kontroly a systémy v rozsahu systému řízení bezpečnosti informací (ISMS)“

SME politika ochrany dat a soukromí politika ochrany dat a soukromí - SME definuje rozsah ochrany soukromí jako:

„Jakýkoli systém, aplikace nebo lokalita, kde jsou osobní údaje uloženy nebo přenášeny“

SME politika řízení rizik politika řízení rizik - SME udržuje outsourcované služby viditelné:

„Veškeré informace, služby a aktiva spravované interně nebo prostřednictvím třetích stran“

Takto krátká ustanovení jsou účinná, protože brání tomu, aby certifikační hranice vyloučila regulovaná data, cloudové služby nebo aktiva spravovaná dodavateli.

Evidence aktiv je místo, kde se rozsah stává skutečností

Prohlášení o rozsahu je věrohodné pouze tehdy, pokud jej lze dohledat k aktivům, vlastníkům, dodavatelům, datovým tokům a důkazům.

Zenith Blueprint ve fázi řízení rizik, krok 9: identifikace aktiv, hrozeb a zranitelností, ukládá organizacím uvést aktiva v rozsahu ISMS a zachytit vlastníka, umístění a klasifikaci. Uvádí praktický příklad:

„Zákaznická databáze – vlastněná IT oddělením – hostovaná na AWS – obsahuje osobní a finanční údaje (vysoká citlivost).“

Tentýž krok doplňuje připomínku k rozsahu, která je přímo relevantní pro NIS2 a GDPR:

„Zajistěte, aby aktiva s osobními údaji byla označena (pro relevanci GDPR) a aby byla uvedena kritická aktiva služeb (pro potenciální použitelnost NIS2, pokud působíte v regulovaném sektoru).“

Zenith Controls: průvodce napříč souladem od Clarysec Zenith Controls považuje ISO/IEC 27002:2022 opatření 5.9, evidence informací a dalších souvisejících aktiv, za základní opatření napříč požadavky na soulad. Jeho atributy klasifikují opatření jako preventivní, podporující důvěrnost, integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Identify, provozní schopností správy aktiv a doménami správy, ekosystému a ochrany.

Zenith Controls vysvětluje relevanci pro GDPR a NIS2 přímo:

„Bez přesné a aktuální evidence aktiv nemohou organizace posuzovat ani zavádět vhodné ochrany.“

Pro NIS2 podporuje evidence aktiv identifikaci kritických systémů a komponent, na nichž stojí základní nebo důležité služby. Pro DORA činí DORA Article 8 identifikaci ICT aktiv a informačních aktiv ústředním prvkem provozní odolnosti. Pro GDPR evidence aktiv podporuje mapování datových toků, kvalitu RoPA a reakci na porušení zabezpečení.

Stejnou logiku posilují i podpůrné normy ISO. ISO/IEC 27005:2024 posiluje identifikaci aktiv v posouzení rizik bezpečnosti informací. ISO 22301:2019 podporuje identifikaci zdrojů potřebných pro kontinuitu činností. ISO/IEC 19770-1:2017 podporuje vyspělost správy IT aktiv. ISO/IEC 27017:2015 a ISO/IEC 27018:2019 podporují cloudově specifická opatření a ochranu PII ve veřejných cloudech. ISO/IEC 27701:2019 rozšiřuje řízení informací o ochraně soukromí. ISO/IEC 29100:2011 přispívá principy ochrany soukromí, jako je transparentnost, minimalizace a bezpečnostní ochranná opatření.

Praktické cvičení vymezení rozsahu pro SaaS a fintech týmy

Začněte jednou regulovanou službou, ne celou společností. Například: „SaaS pro platební analytiku v EU pro finanční instituce.“

Poté vytvořte mapu služba–aktivum–zpracování.

Podrobnější ukázka aktiv může vypadat takto.

Dále použijte Zenith Blueprint krok 13: plánování ošetření rizik a Prohlášení o použitelnosti. Průvodce ukládá uživatelům vytvořit SoA pomocí šablony, která uvádí všechna opatření Annex A, a rozhodnout o použitelnosti na základě ošetření rizik, právních nebo smluvních požadavků, relevance rozsahu a kontextu organizace. Uvádí:

„U každého opatření (řádku) v listu SoA rozhodněte, zda je použitelné pro váš ISMS.“

U výše uvedeného příkladu by SoA mělo zohlednit opatření pro bezpečnost dodavatelů, cloudové služby, řízení incidentů, kontinuitu, právní a regulační požadavky, ochranu soukromí, řízení zranitelností, zálohování, protokolování, monitorování, kryptografii, bezpečný vývoj, bezpečnostní testování a řízení změn.

Praktický pracovní postup je následující:

1. V registru rizik a SoA Builderu vytvořte záložku „Mapování rozsahu ISMS“.
2. Přidejte jeden řádek pro každou regulovanou službu nebo produktovou řadu.
3. Propojte každou službu s aktivy, typy dat, dodavateli, lokalitami a vlastníky obchodních procesů.
4. Označte relevanci NIS2, relevanci DORA a relevanci zpracování podle GDPR.
5. Přidejte rizikové scénáře pro nedostupnost služby, porušení zabezpečení osobních údajů, selhání dodavatele, chybnou konfiguraci cloudu, kritickou zranitelnost a selhání hlášení incidentu.
6. Vyberte opatření SoA na základě těchto rizik a povinností.
7. Zdokumentujte vyloučení, kompenzační opatření a akceptaci rizika.
8. Získejte schválení vrcholového vedení pro konečné hranice a vyloučení.
9. Promítněte konečnou hranici do interního auditu, přezkoumání vedením a monitorování dodavatelů.

Výstupem není jen lepší prohlášení o rozsahu. Je to obhajitelný řetězec od regulované služby k aktivu, dodavateli, datům, opatření, vlastníkovi a důkazům.

Mapování napříč souladem: jeden rozsah, mnoho povinností

Dobře vymezený ISMS podle ISO 27001 se stává provozní vrstvou, ve které lze sladit očekávání NIS2, DORA, GDPR, NIST CSF a COBIT.

U ISO/IEC 27002:2022 opatření 5.31, Právní, zákonné, regulační a smluvní požadavky, Zenith Controls váže povinnosti v oblasti souladu na ochranu soukromí, ochranu PII, uchovávání záznamů, nezávislý přezkum a soulad s interními politikami. Přirozeně se mapuje na odpovědnost podle GDPR, soulad dodavatelského řetězce podle NIS2, řízení rizik ICT a soulad podle DORA, správu NIST CSF a monitorování externího souladu podle COBIT 2019.

U ISO/IEC 27002:2022 opatření 5.34, Ochrana soukromí a ochrana PII, Zenith Controls propojuje ochranu soukromí s evidencí aktiv, cloudovými službami, klasifikací, předáváním informací, řízením přístupu, správou identit a přezkumy projektových změn. Jeho mapování na GDPR pokrývá zabezpečení zpracování a ochranu osobních údajů již od návrhu. Jeho mapování na DORA podporuje integritu, bezpečnost a důvěrnost dat, včetně osobních údajů zpracovávaných v ICT službách.

Princip je jednoduchý: nevytvářejte čtyři odpojené programy souladu. Vytvořte jeden vymezený ISMS, který dokáže vysvětlit, jak jsou povinnosti plněny, doloženy a auditovány.

Rozsah hlášení incidentů: kde hranice ovlivňují regulační lhůty

Nesprávný rozsah se bolestivě projeví při incidentech.

NIS2 Article 23 vyžaduje odstupňované hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin, průběžných zpráv na vyžádání a závěrečné zprávy do jednoho měsíce. Může být vyžadována také komunikace s dotčenými příjemci.

DORA vyžaduje, aby finanční subjekty detekovaly, řídily, klasifikovaly a hlásily závažné incidenty související s ICT podle kritérií, jako jsou dotčení klienti nebo protistrany, doba trvání, nedostupnost služeb, geografické rozšíření, ztráty dat, kritičnost dotčených služeb a ekonomický dopad. Klienti musí být bez zbytečného odkladu informováni, pokud závažný ICT incident ovlivňuje jejich finanční zájmy.

Oznamování porušení zabezpečení osobních údajů podle GDPR závisí na tom, zda porušení vede k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění osobních údajů nebo přístupu k nim.

Pokud je platforma podpory, prostředí logů, služba identity, kanál pro informování zákazníků nebo poskytovatel řízené detekce mimo rozsah ISMS, incidentní týmy nemusí vědět, zda událost spouští NIS2, DORA, GDPR, hlášení podle zákaznické smlouvy nebo všechny tyto povinnosti. Tato nejistota spotřebovává čas určený pro hlášení.

Vyspělý rozsah zahrnuje závislosti relevantní pro incidenty: detekční nástroje, úložiště logů, forenzní repozitáře, komunikační kanály se zákazníky, nástroje podpory, záložní prostředí, incidentní mosty a dodavatele zapojené do triáže nebo obnovy.

Jak auditoři a orgány dohledu otestují rozsah vašeho ISMS

Silný rozsah obstojí při vzorkování. Slabý rozsah se zhroutí, když auditoři porovnají dokumentaci s realitou.

Zenith Controls poskytuje užitečná auditní očekávání pro ISO/IEC 27002:2022 opatření 5.9. Auditoři ve stylu ISO/IEC 19011 si vyžádají evidenci na začátku, aby vymezili další hodnocení a provedli namátkové kontroly fyzických, softwarových a cloudových aktiv. Auditoři ve stylu ISO/IEC 27007 se ptají, jak a kdy se evidence aktualizuje, a hledají vazby na nákup, řízení změn a vyřazení z provozu. Auditoři ve stylu NIST SP 800-53A ověřují, že podrobnosti evidence zahrnují typ aktiva, vlastníka, umístění, síťovou adresu, je-li relevantní, a stav, a že jsou zahrnuta cloudová, virtuální a mobilní aktiva.

U opatření 5.31 Zenith Controls uvádí, že certifikační auditoři očekávají registr souladu nebo seznam právních předpisů a smluv, na které se odkazuje v SoA a plánech ošetření rizik. Auditoři COBIT hledají vlastníky souladu, posouzení a reporting vrcholovému vedení. Auditoři ISACA ITAF vzorkují důkazy, aby potvrdili, že organizace nejen zná své povinnosti, ale aktivně zajišťuje jejich plnění.

U opatření 5.34 auditoři přezkoumávají politiky ochrany soukromí, datové inventáře, DPIA, záznamy o školení, důkazy o šifrování, řízení přístupu, vzorky DSAR, důkazy ochrany soukromí již od návrhu a záznamy incidentů zahrnujících PII. Prohlášení o rozsahu, které vylučuje systém zpracovávající osobní údaje, bude rychle zpochybněno.

Otázka pro řídicí orgány: co nelze vyloučit?

Vrcholové vedení se často ptá, zda může obchodní jednotka, lokalita, dodavatel nebo systém zůstat mimo rozsah ISMS. Někdy je odpověď ano. Ne však tehdy, pokud vyloučení brání organizaci plnit právní, regulační, smluvní nebo bezpečnostní povinnosti vztahující se ke službě.

Před schválením jakéhokoli omezení hranice použijte tento test vyloučení:

• Podporuje jednotka, systém nebo dodavatel službu regulovanou podle NIS2?
• Podporuje kritickou nebo důležitou funkci podle DORA pro organizaci nebo její regulované zákazníky?
• Shromažďuje, ukládá, přenáší, protokoluje, podporuje nebo maže osobní údaje?
• Poskytuje bezpečnostní monitorování, identitu, zálohování, reakci na incidenty nebo obnovu pro službu v rozsahu?
• Poskytuje důkazy potřebné pro klasifikaci incidentu nebo regulační oznámení?
• Vyžaduje zákaznická smlouva, aby byl zahrnut do ISMS?
• Ovlivnila by jeho kompromitace důvěrnost, integritu, dostupnost, právní soulad nebo kontinuitu služby v deklarovaném rozsahu?

Pokud je odpověď ano, vyloučení vyžaduje silné důkazy, kompenzační správu a řízení, akceptaci rizika a formální schválení vrcholovým vedením. V mnoha případech by vyloučeno být nemělo.

Moderní rozsah ISMS podle ISO 27001 by měl zahrnovat:

1. Pokryté obchodní služby a produktové řady.
2. Pokryté právní subjekty, organizační jednotky a lokality.
3. Zákaznické segmenty a jurisdikce, které vytvářejí povinnosti.
4. Kritické nebo důležité funkce a základní služby založené na BIA.
5. Informační aktiva, ICT aktiva a cloudová prostředí.
6. Činnosti zpracování osobních údajů a repozitáře PII.
7. Procesy vývoje, testování, podpory, monitorování a incidentů.
8. Dodavatele a outsourcované služby podporující služby v rozsahu.
9. Rozhraní a závislosti se skupinovými společnostmi nebo externími poskytovateli.
10. Výslovná vyloučení s odůvodněním, akceptací rizika a schválením vrcholovým vedením.

Tak se rozsah ISO 27001 stává stanoviskem správy a řízení na úrovni řídicích orgánů, nikoli certifikační zkratkou.

Připravte rozsah ISMS na audit dříve, než jej za vás vymezí auditor

Nejhorší okamžik pro zjištění problému s rozsahem je během certifikace, dozorového přezkumu, zákaznické prověrky nebo živého incidentu.

Úzký certifikát může splnit zaškrtávací políčko v nákupu, ale neobstojí při důkladném přezkumu, pokud vylučuje služby, ICT funkce, dodavatele a zpracování osobních údajů, které vytvářejí regulační expozici. V roce 2026 projdou audity s jistotou ty organizace, které dokážou ukázat jednu konzistentní mapu od regulované služby k aktivu, dodavateli, osobním údajům, opatření, vlastníkovi a důkazům.

Začněte třemi konkrétními kroky:

1. Použijte Zenith Blueprint Zenith Blueprint, fázi ISMS Foundation & Leadership, krok 2, k přepracování rozsahu ISMS kolem služeb, funkcí, zpracování a závislostí.
2. Použijte Zenith Controls Zenith Controls k mapování evidence aktiv, právních povinností a ochrany PII napříč auditními očekáváními ISO 27001, NIS2, DORA, GDPR, NIST a COBIT 2019.
3. Slaďte rozsah politik pomocí Clarysec politika bezpečnosti informací politika bezpečnosti informací, politika právního a regulačního souladu politika právního a regulačního souladu, politika řízení rizik politika řízení rizik, politika ochrany dat a soukromí politika ochrany dat a soukromí a politika kontinuity činností a obnovy po havárii politika kontinuity činností a obnovy po havárii.

Pokud váš současný rozsah ISMS stále zní jako název oddělení, přestavte jej na hranici souladu. Stáhněte si nástroje Clarysec, zmapujte jednu regulovanou službu od začátku do konce a proměňte rozsah ISO 27001 v auditní důkazy připravené pro NIS2, DORA a GDPR.