Incidensek súlyossági besorolása DORA, NIS2 és GDPR szerint

A 02:17-es incidenshívás, amely szabályozói döntéssé válik

Csütörtök hajnalban, 02:17-kor Sarah, a FinScale CISO-ja meglátja az első riasztást: rendellenes API-forgalom, megugró sikertelen hitelesítési kísérletek és 3000 ms feletti késleltetés a fizetési irányítópulton. Perceken belül az ügyféltámogatás fizetési státuszhibákat jelent. A felhőszolgáltató szerint nincs platformszintű incidens. A SOC két földrajzi régióból származó gyanús hozzáférési tokeneket észlel. A termékcsapat megerősíti, hogy az irányítópult 19 perc után ismét elérhető, de tizenkét ügyfél már hibajegyet nyitott.

03:05-kor Sarah már a válságkezelési konferenciahíváson egyeztet az incidenskezelési vezetővel, a jogi tanácsadóval, az adatvédelmi koordinátorral, a felhőüzemeltetési vezetővel és a felsővezetői szponzorral. A technikai kérdés viszonylag egyértelmű: mi történt az API-átjáróval? A szabályozói kérdések nehezebbek:

1. Ez DORA szerinti jelentős IKT-vonatkozású incidens?
2. Ez NIS2 szerinti jelentős incidens?
3. Történt-e GDPR szerinti, bejelentést igénylő személyesadat-sértés?
4. Tudja-e a szervezet bizonyítani, hogyan jutott ezekre a válaszokra?

A hibás válasz szabályozói kitettséget okozhat. A késedelmes válasz bejelentési határidő elmulasztásához vezethet. A dokumentálatlan válasz hónapokkal később elbukhat egy ISO/IEC 27001:2022 auditon.

Ez a 2026-os incidensreagálás kihívása. Sok szervezet rendelkezik incidensreagálási tervvel, forenzikus eljárásokkal, adatvédelmi forgatókönyvekkel és válságkommunikációs sablonokkal. Kevesebbnek van olyan igazolható incidenssúlyossági besorolási modellje, amely egy zajos biztonsági eseményt dokumentált döntéssé alakít a DORA, a NIS2, a GDPR és az ISO/IEC 27001:2022 bizonyítási elvárásai szerint.

A megoldás nem három külön elsődleges értékelési folyamat. A megoldás egy irányított súlyossági modell, külön szabályozási leképezésekkel, mérhető küszöbértékekkel, eszkalációs szabályokkal, döntési naplókkal és bizonyítékgyűjtési követelményekkel. Gyakorlati értelemben az incidens súlyossága nem lehet nyomás alatt kiválasztott címke. Szabályozott üzleti döntésnek kell lennie, amely kiállja a szabályozó hatóságok, auditorok, igazgatósági tagok, ügyfelek és a DPO vizsgálatát.

Miért lett az incidenssúlyossági besorolás igazgatósági szintű kontroll?

Az incidensek besorolása korábban többnyire technikai kérdés volt: a malware súlyossága, az érintett hosztok, a kihasznált sérülékenységek és az, hogy történt-e adatkivitel. 2026-ban ez már jogi, pénzügyi, társadalmi és szerződéses kérdés is.

A DORA a digitális működési rezilienciát irányítási kötelezettséggé teszi a pénzügyi szervezetek számára. Az irányító testülettől elvárt, hogy meghatározza, jóváhagyja, felügyelje és továbbra is felelősséget viseljen az IKT-kockázatkezelési keretrendszerért. Ez magában foglalja az IKT üzletmenet-folytonosságot, a reagálási és helyreállítási terveket, a jelentős incidensek bejelentési csatornáit, az IKT harmadikfél-kockázatokat és a levont tanulságokat.

A NIS2 megemeli az irányítási tétet az alapvető és fontos szervezetek számára. Article 20 előírja, hogy az irányító testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását és vegyenek részt képzésen. A kockázatkezelés és az incidensjelentés hiányosságait súlyos felügyeleti következményekhez is kapcsolja. Az alapvető szervezetek esetében a maximális közigazgatási bírság kiinduló szintje legalább 10 000 000 EUR vagy a teljes világpiaci éves árbevétel 2 százaléka lehet, attól függően, melyik a magasabb. A fontos szervezetek esetében ez legalább 7 000 000 EUR vagy az árbevétel 1,4 százaléka, attól függően, melyik a magasabb.

