Obseg ISMS po ISO 27001 za NIS2, DORA in GDPR

Maria, direktorica za informacijsko varnost (CISO) v hitro rastočem evropskem fintech podjetju, je menila, da ima nadzorno presojo ISO 27001 pod nadzorom.

Certifikat je bil nov. Izjava o uporabnosti je delovala zrelo. Izjava o obsegu je zajemala »sistem upravljanja informacijske varnosti podjetja, ki podpira delovanje platforme SaaS«. Produkcijsko okolje v oblaku je bilo dokumentirano. Postopek odzivanja na incidente je obstajal. Register tveganj je imel lastnike, datume in ocene preostalega tveganja.

Nato je presojevalec zastavil preprosto vprašanje:

»Kateri deli te platforme SaaS so hkrati v obsegu registracije za NIS2, katere zunanje izvajane storitve podpirajo kritične ali pomembne funkcije po DORA za vaše finančne stranke in kje natančno se obdelujejo osebni podatki po GDPR?«

V sobi je zavladala tišina.

Pravna služba je odprla preglednico regulativnih obveznosti. Produktna ekipa je odprla arhitekturni diagram. Pooblaščena oseba za varstvo podatkov (DPO) je odprla evidence dejavnosti obdelave. Nabava je odprla seznam dobaviteljev. Operativna ekipa je odprla načrt obnovitve po nesreči. Noben dokument se ni ujemal z drugim.

Obseg ISMS je navajal »platformo SaaS«. Ocena za NIS2 je opredelila storitve digitalne infrastrukture v več državah članicah. Pogodbe s strankami so platformo opisovale kot podporo reguliranim finančnim operacijam. Evidence po GDPR so vključevale podatke o identiteti, telemetrijo, naslove IP, metapodatke plačil, podporne zahtevke in analitiko, oddano podizvajalcem. Načrt obnovitve po nesreči je zajemal produkcijo, ne pa platforme za podporo strankam, ki se uporablja za komunikacijo ob kršitvah. Skrbni pregled dobaviteljev je zajemal ponudnika gostovanja, ne pa storitve upravljanega zaznavanja, povezane s produkcijskimi dnevniki.

To je problem opredeljevanja obsega ISMS v letu 2026. Certifikacija ISO 27001 je še vedno dragocena, vendar lahko ozek »minimalni izvedljivi obseg« postane tveganje odgovornosti, ko nadzorni organi, stranke in presojevalci pričakujejo, da isti sistem upravljanja pojasni bistvene storitve po NIS2, kritične ali pomembne funkcije po DORA in meje obdelave po GDPR.

Za ISO/IEC 27001:2022, NIS2, DORA in GDPR šibek obseg ni administrativna pomanjkljivost. Je prva domina. Če je obseg napačen, je ocena tveganja nepopolna, SoA zavajajoča, kontrole dobaviteljev spregledajo kritične ponudnike, roki za poročanje o incidentih postanejo negotovi, odgovornost za zasebnost pa se razdrobi med ekipe.

Zakaj je obseg ISMS po ISO 27001 zdaj regulativna meja

ISO/IEC 27001:2022 točka 4.3 zahteva, da organizacija določi meje in uporabnost ISMS ob upoštevanju notranjih in zunanjih vprašanj, zahtev zainteresiranih strani ter vmesnikov in odvisnosti z drugimi organizacijami ISO/IEC 27001:2022.

Ta zahteva je v letu 2026 pomembnejša kot v prejšnjih certifikacijskih ciklih. NIS2, DORA, GDPR, zunanje izvajanje storitev v oblaku, pogodbe s strankami, skupinske tehnološke storitve in ponudniki upravljanih storitev niso stranske opombe. So vhodni podatki za določitev meje ISMS.

NIS2 zvišuje zahteve upravljanja za bistvene in pomembne subjekte. Zahteva, da organi upravljanja odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzorujejo njihovo izvajanje in prejmejo usposabljanje. NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavo incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo in razvojem, ocenjevanjem učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnostjo, nadzorom dostopa, upravljanjem sredstev in večfaktorsko avtentikacijo, kadar je ustrezno.

