Procedura Zarządzania Zmianami
Klasyfikacja zmian, CAB, testowanie i rollback
1. Typy Zmian
| Typ | Opis | Przykłady | Zatwierdzenie | Czas wdrożenia |
|---|---|---|---|---|
| Standard | Powtarzalna, niskoryzykowna, zatwierdzona z góry | Restart serwera, zmiana hasła, aktualizacja antywirusa | ▸ [Pre-approved / Admin IT samodzielnie] | ▸ [Dowolny termin w oknie serwisowym] |
| Normalna | Planowana, wymaga oceny i zatwierdzenia | Aktualizacja oprogramowania, zmiana konfiguracji firewall, wdrożenie nowego systemu | ▸ [CAB – min. 48h przed]min. 48h przed wdrożeniem | ▸ [Okno serwisowe – zob. pkt 3] |
| Awaryjna (Emergency) | Natychmiastowa reakcja na incydent lub krytyczną podatność | Patch krytycznej podatności 0-day, blokada atakującego IP, naprawa awarii systemu kluczowego | ▸ [CISO + jeden członek zarządu]minimum 2 osoby | ▸ [Natychmiastowe, z pełną dokumentacją post-factum] |
2. Komitet ds. Zmian (CAB – Change Advisory Board)
▸ Organizacja uzupełnia – skład CAB
| Rola w CAB | Stanowisko | Imię i Nazwisko |
|---|---|---|
| Przewodniczący CAB | ▸ CISO | ▸ |
| Przedstawiciel biznesowy | ▸ [Dyrektor / Manager] | ▸ |
| Administrator IT | ▸ Admin IT | ▸ |
| Właściciel systemu (jeśli dotyczy) | ▸ | ▸ |
Częstotliwość spotkań CAB: ▸ [co tydzień]min. co 2 tygodnie
Sposób zatwierdzania: ▸ [e-mail / system ticketowy / spotkanie]
3. Okna Serwisowe
▸ Organizacja uzupełnia – harmonogram okien serwisowych
| Typ systemu | Standardowe okno serwisowe | Wyjątki |
|---|---|---|
| Systemy IT produkcyjne | ▸ [np. Środa 22:00–02:00] | ▸ [zmiany awaryjne poza oknem – zgoda CISO] |
| Systemy OT/ICS (jeśli dotyczy) | ▸ [np. Pierwsza Niedziela miesiąca 06:00–10:00] | ▸ [wyłącznie z zatwierdzeniem zarządu] |
| Strona www / portal klientów | ▸ [np. Sobota 01:00–05:00] | ▸ |
4. Wymagania dla Każdej Zmiany
Przed wdrożeniem
- Opisana i zatwierdzona (wniosek zmiany RFC – Request for Change).
- Ocena ryzyka – szczególnie dla systemów kluczowych.
- Plan testów – jak zweryfikować poprawność działania po zmianie.
- Plan wycofania (rollback) – jak cofnąć zmianę jeśli coś pójdzie źle.
- Backup przed wdrożeniem zmian w systemach krytycznych (DOC-012).
Po wdrożeniu
- Weryfikacja poprawności wg planu testów.
- Aktualizacja dokumentacji konfiguracji.
- Zamknięcie RFC z wynikiem (sukces / częściowy sukces / cofnięcie).
- Dla zmian awaryjnych: pełna dokumentacja retrospektywna w ciągu ▸ [24h].
5. Rejestr Zmian
Wszystkie zmiany są rejestrowane w centralnym systemie: ▸ [np. ServiceNow / Jira / rejestr Excel]. Wpis zawiera: ID, typ, opis, ryzyko, zatwierdzenie, datę wdrożenia, wynik, osobę odpowiedzialną.
Retencja rejestru zmian: ▸ [min. 5 lat]min. 5 lat – KSC.
6. Historia Zmian
| Wersja | Data | Autor | Opis | Zatwierdził |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD.MM.RRRR | ▸ | ▸ Pierwsze wydanie | ▸ Zarząd |
DOC-013 Procedura Zarządzania Zmianami | v1.0 | NIS2/KSC