A GDPR más szempontot ad hozzá. A személyesadat-sértés nem korlátozódik megerősített nyilvános közzétételre vagy ellopott fájlokra. Ide tartozik a személyes adatok véletlen vagy jogellenes megsemmisítése, elvesztése, megváltoztatása, jogosulatlan közlése vagy az azokhoz való jogosulatlan hozzáférés. Az adatkezelőknek értékelniük kell az érintetteket fenyegető kockázatot, és az elszámoltathatóság elve alapján igazolniuk kell az értesítésről vagy annak mellőzéséről szóló döntést.

Az ISO/IEC 27001:2022 bizonyítási alapot ad ezekhez a kötelezettségekhez. A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a környezetét, az érdekelt felek követelményeit, a hatályt, az interfészeket és a függőségeket. Az 5.1–5.3 pontok vezetői elkötelezettséget, szabályzatot, szerepköröket, felelősségeket és jelentéstételt írnak elő. A 6.1.1–6.1.3 pontok kockázatalapú tervezést, kockázatértékelést, kockázatkezelést és alkalmazhatósági nyilatkozatot követelnek meg. A 8.1–8.3 pontok operatív kontrollt, változáskezelést, megőrzött bizonyítékokat és újraértékelést írnak elő, amikor a kockázati feltételek megváltoznak. ISO/IEC 27001:2022

Amikor beérkezik az incidenshívás, a kérdés nem az legyen, hogy „ki szerint kritikus ez?”. A kérdés az legyen: „mit követelnek meg tőlünk most a jóváhagyott kritériumaink, jogi kiváltó feltételeink, bizonyítékaink és eszkalációs szabályaink?”

Egy esemény, három szabályozási besorolási rendszer

A DORA, a NIS2 és a GDPR nem ugyanazt a nyelvezetet használja az incidensekre. Ez az alapvető oka annak, hogy a szervezetek nehézségekbe ütköznek az első órában.

A DORA Article 17 előírja a pénzügyi szervezetek számára olyan IKT-vonatkozású incidenskezelési folyamat létrehozását, amely észleli, kezeli és bejelenti az IKT-incidenseket, nyilvántartja az IKT-vonatkozású incidenseket és a jelentős kiberfenyegetéseket, kezeli a gyökérokokat, korai figyelmeztető indikátorokat használ, kategorizálja és besorolja az incidenseket, szerepköröket rendel hozzá, kezeli a kommunikációt, eszkalálja a jelentős incidenseket a felső vezetés felé, és helyreállítja a biztonságos működést.

A DORA Article 18 olyan szempontok szerinti besorolást ír elő, mint az érintett ügyfelek, érintett szerződéses partnerek, tranzakciók, időtartam, kiesési idő, földrajzi kiterjedés, a rendelkezésre állást, hitelességet, sértetlenséget vagy bizalmasságot érintő adatvesztés, az érintett szolgáltatások kritikussága és a gazdasági hatás. A DORA Article 19 előírja a jelentős IKT-vonatkozású incidensek jelentését és az ügyfelek tájékoztatását, ha pénzügyi érdekeik érintettek.

A NIS2 Article 23 jelentős incidensként határozza meg azt az incidenst, amely súlyos működési zavart vagy pénzügyi veszteséget okozott vagy okozhat, illetve amely másokat jelentős vagyoni vagy nem vagyoni kár okozásával érintett vagy érinthet. Előírja, hogy a jelentős incidensről való tudomásszerzéstől számított 24 órán belül korai figyelmeztetést, 72 órán belül incidensbejelentést, kérésre közbenső jelentéseket, az incidensbejelentéstől számított egy hónapon belül pedig zárójelentést kell adni. Adott esetben az érintett szolgáltatásigénybe vevőket is tájékoztatni kell az általuk megtehető intézkedésekről vagy igénybe vehető jogorvoslatokról.

A GDPR adatvédelmi kockázati kérdést tesz fel. Okozott-e a biztonság sérülése személyes adatok megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést? Ha igen, az adatkezelőnek értékelnie kell a természetes személyek jogait és szabadságait fenyegető kockázatot. Ha a jogsértés valószínűsíthetően kockázattal jár, a felügyeleti hatóságot főszabály szerint a tudomásszerzéstől számított 72 órán belül értesíteni kell. Ha valószínűsíthetően magas kockázattal jár, az érintetteket indokolatlan késedelem nélkül tájékoztatni kell.

Ezért egyetlen incidenst párhuzamosan kell besorolni.

