Dokumentacja ISO 27001 Rzeszów

Który dokument audytor odbiorcy otwiera pierwszy?

Deklarację stosowania, a zaraz po niej rejestr ryzyka. Powód jest prosty: z tych dwóch kartek widać, czy ktoś w firmie naprawdę przeszedł przez wymagania normy, czy tylko kupił plik i podmienił nazwę. Deklaracja, w której wszystkie pozycje mają odpowiedź „stosujemy”, jest podejrzana tak samo jak ta, w której połowa jest wyłączona bez uzasadnienia. Rejestr ryzyka z trzema wierszami mówi audytorowi, że nikt na warsztacie nie siedział.

Reszta kompletu jest czytana wybiórczo i zwykle pod kątem jednego pytania. Ktoś sięgnie po procedurę obsługi incydentu, żeby zobaczyć, kto i w jakim czasie ma zostać powiadomiony. Ktoś inny po zasady pracy z dostawcami, bo interesuje go, co macie zapisane wobec firmy serwisującej maszyny. Dlatego piszemy dokumenty krótkie i konkretne, a nie długie i ostrożne. Dokument na dwadzieścia stron brzmi poważnie do momentu, w którym trzeba z niego wyciągnąć jedną odpowiedź.

Dokument	Kto go naprawdę czyta	Co musi być w nim konkretne
Polityka bezpieczeństwa	zarząd, audytor, odbiorca	zakres, cele i nazwiska odpowiedzialnych
Rejestr ryzyka	audytor, właściciele procesów	konkretne scenariusze i podjęte decyzje
Deklaracja stosowania	audytor jednostki	uzasadnienie każdego wyłączenia
Wykaz aktywów	osoba prowadząca systemy	nazwy systemów, lokalizacje i właściciele
Procedura dostępu	kadry i informatyka	co się dzieje przy przyjęciu i przy odejściu
Procedura nośników	mistrzowie i operatorzy	kto wydaje nośnik i gdzie to zapisuje
Instrukcje stanowiskowe	ludzie na hali	trzy do pięciu zdań o tym, co robić i czego nie

Jak opisać cykl życia danych powierzonych przez odbiorcę?

To jest dokument, którego nie ma w żadnym gotowym pakiecie, a u poddostawcy przemysłu bywa najważniejszy. Opisuje drogę cudzej dokumentacji przez Waszą firmę, etap po etapie, i odpowiada na pytania, które wcześniej albo później zada audytor odbiorcy albo jego dział zakupów.

Zaczyna się od przyjęcia. Skąd przychodzą modele i specyfikacje, kto je odbiera, gdzie lądują i jakie dostają oznaczenie, bo bez oznaczenia nikt w firmie nie odróżni pliku objętego umową o poufności od własnego rysunku. Potem idzie przechowywanie: w którym systemie, z jakimi uprawnieniami, czy kopie tych danych też są objęte tą samą regułą i gdzie leżą. Dalej przekazywanie, czyli kto ma prawo wysłać taki plik dalej, na przykład do podwykonawcy obróbki cieplnej albo do laboratorium pomiarowego, i pod jakim warunkiem.

Ostatni etap sprawia najwięcej kłopotu i najczęściej jest pomijany. Chodzi o zakończenie programu, czyli moment, w którym umowa mówi o zwrocie albo usunięciu danych, a Wasze wymagania techniczne mówią o przechowywaniu dokumentacji wyrobu przez lata. To nie jest sprzeczność do zamiecenia, tylko rzecz do opisania i uzgodnienia z odbiorcą. W procedurze zapisujemy, co dokładnie podlega usunięciu, co zostaje jako zapis identyfikacyjny i kto to rozstrzyga.

Czym deklaracja stosowania różni się od spisu treści?

Tym, że jest decyzją, a nie inwentarzem. Przy każdym zabezpieczeniu z załącznika do normy trzeba powiedzieć trzy rzeczy: czy je stosujecie, dlaczego oraz gdzie jest tego dowód. Ostatnia kolumna jest tą, która przesądza o wartości całego dokumentu, bo odsyła do konkretnej procedury albo do konkretnego zapisu zamiast kończyć zdanie ogólnikiem.

Wyłączenia są dopuszczalne i normalne, o ile mają uzasadnienie wynikające z działalności. Zakład, który nie prowadzi własnego wytwarzania oprogramowania, wyłącza zabezpieczenia dotyczące bezpiecznego programowania i nikt tego nie kwestionuje. Ten sam zakład nie wyłączy natomiast zabezpieczeń dotyczących nośników, bo pendrive z programem obróbczym krąży po hali codziennie. Piszemy te uzasadnienia zdaniami, które odnoszą się do Waszej produkcji, a nie formułą o nieadekwatności do specyfiki organizacji.

Co trzeba dopisać, gdy dochodzi nowy odbiorca?

Zwykle niewiele, o ile komplet jest zbudowany warstwowo. Nowy kontrahent wnosi własne wymagania, ale trafiają one do jednego miejsca, czyli do rejestru wymagań zewnętrznych, gdzie zapisujemy, kto czego wymaga i którego kontraktu to dotyczy. Jeśli wymaganie wykracza poza to, co już robicie, dopisujemy je jako ryzyko i decyzję w rejestrze, a nie przepisujemy polityki.

Zmiana głębsza jest potrzebna tylko wtedy, gdy nowy odbiorca rozszerza zakres działalności objęty systemem, na przykład dokłada proces prowadzony w drugiej hali albo wymusza obsługę danych podlegających ograniczeniom eksportowym. Wtedy aktualizujemy wykaz aktywów, granice systemu i procedurę dostępu do stref. Skalę takiej zmiany łatwiej ocenić po audycie zgodności, a pełny projekt z certyfikacją opisuje wdrożenie ISO 27001.

Gdzie leży granica tego zlecenia?

Na dokumentach i wzorach zapisów. Nie wdrażamy w ramach tej ceny zabezpieczeń technicznych, więc segmentacja sieci, kopie odporne na skasowanie, drugi składnik logowania czy uporządkowanie uprawnień są osobną pracą, wycenianą po ustaleniu zakresu. Nie prowadzimy też audytu wewnętrznego ani nie reprezentujemy Was przed jednostką certyfikującą.

Nie wypełniamy zapisów za Was i to jest granica, której nie przesuwamy. Rejestr nośników, karty incydentów i protokoły przeglądów muszą powstawać w firmie, w czasie rzeczywistym, bo dokument uzupełniony wstecz przed audytem jest gorszy od jego braku. Sam stan wyjściowy przed pisaniem opisuje ISO 27001, a zakres kompletu ustalamy przez kontakt.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026