Az ISO 27001-ről sokan úgy gondolják, hogy „bevezetünk pár policy-t, és kész is vagyunk a tanúsításra”, aztán az első hetekben kiderül, hogy valójában a napi működés kezd el átalakulni. Ebben a részben nem definíciókkal megyünk tovább, hanem a gyakorlatban leggyorsabban felbukkanó változásokkal: hol lesz több egyeztetés, mit kell hirtelen tisztázni, és miért kerül elő a dokumentálás újra és újra. A cél egyszerű: tudd előre, mire készülj, és hogyan fordítsd ezeket a „kellemetlen” változásokat a céged javára. (A háttérben végig ugyanaz a logika dolgozik: kockázat-alapú döntések + bizonyítható, ismételhető működés.)
Kezdjük az elején
Az ISO/IEC 27001:2022 standard lényege, hogy nem „érzésből” döntesz: kockázat-alapon priorizálsz, majd következetesen működteted és időről időre felülvizsgálod, amit vállaltál. A dokumentálás itt nem kipipálandó feladat, hanem eszköz: a dokumentált információ és a rekordok (bizonyítékok) azt mutatják meg, hogy a cég ismételhetően, kontrolláltan, biztonságosan működik.
Három változás az első hetekben
1) Hatókör és felelősségek (nem csak IT)
Mi változik? Az egyik legelső kézzelfogható eredmény a dokumentált ISMS-hatókör (scope): leírod, mely telephelyekre, rendszerekre, folyamatokra és információkra terjed ki a rendszer (és majd később az audit), és miért. Ezzel párhuzamosan a vezetőség szerepe és az információbiztonsági felelősségek is kialakulnak: kinek mi a dolga, ki dönt, ki hagy jóvá, ki vállalja a felelősséget.
A „negatívum”: gyorsan kiderül, hogy néhány dolog eddig „mindenkié volt”, ezért valójában senkié (pl. hozzáférések jóváhagyása, beszállítók kezelése, incidensek kommunikációja, stb.).
A pozitív hozadék: tisztább döntési út, kevesebb félreértés, és gyorsabb reagálás. Főleg akkor, amikor baj van, vagy amikor valaki kiesik szabadság/betegség miatt.
Íme egy konkrét példa, hogy ez hogy néz ki a valóságban és mi haszna van:
- Döntés: a CRM rendszer tulajdonosa (pl. Sales vezető) dönti el, milyen szerepkört kapjon az új belépő (pl. „Sales rep” vs. „Team lead”), mert ő tudja, mi kell a munkához és mi számít túl “széles” jogosultsági körnek.
- Jóváhagyás: a rendszertulajdonos jóváhagyja a hozzáférést; ha kivétel van (pl. admin jog), akkor plusz jóváhagyó lehet az ISMS / információbiztonsági felelős (mert ez már kockázati döntés).
- Végrehajtás: IT / Service Desk beállítja a jogosultságot a kért szerepkör szerint, és rögzíti ticketben, ki mikor mit hagyott jóvá (a szerepek/felelősségek és jogosultságok kijelölése a 27001 logikájának része).
És mi ennek a haszna? Nem az IT-nak kell találgatnia (gyorsabb onboarding), kisebb az esély a túl széles jogkör kiosztására (csökken a visszaélés kockázata), kilépéskor ugyanez a nyomvonal visszafelé is működik (gyorsabb offboarding), és vitás helyzetben/auditnál visszakereshető, hogy ki hozta a döntést, ki állította be és mi alapján.
Az eredmény: kevesebb kockázat, több bizonyíték, gyorsabb döntési út és kevesebb félreértésből induló jogvita.
2) Kockázatkezelés + SoA (végre lesz mihez visszanyúlni)
Mi változik? Kötelezően lesz kockázatértékelési módszertanod (hogyan mérsz, milyen skálán, milyen gyakran), és dokumentálod az eredményeket is. A kockázatkezelés része, hogy kiválasztod a kontrollokat, elkészíted a Statement of Applicability-t (SoA – Magyarul: Alkalmazhatósági nyilatkozat), és felépül a kockázatkezelési terv (mit csinálsz, mikorra, ki felel érte).
A „macera”: a „csináljuk, mert így szoktuk” típusú döntések nem állják meg a helyüket önmagukban, indoklás kell, és néha azt is ki kell mondani, hogy valamilyen kockázatot tudatosan elfogadsz, nem kezelsz azonnal. (Például azért, mert annak kezelése költségesebb, mint maga a kár amit okozhat)
A pozitívum: a SoA és a kockázati nyilvántartás olyan, mint egy térkép: új ügyfél, új rendszer, új beszállító, audit vagy vezetői kérdés esetén nem emlékezetből vitáztok, hanem előveszitek, hogy miért döntöttetek így.
Hogy néz ki ez a gyakorlatban?
Vegyük azt a helyzetet, hogy a cég MS365 környezetében jelenleg nem kötelező az MFA (több faktoros autentikáció) az e-mail fiókokon. Ilyenkor nagyobb az esélye a fiókátvételnek, ami pénzügyi jóváhagyások és utalások eltérítéséhez (BEC), illetve bizalmas céges adatok kiszivárgásához vezethet.
- Risk owner: pénzügyi vezető (üzleti hatás) és IT vezető (technikai felelősség).
- Döntés: kezeljük a kockázatot (nem fogadjuk el).
- Intézkedés: 30 napon belül kötelező MFA minden fiókra; legacy autentikáció tiltása; a közösen használt fiókok megszüntetése.
- Felelős / határidő: IT vezető, 30 nap.
Vagyis azonosítottunk egy konkrét kockázatot, kijelöltük a felelős(öke)t, meghoztuk a döntést annak kezelésére, és létrehoztunk egy egyszerű akciótervet határidővel és felelőssel. Ez később azért segít, mert nem csak „bevezettünk valamit”, hanem visszakövethető, hogy miért döntöttünk így, mikor, ki hagyta jóvá, és mi bizonyítja, hogy a kontroll tényleg működik.
3) „Többet kell dokumentálni” – igen, de ettől lesz skálázható
Mi változik? A 27001 elvárja, hogy kezeld a dokumentált információt (pl. verzió, jóváhagyás, hozzáférés, megőrzés), és tudd bizonyítani, hogy a szükséges rekordok megvannak (pl. kompetencia, monitoring eredmények, belső auditok, vezetőségi átvizsgálás). A gyakorlatban ez hoz egy „dokumentum életciklus” logikát: ez könnyen besorolhatóvá teszi, hogy mi policy, mi eljárás, mi munkautasítás, mi pedig csak egy egyszerű record (jegyzőkönyv, ticket, screenshot).
A „negatívum”: az elején lassabbnak fog tűnni, mert sablonokat, felelősöket és egy minimális jóváhagyási rendet kell kialakítani.
A pozitívum: amikor nő a cég, új ember jön, vagy valaki kilép, a tudás nem a fejekben marad; a változások visszakövethetők, és az audit sem „pánik projekt” lesz.
A fentiek még csak néhány példa azokból a változásokból, amelyek egy szervezet életében megjelennek, amikor ISO 27001-ben kezd gondolkodni. Ezeket most szándékosan általánosságban fogtuk meg, de bízunk benne, hogy segítettek elhelyezni a képet: nagyjából milyen jellegű átalakulásokra számíthatsz, ha belevágsz az ISO 27001 szerinti rendszer felépítésébe és működtetésébe.
Elsőre könnyen tűnhet komplexnek és nehezen követhetőnek, de idővel egy jól átlátható keretrendszerré áll össze, ami rendet tesz a döntésekben és a napi működésben. Ennek a hozadéka tipikusan nem csak a nagyobb biztonság, hanem a gyorsabb működés, a könnyebb tudásátadás, a stabilabb üzem és a kiszámíthatóbb növekedés is. Ha ezeket lépésről lépésre vezeted be, a céged stabilabb alapokra kerülhet, és a növekedés is jóval kezelhetőbbé válik.
Ha szeretnéd ezt a folyamatot magabiztosan, a céged méretéhez és működéséhez igazítva felépíteni, a Manawize ebben is tud segíteni: abban, hogy a folyamataid átalakítása ne „papíron” történjen, hanem valóban működő, stabil rendszerré álljon össze – úgy, hogy közben a legköltséghatékonyabb és legoptimálisabb döntéseket tudd meghozni.
Ha tetszett a cikk, vagy hasznosnak találtad az információkat, kövess minket a blogon és a social media felületeinken is, hogy ne maradj le a következő részekről.