A pénzügyi szervezetek számára a DORA az ágazatspecifikus uniós jogi aktus az IKT-kockázatkezelési és incidensjelentési kötelezettségekre, amelyek átfedhetnek a NIS2-vel. Ez nem teszi irrelevánssá a NIS2-t. Továbbra is jelentősége lehet az együttműködés, az információáramlások, a DORA határán kívüli szolgáltatások, a nem pénzügyi csoporttagok, a felhőszolgáltatások, a menedzselt szolgáltatások és az ügyfélszerződéses kötelezettségek szempontjából. A súlyossági modellnek nemcsak az eredményt, hanem az alkalmazhatósági logikát is rögzítenie kell.

A Clarysec modellje: az eseményt sorolja be, ne az érzelmi reakciót

A Clarysec az ISO/IEC 27002:2022 5.25 kontrollal, az információbiztonsági események értékelésével és az azokról szóló döntéssel indít, mint megfelelőségi hivatkozási ponttal. A Zenith Controls: The Cross-Compliance Guide Zenith Controls kiadványban ez a téma az „Információbiztonsági események értékelése és az azokról szóló döntés” bejegyzésen keresztül kapcsolódik az 5.25 kontrollhoz, amelyet az 5.24 kontrollhoz tartozó „Információbiztonsági incidenskezelés tervezése és előkészítése”, valamint az 5.28 kontrollhoz tartozó „Bizonyítékgyűjtés” támogat.

A megfelelés szempontjából a legfontosabb pillanat gyakran nem az elszigetelés. Hanem az az elágazás, ahol egy biztonsági esemény szabályozási incidenssé válik, vagy igazolható módon alacsonyabb súlyosságú eseményként kerül rögzítésre.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a Kontrollok működésben szakasz 23. lépésében így írja le ezt a pillanatot:

„Nem minden anomália katasztrófa. Nem minden riasztás jelez kompromittálódást. A valóságban a biztonsági csapatokat és üzleti egységeket elárasztja a zaj: bejelentkezési kísérletek, naplóanomáliák, kisebb szabályzatsértések, árnyék-IT tevékenység. Az igazi kihívás nem pusztán az észlelés, hanem annak megkülönböztetése, mi ártalmatlan és mi káros, valamint annak felismerése, mi igényel eszkalációt.”

Ez a mondat pontosan megragadja az operatív problémát. Egy SIEM-riasztás nem jelent automatikusan DORA szerinti jelentős incidenst. Egy átmeneti szolgáltatáskimaradás nem jelent automatikusan NIS2 szerinti jelentős incidenst. Egy gyanús adatbázis-lekérdezés nem jelent automatikusan GDPR szerint bejelentendő incidenst. Mindegyik bejelentéskötelessé válhat a hatástól, a hatókörtől, az adatoktól, az érintett felektől és a bizonyítékoktól függően.

A Zenith Blueprint kockázatkezelési szakaszának 10. lépése azt is javasolja, hogy a hatásdefiníciókat az üzleti mérethez és a szabályozási kitettséghez kell igazítani:

„A hatás meghatározásakor érdemes a szinteket a saját üzleti léptékhez kötni. Például: „Jelentős pénzügyi hatás = veszteség > 100 ezer USD” (igazítsa a saját környezetéhez). Vegye figyelembe a szabályozási hatást is: például egy személyes adatokat érintő adatsértés a GDPR bírságok és bejelentési követelmények miatt automatikusan „Jelentős” vagy „Súlyos” lehet, még akkor is, ha a közvetlen pénzügyi veszteség nem egyértelmű.”

Ez a 2026-os incidenssúlyossági besorolás tervezési alapelve: a súlyosság üzleti hatás plusz jogi hatás plusz a bizonyítékok megbízhatósága.

Gyakorlati incidenssúlyossági taxonómia DORA, NIS2 és GDPR szerint

Egy igazolható taxonómiának el kell különítenie a belső súlyosságot a szabályozási besorolástól. A belső súlyosság határozza meg a reagálás sürgősségét, az erőforrás-allokációt és a felsővezetői eszkalációt. A szabályozási besorolás határozza meg az értesítést, a jogi felülvizsgálatot és a külső kommunikációt.

A belső súlyossági szint nem a végleges szabályozási válasz. Ez az üzemmód. Egy SEV 3 esemény a naplófelülvizsgálat után GDPR szerint bejelentendővé válhat. Egy SEV 2 szolgáltatáskimaradás nem feltétlenül DORA szerinti jelentős incidens, ha a hatásküszöbök nem teljesülnek. Egy SEV 1 zsarolóvírus-incidens egyszerre válthat ki DORA, NIS2, GDPR, ügyfélszerződéses és bűnüldözési koordinációs kötelezettségeket.