DORA spreminja razpravo o obsegu za finančne subjekte. Uporablja se od 17. januarja 2025 in določa enotne zahteve za upravljanje tveganj IKT, poročanje o incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti, izmenjavo informacij in upravljanje tveganj tretjih oseb na področju IKT. DORA Article 6 zahteva dokumentiran okvir za upravljanje tveganj IKT. DORA Article 8 zahteva identifikacijo, razvrstitev in dokumentiranje poslovnih funkcij, podprtih z IKT, informacijskih sredstev in sredstev IKT, vključno z odvisnostmi. DORA Article 28 zahteva upravljanje tveganj tretjih oseb na področju IKT.

GDPR dodaja os osebnih podatkov. Uporablja se za avtomatizirano ali strukturirano obdelavo osebnih podatkov, vključno z obdelavo s strani ustanovitev v EU in določenih upravljavcev ali obdelovalcev zunaj EU, ki ponujajo blago ali storitve posameznikom v Uniji ali spremljajo njihovo vedenje. GDPR Article 30 zahteva evidence dejavnosti obdelave, Article 32 zahteva varnost obdelave, Article 33 pa določa pričakovanja glede obveščanja o kršitvah.

Zagovorljiv obseg ISMS zato ni zapisan po oddelkih. Zapisan je po reguliranih storitvah, kritičnih ali pomembnih funkcijah, obdelavi osebnih podatkov, podpornih sredstvih in odvisnostih od tretjih oseb.

Napaka: obravnavanje ISO 27001, NIS2, DORA in GDPR kot ločenih programov

V številnih organizacijah se pojavlja pogost vzorec:

• Varnostna ekipa pripravi obseg ISO 27001.
• Pravna služba presoja uporabnost NIS2.
• Funkcija za tveganja ali skladnost upravlja obveznosti DORA.
• Ekipa za zasebnost vzdržuje evidence dejavnosti obdelave po GDPR.
• Nabava je lastnik seznama dobaviteljev.
• Operativa je lastnik neprekinjenega poslovanja in obnovitve po nesreči.

Vsaka ekipa lahko svoje delo opravlja razumno dobro. Težava je v tem, da regulirana resničnost prečka vse te meje.

V oblaku gostovana storitev identitete strank lahko hkrati podpira zagotavljanje storitev po NIS2, regulirane operacije strank po DORA in obdelavo osebnih podatkov po GDPR. Ponudnik upravljanega zaznavanja je lahko varnostni dobavitelj, odvisnost za odziv na incidente, obdelovalec ali podobdelovalec dnevniških podatkov in ključen vhodni podatek za odločitve o regulativnem obveščanju. Podporna platforma se lahko šteje za »neprodukcijsko«, čeprav obravnava komunikacijo ob kršitvah osebnih podatkov in zahtevke strank za dokazila.

ISMS je najboljše mesto za integracijo teh obveznosti, ker ISO 27001 zahteva eno disciplinirano vprašanje: kaj je znotraj meje, kaj je zunaj in zakaj?

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to obravnava v fazi temeljev in vodstva ISMS, korak 2: potrebe zainteresiranih strani in obseg ISMS:

»Ko je kontekst razumljen in so zahteve zainteresiranih strani opredeljene, točka 4.3 zahteva, da določite meje in uporabnost ISMS ter tako vzpostavite njegov obseg. Obseg ISMS je ključna opredelitev, ki določa, kaj je vključeno v vaš program upravljanja varnosti in kaj ni.«

Zenith Blueprint poudarja tudi točko, ki jo številne izjave o obsegu še vedno spregledajo:

»Če svojo IT infrastrukturo oddate ponudniku storitev v oblaku, to ne pomeni, da je izključena iz obsega; nasprotno, upravljanje tega odnosa in sredstva v oblaku vključite kot del obsega.«

Zunanje izvajanje prenese izvedbo. Ne izbriše odgovornosti.

Model štirih meja za obseg ISO 27001 v letu 2026

Za organizacije, na katere vplivajo NIS2, DORA in GDPR, Clarysec priporoča opredelitev obsega ISMS po ISO 27001 skozi štiri povezane meje.

