k0nsult.cloud / ai-truth / ipIII / orchestrator / exceptions

Exception Register (F12) — rejestr świadomych wyjątków

Nie każde ryzyko domyka się od razu. Dojrzały proces zamiast udawać, że wyjątków nie ma, rejestruje je jawnie: co, dlaczego, na jak długo i kto za to odpowiada. Ta strona to rejestr wyjątków — techniczny, biznesowy, compliance exception, temporary mitigation, permanent acceptance — z datą wygaśnięcia i właścicielem. Wpisy poniżej są syntetycznymi przykładami ilustrującymi model danych, nie decyzjami operacyjnymi.

Orchestrator Risk acceptance Remediation Znane ograniczenia Status matrix Exception Register ← ipIII hub

Status: MVP. Model danych i widok rejestru są zaprojektowane (typy wyjątków, uzasadnienie, wygaśnięcie, owner). Ta strona prezentuje ustrukturyzowany rejestr na przykładach syntetycznych. Persystencja (zapis wyjątków do bazy, workflow zatwierdzania, powiadomienia o wygaśnięciu, historia zmian) jest oznaczona ROADMAP — jeszcze nie działa jako endpoint. Zgodnie z doktryną claim ≤ proof: to, czego nie umiemy pokazać kodem i endpointem, nazywamy ROADMAP, nie funkcją.

Wyjątek zarejestrowany ≠ ryzyko ukryte.

Każdy wyjątek to świadoma, nazwana i ograniczona w czasie decyzja o niedomykaniu (jeszcze) danego ryzyka. Różni się od znanego ograniczenia tym, że dotyczy konkretnego przypadku i ma datę wygaśnięcia oraz właściciela. Wyjątek bez daty wygaśnięcia lub bez ownera jest niekompletny — rejestr wymusza oba pola.

CYKL ŻYCIA WYJĄTKU: zgłoszenie→uzasadnienie + owner→termin wygaśnięcia→przegląd→domknięcie lub przedłużenie

Typy wyjątków

Techniczny technical

Ograniczenie architektury lub zależności, którego nie da się usunąć w bieżącym sprincie. Np. brak biblioteki, zależność od zewnętrznego dostawcy.

Biznesowy business

Świadoma decyzja właściciela produktu o priorytecie — funkcja odłożona ze względu na koszt, harmonogram lub wartość dla pilota.

Compliance exception compliance

Odstępstwo od wymogu zgodności zarejestrowane świadomie, z uzasadnieniem i planem domknięcia. Nie zwalnia z obowiązku — dokumentuje odroczenie.

Temporary mitigation temp-mitigation

Tymczasowy środek zaradczy w miejsce docelowej korekty. Ważny do czasu wdrożenia właściwej mitigacji — z datą wygaśnięcia.

Permanent acceptance perm-acceptance

Trwała akceptacja ryzyka: uznanie, że koszt domknięcia przewyższa ryzyko. Wymaga podpisu ownera; przegląd okresowy zamiast wygaśnięcia.

Wygaśnięcie expiry

Każdy wyjątek (poza trwałą akceptacją) ma datę wygaśnięcia. Po niej wyjątek jest nieważny — ryzyko wraca do kolejki remediacji.

Rejestr wyjątków (dane przykładowe)

Kolumna Typ = kategoria wyjątku. Każdy wpis wymaga uzasadnienia, daty wygaśnięcia i ownera. Poniższe rekordy są SYNTETYCZNE — ilustrują strukturę, nie realne decyzje. Data widoku: 2026-07-05.

ID	Typ	Uzasadnienie	Wygasa	Owner
`EXC-001`	technical	Brak mTLS na bramie konektorów w środowisku demo — środowisko odizolowane, brak danych produkcyjnych. Odroczone do sprintu hardeningu transportu.	2026-09-30	tech-lead
`EXC-002`	compliance	Evidence-package ma `sha256`, brak podpisu PAdES/TSA. Odroczone świadomie — wartość dowodowa hash wystarcza dla pilota; podpis formalny planowany.	2026-12-31	compliance-owner
`EXC-003`	temp-mitigation	Wzbogacanie CVE offline (seed) zamiast lookup online. Tymczasowo: ręczne odświeżanie seedu co tydzień do czasu wdrożenia harmonogramu NVD/KEV.	2026-08-15	data-owner
`EXC-004`	business	Konektor SIEM odłożony do fazy S5 — pilot opiera się na imporcie z plików skanerów. Decyzja właściciela produktu: priorytet na warstwę evidence.	2026-10-31	product-owner
`EXC-005`	perm-acceptance	Instancja jednoorganizacyjna (brak multi-tenant) akceptowana trwale dla wdrożenia dedykowanego jednego partnera. Przegląd przy skalowaniu na wielu klientów.	przegląd 2027-01	ciso-partner

Skrót rejestru

Typów wyjątku

technical · business · compliance · temp-mitigation · perm-acceptance

Pola wymagane

data wygaśnięcia + owner (bez nich wpis niekompletny)

Rekordów demo

syntetyczne, ilustrują model danych

ROADMAP

Persystencja

zapis do DB + workflow zatwierdzania — jeszcze nie endpoint

Jak to się łączy

1. Znane ograniczenie — /known-limitations opisuje granicę dojrzałości całego systemu. Wyjątek to konkretny przypadek odroczenia w ramach takiej granicy.

2. Risk acceptance — /risk-acceptance to formalna decyzja o zaakceptowaniu ryzyka. Wyjątek typu perm-acceptance jest jej zapisem w rejestrze.

3. Remediation — /remediation to kolejka domknięć. Gdy wyjątek wygasa, powiązane ryzyko wraca do remediacji.

Czego ta strona NIE oznacza

Rejestr wyjątków nie zwalnia z obowiązków. Compliance exception dokumentuje świadome odroczenie z planem domknięcia — nie jest zwolnieniem z wymogu ani interpretacją prawną. Decyzja o akceptacji ryzyka należy do ownera / instytucji, a mapowanie obowiązków to wsparcie decyzji, nie porada prawna.

Wpisy są syntetyczne. Wszystkie rekordy w tabeli to przykłady ilustrujące model danych. Nie odzwierciedlają realnych decyzji o ryzyku żadnej instytucji. Rejestr jako działający endpoint (zapis, zatwierdzanie, powiadomienia o wygaśnięciu) jest ROADMAP.

Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Rejestr wyjątków służy transparentności decyzji o ryzyku, nie ukrywaniu ich. Wszelkie mapowania obowiązków to wsparcie decyzji, nie porada prawna — przed wysyłką do organu konieczny przegląd prawny. Działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement.

Powiązane: formalna akceptacja ryzyka → /risk-acceptance · kolejka domknięć → /remediation · granice dojrzałości systemu → /known-limitations.