Egy részletesebb besorolási mátrix segíti a csapatot abban, hogy a riasztástól eljusson az intézkedésig.

A modellt szabályzatba kell beépíteni, nem szabad a válságkezelési hívás legerősebb hangjára bízni. A KKV-knak szóló Incident Response Policy-sme Incident Response Policy-sme - SME irányítási követelményeinek 5.3.1 pontja kimondja:

„Az ügyvezetőnek az IT-szolgáltató bevonásával az értesítéstől számított egy órán belül súlyosság szerint kell besorolnia minden incidenst.”

Ugyanezen KKV-szabályzat Kockázatkezelés és kivételek fejezetének 7.4.1 pontja hozzáteszi:

„Ha ügyféladat érintett, az ügyvezetőnek értékelnie kell a jogi értesítési kötelezettségeket a GDPR, NIS2 vagy DORA alkalmazhatósága alapján.”

Nagyobb szervezeteknél a vállalati Incident Response Policy Incident Response Policy irányítási követelményeinek 5.3 pontja ugyanezt a koncepciót formalizálja:

„Az incidensbesorolásnak többszintű modellt kell követnie:”

A szabályzati nyelvezet azért fontos, mert a szabályozók és auditorok meg fogják kérdezni, léteztek-e besorolási kritériumok az incidens előtt. Egy utólag kitalált mátrix gyenge bizonyíték. Egy jóváhagyott, oktatott, gyakorolt és következetesen használt mátrix igazolható.

A döntési napló: a legfontosabb bizonyítékelem

Amikor auditorok, szabályozók vagy igazgatósági tagok felülvizsgálnak egy incidenst, ritkán csak azt kérdezik: „Mi történt?” Azt kérdezik: „Mikor szereztek róla tudomást, ki döntött, milyen bizonyíték alapján, és miért nem jelentették korábban?”

Ezért a Clarysec súlyossági döntési naplót javasol minden SEV 3 vagy annál magasabb szintű eseményhez, valamint minden olyan eseményhez, amely személyes adatokat, kritikus szolgáltatásokat, pénzügyi ügyfeleket, menedzselt szolgáltatásokat, felhőinfrastruktúrát vagy határokon átnyúló hatást érint.

Ez közvetlenül kapcsolódik az ISO/IEC 27001:2022-höz. A 8.1 pont előírja a folyamatok megtervezését, végrehajtását és kontroll alatt tartását, valamint elegendő dokumentált információ megőrzését annak igazolására, hogy a folyamatok a tervek szerint működtek. A 8.2 és 8.3 pontok jelentős változások esetén újraértékelést, valamint a kockázatkezelési bizonyítékok megőrzését írják elő. Az A melléklet A.5.24–A.5.28 kontrolljai adják az incidenskezelési gerincet: tervezés és előkészítés, eseményértékelés és döntés, reagálás, tanulás az incidensekből és bizonyítékgyűjtés.

A KKV-knak szóló Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME érvényesítés és megfelelés fejezetének 8.3.2 pontja támogatja a modell GDPR-oldalát:

„Az adatvédelmi koordinátor meghatározza a súlyosságot, kezdeményezi az elszigetelési intézkedéseket, és dokumentálja az ügyet”

Az adatvédelmi értékelésnek nem akkor kell elkezdődnie, amikor a szabályozói óra már kényelmetlenné válik. Az elsődleges értékelési munkafolyamat részének kell lennie.

Gyakorlati példa: Sarah API-incidensének besorolása

Térjünk vissza a FinScale-hez. Ez egy B2B fintech platform, amely felhőinfrastruktúrát, külső csaláselemzési szolgáltatót és menedzselt biztonsági szolgáltatót használ. Egyes tevékenységei tekintetében DORA hatálya alá tartozó pénzügyi szervezet. Emellett digitális szolgáltató is, NIS2 szempontjából releváns működéssel egy tagállamban. Ügyfélszámla-szolgáltatások esetében adatkezelőként, egyes vállalati ügyfelek tekintetében pedig adatfeldolgozóként kezel ügyfél-személyes adatokat.

02:17-kor rendellenes API-forgalmat észlelnek. 02:35-kor megnyílik az incidensjegy. 03:00-kor Sarah elvégzi a kezdeti elsődleges értékelést az incidenskezelési vezetővel.

Először meghatározzák a belső súlyosságot. Az incidens 19 percre érintette az ügyfél-irányítópult rendelkezésre állását, gyanús hozzáférési tokeneket foglalt magában, és kritikus, ügyféloldali funkciót érintett. Az eseményt megerősítésig SEV 3 Közepes szintre sorolják, eszkalációval az incidenskezelési vezető, az adatvédelmi koordinátor, a jogi tanácsadó és a szolgáltatásgazda felé.

