ISO 27001 certification: Przewodnik dla software house'u

Masz zespół, proces delivery działa, sprinty dowożone, CI/CD jest ogarnięte, infrastruktura siedzi w chmurze, a potem na finiszu rozmów handlowych wpada jedno pytanie: „czy macie ISO 27001?”. Jeśli odpowiedź brzmi „jeszcze nie”, bardzo często rozmowa kończy się szybciej, niż chciałbyś przyznać.

Z perspektywy CTO to boli podwójnie. Nie dlatego, że standard jest modny, tylko dlatego, że często firma ma już sporą część sensownych praktyk bezpieczeństwa, ale nie umie ich udowodnić, uporządkować i utrzymać w formie, którą zaakceptuje klient albo audytor. Właśnie dlatego ISO 27001 certification w software house'ie nie jest dziś tematem dla działu compliance w oderwaniu od technologii. To temat dla delivery, DevOps, backendu, HR, zarządu i sprzedaży jednocześnie.

ISO 27001 w software house - fanaberia czy konieczność

Software house najczęściej nie przegrywa przez słaby kod. Przegrywa przez brak zaufania. Klient z fintechu, SaaS albo sektora regulowanego nie chce słuchać, że „mamy dobre praktyki”. On chce zobaczyć system, odpowiedzialności, dowody i powtarzalność.

W praktyce to oznacza jedno. Jeśli działasz jako software house wspierający rozwój i utrzymanie systemów, certyfikacja coraz częściej staje się warunkiem wejścia do rozmowy, a nie dodatkiem na końcu procesu. To szczególnie widoczne tam, gdzie bierzesz odpowiedzialność za dane klientów, środowiska cloud i wsparcie 24/7.

Według opisu standardu ISO 27001:2022 od NQA, w ciągu ostatnich dwóch lat liczba certyfikatów ISO 27001 w Polsce wzrosła o 24,7%, a sam standard dzieli kontrole na cztery obszary: ludzkie (8), organizacyjne (37), technologiczne (34) i fizyczne (14). Dla firm IT, które oferują wsparcie 24/7 i SLA, to już nie wygląda jak papierologia. To wygląda jak język, którym klient ocenia dojrzałość dostawcy.

Co ten standard realnie zmienia

Największa zmiana nie dzieje się w dokumentach. Dzieje się w rozmowach z klientami i wewnątrz firmy.

• Sprzedaż przestaje improwizować. Zespół handlowy nie obiecuje „enterprise-grade security”, tylko pokazuje konkretne ramy działania.
• Delivery zyskuje wspólne zasady. PM, dev, DevOps i support wiedzą, kto za co odpowiada przy incydencie, onboardingu i zmianach w środowisku.
• Zarząd dostaje kontrolę nad ryzykiem. Nie przez intuicję, tylko przez proces.

Praktyczna obserwacja: jeśli firma uważa ISO 27001 za zbędną biurokrację, zwykle nie ma problemu z bezpieczeństwem. Ma problem z nieudokumentowanym chaosem.

Mit o papierologii

Ten mit bierze się stąd, że wiele firm próbuje wdrożyć normę przez kopiowanie szablonów. To prawie zawsze kończy się źle. Dokument, którego nikt z engineeringu nie rozumie, nie poprawia bezpieczeństwa. Tylko zwiększa dystans między audytem a rzeczywistością.

Dobrze wdrożone ISO 27001 porządkuje to, co i tak powinno działać. Dostępy, repozytoria, środowiska, backupy, zasady zmian, klasyfikację informacji, obsługę incydentów, offboarding i zależności od dostawców. W software house'ie to nie jest dodatek do procesu wytwórczego. To jego stabilizator.

Faza 1 Planowanie wdrożenia i budowa zespołu projektowego

Najwięcej problemów powstaje na starcie. Nie dlatego, że norma jest niejasna, tylko dlatego, że firmy biorą zbyt szeroki zakres albo zbyt wąski, który nie wytrzymuje kontaktu z realnym delivery.

Zacznij od zakresu, nie od polityk

Pierwsza decyzja brzmi: co dokładnie certyfikujesz. Całą organizację, tylko development i utrzymanie, a może wybrany strumień usług związany z tworzeniem i hostingiem systemów? Nie ma jednej poprawnej odpowiedzi. Jest tylko odpowiedź uczciwa wobec tego, jak naprawdę pracuje firma.

