Procjena rizika prema ISO 27001 spremna za reviziju za NIS2 i DORA
Kava na Sarinu stolu bila je hladna.
Kao CISO brzorastućeg fintech društva, bila je naviknuta na pritisak. Društvo je upravo dobilo važnog bankarskog partnera, a upitnik za dubinsku analizu dobavljača na njezinu zaslonu trebao je biti formalnost. Prva su pitanja bila poznata: dostavite ISO/IEC 27001:2022 Izjavu o primjenjivosti, podijelite najnoviji registar rizika, objasnite metodologiju procjene rizika.
Zatim se upitnik promijenio.
Dokažite kako vaš program upravljanja rizicima adresira DORA. Objasnite svoju spremnost za Direktivu NIS2, uključujući odgovornost uprave i mjere za rizike u opskrbnom lancu. Dostavite dokaze da se kritični IKT dobavljači procjenjuju, prate i obuhvaćaju planovima odgovora na incidente i kontinuiteta poslovanja.
Do ponedjeljka ujutro isto se pitanje našlo na dnevnom redu odbora za rizike pri upravnom odboru. Certifikacijska revizija ISO 27001 bila je za osam tjedana. Klijenti iz financijskog sektora pojačavali su pritisak vezan uz DORA. Pitanja o klasifikaciji prema NIS2 pojavila su se zbog uslužne linije u oblaku koja se širila u EU. Nabava je tvrdila da pregledi dobavljača postoje, ali dokazi su bili raspršeni po e-pošti, mapama ugovora i proračunskoj tablici dobavljača. Pravni poslovi rekli su da je regulatorno mapiranje još u tijeku. Inženjering je rekao da je registar rizika uglavnom dovršen.
Upravni odbor postavio je jedino pitanje koje je bilo važno:
Možemo li dokazati da su naša procjena rizika i plan obrade rizika dostatni?
To je stvarni problem za SaaS, fintech, pružatelje upravljanih usluga, oblak i društva koja upravljaju digitalnim platformama. Nije pitanje postoji li registar rizika. Nije pitanje jesu li kontrole iz Priloga A kopirane u proračunsku tablicu. Problem je može li organizacija pod pritiskom revizije i klijenata dokazati da je njezin proces procjene rizika prema ISO 27001 ponovljiv, utemeljen na riziku, odobren od vlasnika rizika, povezan s radnjama obrade rizika, mapiran na pravne obveze i operativno živ.
Ako se provede dobro, jedna procjena rizika prema ISO 27001 i jedan plan obrade rizika mogu podržati ISO/IEC 27001:2022 certifikaciju, mjere upravljanja kibernetičkim rizicima iz NIS2 Article 21, zahtjeve DORA za upravljanje IKT rizicima, odgovornost prema GDPR, dokazivanje sigurnosti dobavljača, spremnost za incidente i izvješćivanje upravnom odboru.
Ako se provede loše, pretvara se u proračunsku tablicu koju će revizori rastaviti za trideset minuta.
Ovaj vodič pokazuje kako Clarysec izrađuje dokaze procjene rizika i obrade rizika prema ISO 27001 spremne za reviziju koristeći Zenith Blueprint: revizorov plan u 30 koraka, Clarysec politike i Zenith Controls: vodič za unakrsnu usklađenost.
Zašto je procjena rizika prema ISO 27001 sada središte usklađenosti
Regulatorno okruženje EU konvergira oko jednostavnog načela: kibernetičkim rizikom mora se upravljati, mora biti dokumentiran, testiran i dodijeljen odgovornim vlasnicima.
ISO/IEC 27001:2022 već funkcionira na taj način. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije svoj kontekst, zainteresirane strane, opseg ISMS-a i međudjelovanje procesa prije procjene rizika. Točke 6.1.2 i 6.1.3 zahtijevaju definiran proces procjene i obrade rizika informacijske sigurnosti. Točke 8.2 i 8.3 zahtijevaju da organizacija provodi procjene rizika i implementira plan obrade rizika uz čuvanje dokumentiranih informacija.
NIS2 i DORA istu logiku utemeljenu na riziku čine hitnijom.
NIS2 Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja kibernetičkim rizicima, nadziru njihovu implementaciju i sudjeluju u osposobljavanju o kibernetičkoj sigurnosti. Article 21 zahtijeva primjerene i razmjerne tehničke, operativne i organizacijske mjere za upravljanje rizicima za mrežne i informacijske sustave. Te mjere uključuju analizu rizika, postupanje s incidentima, kontinuitet poslovanja, sigurnost opskrbnog lanca, siguran razvoj, postupanje s ranjivostima, procjenu djelotvornosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom te višefaktorsku autentifikaciju ili sigurne komunikacije, gdje je primjenjivo.
DORA stvara sličan pritisak na financijske subjekte. Articles 5 and 6 zahtijevaju da upravljačko tijelo definira, odobri, nadzire i ostane odgovorno za aranžmane upravljanja IKT rizicima. DORA očekuje dokumentirani okvir za upravljanje IKT rizicima integriran u cjelokupno upravljanje rizicima, podržan politikama, postupcima, protokolima, alatima, internom revizijom, korektivnim radnjama, kontinuitetom poslovanja, testiranjem, upravljanjem incidentima i upravljanjem IKT trećim stranama.
Zaključak je praktičan i neizbježan: registar rizika više nije radni list tehničkog tima. On je dokaz upravljanja.
Clarysecova Enterprise Politika upravljanja rizicima jasno postavlja to očekivanje:
Formalni proces upravljanja rizicima mora se održavati u skladu s ISO/IEC 27005 i ISO 31000 te obuhvaćati identifikaciju, analizu, vrednovanje, obradu, praćenje i komunikaciju rizika.
Iz Enterprise Politike upravljanja rizicima, odjeljak „Zahtjevi upravljanja”, klauzula politike 5.1.
Ista politika definira ishod spreman za reviziju:
Održavati centralizirani, verzionirani Registar rizika i Plan obrade rizika koji odražavaju trenutačni status rizika, obuhvat kontrola i napredak u ublažavanju rizika.
Iz Enterprise Politike upravljanja rizicima, odjeljak „Ciljevi”, klauzula politike 3.3.
Ta formulacija, „trenutačni status rizika, obuhvat kontrola i napredak u ublažavanju rizika”, razlikuje statičnu datoteku za usklađenost od dokazivog programa upravljanja rizicima.
Počnite s opsegom, obvezama i kriterijima rizika
Mnoge slabe procjene rizika prema ISO 27001 započinju kontrolnim popisom kontrola. To je pogrešan redoslijed.
ISO 27001 zahtijeva da organizacija utvrdi kontekst, zahtjeve zainteresiranih strana, opseg ISMS-a, odgovornosti vodstva i planiranje rizika prije odabira kontrola. ISO/IEC 27005:2022 to dodatno potvrđuje preporukom da organizacije identificiraju osnovne zahtjeve zainteresiranih strana prije procjene rizika. Ti zahtjevi mogu proizlaziti iz ISO standarda, sektorskih propisa, nacionalnih zakona, ugovora s klijentima, internih politika, prethodnih aktivnosti obrade rizika i obveza prema dobavljačima.
Za SaaS ili fintech društvo usmjereno na tržište EU, proces upravljanja rizicima treba započeti popisom obveza usklađenosti.
| Izvor zahtjeva | Zašto utječe na procjenu rizika prema ISO 27001 | Artefakt dokaza |
|---|---|---|
| ISO/IEC 27001:2022 točke 4, 5, 6, 8, 9 i 10 | Definira kontekst, vodstvo, procjenu rizika, obradu rizika, operativnu kontrolu, vrednovanje učinkovitosti i poboljšanje | Opseg ISMS-a, metodologija rizika, registar rizika, plan obrade rizika, SoA, zapisi preispitivanja od strane uprave |
| NIS2 Articles 20, 21, and 23 | Dodaje odgovornost uprave, mjere kibernetičke sigurnosti za sve vrste opasnosti i očekivanja u vezi s prijavljivanjem incidenata | Odobrenje upravnog odbora, mapiranje Article 21, operativne upute za prijavljivanje incidenata, dokazi kontinuiteta poslovanja |
| DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30 | Zahtijeva upravljanje IKT rizicima, kontinuitet poslovanja, sigurnosne kopije i oporavak podataka, životni ciklus incidenata, testiranje i kontrole rizika IKT trećih strana | Okvir IKT rizika, testovi BCP-a, registar incidenata, zapisi testiranja otpornosti, registar IKT dobavljača |
| GDPR Articles 3, 4, 5, 6, 9, 10, 25, 32, 33, and 34 | Zahtijeva odgovornost, zakonitu obradu, ugrađenu zaštitu podataka, primjerenu sigurnost i procjenu povrede | Popis podataka, mapiranje pravne osnove, unosi rizika privatnosti, poveznice na DPIA, zapisi procjene povrede |
| Ugovori s dobavljačima i klijentima | Pretvara komercijalna obećanja u kriterije rizika, kontrole, dokaze i rokove | Registar ugovora, zapisi dubinske analize dobavljača, prava na reviziju, SLA-ovi, odredbe o izlasku |
Za MSP-ove, Clarysecova Politika pravne i regulatorne usklađenosti - SME postavlja početnu točku:
Glavni direktor mora održavati jednostavan, strukturiran Registar usklađenosti koji navodi:
Iz SME Politike pravne i regulatorne usklađenosti, odjeljak „Zahtjevi upravljanja”, klauzula politike 5.1.1.
Taj jednostavni registar most je između usklađenosti i upravljanja rizicima. Ako navodi da se GDPR primjenjuje jer se obrađuju osobni podaci iz EU, da se NIS2 može primijeniti jer organizacija pruža digitalne ili upravljane usluge ili da je DORA relevantna zbog klijenata iz financijskog sektora, te obveze moraju utjecati na kriterije rizika i prioritete obrade rizika.
Zenith Blueprint izravan je o tome u fazi upravljanja rizicima, korak 10, „Uspostava kriterija rizika i matrice utjecaja”:
U kriterijima prihvata razmotrite i pravne/regulatorne zahtjeve. Neki rizici mogu biti neprihvatljivi neovisno o vjerojatnosti zbog zakona.
Iz Zenith Blueprinta, faza upravljanja rizicima, korak 10.
Daje i praktično pravilo za radionice:
„Svaki rizik koji bi mogao dovesti do neusklađenosti s primjenjivim zakonima (GDPR itd.) nije prihvatljiv i mora se ublažiti.”
Iz Zenith Blueprinta, faza upravljanja rizicima, korak 10.
Za Sarino fintech društvo to mijenja model bodovanja. Ranjivost API-ja dobavljača može imati nisku vjerojatnost, ali ako bi iskorištavanje moglo pokrenuti veliki IKT incident povezan s DORA, značajan NIS2 incident, procjenu povrede prema GDPR-u, neispunjenje SLA-a prema klijentu ili eskalaciju na razini upravnog odbora, utjecaj je visok ili kritičan. Izloženost usklađenosti postaje dio logike rizika, a ne zasebna proračunska tablica.
Izradite registar rizika koji revizori mogu testirati
Revizori ne pitaju samo koji su vaši najveći rizici. Oni testiraju je li vaša metoda definirana, ponovljiva, sljediva i primijenjena.
Pitat će:
- Kako ste identificirali ove rizike?
- Koja imovina, usluge, dobavljači, vrste podataka i procesi bili su u opsegu?
- Koji su kriteriji korišteni za vjerojatnost i utjecaj?
- Tko je vlasnik svakog rizika?
- Koje postojeće kontrole smanjuju rizik?
- Zašto je odabrana ta odluka o obradi rizika?
- Gdje su dokazi da je obrada provedena?
- Tko je odobrio preostali rizik?
- Kada će rizik biti ponovno procijenjen?
Clarysecova Politika upravljanja rizicima - SME obuhvaća minimalni unos rizika spreman za reviziju:
Svaki unos rizika mora sadržavati: opis, vjerojatnost, utjecaj, ocjenu, vlasnika i plan obrade rizika.
Iz SME Politike upravljanja rizicima, odjeljak „Zahtjevi upravljanja”, klauzula politike 5.1.2.
Za enterprise programe, faza upravljanja rizicima u Zenith Blueprintu, korak 11, „Izrada i dokumentiranje registra rizika”, proširuje strukturu. Preporučuje stupce kao što su ID rizika, imovina, prijetnja, ranjivost, opis rizika, vjerojatnost, utjecaj, razina rizika, postojeće kontrole, vlasnik rizika, odluka o obradi rizika, plan obrade rizika ili kontrole te status.
Snažan unos rizika izgleda ovako:
| Polje | Primjer unosa |
|---|---|
| ID rizika | R-042 |
| Imovina ili proces | Obrada podataka klijenata putem API-ja treće strane za plaćanja i produkcijske baze podataka |
| Prijetnja | Iskorištavanje kritične ranjivosti u API-ju dobavljača ili pratećoj usluzi baze podataka u oblaku |
| Ranjivost | Ograničena vidljivost upravljanja ranjivostima dobavljača, nepotpuno testiranje oporavka podataka i nepostojanje testiranih operativnih uputa za povredu kod dobavljača |
| Opis rizika | Kompromitacija dobavljača ili usluge u oblaku mogla bi izložiti financijske podatke, prekinuti uslugu, pokrenuti regulatorno izvješćivanje i dovesti do povrede ugovora s klijentima |
| Postojeće kontrole | SSO, pristup temeljen na ulogama, ugovor s dobavljačem, zapisivanje događaja u produkciji, dnevne sigurnosne kopije, tromjesečni pregled pristupa |
| Vjerojatnost | Srednja |
| Utjecaj | Kritičan |
| Razina rizika | Kritična |
| Vlasnik rizika | CTO i voditelj platformskog inženjeringa |
| Odluka o obradi rizika | Ublažiti |
| Regulatorno mapiranje | Kontrole ISO 27001 Priloga A za dobavljače, oblak, incidente, zapisivanje događaja, pristup, kontinuitet poslovanja, sigurnosno kopiranje i pravnu usklađenost; NIS2 Articles 20, 21, and 23; DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30; GDPR Articles 32, 33, and 34 |
| Dokazi | Dubinska analiza dobavljača, zahtjev za ostvarivanje prava na reviziju, izvješće o testu oporavka podataka, SIEM pravilo praćenja, stolna vježba incidenta, ažurirani SoA, zapisnik preispitivanja od strane uprave |
To je bitno drukčije od „rizik treće strane, visok, ublažiti”. Verzija spremna za reviziju povezuje imovinu, prijetnju, ranjivost, posljedicu, postojeće kontrole, vlasnika, regulativu, dokaze i upravljanje.
Pretvorite obradu rizika u plan dokaza
Plan obrade rizika mora odgovoriti na četiri operativna pitanja:
- Što ćemo učiniti?
- Tko je vlasnik aktivnosti?
- Kada će biti dovršeno?
- Kako ćemo dokazati da je rizik smanjen?
ISO/IEC 27001:2022 točka 6.1.3 zahtijeva da organizacija odabere opcije obrade rizika, utvrdi potrebne kontrole, usporedi ih s Prilogom A kako bi izbjegla propuste, izradi Izjavu o primjenjivosti, formulira plan obrade rizika i pribavi odobrenje vlasnika rizika za plan i preostale rizike. Točka 8.3 zatim zahtijeva implementaciju plana obrade rizika i čuvanje dokumentiranih informacija o rezultatima.
Enterprise Politika upravljanja rizicima to čini praktičnim:
Službenik za rizike mora osigurati da su obrade rizika realistične, vremenski ograničene i mapirane na kontrole ISO/IEC 27001 Priloga A.
Iz Enterprise Politike upravljanja rizicima, odjeljak „Zahtjevi za provedbu politike”, klauzula politike 6.4.2.
SME politika također pojašnjava da prihvaćanje nije prečac:
Prihvatiti: obrazložiti zašto nije potrebna dodatna radnja i evidentirati preostali rizik.
Iz SME Politike upravljanja rizicima, odjeljak „Zahtjevi za provedbu politike”, klauzula politike 6.1.1.
Prihvaćanje mora biti obrazloženo prema kriterijima, odobreno od odgovarajućeg vlasnika i praćeno. Prema NIS2 i DORA, neodobreni preostali rizik može postati propust u upravljanju.
Cjelovit plan obrade rizika trebao bi sadržavati ova polja:
| Polje obrade rizika | Revizijska svrha |
|---|---|
| ID rizika | Povezuje obradu s procijenjenim rizikom |
| Opcija obrade rizika | Prikazuje obrazloženje: ublažiti, izbjeći, prenijeti ili prihvatiti |
| Odabrane kontrole | Povezuje rizik s Prilogom A, politikama i tehničkim zaštitnim mjerama |
| Regulatorni pokretač | Prikazuje relevantnost za NIS2, DORA, GDPR, ugovor ili klijenta |
| Vlasnik aktivnosti | Dokazuje odgovornost |
| Krajnji rok | Čini obradu vremenski ograničenom |
| Dokazi implementacije | Pokazuju da je aktivnost dovršena |
| Mjera djelotvornosti | Pokazuje je li smanjena vjerojatnost ili utjecaj |
| Preostali rizik | Pokazuje preostalu izloženost |
| Odobrenje vlasnika rizika | Dokazuje prihvaćanje i upravljanje |
Za Sarin R-042, plan obrade rizika postaje popis radnji za unakrsnu usklađenost.
| ID rizika | Radnja obrade rizika | Referenca ISO/IEC 27001:2022 Priloga A | Relevantnost za NIS2 | Relevantnost za DORA | Vlasnik | Dokazi |
|---|---|---|---|---|---|---|
| R-042 | Ostvariti prava na reviziju dobavljača i zatražiti dokaze o upravljanju ranjivostima | 5.19, 5.20, 5.21, 5.22, 5.31 | Article 21(2)(d) sigurnost opskrbnog lanca | Articles 28 and 30 rizik IKT trećih strana i ugovori | CTO i voditelj nabave | Zahtjev za reviziju, odgovor dobavljača, pregled ugovora |
| R-042 | Implementirati pojačano praćenje anomalne aktivnosti API-ja i aktivnosti s povišenim ovlastima | 8.15, 8.16, 5.16, 5.17, 5.18 | Article 21(2)(i) kontrola pristupa i upravljanje imovinom | Articles 6 and 17 IKT rizik i upravljanje incidentima | Voditelj centra sigurnosnih operacija (SOC) | SIEM pravilo, test upozorenja, pregled pristupa |
| R-042 | Testirati oporavak iz sigurnosne kopije i definirati RTO i RPO na razini usluge | 5.30, 8.13, 8.14 | Article 21(2)(c) kontinuitet poslovanja i sigurnosno kopiranje | Articles 11 and 12 odgovor, oporavak, sigurnosno kopiranje i oporavak podataka | Voditelj platformskog inženjeringa | Izvješće o oporavku podataka, odobrenje RTO-a i RPO-a |
| R-042 | Provesti stolnu vježbu povrede kod dobavljača | 5.24, 5.26, 5.27, 5.29 | Articles 21(2)(b) and 23 postupanje s incidentima i izvješćivanje | Articles 17, 18, 19, and 24 upravljanje incidentima, klasifikacija, izvješćivanje i testiranje | CISO | Zapis stolne vježbe, naučene lekcije, alat za praćenje korektivnih radnji |
| R-042 | Ažurirati SoA i odobrenje preostalog rizika | 5.4, 5.31, 5.35 | Article 20 odgovornost uprave | Articles 5 and 6 upravljanje i okvir IKT rizika | CISO i vlasnik rizika | Ažurirani SoA, zapis odobrenja, zapisnik preispitivanja od strane uprave |
Ovaj je plan snažan jer stvara izravnu liniju od jednog scenarija rizika do kontrola ISO 27001, obveza NIS2, članaka DORA, vlasnika i dokaza.
Neka Izjava o primjenjivosti radi više
Izjava o primjenjivosti često se tretira kao certifikacijski artefakt. Trebala bi biti više od toga.
ISO/IEC 27001:2022 točka 6.1.3 zahtijeva da SoA sadržava potrebne kontrole, obrazloženje uključivanja, status implementacije i obrazloženje isključenja. Smjernice ISO/IEC 27005:2022 dodatno potvrđuju potrebu usporedbe odabranih kontrola s ISO/IEC 27001 Prilogom A radi izbjegavanja propusta.
U programu spremnom za reviziju, SoA postaje most između obrade rizika i dokaza unakrsne usklađenosti. Ako plan obrade rizika zahtijeva MFA, zapisivanje događaja, praćenje dobavljača, oporavak iz sigurnosne kopije, siguran razvoj, eskalaciju incidenta ili planiranje izlaska iz oblaka, SoA treba pokazati da su relevantne kontrole Priloga A uključene, obrazložene, implementirane ili planirane te potkrijepljene dokazima.
To također pomaže izbjeći čest revizijski neuspjeh: registar rizika govori jedno, plan obrade rizika drugo, a SoA šuti. Kada se ti artefakti ne podudaraju, revizori brzo gube povjerenje.
Mapiranje obrade rizika prema ISO 27001 na NIS2, DORA i GDPR
ISO 27001 ne zamjenjuje NIS2, DORA ili GDPR. On vam daje strukturirani mehanizam za izradu dokaza za njih.
Ključno je ugraditi mapiranje u proces upravljanja rizicima, a ne dodavati ga naknadno.
| Dokaz obrade rizika prema ISO 27001 | Relevantnost za NIS2 | Relevantnost za DORA | Relevantnost za GDPR |
|---|---|---|---|
| Kriteriji rizika s bodovanjem regulatornog utjecaja | Podržava razmjerne mjere upravljanja kibernetičkim rizicima iz Article 21 | Podržava proporcionalnost, upravljanje i okvir IKT rizika iz Articles 4, 5, and 6 | Podržava odgovornost i primjerenu sigurnost |
| Registar rizika s vlasnicima i CIA utjecajem | Podržava nadzor uprave iz Article 20 i analizu rizika iz Article 21 | Podržava dokumentirano upravljanje IKT rizicima i vlasništvo | Podržava dokazivanje svijesti o rizicima za osobne podatke |
| Plan obrade rizika mapiran na Prilog A | Podržava mjere iz Article 21 u područjima incidenata, kontinuiteta poslovanja, dobavljača, pristupa, ranjivosti i sigurnog razvoja | Podržava IKT kontrole, upravljanje incidentima, kontinuitet poslovanja, testiranje i otpornost trećih strana | Podržava tehničke i organizacijske mjere prema Article 32 |
| Unosi rizika dobavljača i ugovorne kontrole | Podržava sigurnost opskrbnog lanca iz Article 21(2)(d) | Podržava zahtjeve za rizik IKT trećih strana i ugovore iz Articles 28 and 30 | Podržava zaštitne mjere za izvršitelje obrade i prijenose gdje je primjenjivo |
| Scenariji incidenata i operativne upute za izvješćivanje | Podržava radni tok prijavljivanja značajnih incidenata iz Article 23 | Podržava upravljanje incidentima, klasifikaciju i izvješćivanje iz Articles 17, 18, and 19 | Podržava procjenu prijave povrede iz Articles 33 and 34 |
| BCP, sigurnosno kopiranje i obrade oporavka | Podržava kontinuitet poslovanja, sigurnosno kopiranje, oporavak od katastrofe i krizno upravljanje iz Article 21(2)(c) | Podržava odgovor, oporavak, sigurnosno kopiranje i oporavak podataka iz Articles 11 and 12 | Podržava dostupnost i otpornost gdje su uključeni osobni podaci |
| Pregledi djelotvornosti kontrola | Podržava procjenu djelotvornosti iz Article 21(2)(f) | Podržava očekivanja testiranja i korektivnih radnji iz Article 24 | Podržava kontinuiranu odgovornost |
Ovo je mapiranje osobito važno ondje gdje se propisi preklapaju. DORA je sektorski specifičan režim IKT otpornosti za mnoge financijske subjekte, dok NIS2 može ostati izravno relevantan za određene pružatelje usluga, koordinaciju ili subjekte izvan opsega DORA. Fintech društvo može trebati DORA kao svoj primarni okvir IKT otpornosti, dok pružatelj upravljanih usluga koji podržava to fintech društvo može izravno podlijegati obvezama NIS2.
Registar rizika mora moći prikazati obje strane te ovisnosti.
Koristite Zenith Controls kao kompas za unakrsnu usklađenost
Clarysec koristi Zenith Controls kao vodič za unakrsnu usklađenost kako bi spriječio čest neuspjeh u kojem ISO kontrole, regulatorni članci i revizijska pitanja žive u odvojenim svjetovima. Ne stvara zaseban okvir kontrola. Mapira područja kontrola ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na druge standarde, revizijska očekivanja i perspektive usklađenosti.
Za procjenu i obradu rizika prema ISO 27001 ove su reference osobito važne:
| Referenca ISO/IEC 27001:2022 Priloga A korištena u Zenith Controls | Zašto je važna za procjenu i obradu rizika | Atributi obuhvaćeni u Zenith Controls |
|---|---|---|
| 5.4 Odgovornosti uprave | Povezuje vlasništvo nad obradom rizika s upravljanjem, jasnoćom uloga i odgovornošću | Preventivna kontrola, podržava povjerljivost, cjelovitost i dostupnost, mapira se na Identify, Governance, Governance and Ecosystem |
| 5.31 Zakonski, regulatorni i ugovorni zahtjevi | Povezuje registar usklađenosti s kriterijima rizika, odlukama o obradi rizika i uključivanjem u SoA | Preventivna kontrola, podržava povjerljivost, cjelovitost i dostupnost, mapira se na Identify, Legal and Compliance, Governance, Ecosystem i Protection |
| 5.35 Neovisni pregled informacijske sigurnosti | Povezuje internu reviziju, vanjsku reviziju i potvrde uprave s djelotvornošću obrade rizika | Preventivna i korektivna kontrola, podržava povjerljivost, cjelovitost i dostupnost, mapira se na Identify i Protect, Information Security Assurance, Governance and Ecosystem |
Pouka unakrsne usklađenosti jednostavna je. Ako pravne obveze nisu u metodi procjene rizika, bodovanje je nepotpuno. Ako je bodovanje nepotpuno, prioriteti obrade rizika mogu biti pogrešni. Ako su prioriteti pogrešni, SoA i izvješćivanje upravnom odboru postaju nepouzdani.
Zenith Blueprint iznosi istu poantu u fazi upravljanja rizicima, korak 14, „Politike obrade rizika i regulatorne unakrsne reference”. Savjetuje organizacijama izradu tablice mapiranja koja navodi ključne regulatorne sigurnosne zahtjeve i odgovarajuće kontrole ili politike u ISMS-u. To nije obvezno za ISO 27001 certifikaciju, ali je vrlo korisno za dokazivanje da se sigurnošću upravlja u pravnom i ugovornom kontekstu.
Što će pitati različiti revizori
Certifikacijski revizor, NIS2 pregledavatelj, klijent usmjeren na DORA, GDPR pregledavatelj, NIST procjenitelj ili COBIT praktičar mogu ispitivati iste dokaze, ali postavljati različita pitanja.
| Perspektiva revizora | Tipično revizijsko pitanje | Dokazi koje očekuju |
|---|---|---|
| ISO 27001 revizor | Je li metoda procjene rizika definirana, ponovljiva, primijenjena i povezana s obradom rizika i SoA? | Metodologija rizika, kriteriji, registar, SoA, plan obrade rizika, odobrenja preostalih rizika |
| NIS2 usmjereni pregledavatelj | Obuhvaćaju li mjere kibernetičke sigurnosti područja iz Article 21 i odgovornost uprave? | Odobrenja upravnog odbora, mapiranje Article 21, operativne upute za incidente, dokazi kontinuiteta poslovanja, dokazi rizika dobavljača |
| DORA usmjereni pregledavatelj | Je li upravljanje IKT rizicima dokumentirano, uređeno, testirano i prošireno na IKT treće strane? | Okvir IKT rizika, proces klasifikacije incidenata, testovi BCP-a, testiranje otpornosti, registar IKT dobavljača |
| GDPR pregledavatelj | Može li organizacija dokazati primjerenu sigurnost i odgovornost za rizike povezane s osobnim podacima? | Popis podataka, mapiranje pravne osnove, postupak procjene povrede, dokazi obrade rizika privatnosti |
| NIST usmjereni procjenitelj | Jesu li rizici identificirani, postoje li mjere zaštite, otkrivanja, odgovora i oporavka putem mjerljivih kontrola? | Scenariji rizika, popis imovine, implementacija kontrola, praćenje, zapisi odgovora i oporavka |
| COBIT ili ISACA revizor | Je li upravljanje rizicima usklađeno s ciljevima organizacije, ulogama, učinkom, osiguranjem i izvješćivanjem uprave? | Zapisnici upravljačkih tijela, RACI, KRI-jevi, nalazi interne revizije, praćenje korektivnih radnji, nadzorne ploče za upravljanje |
Zato je arhitektura dokaza važna. Isti unos rizika treba biti sljediv od poslovnog cilja do imovine, prijetnje, ranjivosti, kontrole, vlasnika, regulatornog pokretača, radnje obrade rizika, rezultata testiranja i odluke uprave.
Clarysec politike osmišljene su za podršku toj arhitekturi. Enterprise Politika upravljanja rizicima u odjeljku „Referentni standardi i okviri” navodi:
Article 5: nalaže dokumentirani okvir za upravljanje IKT rizicima, u cijelosti obuhvaćen strukturom ove politike, uključujući mapiranje SoA i KRI-jeve.
To pretvara politiku iz statičnog dokumenta u revizijski dokaz da je upravljanje IKT rizicima namjerno osmišljeno imajući DORA na umu.
Česti nalazi koji narušavaju programe upravljanja rizicima
Kada Clarysec pregledava dokaze procjene rizika i obrade rizika prema ISO 27001, isti se nalazi ponavljaju.
Prvo, kriteriji rizika zanemaruju pravni, regulatorni, ugovorni, dobavljački i privatnosni utjecaj. To uzrokuje slabo bodovanje. Povreda osobnih podataka ili otkaz kritičnog dobavljača mogu biti ocijenjeni srednje jer je vjerojatnost niska, iako bi utjecaj prema GDPR-u, NIS2, DORA ili klijentima trebao ocjenu učiniti visokom ili kritičnom.
Drugo, vlasnici rizika su generički. „IT” nije vlasnik rizika. Vlasnik rizika treba biti uloga ili osoba odgovorna za odluke o obradi rizika, proračun, rokove i preostali rizik.
Treće, planovi obrade rizika nisu vremenski ograničeni. „Poboljšati praćenje” nije plan. „Do 30. lipnja u SIEM-u uvesti upozorenja za privilegirane sesije za produkcijske administratorske račune, pod odgovornošću voditelja centra sigurnosnih operacija (SOC), testirano simuliranom administratorskom prijavom, uz priložene dokaze upozorenja” jest plan.
Četvrto, SoA nije povezan s obradom rizika. Ako plan obrade rizika zahtijeva praćenje dobavljača, testiranje sigurnosnih kopija, eskalaciju incidenta, MFA ili zapisivanje događaja, SoA treba odražavati relevantne kontrole i status implementacije.
Peto, preostali rizik nije odobren. ISO 27001 zahtijeva odobrenje vlasnika rizika za plan obrade rizika i preostale rizike. NIS2 i DORA to čine još važnijim jer je odgovornost uprave izričita.
Šesto, rizik dobavljača tretira se kao administracija nabave. Prema NIS2 Article 21(2)(d) i DORA Articles 28 and 30, rizik dobavljača i IKT trećih strana mora biti dio upravljanja rizicima, a ne godišnji upitnik pohranjen u izolaciji.
Sedmo, ne postoje dokazi o djelotvornosti. ISO 27001 točka 6.1.1 zahtijeva da se planirane radnje vrednuju u pogledu djelotvornosti. NIS2 uključuje procjenu djelotvornosti u Article 21(2)(f). DORA očekuje testiranje i korektivne radnje. Kontrola koja postoji, ali se nikada ne testira, slab je dokaz.
SME Politika upravljanja rizicima - SME jasno postavlja očekivanje:
Glavni direktor i koordinator za rizike moraju osigurati da su aktivnosti upravljanja rizicima spremne za reviziju. Registar rizika i povezane radnje podliježu internoj i vanjskoj reviziji.
Iz SME Politike upravljanja rizicima, odjeljak „Provedba i usklađenost”, klauzula politike 8.2.1.
Izvješćivanje upravnom odboru bez zatrpavanja rukovodstva
NIS2, DORA i ISO 27001 upućuju na odgovornost uprave, ali upravnim odborima nije potreban svaki redak rizika. Potrebno im je izvješćivanje korisno za odlučivanje.
Dobar paket rizika za upravni odbor trebao bi prikazati:
- Visoke i kritične rizike po domeni
- Zakašnjele radnje obrade rizika
- Regulatorne rizike koji uključuju NIS2, DORA, GDPR ili ugovore
- Rizike dobavljača koji utječu na kritične ili važne usluge
- Trendove incidenata i zamalo nastalih događaja
- Preostale rizike koji čekaju prihvaćanje
- Rezultate testiranja djelotvornosti kontrola
- Značajne promjene opsega, dobavljača, tehnologije ili propisa
- Nalaze interne revizije i korektivne radnje
Clarysec obično preporučuje mjesečne operativne preglede rizika i tromjesečna preispitivanja od strane uprave. Mjesečni pregledi usmjereni su na provedbu obrade rizika. Tromjesečni pregledi usmjereni su na prihvaćanje, financiranje, prioritizaciju, regulatornu izloženost i strateške odluke o riziku.
Taj ritam također podržava kontinuirano poboljšanje. Procjene rizika treba ažurirati kada nastupe incidenti, pojave se ranjivosti, uvede se nova imovina, promijeni se tehnologija, promijene se dobavljači, promijene se zakoni, promijene se obveze prema klijentima ili se promijeni apetit za rizik.
Clarysecov put implementacije
Jedinstveni program upravljanja rizicima izbjegava nepovezane proračunske tablice za ISO, NIS2, DORA, GDPR i zahtjeve klijenata za potvrde sigurnosti. Praktičan put je:
- Potvrditi opseg ISMS-a, usluge, imovinu, dobavljače, jurisdikcije i obveze prema klijentima.
- Izraditi ili ažurirati registar usklađenosti koristeći Politiku pravne i regulatorne usklađenosti - SME gdje je primjenjivo.
- Definirati metodologiju rizika, kriterije prihvata, ljestvice vjerojatnosti, ljestvice utjecaja i pravila regulatornog utjecaja.
- Izraditi registar rizika koristeći fazu upravljanja rizicima iz Zenith Blueprinta i Clarysecov pristup izgradnje Registra rizika i SoA.
- Identificirati rizike temeljene na imovini i scenarijima, uključujući scenarije dobavljača, oblaka, privatnosti, kontinuiteta poslovanja, incidenata, ranjivosti, sigurnog razvoja i pristupa.
- Bodovati rizike koristeći kriterije koji uključuju pravni, regulatorni, ugovorni, operativni, privatnosni, dobavljački i financijski utjecaj.
- Odabrati opcije obrade rizika: ublažiti, izbjeći, prenijeti ili prihvatiti.
- Mapirati potrebne kontrole na ISO/IEC 27001:2022 Prilog A i smjernice ISO/IEC 27002:2022.
- Izraditi ili ažurirati Izjavu o primjenjivosti.
- Mapirati obrade rizika na NIS2 Article 21, DORA upravljanje IKT rizicima i očekivanja za treće strane, GDPR odgovornost i ugovorne obveze prema klijentima.
- Prikupiti dokaze, provjeriti djelotvornost kontrola i pribaviti odobrenje preostalog rizika.
- Pripremiti revizijski paket organiziran prema riziku, kontroli, regulativi i artefaktu dokaza.
- Uvesti rezultate u preispitivanje od strane uprave, internu reviziju, korektivne radnje i kontinuirano poboljšanje.
To nije dokumentacija radi dokumentacije. To je operativni sustav za dokazivo kibernetičko upravljanje.
Izradite paket obrade rizika spreman za reviziju
Sarina priča završava dobro jer je prestala tretirati ISO 27001, NIS2 i DORA kao odvojene projekte usklađenosti. Upotrijebila je procjenu rizika prema ISO 27001 kao središnji mehanizam, ugradila regulatorne obveze u kriterije rizika, mapirala radnje obrade rizika na Prilog A i zahtjeve EU te prikupila dokaze koje klijenti, revizori i upravni odbor mogu razumjeti.
Vaša organizacija može učiniti isto.
Koristite Zenith Blueprint: revizorov plan u 30 koraka za definiranje kriterija rizika, izradu registra rizika, izradu plana obrade rizika i unakrsno povezivanje regulatornih zahtjeva.
Koristite Zenith Controls: vodič za unakrsnu usklađenost za povezivanje područja kontrola ISO/IEC 27001:2022 Priloga A s upravljanjem, pravnom usklađenošću, osiguranjem i revizijskim perspektivama.
Koristite Clarysecovu Politiku upravljanja rizicima, Politiku upravljanja rizicima - SME i Politiku pravne i regulatorne usklađenosti - SME za standardizaciju vlasništva, registara, odluka o obradi rizika i dokaza spremnih za reviziju.
Najbrži praktični sljedeći korak jest uzeti deset najvećih rizika i testirati ih kroz pet pitanja:
- Je li regulatorni utjecaj vidljiv?
- Je li plan obrade rizika vremenski ograničen i ima li vlasnika?
- Je li svaka obrada mapirana na Prilog A i SoA?
- Je li relevantnost za NIS2, DORA, GDPR ili klijenta dokumentirana gdje je primjenjivo?
- Postoje li dokazi da kontrola djeluje?
Ako je odgovor ne, Clarysec vam može pomoći pretvoriti registar rizika u dokaziv program obrade rizika za unakrsnu usklađenost kojem revizori, regulatori, klijenti i upravni odbori mogu vjerovati.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
