ipIII to szkielet MVP warstwy evidence dla podmiotów finansowych objętych DORA i NIS2: incydent → dowód → owner → raport. Terminy ustawowe pokazujemy jako decision-support — nie jako poradę prawną. To, co działa dziś, oznaczamy LIVE; to, co jest w budowie — ROADMAP.
Podmioty finansowe pod DORA (Digital Operational Resilience Act) i NIS2 muszą wykazać nie tylko, że incydent został wykryty, ale że powstał dowód (evidence-package z hashem integralności), że ktoś jest jego właścicielem (owner z odpowiedzialnością i terminem) i że da się to złożyć w formie zrozumiałej dla organu nadzoru. ipIII spina te trzy elementy w jeden przepływ zamiast trzech osobnych arkuszy.
Finding z pentestu/skanu trafia do incydentu, incydent do evidence-package z sha256
integralności i chain-of-custody w bazie. Zamiast szukać dowodu w mailach — jest jeden rekord.
Każdy incydent ma przypisanego właściciela i deadline. To odpowiedź na wymóg DORA dotyczący jasnej odpowiedzialności operacyjnej za reagowanie na incydent ICT.
Deadline Clock i Legal Trigger Engine pokazują orientacyjne okna zgłoszeniowe (np. wczesne ostrzeżenie / raport wstępny / raport końcowy przy poważnym incydencie ICT). To narzędzie wspierające decyzję compliance — nie zastępuje porady prawnej.
CISO Board Pack i Regulatory Packs porządkują dowody w formę czytelną dla zarządu, audytora wewnętrznego lub partnera bankowego — bez ręcznego składania slajdów przed każdym spotkaniem.
| Etap | Co się dzieje | Jaki dowód powstaje | Status |
|---|---|---|---|
| 1. Import | Wynik skanera/pentestu (np. Burp, ZAP, Nessus) trafia do systemu przez parser konektora. | Rekord findingu z metadanymi źródła i czasem importu. | LIVE |
| 2. Incydent | Finding klasyfikowany jest jako incydent z przypisanym ownerem i priorytetem. | Wpis w rejestrze incydentów, powiązany z findingiem źródłowym. | LIVE |
| 3. Evidence-package | System generuje pakiet dowodowy (manifest, hash sha256, chain-of-custody). |
Plik/JSON z integralnością potwierdzoną hashem — dowód niezmienności treści. | LIVE |
| 4. Retest / close-with-evidence | Po naprawie — retest potwierdza zamknięcie, z odniesieniem do dowodu pierwotnego. | Zamknięcie z linkiem do evidence-package, nie „zamknięte bo ktoś powiedział". | LIVE |
| 5. Legal Trigger / Deadline Clock | Silnik decision-support sugeruje, czy incydent może podlegać obowiązkowi zgłoszenia (DORA/NIS2). | Wskazanie orientacyjnego okna czasowego — do potwierdzenia przez compliance/prawnika. | LIVE (silnik) / ROADMAP (automatyczne wysyłki do organu) |
| 6. Raport / pakiet | Regulatory Packs i CISO Board Pack składają dowody w gotowy do przeglądu dokument. | Pakiet z manifestem i odniesieniami do evidence-package poszczególnych incydentów. | LIVE |
Szczegóły przepływu DORA/TIBER i mapowanie na test resilience operacyjnej: /ai-truth/ipIII/dora-tiber. Gotowe szablony pakietu DORA: /ai-truth/ipIII/dora-pack.
Obsługa wielu klientów w jednej instancji z pełną izolacją danych to ROADMAP, nie funkcja dostępna dziś.
Strumieniowa integracja z SIEM (Splunk/Sentinel/QRadar) to ROADMAP. Dziś import odbywa się z plików skanerów.
System nie wysyła zgłoszeń do KNF/CSIRT automatycznie — to zawsze decyzja i akcja człowieka po weryfikacji compliance.
Pełny, jawny rejestr ograniczeń z ryzykiem, mitigacją i priorytetem: /ai-truth/ipIII/known-limitations.
sha256 i chain-of-custody w bazie — to
dowód niezmienności treści, ale nie jest to jeszcze kwalifikowany podpis elektroniczny (PAdES/TSA).
Formalny podpis dowodu jest oznaczony jako ROADMAP w rejestrze
known-limitations.Powiązane: pełny rejestr znanych ograniczeń → /known-limitations · macierz statusów wszystkich elementów → /status-matrix.