Jeżeli software house obsługuje wiele modeli współpracy, zakres musi uwzględniać zależności między zespołami. Gdy support ma dostęp do produkcji, a DevOps zarządza pipeline'ami dla wielu klientów, sztuczne wycięcie części organizacji zwykle komplikuje audyt. Audytor szybko zobaczy, że procesy przecinają się z obszarami formalnie „poza zakresem”.

Kto musi być w zespole projektowym

Ten projekt nie może być własnością jednej osoby od bezpieczeństwa. Jeśli tak go ustawisz, po kilku tygodniach utknie na etapie zbierania informacji od reszty firmy.

Minimalny skład, który działa w software house'ie:

• Sponsor z zarządu. Bez tej roli nie będzie decyzji o priorytetach, budżecie i egzekwowaniu zmian.
• Osoba odpowiedzialna za ISMS. Ktoś musi spinać całość operacyjnie i pilnować dowodów, harmonogramu oraz niezgodności.
• Przedstawiciel engineeringu. Najlepiej ktoś, kto rozumie repozytoria, branching, release process i codzienną pracę zespołów.
• DevOps albo cloud engineer. Bez tej perspektywy polityki dostępu, backupu, logowania i segregacji środowisk będą oderwane od praktyki.
• HR i operations. Onboarding, offboarding, uprawnienia, sprzęt i świadomość bezpieczeństwa zwykle mieszkają właśnie tutaj.
• PM lub delivery manager. To ta rola wie, jak obietnice kontraktowe przekładają się na proces.

Harmonogram, który ma sens

Najgorszy plan wdrożenia wygląda tak: dwa warsztaty, gotowe polityki, szybki audyt i certyfikat „zaraz”. To nie działa, bo standard dotyczy nie tylko dokumentów, ale też dowodów działania.

Lepiej ułożyć projekt w kolejności:

1. Ustalenie zakresu i właścicieli procesów
2. Gap analysis względem obecnych praktyk
3. Ustalenie metodyki ryzyka
4. Budowa i porządkowanie dokumentacji
5. Wdrożenie brakujących kontroli
6. Zbieranie dowodów operacyjnych
7. Audyt wewnętrzny
8. Działania korygujące i przegląd zarządzania

Firmy technologiczne najczęściej wykładają się nie na „braku bezpieczeństwa”, tylko na przecenieniu swojej gotowości. Jeśli polityka istnieje od wczoraj, a audyt jest za tydzień, audytor potraktuje to jak dekorację.

Gdzie zwykle uciekają zasoby

Najbardziej niedoszacowane są trzy rzeczy:

Obszar	Co firmy zakładają	Co dzieje się w praktyce
Dokumentacja	„Spiszemy to później”	Okazuje się, że proces działa tylko w głowach ludzi
Dostępy	„Mamy SSO, więc temat zamknięty”	Brakuje przeglądów uprawnień, zasad wyjątków i śladów akceptacji
CI/CD	„Pipeline jest bezpieczny”	Sekrety, uprawnienia serwisowe i ręczne obejścia wychodzą dopiero przy analizie

W planowaniu warto od razu założyć udział ludzi technicznych w warsztatach. Bez tego wdrożenie staje się projektem dokumentowym, a nie operacyjnym.

Faza 2 Analiza ryzyka i kluczowa dokumentacja ISMS

Tutaj zaczyna się prawdziwa praca. W wielu software house'ach właśnie ten etap wygląda najgorzej, bo firma próbuje opisać ryzyko językiem ogólnym, zamiast odnieść je do tego, jak naprawdę działa development, cloud i utrzymanie.

W polskich software house'ach 40% błędów wykrywanych podczas wstępnych audytów ISO 27001 dotyczy etapu oceny ryzyka (Clause 6.1.2). Częstym błędem jest mylenie oceny ryzyka z planem postępowania z ryzykiem, co prowadzi do odrzucenia certyfikacji w 65% przypadków przy pierwszej próbie, a średni czas uzyskania certyfikatu w Polsce to 12-18 miesięcy.

Ocena ryzyka to nie lista strachów

Ocena ryzyka odpowiada na pytanie, co może pójść źle, dlaczego, jaki będzie skutek i jak to oceniamy. Plan postępowania z ryzykiem odpowiada dopiero na pytanie, co z tym robimy. Jeśli zmieszasz te dwa etapy, wyjdzie dokument, który nie daje się zweryfikować.

Dla software house'u sensowne ryzyka zwykle dotyczą konkretnych aktywów i przepływów:

• Repozytoria kodu. Nieautoryzowany dostęp, brak separacji między projektami, nadmiarowe uprawnienia maintainerów.
• Środowiska chmurowe. Błędna konfiguracja IAM, niekontrolowane konta serwisowe, zbyt szeroki dostęp do logów i bucketów.
• CI/CD. Sekrety w pipeline'ach, ręczne deploye poza procesem, brak kontroli zmian w definicjach pipeline'ów.
• Dane klientów w środowiskach testowych. Kopie produkcyjnych danych bez maskowania, eksporty trzymane lokalnie, snapshoty bez jasnych zasad retencji.
• Łańcuch dostaw oprogramowania. Biblioteki open source, obrazy kontenerów, integracje z zewnętrznymi usługami.

Jeżeli potrzebujesz uporządkować ten obszar, pomocne jest spojrzenie na praktykę zarządzania ryzykiem w projektach IT, ale ważniejsze od samej metody jest to, żeby była spójna i stosowana konsekwentnie.

Jak wygląda dobra analiza ryzyka w engineeringu

Najlepsze warsztaty ryzyka, jakie widziałem, nie startują od Excela. Startują od mapy systemów i pracy zespołu. Najpierw identyfikujesz aktywa, potem ludzi mających do nich dostęp, później punkty zmian i zależności od dostawców.

Krótka sekwencja, która działa:

1. Spisz aktywa informacyjne. Kod, dane klientów, tajemnice dostępu, dokumentacja architektury, backupy, logi.
2. Opisz, gdzie te aktywa żyją. GitHub, GitLab, AWS, Azure, narzędzia PM, dyski lokalne, komunikatory.
3. Nazwij zagrożenia i podatności. Nadmiarowe role, brak rotacji sekretów, brak review dla zmian infra.
4. Oceń wpływ i prawdopodobieństwo według jednej metody
5. Dopiero potem dobierz działania

Jeśli zespół nie potrafi wskazać, które sekrety są krytyczne i kto jest właścicielem ryzyka, analiza jest za płytka, nawet jeśli arkusz wygląda profesjonalnie.

SoA i dokumentacja, które mają sens

Statement of Applicability, czyli SoA, jest jednym z najważniejszych dokumentów całego ISMS. To nie jest tabela „tak lub nie”. To uzasadnienie, które kontrole z Aneksu A stosujesz, których nie stosujesz i dlaczego.

Dobra SoA w software house'ie jest mocno osadzona w praktyce. Jeśli deklarujesz kontrolę dostępu, audytor będzie oczekiwał dowodów w systemach. Jeśli deklarujesz bezpieczne rozwijanie oprogramowania, zobaczy proces code review, zasady branch protection, skanowanie zależności i ścieżkę zgłaszania podatności.

Minimalny zestaw dokumentów, który zwykle trzeba uporządkować:

• Polityka bezpieczeństwa informacji
• Metodyka oceny ryzyka
• Plan postępowania z ryzykiem
• SoA
• Zasady zarządzania dostępem
• Procedura incydentów
• Zasady pracy z aktywami i sprzętem
• Procedura onboardingu i offboardingu
• Zasady tworzenia kopii zapasowych i odtwarzania
• Zasady bezpiecznego wytwarzania oprogramowania

Nie buduj wszystkiego od zera. Jeśli masz code review, zasady release'ów, checklisty wdrożeń, pull request templates i runbooki incydentowe, wykorzystaj je. Trzeba je uporządkować, powiązać z kontrolami i nadać im właścicieli. To znacznie lepsze niż produkowanie nowej dokumentacji, której nikt nie używa.

Faza 3 Wdrażanie zabezpieczeń w środowisku IT i DevSecOps

Na tym etapie kończy się teoria. Norma nie wymaga konkretnego stacku, ale audytor będzie patrzył, czy twoje zabezpieczenia naprawdę wspierają sposób pracy zespołu. W software house'ie oznacza to integrację z chmurą, repozytoriami, pipeline'ami i rytmem sprintów.

Kontrola dostępu w chmurze i repozytoriach

Najwięcej bałaganu widzę zwykle w uprawnieniach. Firma ma SSO, MFA i nawet ładne grupy, ale po latach wyjątków nikt już nie wie, kto ma dostęp do czego i dlaczego.

Działają proste zasady:

• Role zamiast uprawnień ręcznych. W AWS lub Azure przypisuj dostęp przez role związane z funkcją, nie przez indywidualne wyjątki.
• Osobne role dla środowisk. Development, staging i produkcja nie powinny mieć tego samego modelu dostępu.
• Czasowe podniesienie uprawnień. Dostęp administracyjny do produkcji powinien być przyznawany na konkretny cel i z udokumentowaną akceptacją.
• Branch protection i wymagane review. Bez tego bezpieczne wytwarzanie oprogramowania pozostaje hasłem.

