Szkielet decision-support, który pomaga zespołowi ułożyć zgłoszenie poważnego incydentu ICT zgodnie z rozporządzeniem DORA (art.19): oś czasu raportowania, checklist kompletności i szablon pakietu dowodowego. To wsparcie decyzji, nie porada prawna. Każda pozycja wymaga evidence basis — bez dowodu (link/hash/incydent) pole zostaje otwarte, nie domknięte.
DORA art.19 nakłada na podmioty finansowe obowiązek zgłaszania poważnych incydentów związanych z ICT właściwemu organowi w ustalonych oknach czasowych (wstępne / pośrednie / końcowe). DORA Pack porządkuje ten proces jako wsparcie decyzji: pomaga zebrać fakty, przyporządkować je do wymaganych pól i wygenerować szkielet pakietu (JSON), z którego można przygotować dokument PDF do przeglądu prawnego przed wysyłką.
Poniższe okna są orientacyjne i służą jako wsparcie planowania. Dokładne terminy, definicja „istotnej zmiany statusu" oraz progi klasyfikacji wynikają z rozporządzenia DORA i aktów wykonawczych (RTS/ITS) — zawsze potwierdź z prawnikiem i wytycznymi organu. Data weryfikacji treści: 2026-07-05.
| Etap | Orientacyjne okno | Co zawiera (wsparcie) | Evidence basis |
|---|---|---|---|
| Zgłoszenie wstępne (initial notification) |
Możliwie najszybciej po klasyfikacji jako poważny — orientacyjnie w ciągu godzin od ustalenia; potwierdź RTS/ITS. | Fakt wystąpienia, wstępny zakres, dotknięte usługi, status. Minimalny zestaw pól. | Wpis incydentu + znacznik czasu wykrycia/klasyfikacji. |
| Raport pośredni (intermediate report) |
Po istotnej zmianie statusu obsługi lub w oknie wskazanym przez akty wykonawcze. | Aktualizacja zakresu, wpływ, działania naprawcze w toku, przyczyna wstępna. | Log działań + zmiany statusu incydentu. |
| Raport końcowy (final report) |
Po zamknięciu i analizie przyczyn źródłowych — w oknie z RTS/ITS. | Root cause, pełny wpływ, wnioski, działania zapobiegawcze. | Pakiet dowodowy zamknięcia (evidence-package) + chain-of-custody. |
Interaktywny odliczacz okien → /deadline-clock · graficzna oś → /dora-timeline. Oba jako wsparcie planowania, nie jako wiążący termin prawny.
Pola oparte na strukturze zgłoszenia DORA art.19. Każde pole ma mieć evidence basis — dopóki brak dowodu, pole traktujemy jako otwarte (nie zaznaczone). To checklist wsparcia, nie automatyczne domknięcie obowiązku.
| # | Pole | Opis | Wymagany dowód |
|---|---|---|---|
| 1 | Identyfikacja podmiotu | Nazwa, kod LEI, rola, właściwy organ nadzoru. | Rejestr podmiotu. |
| 2 | Klasyfikacja incydentu | Czy spełnia progi „poważnego" (major) wg kryteriów DORA/RTS. | Ocena progowa + akceptacja prawna. |
| 3 | Czas wykrycia / wystąpienia | Znaczniki czasu: wystąpienie, wykrycie, klasyfikacja. | Log/monitoring z timestampem. |
| 4 | Dotknięte usługi i systemy | Lista usług ICT, funkcji krytycznych, klientów/kontrahentów. | Mapa zależności / CMDB. |
| 5 | Wpływ | Zakres geograficzny, liczba dotkniętych, wpływ finansowy/reputacyjny. | Dane operacyjne + wyliczenia. |
| 6 | Działania naprawcze | Podjęte i planowane kroki mitigacji oraz przywrócenia usług. | Log działań / playbook. |
| 7 | Przyczyna źródłowa | Root cause (wstępny → końcowy) i wektor. | Analiza RCA (raport końcowy). |
| 8 | Powiadomienia stron trzecich | Czy i kiedy poinformowano klientów, dostawców ICT, inne organy. | Rejestr komunikacji. |
| 9 | Pakiet dowodowy | Załączony evidence-package z hashem integralności i chain-of-custody. | package_sha256 + manifest. |
| 10 | Przegląd prawny | Draft przejrzany przez radcę/kancelarię przed wysyłką do organu. | Akceptacja prawna (podpis/log). |
Struktura wyjściowa DORA Pack (MVP). To szkielet — pola bez dowodu pozostają puste/oznaczone
evidence: null. Wartości poniżej są przykładowe/syntetyczne, wyłącznie ilustracyjne.
{
"pack": "dora-major-ict-incident",
"version": "mvp-0.1",
"doctrine": "claim <= proof",
"disclaimer": "decision-support, nie porada prawna",
"entity": {
"name": null,
"lei": null,
"competent_authority": null
},
"incident": {
"classification": { "major": null, "basis": "RTS thresholds", "evidence": null },
"timestamps": {
"occurred": null,
"detected": null,
"classified": null
},
"affected_services": [],
"impact": { "geographic": null, "clients": null, "financial": null }
},
"reporting": {
"initial": { "due_window": "orientacyjne — potwierdz RTS/ITS", "status": "open", "evidence": null },
"intermediate": { "due_window": "orientacyjne — potwierdz RTS/ITS", "status": "open", "evidence": null },
"final": { "due_window": "orientacyjne — potwierdz RTS/ITS", "status": "open", "evidence": null }
},
"remediation": [],
"root_cause": { "preliminary": null, "final": null },
"evidence_package": { "package_sha256": null, "chain_of_custody": [] },
"legal_review": { "reviewed_by": null, "approved": false }
}
status może przejść z open na ready
dopiero, gdy evidence nie jest null (link do incydentu, hash pakietu, log akceptacji).
Bez dowodu pakiet zostaje szkicem — zgodnie z doktryną claim ≤ proof.
DORA Pack ma docelowo produkować dokument PDF do przeglądu prawnego. Poniżej opis zamierzonego procesu — uczciwie oznaczony statusem.
package_sha256 i manifest
chain-of-custody (jak w evidence-package ipIII). ROADMAP dla PAdES/TSA — dziś tylko hash treści.| Element | Status | Uwaga |
|---|---|---|
| Checklist 10 pól + evidence basis | MVP | Szkielet do wypełnienia ręcznego; walidacja kompletności manualna. |
| Oś czasu raportowania (opis) | MVP | Okna orientacyjne; terminy wiążące z RTS/ITS + prawnik. |
| Szkielet pakietu JSON | MVP | Struktura pól; wartości syntetyczne/przykładowe. |
| Automatyczny render PDF z JSON | ROADMAP | Renderer nie jest podpięty. |
| Podpis PAdES + znacznik czasu TSA | ROADMAP | Dziś tylko hash integralności treści. |
| Automatyczna klasyfikacja „major" | ROADMAP | Wymaga oceny progowej + akceptacji prawnej; nie automatyzujemy obowiązku. |
| Odliczacz okien (deadline-clock) | ROADMAP | Wsparcie planowania → /deadline-clock. |
| Przegląd prawny przed wysyłką | always | Trwałe z założenia — narzędzie nie zastępuje prawnika. |
Powiązane: katalog pakietów → /regulatory-packs · panel prawny → /legal-board · oś czasu DORA → /dora-timeline · odliczacz terminów → /deadline-clock.