Mapování souladu s nařízením DORA¶
Soulad MazeVault s nařízením o digitální provozní odolnosti (EU 2022/2554)
ID dokumentu: MV-LEG-021
Verze: 1.0.0
Klasifikace: Interní
Vlastník: Ředitel pro informační bezpečnost (CISO)
Poslední aktualizace: 2026-05-01
Cyklus revize: Roční
Schválil: CEO / Představenstvo
1. Regulatorní přehled¶
1.1 Nařízení o digitální provozní odolnosti (DORA)¶
Nařízení (EU) 2022/2554 — nařízení o digitální provozní odolnosti („DORA") — stanoví komplexní rámec pro řízení rizik v oblasti informačních a komunikačních technologií (ICT) ve finančním sektoru. Nařízení DORA vstoupilo v účinnost dne 17. ledna 2025 a je přímo použitelné ve všech členských státech EU bez nutnosti národní transpozice.
Klíčové regulatorní parametry:
| Aspekt | Popis |
|---|---|
| Právní základ | Nařízení (EU) 2022/2554 ze dne 14. prosince 2022 |
| Datum účinnosti | 17. ledna 2025 |
| Působnost | 21 typů finančních subjektů + poskytovatelé ICT služeb třetích stran |
| Orgány dohledu | EBA, ESMA, EIOPA (společně prostřednictvím Společného výboru); vnitrostátní příslušné orgány |
| Hlavní dohlížitel | Určený ESA pro kritické poskytovatele služeb třetích stran (CTPPs) |
| Akty v přenesené/prováděcí pravomoci | RTS a ITS přijaté Evropskou komisí na základě návrhů ESA |
| Sankce | Stanovené vnitrostátními příslušnými orgány; periodické penále pro CTPPs |
| Křížové odkazy | Směrnice NIS2 (2022/2555), nařízení GDPR (2016/679), MiFID II, PSD2, Solvency II |
1.2 Subjekty v působnosti¶
Nařízení DORA se vztahuje na 21 kategorií finančních subjektů, včetně:
- Úvěrové instituce (banky)
- Platební instituce
- Poskytovatelé služeb informování o účtu
- Instituce elektronických peněz
- Investiční podniky
- Poskytovatelé služeb v oblasti kryptoaktiv
- Centrální depozitáře cenných papírů
- Ústřední protistrany
- Obchodní místa
- Registry obchodních údajů
- Správci alternativních investičních fondů (AIFMs)
- Správcovské společnosti (UCITS)
- Poskytovatelé služeb hlášení údajů
- Pojišťovny a zajišťovny
- Pojišťovací zprostředkovatelé
- Instituce zaměstnaneckého penzijního pojištění
- Ratingové agentury
- Správci kritických referenčních hodnot
- Poskytovatelé služeb skupinového financování
- Registry sekuritizací
- Poskytovatelé ICT služeb třetích stran (určení jako kritičtí — CTPPs)
1.3 Regulatorní architektura¶
Nařízení DORA je strukturováno do pěti věcných kapitol:
| Kapitola | Název | Články | Klíčové požadavky |
|---|---|---|---|
| II | Řízení rizik ICT | Čl. 5-16 | Komplexní rámec řízení rizik ICT |
| III | Řízení incidentů souvisejících s ICT | Čl. 17-23 | Klasifikace, řízení a hlášení incidentů |
| IV | Testování digitální provozní odolnosti | Čl. 24-27 | Program testování včetně TLPT |
| V | Rizika třetích stran v oblasti ICT | Čl. 28-44 | Rámec dohledu nad třetími stranami |
| VI | Sdílení informací | Čl. 45 | Dobrovolné sdílení informací o hrozbách |
1.4 Regulační technické normy (RTS) a prováděcí technické normy (ITS)¶
Nařízení DORA doplňují následující akty v přenesené a prováděcí pravomoci:
- RTS o rámci řízení rizik ICT (Nařízení Komise v přenesené pravomoci 2024/1774)
- RTS o klasifikaci incidentů souvisejících s ICT (Nařízení Komise v přenesené pravomoci 2024/1772)
- ITS o hlášení závažných incidentů souvisejících s ICT (Prováděcí nařízení Komise 2024/1773)
- RTS o subdodávání ICT služeb (Nařízení Komise v přenesené pravomoci 2024/1775)
- RTS o TLPT (Nařízení Komise v přenesené pravomoci 2024/1776)
- RTS o kritériích pro určení CTPP (Nařízení Komise v přenesené pravomoci 2024/1777)
- ITS o registru informací (Prováděcí nařízení Komise 2024/1778)
2. Postavení MazeVault z hlediska nařízení DORA¶
2.1 Klasifikace¶
MazeVault je klasifikován jako poskytovatel ICT služeb třetích stran podle článku 3 odst. 21 nařízení DORA:
„Poskytovatel ICT služeb třetí strany znamená podnik poskytující ICT služby"
Služby MazeVault kvalifikující se jako ICT služby podle nařízení DORA:
| Služba | Relevance pro DORA | Kritičnost |
|---|---|---|
| Správa životního cyklu certifikátů | ICT služba podporující infrastrukturu autentizace a šifrování | Důležitá/Kritická (závisí na zákazníkovi) |
| Správa tajemství | ICT služba spravující kryptografické materiály a přihlašovací údaje | Kritická |
| Služby PKI (CA, OCSP) | ICT služba poskytující důvěryhodnou infrastrukturu | Kritická |
| Správa klíčů (integrace HSM) | ICT služba spravující životní cyklus kryptografických klíčů | Kritická |
| MazeVault Agent | ICT služba nasazená na infrastruktuře zákazníka | Důležitá |
| MazeVault Gateway | ICT služba umožňující konektivitu a distribuci certifikátů | Důležitá |
2.2 Posouzení určení jako CTPP¶
MazeVault není v současné době určen jako kritický poskytovatel služeb třetích stran (CTPP) orgány ESA. Kritéria pro určení jako CTPP podle článku 31 zahrnují:
- Systémový význam pro finanční subjekty
- Míra nahraditelnosti
- Míra závislosti finančních subjektů
- Počet a typ obsluhovaných finančních subjektů
Hodnocení MazeVault: Pod prahovými hodnotami pro určení jako CTPP. MazeVault však udržuje připravenost na případné budoucí určení a dobrovolně implementuje kontroly v souladu s očekáváními dohledu nad CTPP.
2.3 Smluvní postavení¶
Povinnosti MazeVault podle nařízení DORA vyplývají především ze smluvních požadavků uložených zákazníky z řad finančních subjektů podle kapitoly V (články 28-30). Finanční subjekty musí:
- Přijmout a pravidelně přezkoumávat strategii řízení rizik ICT třetích stran
- Udržovat registr informací o všech ujednáních s poskytovateli ICT služeb třetích stran
- Zajistit, aby smluvní ustanovení splňovala požadavky článku 30
- Provádět hloubkovou kontrolu před zahájením a v průběhu spolupráce
- Hlásit příslušným orgánům ujednání s třetími stranami
Smluvní rámec MazeVault je navržen tak, aby splňoval všechny požadavky článku 30 bez nutnosti individuálního vyjednávání standardních bezpečnostních ustanovení pro jednotlivé zákazníky.
3. Kapitola II — Řízení rizik ICT (články 5-16)¶
3.1 Mapovací tabulka¶
| Článek | Požadavek | Implementace MazeVault | Důkaz |
|---|---|---|---|
| Čl. 5 — Správa a organizace | Řídící orgán definuje, schvaluje a dohlíží na rámec řízení rizik ICT. Přiměřená nezávislost kontrolních funkcí. | Role CISO s přímým podřízeností CEO. Schválení ISP představenstvem (MV-LEG-001). Oddělení vývoje a bezpečnostního dohledu. Správa výboru pro rizika. | Záznamy o schválení představenstvem, jmenování CISO, organizační schéma, zápisy výboru pro rizika |
| Čl. 6 — Rámec řízení rizik ICT | Komplexní, dokumentovaný rámec řízení rizik ICT. Strategie, politiky, postupy, nástroje. Minimálně roční přezkum. | Kompletní ISMS: Politika informační bezpečnosti (MV-LEG-001), Politika řízení rizik (MV-LEG-002), 10+ podřízených politik. Roční cyklus přezkumu. ComplianceReportService pro průběžný monitoring. | Knihovna politik, záznamy o ročním přezkumu, zprávy o souladu, dokumentace rozsahu ISMS |
| Čl. 7 — ICT systémy, protokoly a nástroje | Používání a udržování aktualizovaných ICT systémů, protokolů a nástrojů. Přiměřené rozsahu a složitosti. | SSDLC s bezpečnostními branami. Skenování zranitelností při každém sestavení (Trivy, govulncheck). SLA pro záplatování (Kritické ≤48h). Automatizované aktualizace závislostí. Správa životního cyklu kontejnerových obrazů. | Konfigurace CI/CD pipeline, výsledky skenování zranitelností, záznamy o záplatování, protokoly aktualizací |
| Čl. 8 — Identifikace | Identifikace, klasifikace a dokumentace všech ICT aktiv. Mapování propojení. Identifikace závislostí. Minimálně roční přezkum. | database_health.go ExpectedTables pro identifikaci systémových aktiv. Správa konfigurací. Mapování závislostí služeb. Dokumentace datových toků. Klasifikace aktiv dle MV-LEG-005. | Inventář aktiv, mapy závislostí, diagramy datových toků, konfigurační databáze, záznamy o ročním přezkumu |
| Čl. 9 — Ochrana a prevence | Implementace politik, postupů a nástrojů bezpečnosti ICT. Řízení přístupu, autentizace, šifrování. | RBAC (8 rolí, 50+ oprávnění). Vynucení MFA. Šifrování AES-256-GCM. Povinné TLS 1.2+. Integrace HSM. Segmentace sítě. Bezpečnostní hlavičky. Validace vstupů. | Politika řízení přístupu (MV-LEG-003), Politika kryptografie (MV-LEG-004), konfigurace TLS, auditní protokoly HSM, matice oprávnění |
| Čl. 10 — Detekce | Mechanismy pro detekci anomálních aktivit. Více vrstev kontroly. | AnomalyDetectionService s behaviorální analýzou a detekcí vzorců založenou na ML. 17 detekčních pravidel připravených pro SIEM. Alertování Prometheus (CPU, paměť, latence, chybovost). Monitoring auditního protokolu s řetězenými hashi. Dashboardy v reálném čase. | Konfigurace pravidel SIEM, pravidla alertů Prometheus, protokoly detekce anomálií, konfigurace dashboardů, historie alertů |
| Čl. 11 — Reakce a obnova | Politika kontinuity provozu ICT. BCP a DRP. Postupy reakce a obnovy. | BCP/DRP (MV-LEG-008). Nasazení ve více datových centrech. Převzetí při selhání Gateway (aktivní/pasivní). Replikace databáze. Automatizované postupy převzetí. Definované cíle RTO/RPO. Automatizace zálohování a obnovy. | Dokument BCP/DRP, výsledky testů převzetí, zprávy z cvičení DR, záznamy měření RTO/RPO, protokoly ověření záloh |
| Čl. 12 — Politiky zálohování | Politiky zálohování a obnovy. Rozsah, frekvence, metody zálohování. Oddělení od primárního systému. Periodické testování. | Denní plné zálohy PostgreSQL. Zálohy transakčních protokolů každých 15 minut. Záloha šifrovacích klíčů do sekundárního HSM. Denní záloha konfigurace Vault. Geograficky oddělené úložiště záloh. Šifrovaná záložní data. Měsíční testování obnovy. | Politika zálohování, protokoly provádění záloh, výsledky testů obnovy, dokumentace geografického oddělení |
| Čl. 13 — Učení se a vývoj | Přezkum po incidentu. Poučení. Sdílení znalostí. Aktualizace rámce na základě incidentů a testování. | Povinný přezkum po incidentu pro všechny incidenty P1/P2. Dokumentace poučení. Aktualizace politik vyvolané nálezy. Přezkum bezpečnostní architektury po významných incidentech. Údržba znalostní báze. | Zprávy po incidentech, dokumenty poučení, historie změn politik, záznamy znalostní báze |
| Čl. 14 — Komunikace | Plány krizové komunikace. Interní a externí komunikační postupy. Určený mluvčí. | Postupy komunikace při incidentech v IRP (MV-LEG-007). Určené komunikační kanály podle závažnosti. Postupy oznámení zákazníkům. Pracovní postup komunikace s regulatorními orgány. Proces schvalování externí komunikace. | Komunikační plán, šablony oznámení, seznamy kontaktů, protokoly komunikace |
| Čl. 15 — Další harmonizace nástrojů, metod, procesů a politik řízení rizik ICT | Uplatnění RTS o podrobnostech rámce řízení rizik ICT. | Implementace v souladu s požadavky nařízení Komise v přenesené pravomoci 2024/1774 na prvky rámce řízení rizik ICT. | Kontrolní seznam souladu s RTS, dokumentace analýzy rozdílů |
| Čl. 16 — Zjednodušený rámec řízení rizik ICT | Přiměřený rámec pro subjekty splňující kritéria čl. 16 odst. 1. | Nepoužitelné. MazeVault implementuje plný rámec řízení rizik ICT, překračující zjednodušené požadavky. Všichni zákazníci z řad finančních subjektů těží z implementace plného rámce bez ohledu na vlastní posouzení proporcionality. | Nepoužitelné (plný rámec dokumentován) |
3.2 Komponenty rámce řízení rizik ICT¶
Rámec řízení rizik ICT společnosti MazeVault se skládá z:
┌─────────────────────────────────────────────────────────┐
│ SPRÁVA A DOHLED │
│ Schválení představenstvem │ Vlastnictví CISO │ Výbor │
│ pro rizika │
├─────────────────────────────────────────────────────────┤
│ POLITIKY A STANDARDY │
│ ISP (MV-LEG-001) │ Politika rizik │ 10+ podpolitik │
├─────────────────────────────────────────────────────────┤
│ TECHNICKÉ KONTROLY │
│ 5vrstvá bezpečnostní architektura │
│ Síť → Aplikace → Autentizace → Autorizace → Data │
├─────────────────────────────────────────────────────────┤
│ PROVOZNÍ PROCESY │
│ Monitoring │ Reakce na incidenty │ Řízení změn │
├─────────────────────────────────────────────────────────┤
│ PRŮBĚŽNÉ ZLEPŠOVÁNÍ │
│ Přezkumy rizik │ Audit │ Testování │ Poučení │
└─────────────────────────────────────────────────────────┘
4. Kapitola III — Řízení incidentů souvisejících s ICT (články 17-23)¶
4.1 Mapovací tabulka¶
| Článek | Požadavek | Implementace MazeVault | Důkaz |
|---|---|---|---|
| Čl. 17 — Proces řízení incidentů souvisejících s ICT | Definovat, zavést a implementovat proces řízení incidentů souvisejících s ICT. Indikátory včasného varování. Klasifikace. Postupy reakce. | IncidentService implementující kompletní životní cyklus incidentu: Detekce → Třídění → Klasifikace → Zadržení → Odstranění → Obnova → Přezkum po incidentu. Definované doby reakce podle závažnosti (P1: ≤15 min, P2: ≤1h, P3: ≤4h, P4: ≤24h). | Plán reakce na incidenty (MV-LEG-007), implementace IncidentService, záznamy o incidentech, metriky doby reakce |
| Čl. 18 — Klasifikace incidentů souvisejících s ICT a kybernetických hrozeb | Klasifikace na základě: dotčených klientů, ztráty dat, geografického rozšíření, trvání, ekonomického dopadu, kritičnosti. Významné kybernetické hrozby klasifikovány samostatně. | 4stupňová klasifikace závažnosti (P1-P4). Vícerozměrné posouzení dopadu: Důvěrnost, Integrita, Dostupnost, Rozsah, Trvání, Ekonomický dopad. CVSS hodnocení pro incidenty související se zranitelnostmi. Klasifikace hrozeb dle MITRE ATT&CK. | Klasifikační matice, záznamy o incidentech s klasifikací, posouzení CVSS, zprávy o hrozbách |
| Čl. 19 — Hlášení závažných incidentů souvisejících s ICT a významných kybernetických hrozeb | Hlášení závažných incidentů příslušnému orgánu: počáteční oznámení (4h od klasifikace), průběžná zpráva (72h), závěrečná zpráva (1 měsíc). | MazeVault umožňuje hlášení zákazníkům prostřednictvím: (1) Okamžitá interní detekce a klasifikace, (2) Oznámení zákazníkovi do 4h od zjištění incidentu s dopadem na zákazníka, (3) Strukturovaná data o incidentu v souladu s formátem hlášení ITS, (4) Časová osa a důkazy pro vlastní regulatorní hlášení zákazníka. | Protokoly oznámení zákazníkům, strukturované zprávy o incidentech, dokumentace časové osy, balíčky důkazů |
| Čl. 20 — Harmonizovaný obsah a šablony hlášení | Obsah hlášení dle šablon ITS: identifikace, klasifikace, dopad, příčina, řešení, poučení. | Zprávy o incidentech strukturovány dle formátu prováděcího nařízení Komise 2024/1773. Pole zahrnují: ID incidentu, klasifikaci, dotčené systémy, obchodní dopad, hlavní příčinu, časovou osu, nápravu. Zákazník obdrží předformátované důkazy. | Šablony zpráv o incidentech, vyplněné zprávy, dokumentace mapování polí ITS |
| Čl. 23 — Provozní nebo bezpečnostní incidenty související s platbami | Úvěrové instituce, platební instituce: hlášení provozních/bezpečnostních platebních incidentů dle PSD2. | MazeVault nezpracovává platby. Služby PKI/certifikátů MazeVault však podporují bezpečnost platebních systémů. MazeVault poskytuje důkazy na podporu hlášení platebních incidentů zákazníků, kde služby MazeVault jsou přispívajícím faktorem. | Nepoužitelné pro přímé hlášení; podpůrné důkazy dostupné pro zprávy zákazníků o platebních incidentech |
4.2 Soulad klasifikace incidentů s čl. 18 nařízení DORA¶
Podle nařízení Komise v přenesené pravomoci 2024/1772 jsou incidenty klasifikovány jako „závažné" na základě:
| Klasifikační kritérium | Prahová hodnota | Měření MazeVault |
|---|---|---|
| Dotčení klienti | >10 % klientů nebo >100 000 klientů | Oznámení zákazníkovi se spouští při jakémkoli dopadu na zákazníka |
| Ztráta integrity/důvěrnosti dat | Jakákoli potvrzená ztráta D/I | Okamžitá klasifikace P1 pro jakékoli narušení dat |
| Kritičnost dotčených služeb | Kritické nebo důležité funkce | Správa certifikátů/tajemství = ve výchozím nastavení kritická |
| Ekonomický dopad | >100 000 EUR přímých ztrát | Posouzení dopadu ve zprávě o incidentu |
| Trvání incidentu | >24 hodin (nebo >2h pro kritické funkce) | Sledování trvání v reálném čase v IncidentService |
| Geografické rozšíření | >2 členské státy | Posouzení rozsahu v klasifikaci incidentu |
4.3 Časová osa oznámení MazeVault¶
Detekce incidentu (T=0)
│
├── T+15 min: Interní třídění a klasifikace (P1)
│
├── T+1h: Zahájen postup zadržení
│
├── T+4h: Oznámení zákazníkovi (předběžné)
│ [Umožňuje zákazníkovi podat počáteční oznámení orgánu do 4h]
│
├── T+12h: Podrobné oznámení zákazníkovi
│
├── T+48h: Průběžná zpráva zákazníkovi
│ [Umožňuje zákazníkovi podat průběžnou zprávu do 72h]
│
├── T+14d: Závěrečná zpráva zákazníkovi
│ [Umožňuje zákazníkovi podat závěrečnou zprávu do 1 měsíce]
│
└── T+30d: Přezkum po incidentu dokončen
5. Kapitola IV — Testování digitální provozní odolnosti (články 24-27)¶
5.1 Mapovací tabulka¶
| Článek | Požadavek | Implementace MazeVault | Důkaz |
|---|---|---|---|
| Čl. 24 — Obecné požadavky na testování digitální provozní odolnosti | Zavést, udržovat a přezkoumávat spolehlivý program testování digitální provozní odolnosti. Přiměřeně velikosti a riziku. | Komplexní testovací program: průběžné automatizované skenování, periodické manuální testování, roční penetrační testy, cvičení DR. Testování pokrývá všechny kritické ICT systémy podporující správu certifikátů/tajemství. | Dokumentace testovacího programu, plán testů, archiv výsledků testů |
| Čl. 25 — Testování ICT nástrojů a systémů | Rozsah testů: posouzení zranitelností, analýzy open source, síťová bezpečnost, analýzy mezer, přezkumy fyzické bezpečnosti, skenování, přezkumy zdrojového kódu, testy založené na scénářích, kompatibilita, výkon, end-to-end testování. | Posouzení zranitelností: govulncheck (Go), Trivy (kontejnery), npm audit (Node.js). Analýza open source: generování SBOM (CycloneDX), soulad licencí. Síťová bezpečnost: skenování TLS, analýza portů. Přezkumy zdrojového kódu: povinný code review při PR, SAST. Testy založené na scénářích: integrační testování, chaos engineering. Testování výkonu: zátěžové testy, stresové testy. End-to-end testování: automatizované E2E testovací sady. | Zprávy ze skenování, SBOM, výsledky testů TLS, záznamy o přezkumech PR, výsledky testovacích sad, zprávy o výkonnostním testování |
| Čl. 26 — Pokročilé testování ICT nástrojů, systémů a procesů na základě TLPT | Penetrační testování řízené hrozbami (TLPT) pro významné finanční subjekty. Poskytovatelé ICT služeb třetích stran mohou být zahrnuti do rozsahu. Minimálně každé 3 roky. | MazeVault podporuje a spolupracuje na zákaznických TLPT zakázkách: (1) Poskytuje informace o rozsahu pro fázi zpravodajství o hrozbách, (2) Umožňuje kontrolované testování proti komponentám MazeVault, (3) Poskytuje přístup k protokolům během cvičení red team, (4) Účastní se nápravy po TLPT. MazeVault jednostranně neprovádí TLPT, ale spolupracuje, když zákazníci zahrnují MazeVault do rozsahu svého TLPT. | Záznamy o spolupráci na TLPT, dokumentace rozsahu, záznamy o poskytnutí protokolů, důkazy o nápravě |
| Čl. 27 — Požadavky na testery | Externí testeři: nejvyšší vhodnost a reputace. Odbornost v oblasti zpravodajství o hrozbách, penetračního testování, testování red team. Profesní certifikace. Pokryti pojištěním profesní odpovědnosti. | Roční penetrační test MazeVault provádí kvalifikovaná firma třetí strany splňující kritéria čl. 27: testeři certifikovaní CREST/OSCP, pojištění profesní odpovědnosti, zavedená reputace, potvrzená nezávislost. | Dokumentace kvalifikace testerů, certifikace, certifikáty pojištění, smlouvy o zakázce |
5.2 Přehled testovacího programu¶
| Typ testu | Nástroj/Metoda | Frekvence | Rozsah | Standard |
|---|---|---|---|---|
| Skenování zranitelností kontejnerů | Trivy | Při každém sestavení (průběžně) | Všechny kontejnerové obrazy | Databáze CVE |
| Skenování závislostí Go | govulncheck | Při každém sestavení (průběžně) | Všechny závislosti Go | Databáze zranitelností Go |
| Skenování frontendových závislostí | npm audit | Při každém sestavení (průběžně) | Všechny závislosti Node.js | Databáze npm advisory |
| SAST (statická analýza) | Go vet, staticcheck, ESLint | Při každém sestavení (průběžně) | Veškerý zdrojový kód | Pravidla specifická pro jazyk |
| Generování SBOM | CycloneDX | Při každém vydání | Kompletní inventář softwaru | CycloneDX 1.5 |
| Skenování konfigurace TLS | testssl.sh / SSL Labs | Měsíčně | Všechny externí koncové body | Pokyny Mozilla pro TLS |
| Penetrační test | Firma třetí strany | Ročně (Q4) | Plný rozsah (síť, aplikace, API) | OWASP, PTES |
| Cvičení DR | Interní tým | Ročně | Kompletní převzetí a obnova | Postupy BCP/DRP |
| Test obnovy ze zálohy | Automatizovaný + manuální | Měsíčně | Všechny typy záloh | Politika zálohování |
| Cvičení reakce na incidenty | Stolní cvičení | Ročně | Všechny úrovně závažnosti | Postupy IRP |
| Red team / TLPT (zákazník) | Řízeno zákazníkem | Dle požadavku zákazníka | Dle rozsahu stanoveného zákazníkem | TIBER-EU / DORA RTS |
5.3 Rámec spolupráce na TLPT¶
Pokud zákazník z řad finančních subjektů zahrnuje MazeVault do rozsahu svého TLPT (dle čl. 26):
- Fáze stanovení rozsahu: MazeVault poskytuje informace o architektuře systému, dokumentaci útočné plochy a specifikace API poskytovateli zpravodajství o hrozbách
- Fáze testování: MazeVault poskytuje kontrolované testovací prostředí nebo koordinuje živé testování s odpovídajícími ochrannými opatřeními
- Validace detekce: Detekční schopnosti MazeVault (AnomalyDetectionService, pravidla SIEM) jsou testovány bez předchozího upozornění personálu SOC
- Fáze důkazů: Plný přístup k protokolům poskytnut týmu TLPT pro rekonstrukci časové osy
- Fáze nápravy: Nálezy začleněny do procesu správy zranitelností s dohodnutými termíny nápravy
- Fáze hlášení: MazeVault přispívá do zprávy purple team a společného plánu nápravy
6. Kapitola V — Rizika třetích stran v oblasti ICT (články 28-44)¶
6.1 Přehled¶
Kapitola V je nejvíce přímo použitelná kapitola nařízení DORA pro vztah MazeVault se zákazníky z řad finančních subjektů. Stanoví:
- Zásady řízení rizik ICT třetích stran (čl. 28)
- Požadavky na předběžné posouzení a průběžnou hloubkovou kontrolu (čl. 29)
- Povinná smluvní ustanovení (čl. 30)
- Rámec dohledu nad CTPP (čl. 31-44)
6.2 Článek 28 — Obecné zásady¶
| Požadavek | Reakce MazeVault |
|---|---|
| Finanční subjekt zůstává plně odpovědný za dodržování předpisů | MazeVault uznává konečnou odpovědnost zákazníka; poskytuje nástroje a důkazy na podporu souladu |
| Strategie řízení rizik ICT třetích stran na úrovni subjektu | MazeVault podporuje strategii zákazníka poskytováním komplexní dokumentace rizik |
| Registr informací o všech smluvních ujednáních | MazeVault poskytuje veškeré informace potřebné pro registr zákazníka (viz oddíl 7) |
| Přiměřené řízení rizika koncentrace ICT | MazeVault podporuje možnosti vícenásobného nasazení (on-premise, Azure, hybridní) pro snížení koncentrace |
| Hloubková kontrola před zahájením a v průběhu spolupráce | Kompletní dokumentační balíček k dispozici; průběžně poskytovány důkazy o souladu |
6.3 Článek 29 — Předběžné posouzení¶
MazeVault poskytuje následující podklady pro předběžné posouzení zákazníkem:
| Dimenze posouzení | Poskytovaná dokumentace/důkazy |
|---|---|
| Vhodnost poskytovatele | Dokumentace schopností služby, reference zákazníků, dosavadní výsledky |
| Potenciální rizika (provozní, právní, regulatorní) | Dokumentace posouzení rizik, mapování regulatorního souladu (tento dokument) |
| Schopnost poskytovatele zajistit kontinuitu | BCP/DRP (MV-LEG-008), výsledky testů DR, dokumentace redundance architektury |
| Kvalita bezpečnostních opatření | ISMS v souladu s ISO 27001, výsledky penetračních testů, zprávy ze skenování zranitelností |
| Posouzení nahraditelnosti | Standardní protokoly, přenositelnost dat, dokumentovaná API, strategie ukončení |
| Soulad s ochranou osobních údajů | DPA, zpráva o souladu s nařízením GDPR, posouzení vlivu na soukromí |
| Místo zpracování dat | Zpracování v EU, zákazníkem kontrolovaná rezidence dat |
| Ujednání o subdodávání | Seznam subdodavatelů, dokumentace správy subdodavatelů |
| Finanční situace poskytovatele | Registrace společnosti, ukazatele finanční stability |
| Soulad s regulatorními požadavky | Toto mapování souladu s nařízením DORA, mapování souladu se směrnicí NIS2 (MV-LEG-020) |
6.4 Článek 30 — Klíčová smluvní ustanovení¶
Článek 30 stanoví konkrétní ustanovení ve smlouvách mezi finančními subjekty a poskytovateli ICT služeb třetích stran. Smluvní rámec MazeVault řeší každý požadavek:
6.4.1 Čl. 30 odst. 2 — Obecná ustanovení (všechny ICT služby)¶
| Požadavek čl. 30 odst. 2 | Smluvní ustanovení MazeVault | Odkaz na dokument |
|---|---|---|
| (a) Jasný a úplný popis všech funkcí a ICT služeb | Podrobný popis služby včetně: správy životního cyklu certifikátů, správy tajemství, služeb PKI, nasazení agenta, provozu gateway, respondéru OCSP. Specifikuje klasifikaci kritičnosti. | Přehled služeb (Příloha A k Rámcové smlouvě) |
| (b) Místa, kde budou smluvní/subdodavatelské funkce poskytovány a data zpracovávána | Zpracování v EU. Konkrétní místa dokumentována: primární region Azure (EU), region pro obnovu po havárii (EU). Možnost zákazníka on-premise. Místa subdodavatelů zveřejněna. | Smlouva o zpracování údajů §4, Seznam subdodavatelů |
| (c) Ustanovení o dostupnosti, autentičnosti, integritě a důvěrnosti dat | Šifrování AES-256-GCM (důvěrnost/integrita). Auditní protokoly s řetězenými hashi (autentičnost/integrita). Architektura dostupnosti s více DC. Cíle dostupnosti SLA. | Bezpečnostní příloha §3, SLA §2 |
| (d) Ustanovení o zajištění přístupu k datům, jejich obnovy a vrácení | Export dat ve standardních formátech (JSON, PEM, PKCS#12). Hromadný export přes API. Potvrzení bezpečného smazání. Období asistence při přechodu. | Příloha strategie ukončení, DPA §7 |
| (e) Popisy úrovní služeb včetně kvantitativních a kvalitativních cílů | SLA dostupnosti (minimálně 99,9 %). SLA doby odezvy. SLA oznámení incidentu (≤4h). SLA nápravy zranitelností. Metriky výkonu. | Dokument SLA (komplexní metriky) |
| (f) Pomoc v případě ICT incidentu bez dalších nákladů | Oznámení incidentu, poskytnutí důkazů, spolupráce při forenzní analýze, hlášení časové osy — vše zahrnuto v základní službě. Žádné dodatečné poplatky za spolupráci při reakci na incident. | Bezpečnostní příloha §6, ustanovení o reakci na incidenty |
| (g) Povinnost spolupracovat s příslušnými orgány | Plná spolupráce s NÚKIB, ČNB, ECB, EBA a dalšími příslušnými orgány. Žádné omezení přístupu regulátora k informacím o službách MazeVault. | Rámcová smlouva §12, doložka o regulatorní spolupráci |
| (h) Práva na ukončení | Zákazník může ukončit z důvodu (podstatné porušení, bezpečnostní incident, příkaz regulátora). Minimální 6měsíční výpovědní lhůta pro ukončení z důvodu pohodlí. Žádné uzamčení nad rámec výpovědní lhůty. | Rámcová smlouva §15, ustanovení o ukončení |
6.4.2 Čl. 30 odst. 3 — Ustanovení pro kritické/důležité funkce¶
| Požadavek čl. 30 odst. 3 | Smluvní ustanovení MazeVault | Odkaz na dokument |
|---|---|---|
| (a) Úplné SLA s přesnými kvantitativními a kvalitativními cíli | Komplexní SLA: dostupnost (99,9 %), latence (p95 <500ms), reakce na incident (P1: 15 min), vydání certifikátu (<5s), odpověď OCSP (<200ms). Sankce za porušení SLA. | Dokument SLA s měřitelnými KPI |
| (b) Výpovědní lhůty a oznamovací povinnosti | 30denní předběžné oznámení podstatných změn. Měsíční provozní zprávy. Čtvrtletní zprávy o souladu. Okamžité oznámení incidentů a bezpečnostních událostí. | SLA §5 (Hlášení), Bezpečnostní příloha §4 (Oznámení) |
| (c) Požadavky na bezpečnost ICT | Úplné bezpečnostní požadavky dle Bezpečnostní přílohy: standardy šifrování, řízení přístupu, správa zranitelností, monitoring, reakce na incidenty, testování, personální bezpečnost. | Bezpečnostní příloha (komplexní) |
| (d) Testování BCP a obnovy po havárii ICT | Roční přezkum BCP/DRP. Roční test DR se sdílenými výsledky. Zákazník může na požádání pozorovat cvičení DR. Oznámení podstatných změn BCP/DRP. | Příloha BCP/DRP, Zprávy z testů DR |
| (e) Účast na testování (včetně TLPT) | Neomezená spolupráce s programem testování provozní odolnosti zákazníka. Podpora zakázek TLPT. K dispozici kontrolované testovací prostředí. Přístup k protokolům pro cvičení red team. | Doložka o spolupráci na testování, rámec spolupráce na TLPT |
| (f) Neomezená práva na audit a inspekci | Právo na audit s 30denním oznámením (běžný) nebo okamžitě (z důvodu). Fyzický nebo vzdálený přístup. Bez omezení frekvence auditu (přiměřené). Povolení auditora třetí strany. Plný přístup k dokumentaci. | Doložka o právech na audit (Bezpečnostní příloha §5) |
| (g) Strategie ukončení | Komplexní strategie ukončení: plánování přechodu, export dat, předání znalostí, období paralelního provozu, bezpečné smazání, spolupráce při přechodu. Minimálně 6měsíční podpora přechodu. | Příloha strategie ukončení |
6.4.3 Čl. 30 odst. 4-5 — Subdodávání¶
| Požadavek | Ustanovení MazeVault |
|---|---|
| Právo vznést námitku proti subdodávání kritických funkcí | Ano. Zákazník má právo vznést námitku proti novým subdodavatelům do 30 dnů od oznámení. |
| Předchozí souhlas se subdodáváním kritických/důležitých funkcí | MazeVault získá výslovný souhlas před zapojením subdodavatelů pro kritické složky služby. |
| Informace o subdodavatelích | Kompletní seznam subdodavatelů: název subjektu, jurisdikce, poskytovaná služba, kritičnost. |
| Stejné smluvní požadavky se přenášejí na subdodavatele | Bezpečnostní požadavky smluvně přeneseny na všechny subdodavatele. |
| Oznámení zamýšlených změn v subdodávání | 30denní předběžné písemné oznámení jakéhokoli přidání nebo změny subdodavatele. |
6.5 Články 31-44 — Rámec dohledu (CTPP)¶
MazeVault není v současné době určen jako kritický poskytovatel služeb třetích stran (CTPP). MazeVault však udržuje povědomí o rámci dohledu a připravenost na něj:
| Prvek dohledu | Připravenost MazeVault |
|---|---|
| Monitorování kritérií pro určení | Roční sebehodnocení podle kritérií čl. 31 |
| Spolupráce s hlavním dohlížitelem | Určený regulatorní kontakt; postupy spolupráce dokumentovány |
| Poskytování informací | Schopnost poskytnout veškeré informace požadované podle čl. 37 |
| Obecná vyšetřování/inspekce | Dokumentace připravená na audit; politika regulatorní spolupráce |
| Soulad s doporučeními | Proces implementace doporučení dohledu v předepsaných lhůtách |
| Riziko periodických penále | Řízení souladu k zamezení nesouladu vyvolávajícího sankce |
7. Registr informací (čl. 28 odst. 3)¶
7.1 Přehled¶
Finanční subjekty musí udržovat registr informací o všech smluvních ujednáních s poskytovateli ICT služeb třetích stran (dle prováděcího nařízení Komise 2024/1778). MazeVault poskytuje veškeré informace potřebné pro záznam v registru zákazníka.
7.2 Informace poskytované pro registr zákazníka¶
| Pole registru | Informace MazeVault |
|---|---|
| Identifikace poskytovatele | MazeVault s.r.o., IČO: [registrováno], sídlo: Česká republika |
| LEI | [Identifikátor právnické osoby — k dispozici na vyžádání] |
| Popis služby | Správa životního cyklu certifikátů, správa tajemství, služby PKI (CA, OCSP), správa klíčů, zajišťování certifikátů na bázi agenta, konektivita gateway |
| Klasifikace služby | ICT služba podporující bezpečnostní a kryptografickou infrastrukturu |
| Posouzení kritičnosti | Stanoveno zákazníkem; MazeVault poskytuje vstupy pro posouzení dopadu |
| Datum zahájení ujednání | Dle data uzavření smlouvy se zákazníkem |
| Doba trvání smlouvy | Dle podmínek Rámcové smlouvy (typicky roční obnova) |
| Výpovědní lhůta | 6 měsíců (minimum) |
| Místa zpracování dat | EU — konkrétní region Azure dle nasazení; možnost on-premise u zákazníka |
| Místa uložení dat | Shodná s místy zpracování (žádné samostatné jurisdikce úložiště) |
| Subdodávání | Seznam subdodavatelů poskytnut (viz oddíl 9) |
| Posouzení nahraditelnosti | Standardní API (ACME, EST, CMP); data exportovatelná ve standardních formátech; dokumentovaná cesta migrace |
| Důvod nenahraditelnosti | Nepoužitelné — MazeVault je navržen s ohledem na nahraditelnost s dokumentovanými postupy ukončení |
| Datum posledního auditu | [Dle plánu auditů — minimálně ročně] |
| Smluvní záruky | Bezpečnostní příloha, DPA, SLA, Strategie ukončení, Práva na audit, ustanovení BCP/DRP |
| Koncentrace rizika | MazeVault podporuje strategie více poskytovatelů; nasazení on-premise eliminuje koncentraci v cloudu |
7.3 Roční aktualizace registru¶
MazeVault poskytuje zákazníkům aktualizované informace pro registr: - Ročně — proaktivní aktualizace všech polí registru - Při změně — okamžité oznámení podstatných změn (do 30 dnů od změny) - Na vyžádání — do 10 pracovních dnů od žádosti zákazníka
8. Ustanovení o strategii ukončení (čl. 28 odst. 8)¶
8.1 Regulatorní požadavek¶
Článek 28 odst. 8 požaduje, aby finanční subjekty zavedly strategie ukončení zohledňující: - Rizika vyplývající ze selhání poskytovatele ICT služeb třetí strany - Zhoršení kvality služeb - Narušení provozu v důsledku nevhodného nebo neúspěšného přechodu služby - Omezení porozumění riziku z komplexních řetězců subdodávání
8.2 Strategie ukončení MazeVault¶
MazeVault poskytuje komplexní, dokumentovanou strategii ukončení:
| Fáze ukončení | Trvání | Činnosti | Povinnosti MazeVault |
|---|---|---|---|
| Oznámení | Měsíc 0 | Zákazník podá výpověď (min. 6 měsíců) | Potvrzení, zahájení plánování přechodu |
| Plánování | Měsíc 1-2 | Společné plánování přechodu, identifikace nástupce poskytovatele | Poskytnutí dokumentace migrace, specifikací API, datových schémat |
| Paralelní provoz | Měsíc 2-5 | Nastavení nástupce poskytovatele, migrace dat, testování | Pokračování plné služby, poskytnutí exportů dat, zodpovězení technických dotazů |
| Migrace | Měsíc 4-5 | Aktivní přenos dat, příprava přepnutí systému | Export všech dat ve standardních formátech, ověření úplnosti, podpora testování |
| Přepnutí | Měsíc 5-6 | Přechod služby na nástupce | Konečná synchronizace dat, předání služby, dostupnost během přepnutí |
| Po přechodu | Měsíc 6+ (30 dní) | Validace, řešení problémů | Podpora po přechodu, řešení problémů, konečné potvrzení dat |
| Bezpečné smazání | Po potvrzení | Trvalé smazání dat zákazníka | Kryptografické smazání, vydání potvrzení o smazání |
8.3 Přenositelnost dat¶
| Typ dat | Formát exportu | Metoda |
|---|---|---|
| Certifikáty | PEM, DER, PKCS#12 | Hromadný export přes API, stažení souboru |
| Soukromé klíče (pokud spravované MazeVault) | PEM (šifrovaný), PKCS#12 | Bezpečný export s šifrovacím klíčem zákazníka |
| Tajemství | JSON (šifrovaný) | Hromadný export přes API |
| Auditní protokoly | JSON (s řetězenými hashi) | Export přes API, hromadné stažení souboru |
| Konfigurace | JSON, YAML | Export přes API |
| Politiky certifikátů | JSON | Export přes API |
| Data uživatelů/rolí | JSON | Export přes API |
8.4 Nenarušování¶
MazeVault garantuje: - Žádné zhoršení kvality služby během výpovědní/přechodové doby - Žádné odebrání přístupu nebo funkcí během přechodu - Pokračující bezpečnostní monitoring a reakce na incidenty během přechodu - Žádné dodatečné poplatky za standardní asistenci při přechodu - Žádné scénáře zadržování dat — všechna data zákazníka exportovatelná kdykoli během doby trvání smlouvy
9. Oznámení o subdodávání (čl. 29 odst. 2, čl. 30 odst. 4-5)¶
9.1 Seznam subdodavatelů¶
MazeVault udržuje aktuální seznam všech subdodavatelů zapojených do poskytování služeb:
| Subdodavatel | Poskytovaná služba | Místo | Kritičnost | Přístup k datům |
|---|---|---|---|---|
| Microsoft Azure | Cloudová infrastruktura (výpočetní prostředky, úložiště, síť) | EU (zákazníkem vybraný region) | Kritická | Na úrovni infrastruktury (šifrovaná data v klidu) |
| Azure Key Vault | Správa klíčů s podporou HSM | EU (stejný region jako nasazení) | Kritická | Operace s klíči (žádný přístup k nešifrovaným klíčům zákazníka) |
| PostgreSQL (spravovaný Azure nebo zákazníkem) | Databázová služba | EU (stejný region jako nasazení) | Kritická | Šifrované uložení dat |
| Container Registry | Úložiště kontejnerových obrazů | EU | Významná | Aplikační obrazy MazeVault (žádná data zákazníka) |
| CI/CD Platform | Automatizace sestavení a nasazení | EU/US (žádná data zákazníka zpracovávána) | Standardní | Zdrojový kód, artefakty sestavení (žádná data zákazníka) |
Poznámka: Při nasazení on-premise se cloudoví subdodavatelé nemusí uplatňovat. Infrastruktura zákazníka slouží jako hostingová platforma pod vlastními kontrolami zákazníka.
9.2 Postup oznámení¶
| Krok | Časový rámec | Popis |
|---|---|---|
| 1 | T-30 dní | Písemné oznámení zákazníkovi o zamýšlené změně subdodavatele (přidání, odebrání nebo podstatná úprava) |
| 2 | T-30 až T-0 | Období přezkumu zákazníkem; zákazník může vznést námitku |
| 3 | Při námitce | MazeVault zahájí konzultaci; pokud nevyřešeno, zákazník může ukončit smlouvu |
| 4 | Bez námitky | Změna proběhne k plánovanému datu |
| 5 | Po změně | Poskytnut aktualizovaný seznam subdodavatelů; aktualizovány informace pro registr |
9.3 Práva zákazníka¶
- Právo být informován: 30denní předběžné oznámení všech změn subdodavatelů
- Právo vznést námitku: Písemná námitka v 30denní oznamovací lhůtě
- Právo na ukončení: Pokud námitka nevyřešena, zákazník může ukončit bez sankce
- Právo na audit: Práva auditu subdodavatelů přenesena prostřednictvím smluv MazeVault
- Právo na informace: Aktualizovaný seznam subdodavatelů kdykoli k dispozici na vyžádání
10. Důkazy o souladu¶
10.1 Katalog důkazů¶
MazeVault poskytuje následující důkazní artefakty na podporu souladu zákazníků z řad finančních subjektů s nařízením DORA:
| Kategorie | Důkazní artefakt | Frekvence | Formát | Účel |
|---|---|---|---|---|
| Řízení rizik ICT | Politika řízení rizik | Na vyžádání | Důkaz čl. 5-6 | |
| Řízení rizik ICT | Registr rizik (relevantní záznamy) | Čtvrtletní souhrn | Důkaz čl. 6 | |
| Řízení rizik ICT | Zpráva o souladu (ISO 27001) | Na vyžádání (API) | JSON/PDF | Soulad s rámcem |
| Řízení rizik ICT | Zpráva o souladu (SOC 2) | Na vyžádání (API) | JSON/PDF | Kritéria důvěryhodných služeb |
| Ochrana | Dokumentace řízení přístupu | Na vyžádání | Důkaz čl. 9 | |
| Ochrana | Dokumentace šifrování/správy klíčů | Na vyžádání | Důkaz čl. 9 | |
| Detekce | Dokumentace pravidel SIEM | Na vyžádání | Důkaz čl. 10 | |
| Detekce | Konfigurace detekce anomálií | Na vyžádání | Důkaz čl. 10 | |
| Testování | Roční zpráva o penetračním testu (manažerský souhrn) | Ročně (Q4) | Důkaz čl. 24-25 | |
| Testování | Souhrn průběžného skenování zranitelností | Čtvrtletně | Důkaz čl. 25 | |
| Testování | SBOM (CycloneDX) | Při každém vydání | XML/JSON | Čl. 25 (analýza open source) |
| Řízení incidentů | Plán reakce na incidenty | Na vyžádání | Důkaz čl. 17 | |
| Řízení incidentů | Historie incidentů (relevantní pro zákazníka) | Na vyžádání | PDF/JSON | Důkaz čl. 17-19 |
| Řízení incidentů | Zprávy po incidentu | Při každém incidentu | Důkaz čl. 13, 17 | |
| Kontinuita | Dokumentace BCP/DRP | Na vyžádání | Důkaz čl. 11-12 | |
| Kontinuita | Výsledky testů DR | Ročně | Důkaz čl. 11-12 | |
| Kontinuita | Výsledky ověření záloh | Měsíční souhrn | Důkaz čl. 12 | |
| Rizika třetích stran | Seznam subdodavatelů | Na vyžádání / při změně | Důkaz čl. 29-30 | |
| Rizika třetích stran | Dokumentace správy subdodavatelů | Na vyžádání | Důkaz čl. 29 | |
| Audit | Exporty auditních protokolů (specifické pro zákazníka) | Na vyžádání | JSON | Důkaz čl. 30 odst. 3 písm. f) |
| Audit | Zpráva o ověření řetězených hashí | Na vyžádání | Důkaz integrity protokolů |
10.2 API pro hlášení souladu¶
ComplianceReportService společnosti MazeVault poskytuje automatizované zprávy o souladu:
GET /api/v1/compliance/iso27001 → Stav kontrol ISO 27001
GET /api/v1/compliance/soc2 → Kritéria důvěryhodných služeb SOC 2
GET /api/v1/compliance/pci-dss → Relevantní kontroly PCI DSS
GET /api/v1/compliance/gdpr → Stav souladu s nařízením GDPR
Každá zpráva obsahuje: - Stav implementace kontroly (Implementováno / Částečně implementováno / Plánováno) - Odkazy na důkazy - Datum posledního posouzení - Odpovědný vlastník - Harmonogram nápravy (pokud je relevantní)
10.3 Poskytování důkazů na vyžádání¶
- Standardní žádosti: Důkazy poskytnuty do 10 pracovních dnů
- Naléhavé žádosti (regulatorní šetření): Důkazy poskytnuty do 5 pracovních dnů
- Žádosti související s incidenty: Důkazy poskytnuty do 24 hodin
- Podpora auditu: Vyhrazený zdroj k dispozici během auditů zákazníka
11. Související dokumenty¶
| ID dokumentu | Název | Relevance pro DORA |
|---|---|---|
| MV-LEG-001 | Politika informační bezpečnosti | Čl. 5-6 (rámec řízení rizik ICT) |
| MV-LEG-002 | Politika řízení rizik | Čl. 5-6 (správa rizik) |
| MV-LEG-003 | Politika řízení přístupu | Čl. 9 (ochrana a prevence) |
| MV-LEG-004 | Politika kryptografie | Čl. 9 (šifrování, správa klíčů) |
| MV-LEG-005 | Politika klasifikace a uchovávání dat | Čl. 8 (identifikace), čl. 12 (zálohování) |
| MV-LEG-007 | Plán reakce na incidenty | Čl. 17-19 (řízení incidentů) |
| MV-LEG-008 | Kontinuita provozu a obnova po havárii | Čl. 11-12 (reakce, obnova, zálohování) |
| MV-LEG-009 | Politika protokolování a monitoringu | Čl. 10 (detekce) |
| MV-LEG-010 | Politika správy zranitelností a záplatování | Čl. 7 (údržba systémů), čl. 24-25 (testování) |
| MV-LEG-011 | Politika řízení rizik třetích stran | Čl. 28-30 (rizika ICT třetích stran) |
| MV-LEG-020 | Soulad se směrnicí NIS2 / zákonem č. 264/2025 Sb. o kybernetické bezpečnosti | Doplňkový soulad s českou národní legislativou |
Příloha A — Křížový rejstřík článků nařízení DORA¶
| Článek | Název | Oddíl v tomto dokumentu |
|---|---|---|
| Čl. 3 odst. 21 | Definice poskytovatele ICT služeb třetí strany | §2.1 |
| Čl. 5 | Správa a organizace | §3.1 |
| Čl. 6 | Rámec řízení rizik ICT | §3.1 |
| Čl. 7 | ICT systémy, protokoly a nástroje | §3.1 |
| Čl. 8 | Identifikace | §3.1 |
| Čl. 9 | Ochrana a prevence | §3.1 |
| Čl. 10 | Detekce | §3.1 |
| Čl. 11 | Reakce a obnova | §3.1 |
| Čl. 12 | Politiky zálohování | §3.1 |
| Čl. 13 | Učení se a vývoj | §3.1 |
| Čl. 14 | Komunikace | §3.1 |
| Čl. 16 | Zjednodušený rámec řízení rizik ICT | §3.1 |
| Čl. 17 | Proces řízení incidentů souvisejících s ICT | §4.1 |
| Čl. 18 | Klasifikace incidentů souvisejících s ICT | §4.1, §4.2 |
| Čl. 19 | Hlášení závažných incidentů souvisejících s ICT | §4.1 |
| Čl. 20 | Harmonizovaný obsah hlášení | §4.1 |
| Čl. 23 | Incidenty související s platbami | §4.1 |
| Čl. 24 | Obecné požadavky na testování | §5.1 |
| Čl. 25 | Testování ICT nástrojů a systémů | §5.1, §5.2 |
| Čl. 26 | Pokročilé testování (TLPT) | §5.1, §5.3 |
| Čl. 27 | Požadavky na testery | §5.1 |
| Čl. 28 | Obecné zásady (rizika třetích stran) | §6.2 |
| Čl. 29 | Předběžné posouzení | §6.3 |
| Čl. 30 | Klíčová smluvní ustanovení | §6.4 |
| Čl. 31-44 | Rámec dohledu (CTPPs) | §6.5 |
| Čl. 28 odst. 3 | Registr informací | §7 |
| Čl. 28 odst. 8 | Strategie ukončení | §8 |
Řízení dokumentu¶
| Verze | Datum | Autor | Změny |
|---|---|---|---|
| 1.0.0 | 2026-05-01 | CISO | Úvodní vydání |
Tento dokument je spravován týmem informační bezpečnosti MazeVault a podléhá ročnímu přezkumu. V případě dotazů k tomuto dokumentu nebo záležitostem souladu s nařízením DORA kontaktujte CISO nebo tým právního souladu.