Šibka izjava o obsegu navaja samo »platformo SaaS«. Močnejša izjava določa, katere poslovne storitve, sistemi, okolja, lokacije, dejavnosti obdelave podatkov, skupine osebja, odnosi z dobavitelji in procesi upravljanja so vključeni.

Bolj zagovorljiva različica bi se lahko glasila:

»ISMS zajema upravljanje, obvladovanje tveganj, delovanje in nenehno izboljševanje informacijske varnosti za platformo podjetja za analitiko plačil SaaS v EU, vključno s produkcijskimi in neprodukcijskimi okolji v oblaku, storitvami identitete strank, administrativnimi vmesniki, podpornimi operacijami, platformami za beleženje in spremljanje, odzivom na incidente, neprekinjenim poslovanjem, upravljanjem dobaviteljev ter vsemi dejavnostmi obdelave osebnih podatkov, ki podpirajo storitev. ISMS vključuje upravljanje zunanje izvajanega gostovanja v oblaku, upravljanega zaznavanja in orodij za podporo strankam, ki se uporabljajo za izvajanje storitve, odpornost, varnostno spremljanje ali komunikacije, povezane z GDPR.«

Ta obseg ni zgolj daljši. Primernejši je za presojo, ker povezuje storitve, sredstva, obdelavo in odvisnosti.

Kako politike Clarysec pretvorijo obseg v jezik upravljanja

Obseg ne sme živeti v samostojnem dokumentu. Usklajen mora biti s politiko informacijske varnosti, pravno in regulativno skladnostjo, obvladovanjem tveganj, zasebnostjo, upravljanjem dobaviteljev, merili presoje in načrtovanjem neprekinjenega poslovanja.

Podjetniška Politika informacijske varnosti Politika informacijske varnosti preprečuje dvoumnost glede izključitev:

»Vse izključitve ali omejitve tega obsega morajo biti dokumentirane v izjavi o obsegu ISMS in utemeljene s formalno odobritvijo najvišjega vodstva.«

Ta določba je pomembna, ko poslovna enota trdi, da je podpora strankam zunaj platforme, čeprav podporni agenti dostopajo do identifikatorjev strank in obravnavajo komunikacijo ob kršitvah. Izključitev je dopustna le, če je dokumentirana, utemeljena in odobrena.

Podjetniška Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti pravno mapiranje pretvori v operativno prakso:

»Vse zakonske in regulativne obveznosti morajo biti mapirane na posebne politike, kontrole in lastnike v okviru sistema upravljanja informacijske varnosti (ISMS).«

To je most med pravno uporabnostjo in Izjavo o uporabnosti. NIS2 Article 21 ne sme ostati v pravnem memorandumu. Obveznosti tretjih oseb na področju IKT po DORA ne smejo ostati le v nabavnih smernicah. Obveznosti GDPR Article 30 in Article 32 ne smejo biti samo v evidenci zasebnosti. Potrebujejo mapirane lastnike, kontrole in dokazila.

Podjetniška Politika upravljanja tveganj Politika upravljanja tveganj razširi obseg na tretje osebe:

»Ta politika velja za vse organizacijske enote, poslovne procese, sisteme, osebje in angažmaje tretjih oseb, vključene v ravnanje z informacijskimi sredstvi, njihov razvoj, hrambo ali upravljanje.«

Takšno besedilo je skladno z varnostjo dobavne verige po NIS2, tveganji tretjih oseb na področju IKT po DORA in odgovornostjo upravljavca ali obdelovalca po GDPR.

Podjetniška Politika varstva podatkov in zasebnosti Politika varstva podatkov in zasebnosti zasidra obseg zasebnosti v obdelavi:

»Ta politika velja za vse organizacijske enote, osebje in sisteme, vključene v obdelavo osebno določljivih podatkov (PII), vključno z:«

Načelo je odločilno. Če sistem obdeluje PII, za ISMS ne sme biti neviden zato, ker je »samo podpora«, »neprodukcijski« ali »v lasti marketinga«.

Podjetniška Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči povezuje obseg z rezultati BIA:

»Ta politika velja za vse organizacijske enote, informacijske sisteme, poslovne procese, osebje in storitve tretjih oseb, ki so na podlagi rezultatov analize vpliva na poslovanje (BIA) razvrščeni kot kritični ali bistveni.«