Warto też regularnie sprawdzać, czy konta serwisowe i integracje nadal są potrzebne. W wielu organizacjach to właśnie one mają najszersze uprawnienia i najmniej kontroli.

CI/CD bez sekretów w złych miejscach

Pipeline jest częścią systemu bezpieczeństwa, nie tylko mechanizmem dostarczania kodu. Jeśli w CI/CD masz ręczne obejścia, sekrety wpisywane ad hoc albo deploy z laptopa „na chwilę”, audyt to wyłapie.

Dobre praktyki, które warto wdrożyć:

• Sekrety poza repozytorium. Trzymaj je w dedykowanych mechanizmach, takich jak HashiCorp Vault albo natywne usługi chmurowe.
• Rotacja kluczy i tokenów. Szczególnie dla integracji między systemami oraz kont technicznych.
• Podpisane i wersjonowane zmiany pipeline'ów. Definicje CI/CD też powinny przechodzić review.
• Skanowanie zależności i artefaktów. Nie jako jednorazowa akcja przed audytem, tylko element codziennego procesu.
• Rozdział obowiązków. Osoba pisząca zmianę nie powinna mieć zawsze pełnej, niekontrolowanej ścieżki do wdrożenia jej na produkcję.

Bezpieczeństwo w DevSecOps nie polega na dokładaniu kolejnych skanerów. Polega na tym, że zespół nie musi obchodzić procesu, żeby dostarczyć zmianę na czas.

Zdalny zespół też musi mieć zasady fizyczne i operacyjne

Wiele firm zakłada, że skoro pracują zdalnie, kontrole fizyczne ich nie dotyczą. To błąd. Dotyczą, tylko w innej formie. Polityka czystego biurka i ekranu nadal ma sens, nawet jeśli biurkiem jest domowe stanowisko, a ekranem laptop w coworku.

W praktyce warto doprecyzować:

Obszar	Co działa
Sprzęt	Szyfrowanie dysków, standard konfiguracji, zdalne wymazanie, ewidencja urządzeń
Ekran	Automatyczna blokada, ograniczenie pracy z danymi w miejscach publicznych, filtry prywatności tam, gdzie to uzasadnione
Nośniki i pliki	Zakaz lokalnego przechowywania wrażliwych eksportów bez kontroli i retencji
Komunikacja	Jasne zasady, kiedy używamy ticketów, komunikatora, maila i gdzie wolno przekazywać dane klienta

Szkolenia dla developerów muszą dotyczyć ich pracy

Najgorsze szkolenie security awareness to prezentacja pełna ogólników o phishingu, po której backend, frontend i DevOps wracają do pracy bez żadnej zmiany zachowania. Dobre szkolenie odnosi się do codziennych decyzji technicznych.

Lepiej oprzeć je o sytuacje z życia zespołu:

• merge request z wyłączonym sprawdzeniem,
• token wrzucony do pliku konfiguracyjnego,
• debug log zawierający dane klienta,
• tymczasowy dostęp do produkcji, który został na stałe,
• biblioteka bez przeglądu licencji i podatności.

Jeśli potrzebujesz wsparcia po stronie technicznej, jedną z opcji jest usługa web security dla zespołów rozwijających aplikacje i systemy online. Ważne, żeby niezależnie od wybranego partnera kontrole były osadzone w procesie wytwórczym, a nie obok niego.

Faza 4 Audyt wewnętrzny jako próba generalna przed certyfikacją

Audyt wewnętrzny działa jak porządne testy przed releasem. Jego zadaniem nie jest udowodnić, że wszystko jest idealne. Jego zadaniem jest znaleźć to, co rozwali cię później przy audycie zewnętrznym.

Według danych krajowych firm audytorskich, w 90% audytów certyfikujących ISO 27001:2022 w polskich firmach IT wykrywana jest niedostateczna dokumentacja procesów Risk Treatment. Do tego 78% niepowodzeń przy pierwszej próbie certyfikacji wynika z nieprzeprowadzenia wymaganego audytu wewnętrznego przed audytem zewnętrznym (Stage 1).

Jak prowadzić audyt, żeby nie był teatrem

Jeśli audyt wewnętrzny wygląda jak czytanie polityk i potakiwanie właścicieli procesów, to nie jest audyt. To przegląd dokumentów. Prawdziwy test zaczyna się wtedy, gdy pytasz o dowody i sprawdzasz, czy proces działa w praktyce.

Dobry audytor wewnętrzny:

