Dokumentacja ISO 27001 Wrocław

Dokument opisuje narzędzie, nie odwrotnie

W firmie, która wytwarza oprogramowanie albo prowadzi usługę w chmurze, spora część wymagań normy jest już realizowana. Zmiany przechodzą przez przegląd i zatwierdzenie. Dostęp nadaje się na podstawie zgłoszenia. Wdrożenie zostawia ślad w potoku. Problem polega na tym, że nigdzie nie jest napisane, że tak ma być, ani kto odpowiada, gdy nie jest.

Dokumentacja pisana od tej strony wygląda inaczej niż typowy komplet. Jest krótsza, bo nie opisuje krok po kroku czynności, którą narzędzie i tak wymusza. Za to precyzyjnie mówi trzy rzeczy: kto jest właścicielem zasady, jaki jest wymagany rytm i co zrobić przy odstępstwie.

Gdzie kończy się procedura, a zaczyna ustawienie w systemie

Obszar	Co trafia do procedury	Co zostaje w konfiguracji narzędzia
Nadawanie dostępów	kto wnioskuje, kto zatwierdza, w jakim terminie	uprawnienia w katalogu tożsamości i grupach
Zmiana w systemie produkcyjnym	wymóg przeglądu i zatwierdzenia przed wdrożeniem	reguły w repozytorium i w potoku wdrożeniowym
Przegląd uprawnień	rytm kwartalny i kto podpisuje wynik	eksport z katalogu jako dowód wykonania
Incydent	klasyfikacja, ścieżka zgłoszenia, terminy	rejestr zgłoszeń z historią i czasem zamknięcia
Kopie zapasowe	zakres, retencja, wymóg testu odtworzenia	harmonogram zadań i raport z ich wykonania
Praca zdalna	wymagania wobec urządzenia i sposobu pracy	zasady dostępu warunkowego i szyfrowanie dysków
Współpraca z kontraktorem	wymagania w umowie i zamknięcie dostępów	konta gościnne z terminem wygaśnięcia

Kolumna trzecia jest tym, czego nie przepisujemy do dokumentów. Procedura, która powtarza konfigurację, dezaktualizuje się przy pierwszej zmianie ustawienia i staje się dowodem, że system nie nadąża za rzeczywistością.

Skąd bierze się treść

Z rozmów i z oglądania konfiguracji. Pytamy, jak wygląda pierwszy dzień nowej osoby, kto nadaje dostęp do środowiska produkcyjnego, co się dzieje, gdy kontraktor kończy współpracę w połowie sprintu, jak przebiega wdrożenie na produkcję w piątek po południu i kto o tym decyduje.

Odpowiedzi bywają niewygodne, bo pokazują, że część rzeczy dzieje się inaczej, niż zakłada zarząd. To jest dokładnie ten materiał, z którego powstaje dokumentacja możliwa do obrony. Opisanie stanu życzeniowego kończy się niezgodnością w pierwszej rozmowie audytora z pracownikiem.

Dwa źródła dowodu

Przy każdym wymaganiu zapisujemy, skąd weźmie się dowód. Pierwsze źródło to ślad w narzędziu, który powstaje sam przy wykonywaniu pracy. Drugie to formularz, wypełniany świadomie, potrzebny tam, gdzie żaden system nie rejestruje zdarzenia.

Formularzy robimy tyle, ile trzeba, i ani jednego więcej. Każdy z nich jest zobowiązaniem, że ktoś będzie go wypełniał przez kolejne lata, więc wzory projektujemy pod realny czas tej osoby, a nie pod komplet wyglądający dobrze w spisie treści.

Kiedy sam komplet wystarczy, a kiedy nie

Wystarczy, gdy analizę ryzyka prowadzicie sami, zabezpieczenia macie wdrożone, a brakuje wyłącznie warstwy opisowej. Wtedy dokumentacja jest ostatnim elementem i można ją zamówić osobno.

Nie wystarczy, gdy nie ma jeszcze decyzji o zakresie systemu ani rejestru ryzyk, bo deklaracja stosowania nie ma się wtedy z czego wziąć. W takiej sytuacji zaczynamy od audytu zgodności, a całość prowadzi wdrożenie. Wymagania samej normy tłumaczy ISO 27001. Zakres dokumentów ustalamy przez kontakt.

Treść sprawdzona i zaktualizowana: 31 lipca 2026