Postmortemy i analiza przyczyny źródłowej

Po co to?

Rozwiązanie podatności zamyka sprawę z badaczem, ale nie odpowiada na pytanie, które zaraz zada Twój audytor (i Twój własny zespół): dlaczego do tego doszło i co zmieniliśmy, żeby już się nie powtórzyło? Postmortem to ta odpowiedź — uchwycona raz i zachowana na potrzeby dokumentacji.

Każde zgłoszenie ma jeden postmortem — prywatną, ustrukturyzowaną analizę przyczyny źródłowej, w całości należącą do Twojego zespołu.

Co się w nim znajduje

Postmortem łączy ustrukturyzowane pola z trzema opisowymi sekcjami w formie swobodnego tekstu:

Pole	Co opisuje
Podsumowanie	Jednolinijkowy opis incydentu
Poziom ważności	Poziom ważności incydentu
Kategoria	Klasa przyczyny źródłowej (np. konfiguracja, błąd w kodzie, luka w procesie)
Wystąpienie / Wykrycie / Rozwiązanie	Znaczniki czasu wskazujące, kiedy problem się zaczął, kiedy został wykryty i kiedy go naprawiono
Czas do naprawy	Wyliczany automatycznie ze znaczników wystąpienia i rozwiązania
Przyczyna źródłowa	Co naprawdę poszło nie tak, pod warstwą objawów
Działania naprawcze	Co zmieniłeś (lub zmienisz), żeby zapobiec ponownemu wystąpieniu
Wyciągnięte wnioski	Co zespół z tego wynosi — proces, narzędzia, odpowiedzialność

Możesz też dołączyć pliki dowodowe — zrzuty ekranu, logi, linki do commita lub zgłoszenia z poprawką.

Kiedy otwierasz nowy postmortem, Kit wypełnia go wstępnie na podstawie zgłoszenia: poziom ważności, oś czasu rozwiązania i wstępne podsumowanie są już uzupełnione, więc zaczynasz od kontekstu, a nie od pustej strony.

Kto może go tworzyć

Każdy członek Twojego zespołu CSIRT może utworzyć lub edytować postmortem zgłoszenia — nie ma tu osobnych uprawnień administratora. Funkcja jest dostępna wszędzie tam, gdzie zarządzanie zgłoszeniami CSIRT, więc może z niej korzystać każdy aktywny program z dostępem do zgłoszeń.

Zakładka Postmortem

Otwórz zgłoszenie i wybierz zakładkę Postmortem. Jeśli jeszcze żadnego nie ma, pusty stan z ikoną kłódki zachęci Cię do napisania pierwszego. Tworzenie i edycja odbywają się na osobnych, pełnoekranowych formularzach, żebyś miał miejsce na pisanie.

Dziennik audytu

Każdy zapis tworzy niezmienną, przypisaną wersję — kto co zmienił i kiedy. Wersje nigdy nie są nadpisywane ani usuwane, więc postmortem niesie ze sobą własną historię zmian. Każda wersja pojawia się też w osi czasu zgłoszenia obok zmian statusu i ocen, dając Ci jeden chronologiczny zapis całego incydentu.

Dossier PDF

Z zakładki Postmortem możesz pobrać dossier PDF dla pojedynczego zgłoszenia — pełne zgłoszenie wraz z jego postmortemem w jednym pliku. To Twój dowód z konkretnego momentu: wrzuć go do folderu audytowego, dołącz do zgłoszenia w systemie albo przekaż audytorowi jako kompletny zapis pojedynczego incydentu.

Zgodność z przepisami

Analiza przyczyny źródłowej dla pojedynczego zgłoszenia to dokładnie to, czego wymaga kilka standardów:

• SOC 2 — spełnia test dowodowy Vanta „Incident report or root cause analysis”. Zobacz Integrację z Vanta.
• ISO 22301:2019 — wspiera wymagania dotyczące ciągłości działania z §10.1.1, §10.1.2 i §10.1.3 (niezgodność, działania naprawcze i ciągłe doskonalenie).

Zarządzaj nim z pomocą AI

Dwa narzędzia MCP pozwalają asystentowi AI odczytywać i utrzymywać postmortemy:

• csirt_get_postmortem — odczytuje postmortem zgłoszenia, w tym trzy sekcje opisowe, time_to_fix_seconds oraz revisions_count.
• csirt_set_postmortem — tworzy lub aktualizuje postmortem (upsert). Zmieniane są tylko przekazane pola; reszta pozostaje nietknięta.

Pełne parametry i uprawnienia znajdziesz w Dokumentacji narzędzi MCP.

Co dalej

• Triaging Reports — rozwiąż zgłoszenie, a następnie uchwyć jego postmortem
• Metrics and Exports — zbiorcze pakiety dowodów SOC 2 obok dossier dla pojedynczych zgłoszeń
• Integracja z Vanta — zamień striażowane podatności w aktualne dowody zgodności