Ta določba se naravno ujema s kritičnimi ali pomembnimi funkcijami po DORA in neprekinjenim izvajanjem storitev po NIS2.

Za manjše organizacije Clarysecove politike za SME ohranjajo jedrnato besedilo, hkrati pa ohranjajo isto logiko. SME Politika spremljanja presoje in skladnosti-sme Politika spremljanja presoje in skladnosti-sme - SME opredeljuje pokritost presoje kot:

»Vse kontrole in sisteme v obsegu sistema upravljanja informacijske varnosti (ISMS)«

SME Politika varstva podatkov in zasebnosti-sme Politika varstva podatkov in zasebnosti-sme - SME opredeljuje obseg zasebnosti kot:

»Vsak sistem, aplikacijo ali lokacijo, kjer se osebni podatki hranijo ali prenašajo«

SME Politika upravljanja tveganj-sme Politika upravljanja tveganj-sme - SME ohranja vidnost zunanje izvajanih storitev:

»Vse informacije, storitve in sredstva, upravljana interno ali prek tretjih oseb«

Takšne kratke določbe so učinkovite, ker preprečujejo, da bi certifikacijska meja izključila regulirane podatke, storitve v oblaku ali sredstva, ki jih upravljajo dobavitelji.

Popis sredstev je mesto, kjer obseg postane stvaren

Izjava o obsegu je verodostojna le, če jo je mogoče povezati s sredstvi, lastniki, dobavitelji, tokovi podatkov in dokazili.

Zenith Blueprint v fazi obvladovanja tveganj, korak 9: prepoznavanje sredstev, groženj in ranljivosti, organizacijam naroča, naj navedejo sredstva v obsegu ISMS ter zajamejo lastnika, lokacijo in razvrstitev. Navaja praktičen primer:

»Podatkovna baza strank – v lasti IT oddelka – gostovana na AWS – vsebuje osebne in finančne podatke (visoka občutljivost).«

Isti korak dodaja opomnik glede obsega, ki je neposredno relevanten za NIS2 in GDPR:

»Zagotovite, da so sredstva z osebnimi podatki označena za namen GDPR in da so označena sredstva kritičnih storitev za morebitno uporabnost NIS2, če delujete v reguliranem sektorju.«

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls obravnava kontrolo ISO/IEC 27002:2022 5.9, popis informacij in drugih povezanih sredstev, kot temeljno kontrolo za skladnost prek več okvirov. Njeni atributi razvrščajo kontrolo kot preventivno, ki podpira zaupnost, celovitost in razpoložljivost, usklajeno s konceptom kibernetske varnosti Identify, operativno zmožnostjo upravljanja sredstev ter področji upravljanja, ekosistema in zaščite.

Zenith Controls jasno pojasni pomen za GDPR in NIS2:

»Brez točne in ažurne evidence sredstev organizacije ne morejo presojati ali uvesti ustreznih zaščitnih ukrepov.«

Za NIS2 popis sredstev podpira identifikacijo kritičnih sistemov in komponent, ki podpirajo bistvene ali pomembne storitve. Za DORA DORA Article 8 postavlja identifikacijo sredstev IKT in informacijskih sredstev v središče operativne odpornosti. Za GDPR popis sredstev podpira mapiranje tokov podatkov, kakovost RoPA in odziv na kršitve.

Podporni standardi ISO potrjujejo isto logiko. ISO/IEC 27005:2024 krepi identifikacijo sredstev pri oceni tveganja informacijske varnosti. ISO 22301:2019 podpira identifikacijo virov, potrebnih za neprekinjeno poslovanje. ISO/IEC 19770-1:2017 podpira zrelost upravljanja IT-sredstev. ISO/IEC 27017:2015 in ISO/IEC 27018:2019 podpirata kontrole, specifične za oblak, in zaščito PII v javnih oblakih. ISO/IEC 27701:2019 razširja upravljanje informacij o zasebnosti. ISO/IEC 29100:2011 prispeva načela zasebnosti, kot so preglednost, minimizacija in varnostni zaščitni ukrepi.