Másodszor elvégzik a DORA szűrést. A csapat ellenőrzi az érintett ügyfeleket, szerződéses partnereket, tranzakciókat, időtartamot, kiesési időt, földrajzi kiterjedést, adatvesztést, kritikusságot és gazdasági hatást. Nincs megerősített sikertelen vagy módosított tranzakció. A kiesési idő korlátozott. Adatvesztés nem bizonyított. Ugyanakkor mivel kritikus pénzügyi szolgáltatási komponensről van szó, és az ügyfelek pénzügyi érdekei érintettek lehetnek, az incidenst DORA szempontból továbbra is nyomon követik, és újrabesorolható.

Harmadszor rögzítik a NIS2 szűrést. A csapat megállapítja, hogy a hatály alá tartozó pénzügyi szervezeti kötelezettségek tekintetében a DORA az elsődleges ágazatspecifikus jelentéstételi rezsim. Azt is ellenőrzik, érinti-e az incidens a DORA peremén kívüli szolgáltatásokat vagy ügyfeleket. Ebben a szakaszban nincs megerősítve súlyos működési zavar vagy jelentős kár.

Negyedszer elindul a GDPR szűrés. A gyanús tokenek hozzáférést tehettek lehetővé az ügyfél-irányítópult adataihoz. Az adatvédelmi koordinátor dokumentálja az adatkategóriákat, az érintett felhasználókat, a token hatókörét, a felülvizsgált naplókat, azt, hogy megtekintettek-e vagy exportáltak-e adatokat, valamint az olyan védelmi intézkedéseket, mint a token lejárata és a hozzáférés-szabályozás.

04:20-ra a naplóelemzés kimutatja, hogy két tokent 41 ügyfél irányítópult-metaadatainak elérésére használtak, beleértve neveket, fiókazonosítókat és tranzakciós státuszokat, de fizetési hitelesítő adatokat vagy személyazonosító dokumentumokat nem. A csapat SEV 2 Jelentős szintre módosítja az incidenst, mert a személyes adatok bizalmassága érintett volt, és ügyfélkommunikációra lehet szükség. A DPO értékeli az érintetteket fenyegető GDPR-kockázatot. A DORA-döntést újra megvizsgálják az ügyfélhatás, a tranzakciós hatás és a gazdasági hatás alapján.

Ez a modell gyakorlati értéke. A kezdeti besorolás nem végleges jogi következtetés. Bizonyítékvezérelt döntés, amely a tények alakulásával frissíthető.

Naplózás, felügyelet és forenzikus bizonyítékok: a bizonyítási réteg

Bizonyítékok nélkül a súlyossági modell csupán értekezleti vélemény. A 2026-os elvárás az, hogy a besorolást naplók, felügyeleti adatok, megőrzött bizonyítékelemek és bizonyítéklánc támassza alá.

A KKV-knak szóló Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME érvényesítés és megfelelés fejezetének 8.3.4 pontja kimondja:

„Az adatsértési vizsgálatokat megfelelő naplókkal kell alátámasztani a GDPR és a DORA szerinti elszámoltathatósági elv teljesítése érdekében”

A forenzikus kezelés ugyanilyen fontos. A KKV-knak szóló Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME irányítási követelményeinek 5.3.1 pontja előírja:

„Minden incidenshez egyszerű bizonyítéklánc-naplót (pl. Excel-fájlt vagy sablondokumentumot) kell vezetni.”

Vállalati környezetekben az Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy irányítási követelményeinek 5.5 pontja előírja:

„Minden begyűjtött bizonyítékot egyedileg azonosítani, címkézni és biztonságos adattárban tárolni kell az alábbiakkal:”

A Zenith Blueprint Kontrollok működésben szakaszának 23. lépése elmagyarázza, miért fontos ez az ISO/IEC 27002:2022 5.28 kontroll szempontjából:

„Amikor információbiztonsági incidens történik, a reagálás egyik legkritikusabb, mégis gyakran figyelmen kívül hagyott eleme a bizonyíték. Nem naplók, nem képernyőképek, nem laza narratívák, hanem megfelelően megőrzött, a bizonyítékláncot tiszteletben tartó, manipulációálló bizonyíték.”

Egy jelentős vagy potenciálisan bejelentésköteles incidens gyakorlati bizonyítékcsomagjának tartalmaznia kell:

• Incidensjegy és idővonal
• Súlyossági döntési napló és újrabesorolási előzmények
• SIEM-riasztások, EDR-riasztások, felhőnaplók és identitásnaplók
• Adathozzáférési naplók és exportnaplók
• Érintett eszköz- és szolgáltatásnyilvántartási bejegyzések
• Ügyfél-, tranzakció- és földrajzi hatásvizsgálat
• DORA, NIS2 és GDPR szűrési munkalap
• DPO- vagy jogi értékelés
• Kommunikációs jóváhagyások és kiküldött üzenetek
• Bizonyítéklánc-bejegyzés
• Gyökérok-elemzés
• Helyesbítő intézkedések és levont tanulságok

Ez a bizonyítékcsomag támogatja az ISO/IEC 27001:2022 A mellékletének A.8.15 naplózás, A.8.16 felügyeleti tevékenységek, A.5.28 bizonyítékgyűjtés, A.5.27 információbiztonsági incidensekből való tanulás, A.5.31 jogi, jogszabályi, szabályozási és szerződéses követelmények, valamint A.5.34 személyazonosításra alkalmas információk védelme és adatvédelem kontrolljait is.

Keresztmegfelelőségi leképezés: építse fel egyszer, válaszoljon sok auditornak

A legerősebb incidenssúlyossági modelleket egyszer építik fel, és sokszor leképezik. A Zenith Controls ehhez a munkához keresztmegfelelőségi iránytűként készült. Ebben a témában az ISO/IEC 27002:2022 alapvető bejegyzései: 5.24 információbiztonsági incidenskezelés tervezése és előkészítése, 5.25 információbiztonsági események értékelése és az azokról szóló döntés, 5.26 reagálás információbiztonsági incidensekre, 5.27 tanulás információbiztonsági incidensekből és 5.28 bizonyítékgyűjtés.

Ezek a kontrollok természetesen kapcsolódnak az ISO/IEC 27001:2022 irányítási rendszeréhez. A 4., 5., 6. és 8. pontok meghatározzák a hatályt, a vezetést, a kockázati kritériumokat, a kezelést és az operatív bizonyítékokat. Az ISO/IEC 27002:2022 biztosítja a kontrollok végrehajtási nyelvezetét. Az ISO 22301 jellegű üzletmenet-folytonossági gondolkodás támogatja a zavarási küszöbértékeket, a helyreállítási prioritásokat és a válságkezelést. Az ISO/IEC 27035 jellegű incidenskezelési gyakorlatok támogatják a strukturált észlelést, jelentéstételt, értékelést, reagálást és tanulást. Az ISO/IEC 27701 jellegű adatvédelmi irányítás támogatja a személyesadat-sértési szerepköröket, az adatkezelői és adatfeldolgozói szempontokat, az adatvédelmi bizonyítékokat és az elszámoltathatóságot.

Ugyanez a modell leképezhető a NIST Cybersecurity Framework 2.0-ra. A GOVERN funkció megköveteli, hogy a jogi, szabályozási, szerződéses, adatvédelmi és polgári szabadságjogi kötelezettségek ismertek és kezeltek legyenek. Elvárja továbbá a kockázatvállalási hajlandóság, a szerepkörök, a hatáskörök, a szabályzatok és a felügyelet meghatározását. A DETECT, RESPOND és RECOVER funkciók támogatják az elsődleges értékelési folyamatot, az elemzést, az eszkalációt, az elszigetelést, a helyreállítást, a kommunikációt és a fejlesztést.

Az előny gyakorlati. Amikor egy DORA-felügyelet a jelentős IKT-vonatkozású incidens indokolását kéri, egy NIS2-hatóság a 24 órás korai figyelmeztetési döntést kérdezi, egy adatvédelmi hatóság azt kérdezi, miért történt vagy nem történt GDPR-értesítés, egy ISO auditor pedig azt, hogy az IBIR a tervek szerint működött-e, a szervezet ugyanabból a bizonyítékkészletből tud válaszolni.

Hogyan tesztelik majd az auditorok és szabályozók a modellt?

Egy ISO/IEC 27001:2022 auditor általában a hatállyal és a jogi követelményekkel kezdi. Meg fogja kérdezni, hogy a DORA, a NIS2, a GDPR, az ügyfélszerződések és az IKT harmadik felekkel kapcsolatos kötelezettségek érdekelt felek követelményeiként azonosításra kerültek-e. Ezután végigköveti a nyomvonalat a kockázati kritériumokig, az alkalmazhatósági nyilatkozatig, az incidenskezelési eljárásokig, az operatív nyilvántartásokig és a bizonyítékmegőrzésig. Bizonyítékot akar arra, hogy a besorolási folyamatot nem az incidens közben találták ki.

