Nie każdy defekt da się naprawić od razu. Dojrzały proces GRC nie udaje, że wtedy problem znika — nadaje mu jawnego właściciela, termin ważności i dowód decyzji. Ta strona opisuje szkielet workflow: kto akceptuje ryzyko, na jak długo, na podstawie jakiego dowodu, kiedy akceptacja wygasa, kto ją odnawia i kiedy defekt wraca do backlogu. Uczciwie: opisany jest przepływ i model danych (MVP), a trwała persystencja rejestru akceptacji jest oznaczona jako ROADMAP — dokładnie tak, jak builder ticketing.
Kiedy remediation nie jest teraz możliwa (np. zależność od dostawcy, zamrożenie zmian, koszt większy niż ekspozycja), defekt nie znika i nie jest cicho zamykany. Otrzymuje jawnego akceptanta, uzasadnienie, dowód stanu, datę wygaśnięcia i regułę powrotu do backlogu. Gdy akceptacja wygaśnie i nikt jej nie odnowi — pozycja automatycznie wraca jako otwarta. To odróżnia świadomą decyzję biznesową od ukrytego długu.
Każda pozycja ryzyka przechodzi przez zdefiniowany cykl. Przejścia są jawne i (docelowo) zapisywane w audit-logu z dowodem — nie ma cichego przeskoku do „zamknięte".
| Stan | Co oznacza | Kto inicjuje przejście | Warunek wejścia |
|---|---|---|---|
| open | Defekt/ryzyko istnieje w backlogu, niezaadresowane. Domyślny stan po imporcie findingu, którego nie da się teraz naprawić. | System / import findingu | Finding istnieje, remediation nie rozpoczęta lub niemożliwa teraz. |
| proposed | Wnioskujący składa wniosek o akceptację ryzyka: uzasadnienie, proponowany okres, dowód stanu kompensacji. | Owner findingu / zespół produktowy | Uzasadnienie + proponowana data wygaśnięcia + wskazany akceptant. |
| accepted | Ryzyko formalnie zaakceptowane na czas określony. Aktywne, ale monitorowane. Nie znika z rejestru. | Akceptant o właściwym poziomie (patrz macierz ról) | Decyzja akceptanta + dowód + data wygaśnięcia zapisane. |
| expiring | Zbliża się data wygaśnięcia (okno przypomnienia, np. T-14 dni). Wymaga decyzji: odnowić czy pozwolić wygasnąć. | System (harmonogram) → powiadamia akceptanta i ownera | Bieżąca data ≥ (data wygaśnięcia − okno przypomnienia). |
| reopened | Akceptacja wygasła i nie została odnowiona — pozycja wraca do backlogu jako otwarta, z historią poprzedniej akceptacji. | System (po dacie wygaśnięcia) lub akceptant (cofnięcie) | Data wygaśnięcia minęła bez odnowienia LUB warunek kompensacji przestał obowiązywać. |
Poziom akceptanta zależy od wagi ryzyka (patrz macierz niżej). Krytyczne ryzyko nie może być zaakceptowane przez zespół — wymaga właściciela na poziomie kierowniczym / CISO.
Każda akceptacja ma datę wygaśnięcia. Brak „na zawsze". Im wyższe ryzyko, tym krótszy maksymalny okres (np. krytyczne ≤ 30 dni, niskie ≤ 180 dni).
Wniosek dołącza dowód stanu: kontrola kompensacyjna, wynik retestu, evidence-package z remediation, hash artefaktu. Bez dowodu = brak akceptacji.
Data wygaśnięcia jest polem obowiązkowym. Harmonogram (docelowo) wykrywa zbliżający się termin i przełącza pozycję w stan expiring.
Odnowienie = nowa decyzja akceptanta na podstawie aktualnego dowodu, nie automatyczne przedłużenie. Odnowienie tworzy nowy wpis w historii, stary zostaje.
Gdy akceptacja wygaśnie bez odnowienia albo warunek kompensacji upadnie — pozycja przechodzi w reopened i wraca jako otwarta z pełną historią.
Poziom akceptanta i maksymalny okres skalują się z wagą ryzyka. Wartości poniżej to domyślny szkielet (przykład syntetyczny) — parametry do ustalenia w polityce organizacji.
| Waga ryzyka | Minimalny poziom akceptanta | Maks. okres akceptacji | Wymagany dowód |
|---|---|---|---|
| krytyczne | CISO / właściciel ryzyka na poziomie zarządu | ≤ 30 dni | Kontrola kompensacyjna + retest + dowód dołączony do wniosku. |
| wysokie | Kierownik bezpieczeństwa / właściciel systemu | ≤ 90 dni | Kontrola kompensacyjna LUB udokumentowany plan remediation z terminem. |
| średnie | Owner produktu / lead zespołu | ≤ 120 dni | Uzasadnienie biznesowe + odnotowany stan. |
| niskie | Owner findingu | ≤ 180 dni | Uzasadnienie (dług świadomy). |
Kształt rekordu akceptacji ryzyka. Przykład syntetyczny. Trwały zapis i harmonogram wygasania = ROADMAP.
{
"risk_id": "RA-2026-0007",
"finding_ref": "FND-8842",
"state": "accepted",
"severity": "high",
"justification": "Poprawka wymaga aktualizacji biblioteki dostawcy; okno zmian zamknięte do końca kwartału. Wektor ograniczony kontrolą kompensacyjną (WAF rule + segmentacja).",
"compensating_control": "WAF-RULE-1188 + segmentacja VLAN",
"evidence_ref": "evidence-package://EP-3310 (sha256: a1b2...synthetic)",
"requested_by": "owner.system@example.test",
"accepted_by": "ciso.deputy@example.test",
"accepted_at": "2026-07-05",
"expires_at": "2026-10-03",
"reminder_window_days": 14,
"renewal_of": null,
"on_expiry": "reopen_to_backlog",
"history": [
{ "state": "open", "at": "2026-07-01" },
{ "state": "proposed", "at": "2026-07-04", "by": "owner.system@example.test" },
{ "state": "accepted", "at": "2026-07-05", "by": "ciso.deputy@example.test" }
]
}
| Element | Status | Uwaga |
|---|---|---|
| Definicja lifecycle (5 stanów) i reguł przejść | MVP | Opisane na tej stronie; stosowalne jako procedura GRC. |
| Macierz ról i maksymalnych okresów | MVP | Szkielet domyślny; parametry do polityki organizacji. |
| Model danych rekordu akceptacji | MVP | Kształt zdefiniowany; przykład syntetyczny. |
| Trwały rejestr akceptacji w bazie | ROADMAP | Jak persystencja w builderze ticketing — do implementacji. |
| Automatyczne wygasanie + przypomnienia (harmonogram) | ROADMAP | Stan expiring i powrót do backlogu wymaga schedulera. |
| Audit-log decyzji z dowodem | ROADMAP | Docelowo spięty z evidence-package z remediation. |
Powiązane: ścieżka naprawy defektu → /remediation · proces wyjątków → /exceptions · jawny rejestr granic → /known-limitations.