Praktična vaja opredeljevanja obsega za ekipe SaaS in fintech

Začnite z eno regulirano storitvijo, ne s celotnim podjetjem. Na primer: »SaaS za analitiko plačil v EU za finančne institucije.«

Nato pripravite zemljevid od storitve do sredstva in obdelave.

Podrobnejši vzorec sredstev bi lahko izgledal tako.

Nato uporabite Zenith Blueprint korak 13: načrtovanje obravnave tveganj in Izjava o uporabnosti. Vodnik uporabnikom naroča, naj SoA pripravijo s predlogo, ki navaja vse kontrole iz Priloge A, ter se odločijo o uporabnosti na podlagi obravnave tveganj, zakonskih ali pogodbenih zahtev, relevantnosti obsega in organizacijskega konteksta. Navaja:

»Za vsako kontrolo (vrstico) v listu SoA se odločite, ali je uporabna za vaš ISMS.«

Za zgornji primer mora SoA upoštevati kontrole za varnost dobaviteljev, storitve v oblaku, upravljanje incidentov, neprekinjeno poslovanje, zakonske in regulativne zahteve, zasebnost, upravljanje ranljivosti, varnostne kopije, beleženje, spremljanje, kriptografijo, varen razvoj, varnostno testiranje in upravljanje sprememb.

Praktičen delovni tok je:

1. V registru tveganj in gradniku SoA ustvarite zavihek »Mapiranje obsega ISMS«.
2. Dodajte eno vrstico za vsako regulirano storitev ali produktno linijo.
3. Vsako storitev povežite s sredstvi, vrstami podatkov, dobavitelji, lokacijami in lastniki poslovnih procesov.
4. Označite relevantnost za NIS2, relevantnost za DORA in relevantnost obdelave po GDPR.
5. Dodajte scenarije tveganj za nerazpoložljivo storitev, kršitev varnosti osebnih podatkov, odpoved dobavitelja, napačno varnostno konfiguracijo oblaka, kritično ranljivost in neuspešno poročanje o incidentu.
6. Izberite kontrole SoA na podlagi teh tveganj in obveznosti.
7. Dokumentirajte izključitve, kompenzacijske kontrole in sprejem tveganja.
8. Pridobite odobritev najvišjega vodstva za končne meje in izključitve.
9. Končno mejo vključite v notranjo presojo, pregled vodstva in spremljanje dobaviteljev.

Rezultat ni le boljša izjava o obsegu. Je zagovorljiva veriga od regulirane storitve do sredstva, dobavitelja, podatkov, kontrole, lastnika in dokazil.

Mapiranje skladnosti prek več okvirov: en obseg, številne obveznosti

Dobro opredeljen ISMS po ISO 27001 postane operativna plast, kjer je mogoče uskladiti pričakovanja NIS2, DORA, GDPR, NIST CSF in COBIT.

Za kontrolo ISO/IEC 27002:2022 5.31, zakonske, statutarne, regulativne in pogodbene zahteve, Zenith Controls povezuje obveznosti skladnosti z zasebnostjo, zaščito PII, hrambo zapisov, neodvisnim pregledom in notranjo skladnostjo s politikami. Naravno se preslika na odgovornost po GDPR, skladnost dobavne verige po NIS2, upravljanje tveganj IKT in skladnost po DORA, upravljanje po NIST CSF ter spremljanje zunanje skladnosti po COBIT 2019.

Za kontrolo ISO/IEC 27002:2022 5.34, zasebnost in zaščita PII, Zenith Controls povezuje zasebnost s popisom sredstev, storitvami v oblaku, razvrščanjem, prenosom informacij, nadzorom dostopa, upravljanjem identitet in pregledi projektnih sprememb. Njeno mapiranje GDPR zajema varnost obdelave in vgrajeno varstvo podatkov. Njeno mapiranje DORA podpira celovitost, varnost in zaupnost podatkov, vključno z osebnimi podatki, obravnavanimi v storitvah IKT.

Načelo je preprosto: ne ustvarjajte štirih nepovezanih programov skladnosti. Ustvarite en ISMS z opredeljenim obsegom, ki lahko pojasni, kako so obveznosti izpolnjene, podprte z dokazili in preverjene pri presoji.