Egy DORA-felügyelet vagy belső auditcsoport életciklus-hurkot fog keresni: incidenskezelési folyamat, korai figyelmeztető indikátorok, besorolási kritériumok, jelentős incidens eszkalációja, ügyfélkommunikáció, gyökérok, végleges hatásszámok, rezilienciatesztelés és az irányító testület felügyelete. Azt is meg fogják kérdezni, figyelembe vették-e az IKT harmadikfél-függőségeket, különösen ha felhő, SaaS, menedzselt biztonsági vagy kiszervezési szolgáltatók érintettek voltak.

Egy NIS2-re fókuszáló auditor vagy hatóság azt fogja vizsgálni, hogy a szervezet képes-e azonosítani a jelentős incidenseket, teljesíteni a szakaszos határidőket, kommunikálni az érintett szolgáltatásigénybe vevőkkel, és bizonyítékot adni a határokon átnyúló hatás értékeléséről. Az incidenskezelést összekapcsolják az Article 21 kockázatkezelési intézkedéseivel, beleértve az üzletmenet-folytonosságot, a válságkezelést, az ellátási lánc biztonságát, a hozzáférés-szabályozást, az eszközkezelést és a képzést.

Egy GDPR DPO vagy felügyeleti hatóság azt vizsgálja, hogy a szervezet azonosította-e a személyes adatokat, a szerepköröket, az érintetteket, a kategóriákat, az érintett rendszereket, a jogsértés típusát és az egyéneket fenyegető kockázatot. Tesztelni fogják, hogy az adatkezelő képes-e igazolni az elszámoltathatóságot, és hogy az adatfeldolgozói értesítések az adatkezelők felé időben és teljes körűen megtörténtek-e.

Egy ISACA vagy COBIT 2019 szemléletű auditor az irányítási bizonyítékokra fog összpontosítani. Ki hagyta jóvá a súlyossági taxonómiát? Ki a kockázatgazda? Milyen mutatókat jelentenek a vezetésnek? Hogyan kezelik a kivételeket? Hogyan alakítják a levont tanulságokat kontrollfejlesztésekké?

Gyakori hibaminták az incidensbesorolásban

Az első hiba az egycímkés gondolkodás. A csapatok magas, közepes vagy alacsony szintre sorolják az eseményt, de külön nem értékelik a DORA, a NIS2 és a GDPR kiváltó feltételeit. Az eredmény egy súlyossági címke, amely nem tud megmagyarázni egy jelentéstételi döntést.

A második hiba a megerősített adatsértésre való torzítás. A csapatok megvárják az adatkivitel abszolút bizonyítékát, mielőtt bevonnák az adatvédelmi vagy jogi területet. A GDPR szerinti adatsértésértékelés gyakran már a lehetséges jogosulatlan hozzáféréssel, elvesztéssel, megváltoztatással vagy közléssel kezdődik, nem csak az adatok megerősített közzétételével.

A harmadik hiba az időzítési követelmények körüli bizonytalanság. A NIS2 és a GDPR határidői a tudomásszerzéstől és az értékeléstől függenek. Ha az incidensjegy nem rögzíti a tudomásszerzés idejét, a besorolási időt és az eszkaláció idejét, a szervezet nehezen tudja bizonyítani a határidők betartását.

A negyedik hiba a forenzika a helyreállítás után. A mérnökök kulcsokat rotálnak, hosztokat építenek újra és ideiglenes bizonyítékokat törölnek, mielőtt a vizsgálati üzemmód aktiválódna. Ez megsemmisítheti a szabályozási, szerződéses vagy jogi felülvizsgálathoz szükséges bizonyítékokat.

Az ötödik hiba a beszállítói vakság. A DORA, a NIS2 és a NIST CSF 2.0 egyaránt hangsúlyozza a harmadikfél- és ellátásilánc-kockázatot. Ha felhőszolgáltató, menedzselt szolgáltató, fizetésfeldolgozó, identitásszolgáltató vagy SaaS-beszállító része az incidensláncnak, a besorolási modellnek tartalmaznia kell a beszállítói hatást és a szerződéses értesítési kötelezettségeket.

Clarysec bevezetési ellenőrzőlista 2026-ra

Egy igazolható incidenssúlyossági besorolási modell működtetéséhez a Clarysec az alábbi sorrendet javasolja:

1. Erősítse meg a szabályozási alkalmazhatóságot DORA, NIS2, GDPR, ügyfélszerződések és ágazati szabályok szerint.
2. Frissítse az IBIR alkalmazási területét és az érdekelt felek követelményeit az ISO/IEC 27001:2022 szerint.
3. Határozza meg a belső súlyossági szinteket mérhető küszöbértékekkel a kiesési időre, adatokra, ügyfelekre, földrajzi kiterjedésre, pénzügyi veszteségre és kritikusságra.
4. Adjon külön DORA, NIS2 és GDPR szűrési kérdéseket az incidensjegy-munkafolyamathoz.
5. Határozza meg az eszkalációs kiváltó feltételeket az incidenskezelési vezető, a DPO, a jogi terület, a felső vezetés és az igazgatóság számára.
6. Hozzon létre súlyossági döntési napló sablont.
7. Kapcsolja össze a besorolást a bizonyítékgyűjtési és bizonyítéklánc-eljárásokkal.
8. Ellenőrizze a naplózási lefedettséget az identitás-, felhő-, alkalmazás-, adatbázis-, hálózati és beszállítói eseményekre.
9. Tartson asztali gyakorlatokat DORA szerinti jelentős incidens, NIS2 szerinti jelentős incidens és GDPR szerinti adatsértési forgatókönyvekre.
10. Építse be a levont tanulságokat a kockázatkezelésbe, az alkalmazhatósági nyilatkozatba, a képzésbe és a rezilienciatesztelésbe.

A Zenith Blueprint Kontrollok működésben szakaszának 16. lépése megerősíti a modell emberi oldalát: a jelentéseket naplózni, elsődlegesen értékelni, az incidensreagálási terven keresztül eszkalálni kell, és még a kisebb eseményeket is nyomon kell követni, mert a trendek kontrollgyengeségeket tárnak fel. Alacsony küszöbű jelentési szemléletet támogat: „Ha kétsége van, jelentse.”

Ez a kulturális szempont kritikus. A súlyossági modell kudarcot vall, ha a munkavállalók azért késleltetik a jelentést, mert túlzott reakciótól tartanak. A cél a gyors jelentés, a fegyelmezett elsődleges értékelés és az igazolható besorolás.

Az incidensbizonytalanság alakítása auditra alkalmas bizonyítékká

2026-ban az incidenssúlyossági besorolás már nem kizárólag SOC-döntés. Szabályozott irányítási folyamat, amelynek össze kell kapcsolnia a DORA szerinti jelentős IKT-vonatkozású incidenskritériumokat, a NIS2 szerinti jelentős incidensküszöböket, a GDPR szerinti adatsértési kockázatot és az ISO/IEC 27001:2022 bizonyítékokat.

Az incidensek során legjobban teljesítő szervezetek nem azok lesznek, amelyeknél a legvastagabb reagálási dosszié található. Hanem azok, amelyek gyorsan meg tudnak válaszolni négy kérdést, és később minden választ bizonyítani tudnak:

• Mi történt?
• Mennyire súlyos?
• Mely szabályozási kötelezettségek lehetnek alkalmazandók?
• Milyen bizonyíték támasztja alá a döntést?

A Clarysec szabályzatsablonokkal, súlyossági taxonómiákkal, döntési naplókkal, asztali forgatókönyvekkel és keresztmegfelelőségi leképezésekkel segít a szervezeteknek felépíteni ezt a hidat. Kezdje az incidensszabályzatokkal, ellenőrizze kockázati kritériumait a Zenith Blueprint Zenith Blueprint alapján, és használja a Zenith Controls Zenith Controls megoldást az ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 és 5.28 kontrolljainak DORA, NIS2, GDPR, NIST CSF és auditelvárások szerinti leképezésére.

Ha a csapata az első órában nem tud válaszolni arra, hogy „DORA szerint jelentős, NIS2 szerint jelentős vagy GDPR szerint bejelentendő ez az incidens?”, akkor a következő lépés nem egy újabb általános incidensreagálási terv. A következő lépés egy igazolható incidenssúlyossági besorolási működési modell, amelyet még a következő 02:17-es hívás előtt tesztelnek.

Készen áll arra, hogy a pánikot folyamattal váltsa fel? Töltse le a Clarysec incidensreagálási és bizonyítékgyűjtési szabályzatsablonjait, vizsgálja felül jelenlegi súlyossági taxonómiáját a Zenith Blueprint alapján, vagy kérjen Clarysec felkészültségi értékelést egy auditra alkalmas DORA, NIS2, GDPR és ISO/IEC 27001 incidensbesorolási modell kialakításához.