Jedna oś czasu incydentu odpowiadająca na pytanie „kiedy, komu i na jakiej podstawie trzeba było zgłosić?". Od wykrycia przez kwalifikację po progi RODO 72h, NIS2, DORA i AI Act — z zapisem kto podjął decyzję i jaki dowód był jej podstawą. To wsparcie decyzji (decision-support), NIE porada prawna. Terminy orientacyjne — wiążącą kwalifikację robi prawnik.
Zamiast osobno pilnować RODO, NIS2, DORA i AI Act, ipIII układa je na wspólnej osi czasu liczonej od momentu wykrycia. Każdy próg to pytanie decyzyjne z przypisanym właścicielem i wymaganym dowodem — nie automatyczna kwalifikacja. Kwalifikacja prawna pozostaje po stronie człowieka.
Poniższy przebieg jest syntetyczny (dane przykładowe, nie realny incydent). Czasy liczone od T0 = moment wykrycia. Kolory węzłów: próg / zegar · zdarzenie · decyzja człowieka.
Konektor zaciągnął finding ze skanera (przykład: eksfiltracja logów z systemu przetwarzającego dane osobowe klientów). Utworzono incydent, nadano ID, zapisano hash artefaktu.
finding_sha256 + wpis audit-log (timestamp wykrycia)Triaż: potwierdzono, że zdarzenie dotyczy danych osobowych i systemu istotnego dla usług. Nadano wstępną kategorię wagi. To kwalifikacja techniczna, nie prawna.
Pytanie: czy doszło do naruszenia ochrony danych osobowych o ryzyku dla praw i wolności osób? Jeśli tak — orientacyjny termin 72 h od stwierdzenia naruszenia (zgłoszenie do organu nadzorczego, np. UODO). Zegar i checklistę prowadzi Deadline Clock; pakiet dowodowy → RODO Pack.
Pytanie: czy organizacja jest podmiotem objętym NIS2 i czy incydent jest istotny? Jeśli tak — reżim przewiduje etapowe powiadomienia CSIRT (m.in. wczesne ostrzeżenie orientacyjnie w krótkim oknie oraz raport następczy). Konkretne progi i okna zależą od kwalifikacji podmiotu i implementacji krajowej — ustala prawnik / compliance.
Pytanie: czy podmiot podlega DORA i czy incydent ICT jest „istotny"? Jeśli tak — reżim przewiduje raportowanie do właściwego organu (wstępne / pośrednie / końcowe) w oknach zależnych od klasyfikacji. Pakiet i mapowanie obowiązków → DORA Pack. Klasyfikacja istotności jest decyzją człowieka.
Pytanie: czy w incydencie uczestniczy system AI wysokiego ryzyka i czy zaszedł „poważny incydent"? Jeśli tak — reżim przewiduje zgłoszenie do właściwego organu. Uwaga: część obowiązków high-risk (Aneks III) ma orientacyjnie odroczony termin stosowania (do 2027) — kwalifikacja i harmonogram to sprawa prawnika.
Zapis imienny/ról: kto zatwierdził (lub odrzucił) każde zgłoszenie w każdym reżimie, z uzasadnieniem. Narzędzie rejestruje decyzję — nie podejmuje jej za człowieka.
Do każdej decyzji dowiązany jest materiał dowodowy (finding, klasyfikacja, ocena ryzyka, korespondencja) z sumą kontrolną i chain-of-custody. Pełny przegląd i eksport → Legal Board.
sha256) + łańcuch dowiązań decyzja→artefaktZgodnie z doktryną claim ≤ proof: rozdzielamy to, co dowiedlnie działa, od tego, co planowane. Data weryfikacji: 2026-07-05.
| Element osi czasu | Co robi dziś | Status |
|---|---|---|
| Węzły „wykryto / zakwalifikowano" | Import findings, utworzenie incydentu, hash artefaktu, audit-log z czasem — warstwa evidence MVP. | LIVE (MVP) |
| Progi RODO 72h / NIS2 / DORA / AI Act | Prezentacja sekwencji pytań decyzyjnych z właścicielem i wymaganym dowodem. Terminy orientacyjne, mapowanie poglądowe. | MVP |
| Automatyczne liczenie zegarów per reżim | Zegar odliczający okna raportowe i alerty przy zbliżaniu terminu — dziś częściowo w Deadline Clock, pełne spięcie z osią czasu planowane. | ROADMAP |
| Wiążąca kwalifikacja prawna progu | Nie realizujemy i nie planujemy automatyzować. Kwalifikacja „czy trzeba zgłosić" pozostaje przy prawniku — trwałe z założenia. | always human |
| Eksport osi czasu do pakietu dla organu | Złożenie węzłów + dowodów w podpisany pakiet (znacznik czasu) — planowane; dziś eksport evidence-package z sumą kontrolną. | ROADMAP |
Powiązane: przegląd decyzji → /legal-board · zegary terminów → /deadline-clock · znane ograniczenia → /known-limitations.