Obseg poročanja o incidentih: kjer meje vplivajo na regulativne roke

Napačen obseg postane boleče očiten med incidenti.

NIS2 Article 23 zahteva fazno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah, vmesnimi poročili na zahtevo in končnim poročilom v enem mesecu. Morda je zahtevana tudi komunikacija prizadetim prejemnikom.

DORA od finančnih subjektov zahteva, da zaznavajo, upravljajo, razvrščajo in poročajo o večjih incidentih, povezanih z IKT, na podlagi meril, kot so prizadete stranke ali nasprotne stranke, trajanje, izpad, geografska razširjenost, izgube podatkov, kritičnost prizadetih storitev in ekonomski vpliv. Stranke morajo biti brez nepotrebnega odlašanja obveščene, kadar večji incident IKT vpliva na njihove finančne interese.

Obveščanje o kršitvi varnosti osebnih podatkov po GDPR je odvisno od tega, ali kršitev povzroči nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih.

Če so podporna platforma, dnevniško okolje, storitev identitete, kanal za obveščanje strank ali ponudnik upravljanega zaznavanja zunaj obsega ISMS, ekipe za obravnavo incidentov morda ne bodo vedele, ali dogodek sproži poročanje po NIS2, DORA, GDPR, pogodbi s stranko ali po vseh teh podlagah. Ta negotovost porablja čas, namenjen poročanju.

Zrel obseg vključuje odvisnosti, relevantne za incidente: orodja za zaznavanje, hrambo dnevnikov, forenzične repozitorije, komunikacijske kanale s strankami, podporna orodja, okolja za varnostno kopiranje, komunikacijske mostove za obravnavo incidentov in dobavitelje, vključene v triažo ali obnovitev.

Kako bodo presojevalci in nadzorni organi preverjali vaš obseg ISMS

Močan obseg zdrži vzorčenje. Šibek obseg se sesuje, ko presojevalci primerjajo dokumente z dejanskim stanjem.

Zenith Controls zagotavlja uporabna pričakovanja presoje za kontrolo ISO/IEC 27002:2022 5.9. Presojevalci v slogu ISO/IEC 19011 popis zahtevajo zgodaj, da določijo obseg drugih ocenjevanj, ter z naključnimi pregledi preverijo fizična, programska in oblačna sredstva. Presojevalci v slogu ISO/IEC 27007 sprašujejo, kako in kdaj se popis posodablja, ter iščejo povezave z nabavo, upravljanjem sprememb in izločanjem iz uporabe. Presojevalci v slogu NIST SP 800-53A preverjajo, da podrobnosti popisa vključujejo vrsto sredstva, lastnika, lokacijo, omrežni naslov, kjer je ustrezno, in status ter da so vključena sredstva v oblaku, virtualna in mobilna sredstva.

Za kontrolo 5.31 Zenith Controls navaja, da certifikacijski presojevalci pričakujejo evidenco skladnosti ali seznam zakonov in pogodb, sklicevan v SoA in načrtih obravnave tveganj. Presojevalci COBIT iščejo lastnike skladnosti, presoje in poročanje višjemu vodstvu. Presojevalci ISACA ITAF vzorčijo dokazila, da potrdijo, da organizacija svojih obveznosti ne le pozna, temveč aktivno zagotavlja njihovo izpolnjevanje.

Za kontrolo 5.34 presojevalci pregledajo politike zasebnosti, popise podatkov, DPIA, dnevnike usposabljanja, dokazila o šifriranju, kontrole dostopa, vzorce DSAR, dokazila o vgrajenem varstvu zasebnosti in zapise incidentov, ki vključujejo PII. Izjava o obsegu, ki izključuje sistem, ki obdeluje osebne podatke, bo hitro izpodbijana.

Vprašanje organa upravljanja: česa ni mogoče izključiti?

Najvišje vodstvo pogosto sprašuje, ali lahko poslovna enota, lokacija, dobavitelj ali sistem ostane zunaj obsega ISMS. Včasih je odgovor pritrdilen. Vendar ne takrat, kadar izključitev organizaciji preprečuje izpolnjevanje zakonskih, regulativnih, pogodbenih ali varnostnih obveznosti storitve.