• rozmawia z ludźmi wykonującymi proces, nie tylko z managerem,
• prosi o próbki, logi, ticketi, akceptacje i historię zmian,
• sprawdza, czy dokument odpowiada temu, co naprawdę dzieje się w systemie,
• zapisuje nie tylko niezgodności, ale też obserwacje i ryzyka operacyjne.

Celem audytu wewnętrznego nie jest „zdać”. Celem jest zobaczyć system takim, jaki jest, zanim zrobi to ktoś z zewnątrz.

Pytania, które warto zadać zespołowi

Zamiast abstrakcyjnych rozmów o bezpieczeństwie lepiej wejść w konkret. Poniżej zestaw pytań, które dobrze działają w software house'ie.

Do developerów

• W jaki sposób zgłaszasz incydent bezpieczeństwa lub podejrzane zdarzenie?
• Kto zatwierdza dostęp do repozytorium i produkcji?
• Co robisz, gdy potrzebujesz wyjątku od standardowego procesu wdrożenia?
• Czy wiesz, gdzie przechowywać sekrety i gdzie na pewno nie wolno ich trzymać?

Do DevOps i administratorów

• Jak wygląda przegląd uprawnień do środowisk?
• Czy da się odtworzyć, kto i kiedy zmienił konfigurację?
• Jak testowane jest odtwarzanie backupu?
• Jak obsługiwane są konta techniczne i integracje?

Do PM-ów i delivery

• Jak klasyfikowane są informacje klienta w projekcie?
• Gdzie zapisujecie ustalenia dotyczące bezpieczeństwa i wyjątków procesowych?
• Jak weryfikujesz, że podwykonawca lub nowa usługa nie wprowadza nieakceptowalnego ryzyka?

W obszarze technicznym dobrze działa też praktyka vulnerability assessment, bo pokazuje różnicę między deklarowanym a faktycznym poziomem zabezpieczeń.

Raport i działania korygujące

Raport z audytu nie powinien kończyć się na zdaniu „stwierdzono niezgodności”. Trzeba jasno opisać:

1. Co jest niezgodne
2. Jaki dowód to potwierdza
3. Który wymóg lub kontrola są dotknięte
4. Kto jest właścicielem poprawki
5. W jakim terminie nastąpi korekta
6. Jak sprawdzisz skuteczność działania

Najwięcej wartości daje tu precyzja. „Należy poprawić proces dostępów” nic nie znaczy. „Brak śladu akceptacji dla podniesienia uprawnień do produkcji w dwóch sprawdzonych przypadkach” znaczy bardzo dużo.

Po certyfikacji Utrzymanie i rozwój systemu w zgodzie z NIS2

Po otrzymaniu certyfikatu część firm popełnia ten sam błąd. Traktują projekt jako zamknięty. Tymczasem ISMS działa dobrze tylko wtedy, gdy jest utrzymywany jak produkt wewnętrzny. Ma właścicieli, backlog zmian, przeglądy i regularne sprawdzanie, czy dalej pasuje do architektury oraz modelu pracy.

W praktyce po certyfikacji trzeba pilnować zmian w środowiskach cloud, nowych narzędzi w pipeline'ach, aktualizacji procesu onboardingu, zmian u dostawców i sposobu obsługi incydentów. Szczególnie w software house'ie system szybko się dezaktualizuje, jeśli engineering rozwija proces szybciej niż dokumentacja i kontrole.

Tu wchodzi też drugi ważny temat, czyli zgodność regulacyjna. Wdrożenie ISO 27001 może automatycznie spełnić do 80% wymagań z art. 10 polskiej ustawy wdrażającej dyrektywę NIS2. Mimo to według raportu UKE z 2024 roku tylko 15% firm z sektora IT przeprowadziło audyt zgodności z nowymi wymaganiami, co pokazuje lukę, którą certyfikacja może wypełnić, stanowiąc dowód należytej staranności w ocenie ryzyka.

Co utrzymywać po audycie

• Przeglądy zarządzania. Nie jako formalność, tylko decyzje o ryzyku, priorytetach i zasobach.
• Regularne audyty wewnętrzne. Z naciskiem na obszary, które zmieniają się najszybciej.
• Aktualizację SoA i rejestru ryzyk. Zwłaszcza po zmianach architektury, narzędzi albo modelu świadczenia usług.
• Dowody operacyjne. To one pokazują, że system żyje, a nie tylko istnieje na papierze.

Certyfikat daje wiarygodność. Dopiero utrzymany system daje odporność operacyjną.

---

A CTA for Develos Ratajczak Gajos S.K.A..