Pred odobritvijo katere koli omejitve meje uporabite ta test izključitve:

• Ali enota, sistem ali dobavitelj podpira storitev, regulirano po NIS2?
• Ali podpira kritično ali pomembno funkcijo po DORA za organizacijo ali njene regulirane stranke?
• Ali zbira, hrani, prenaša, beleži, podpira ali briše osebne podatke?
• Ali zagotavlja spremljanje varnosti, identiteto, varnostno kopiranje, odziv na incidente ali obnovitev za storitev v obsegu?
• Ali zagotavlja dokazila, potrebna za razvrstitev incidenta ali regulativno obvestilo?
• Ali pogodba s stranko zahteva, da je zajeto v ISMS?
• Ali bi njegova kompromitacija vplivala na zaupnost, celovitost, razpoložljivost, pravno skladnost ali neprekinjeno izvajanje storitev v navedenem obsegu?

Če je odgovor pritrdilen, izključitev zahteva močna dokazila, kompenzacijsko upravljanje, sprejem tveganja in formalno odobritev najvišjega vodstva. V številnih primerih ne bi smela biti izključena.

Sodoben obseg ISMS po ISO 27001 mora vključevati:

1. Zajete poslovne storitve in produktne linije.
2. Zajete pravne subjekte, organizacijske enote in lokacije.
3. Segmente strank in jurisdikcije, ki ustvarjajo obveznosti.
4. Kritične ali pomembne funkcije ter bistvene storitve na podlagi BIA.
5. Informacijska sredstva, sredstva IKT in okolja v oblaku.
6. Dejavnosti obdelave osebnih podatkov in repozitorije PII.
7. Procese razvoja, testiranja, podpore, spremljanja in obravnave incidentov.
8. Dobavitelje in zunanje izvajane storitve, ki podpirajo storitve v obsegu.
9. Vmesnike in odvisnosti s skupinskimi družbami ali zunanjimi ponudniki.
10. Izrecne izključitve z utemeljitvijo, sprejemom tveganja in odobritvijo najvišjega vodstva.

Tako obseg ISO 27001 postane stališče upravljanja na ravni organa upravljanja, ne certifikacijska bližnjica.

Pripravite obseg ISMS na presojo, preden ga namesto vas opredeli presojevalec

Najslabši trenutek za odkritje težave z obsegom je med certifikacijo, nadzornim pregledom, skrbnim pregledom stranke ali živim incidentom.

Ozek certifikat lahko zadosti nabavnemu kontrolnemu polju, vendar ne bo vzdržal resne presoje, če izključuje storitve, funkcije IKT, dobavitelje in obdelavo osebnih podatkov, ki ustvarjajo regulativno izpostavljenost. V letu 2026 bodo organizacije, ki bodo samozavestno prestale presoje, tiste, ki bodo lahko pokazale enoten zemljevid od regulirane storitve do sredstva, dobavitelja, osebnih podatkov, kontrole, lastnika in dokazil.

Začnite s tremi konkretnimi ukrepi:

1. Uporabite Zenith Blueprint Zenith Blueprint, faza: temelji in vodstvo ISMS, korak 2, za ponovno oblikovanje obsega ISMS okoli storitev, funkcij, obdelave in odvisnosti.
2. Uporabite Zenith Controls Zenith Controls za mapiranje popisa sredstev, zakonskih obveznosti in zaščite PII prek pričakovanj presoje za ISO 27001, NIS2, DORA, GDPR, NIST in COBIT 2019.
3. Uskladite obseg politik s Clarysecovimi Politika informacijske varnosti Politika informacijske varnosti, Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti, Politika upravljanja tveganj Politika upravljanja tveganj, Politika varstva podatkov in zasebnosti Politika varstva podatkov in zasebnosti in Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči.

Če se vaš trenutni obseg ISMS še vedno bere kot oznaka oddelka, ga preoblikujte v mejo skladnosti. Prenesite orodja Clarysec, mapirajte eno regulirano storitev od začetka do konca in pretvorite svoj obseg ISO 27001 v dokazila za NIS2, DORA in GDPR, pripravljena na presojo.