Ład zarządczy projektów ICT oparty na zasadzie security by design w 2026 roku

Projekt był realizowany terminowo, dopóki audyt nie zadał jednego pytania

Dyrektor ds. bezpieczeństwa informacji szybko rosnącej spółki z sektora technologii płatniczych miał dobre wiadomości dla zarządu. Nowa platforma onboardingu klientów była gotowa do uruchomienia. Zespół produktowy dostarczył doświadczenie mobilne, zespół inżynieryjny zintegrował weryfikację tożsamości, dział prawny podpisał umowy z dostawcami chmury i interfejsów API, a zespół operacyjny przećwiczył plan uruchomienia produkcyjnego.

Następnie audytor wewnętrzny zadał proste pytanie:

„Pokażcie, gdzie na każdym etapie projektu uwzględniono bezpieczeństwo i prywatność.”

W sali projektowej zapadła cisza.

Był raport z testów penetracyjnych, ale powstał późno. Był diagram architektury chmury, ale brakowało dowodów, że przepływy danych przeanalizowano względem zasad GDPR. Był kwestionariusz due diligence dostawcy, ale nie powiązano go z rejestrem ryzyk. Było zgłoszenie zmiany dotyczące wdrożenia produkcyjnego, ale zatwierdzenie nie odnosiło się do wpływu na usługi krytyczne, zgłaszania incydentów, testowania odporności, powiadamiania klientów ani eskalacji naruszenia ochrony danych osobowych. Były notatki ze sprintów, ale wymagania bezpieczeństwa były rozproszone w historyjkach użytkownika i wiadomościach czatowych.

Nic nie wyglądało na oczywiste zaniedbanie. Wszystko przypominało intensywnie prowadzony, nowoczesny projekt ICT. Jednak dla podmiotu finansowego objętego DORA, dostawcy SaaS potencjalnie objętego zakresem NIS2 oraz administratora lub podmiotu przetwarzającego w rozumieniu GDPR problemem nie było już tylko to, czy bezpieczeństwo zostało zapewnione. Problemem było to, czy można wykazać stosowanie zasady security by design.

To jest wyzwanie roku 2026. Projekty ICT nie są już oceniane wyłącznie przez pryzmat szybkości dostarczenia, kontroli kosztów i jakości technicznej. Ocenia się je przez dowody ładu zarządczego: oceny ryzyka, decyzje projektowe, due diligence dostawców, zapisy bezpiecznego wytwarzania oprogramowania, zatwierdzenia zmian, decyzje dotyczące prywatności, wyniki testów oraz nadzór kierownictwa.

ISO/IEC 27001:2022 daje organizacjom praktyczny szkielet systemu zarządzania do rozwiązania tego problemu. Pomaga dyrektorom ds. bezpieczeństwa informacji, menedżerom zgodności, sponsorom projektów, inspektorom ochrony danych, architektom, zespołom zakupowym i audytorom przekształcać istotne projekty ICT w możliwe do obrony dowody stosowania zasady security by design.

Dlaczego ład zarządczy projektów ICT stał się problemem dowodowym w regulacjach

Migracja do chmury, portal klienta, platforma płatnicza, wdrożenie CRM, zmiana dostawcy tożsamości, potok analityczny, integracja API, przepływ pracy SaaS, aplikacja low-code lub przejście na usługę zarządzaną mogą zmienić profil ryzyka organizacji. W 2026 roku takie zmiany zachodzą w warunkach nakładających się obowiązków.

NIS2 ma szerokie zastosowanie do podmiotów kluczowych i ważnych w sektorach z Załącznika I i Załącznika II, w tym infrastruktury cyfrowej, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa oraz dostawców cyfrowych. NIS2 Article 20 nakłada na organy zarządzające odpowiedzialność za zatwierdzanie środków zarządzania ryzykiem cyberbezpieczeństwa i nadzorowanie ich wdrożenia. NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w zakresie zarządzania ryzykiem, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego nabywania, bezpiecznego wytwarzania oprogramowania, obsługi podatności, oceny skuteczności, cyberhigieny, kryptografii, kontroli dostępu, zarządzania aktywami oraz bezpiecznej komunikacji.

DORA ma zastosowanie do podmiotów finansowych i koncentruje się na cyfrowej odporności operacyjnej. DORA Article 5 przypisuje organowi zarządzającemu odpowiedzialność za zarządzanie ryzykiem ICT. DORA Article 6 wymaga solidnych, kompleksowych i dobrze udokumentowanych ram zarządzania ryzykiem ICT. DORA obejmuje również zgłaszanie incydentów związanych z ICT, testowanie odporności operacyjnej, ciągłość działania ICT, reagowanie i odtwarzanie, wymianę informacji o cyberzagrożeniach, zarządzanie ryzykiem stron trzecich ICT, ustalenia umowne oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT.

GDPR dodaje warstwę rozliczalności dla danych osobowych. GDPR Article 25 wymaga ochrony danych w fazie projektowania i domyślnej ochrony danych. Administratorzy muszą być w stanie wykazać zgodność z zasadami takimi jak zgodność z prawem, rzetelność, przejrzystość, ograniczenie celu, minimalizacja danych, ograniczenie przechowywania, integralność, poufność i rozliczalność. Jeżeli przetwarzanie może powodować wysokie ryzyko, może być również wymagana ocena skutków dla ochrony danych (DPIA) na podstawie GDPR Article 35.

Wspólnym mianownikiem są dowody. Organy regulacyjne i audytorzy nie pytają wyłącznie, czy platforma była szyfrowana, aktualizowana, skanowana albo testowana. Pytają, czy organizacja może wykazać, że bezpieczeństwo, prywatność, ryzyko dostawców i odporność były elementem procesu decyzyjnego od samego początku.

Dlatego ład zarządczy projektów oparty na ISO/IEC 27001:2022 jest tak skuteczny. Pozwala organizacji zarządzać NIS2, DORA, GDPR, NIST CSF 2.0, obowiązkami umownymi i programami zapewnienia dla klientów w ramach jednego powtarzalnego procesu SZBI, zamiast wielu odseparowanych list kontrolnych.

Szkielet ładu zarządczego projektów według ISO 27001

ISO/IEC 27001:2022 bywa błędnie postrzegana jako ćwiczenie certyfikacyjne. W projektach ICT jej wartość operacyjna jest szersza. Zapewnia szkielet ładu zarządczego dla zmian biznesowych.

Klauzule 4.1–4.4 wymagają, aby organizacje rozumiały zagadnienia wewnętrzne i zewnętrzne, zainteresowane strony, wymagania prawne, regulacyjne i umowne, zakres SZBI, interfejsy oraz zależności. W ujęciu projektowym oznacza to, że karta projektu powinna identyfikować objęte wpływem usługi, klientów, dostawców, regulacje, procesy biznesowe, dane osobowe, operacje krytyczne oraz usługi outsourcingowe.

Klauzule 5.1–5.3 wymagają zaangażowania kierownictwa, zgodności z politykami, zasobów, integracji z procesami biznesowymi oraz przypisanych odpowiedzialności. Ma to znaczenie, ponieważ zarówno NIS2, jak i DORA przypisują cyberbezpieczeństwo i ryzyko ICT do odpowiedzialności organu zarządzającego. Projekt zmieniający krytyczną platformę klienta nie może opierać się na nieformalnym komentarzu bezpieczeństwa w wątku czatowym. Wymaga jasnej rozliczalności.

Klauzule 6.1.1–6.1.3 wymagają powtarzalnego procesu oceny ryzyka i postępowania z ryzykiem, kryteriów ryzyka, właścicieli ryzyka, oceny poufności, integralności i dostępności, planów postępowania z ryzykiem, Deklaracji stosowania oraz zatwierdzenia ryzyka rezydualnego. W tym miejscu ryzyko projektowe staje się dowodem audytowym.

Klauzule 7.1–7.5 wymagają zasobów, kompetencji, świadomości, komunikacji oraz nadzoru nad udokumentowaną informacją. Dzięki temu zapisy projektowe stają się wiarygodnymi dowodami, a nie rozproszonymi artefaktami.

Klauzula 8.1 wymaga planowania i nadzoru operacyjnego, udokumentowanej informacji wykazującej, że procesy zrealizowano zgodnie z planem, kontroli planowanych zmian, przeglądu niezamierzonych zmian, ograniczania negatywnych skutków oraz kontroli procesów, produktów lub usług dostarczanych zewnętrznie, które są istotne dla SZBI. Klauzule 8.2 i 8.3 wymagają przeprowadzania ocen ryzyka bezpieczeństwa informacji oraz postępowania z ryzykiem w zaplanowanych odstępach lub po wystąpieniu istotnych zmian.

Załącznik A łączy następnie ten cykl zarządzania z praktycznymi zabezpieczeniami. Dla security by design w projektach ICT kluczowe są trzy zabezpieczenia z Załącznika A ISO/IEC 27001:2022:

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap traktuje bezpieczeństwo informacji w zarządzaniu projektami jako zagadnienie ładu zarządczego we wszystkich typach projektów, a nie tylko w wytwarzaniu oprogramowania:

„Każdy projekt — migracja systemu marketingowego, relokacja budynku, przeprojektowanie procesu biznesowego, platforma onboardingu HR, a nawet fuzja lub przejęcie — może wpływać na poufność, integralność lub dostępność informacji. Gdy tak się dzieje, bezpieczeństwo musi mieć miejsce przy stole decyzyjnym.”

Ta sama sekcja ujmuje kluczową lekcję wdrożeniową:

„Celem tego zabezpieczenia nie jest obciążanie projektów biurokracją. Celem jest zapewnienie, że bezpieczeństwo jest traktowane jako wejście projektowe, a nie faza testów.”

To rozróżnienie oddziela pozorną zgodność od możliwej do obrony zasady security by design.

Jak wygląda security by design wewnątrz projektu ICT

Security by design zaczyna się przed pierwszym sprintem, wnioskiem zakupowym, diagramem architektury lub podręcznikiem migracji. Zadaje proste pytanie: co ten projekt może zmienić w ryzyku?

Praktyczny model ładu zarządczego projektu wykorzystuje siedem bramek dowodowych.

Nie chodzi o biurokrację. Chodzi o to, aby bezpieczeństwo było widoczne tam, gdzie faktycznie zapadają decyzje projektowe.

Clarysec Enterprise Polityka bezpieczeństwa informacji ujmuje to bezpośrednio:

„Ład bezpieczeństwa należy zintegrować z ładem korporacyjnym, zarządzaniem projektami, zakupami oraz funkcjami nadzoru prawnego, aby zapewnić, że bezpieczeństwo informacji nie jest odseparowane, lecz wbudowane w procesy podejmowania decyzji biznesowych.”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.5.

Polityka wskazuje również, że cykle życia projektów są objęte wdrożeniem:

„Cykle życia projektów (np. bezpieczne wytwarzanie oprogramowania, modelowanie zagrożeń)”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.1.1.

I formułuje zasadę audytową, którą wiele organizacji odkrywa zbyt późno:

„Wszystkie wdrożone zabezpieczenia muszą być możliwe do prześledzenia audytowo, wspierane udokumentowanymi procedurami oraz zachowanymi dowodami działania.”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.6.1.

Innymi słowy, prace bezpieczeństwa, które nie są objęte ładem zarządczym, zachowane i zmapowane, często nie przejdą audytu, nawet jeśli zespoły techniczne podejmowały racjonalne decyzje.

Od modelowania zagrożeń do dowodów: praktyczny przykład fintech

Rozważmy projekt uruchomienia nowego portalu onboardingu klientów w UE dla fintechu. Portal gromadzi dokumenty tożsamości, wykonuje weryfikację biometryczną przez stronę trzecią, przechowuje status onboardingu, integruje się z CRM, wyzwala powiadomienia klientów i zasila punktację ryzyka.

Podejście security by design budowałoby dowody w miarę postępu projektu.

Po pierwsze, należy otworzyć zapis klasyfikacji bezpieczeństwa projektu. Trzeba ustalić, czy projekt wpływa na funkcje krytyczne lub ważne, dane osobowe, szczególne kategorie danych osobowych, uwierzytelnianie, dostępność usług dla klientów, outsourcingowe usługi ICT, regulowane procesy sprawozdawcze lub komunikację z klientami. Zgodnie z GDPR dane biometryczne wykorzystywane do jednoznacznej identyfikacji są szczególną kategorią danych osobowych, chyba że ma zastosowanie konkretny wyjątek. To natychmiast podnosi wymagany poziom analizy prawnej i zabezpieczeń.

Po drugie, należy utworzyć projektową ocenę ryzyka. Clarysec SME Polityka zarządzania ryzykiem czyni zarządzanie ryzykiem elementem planowania, a nie kwartalnym ćwiczeniem w arkuszu kalkulacyjnym:

„1.2 Zapewnia, że zarządzanie ryzykiem jest aktywnym składnikiem planowania, realizacji projektów, wyboru dostawców i reagowania na incydenty, zgodnie z ISO 27001, ISO 31000 oraz mającymi zastosowanie wymaganiami regulacyjnymi.”

Z sekcji „Cel”, klauzula polityki 1.2.

Dla środowisk enterprise Clarysec Enterprise Polityka zarządzania ryzykiem definiuje zakres na poziomie strategicznym, operacyjnym, projektowym i technicznym:

„Obejmuje ryzyka bezpieczeństwa informacji na poziomie strategicznym, operacyjnym, projektowym i technicznym oraz jest obowiązkowa dla całego personelu, wykonawców i dostawców usług zaangażowanych w działania Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).”

Z sekcji „Zakres”, klauzula polityki 2.3.

Po trzecie, należy przeprowadzić modelowanie zagrożeń przed rozpoczęciem prac rozwojowych. Enterprise Polityka bezpiecznego wytwarzania oprogramowania wskazuje to jednoznacznie:

„Wszystkie nowe aplikacje i istotne zmiany muszą przejść przegląd bezpiecznej architektury oraz modelowanie zagrożeń przed rozpoczęciem prac rozwojowych.”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Dla portalu onboardingu model zagrożeń powinien obejmować eksponowane interfejsy, przepływy tożsamości, granice uprawnień, przypadki nadużyć API, podszywanie się pod webhooki, ataki powtórzeniowe, naruszone poświadczenia, ścieżki wycieku danych, ryzyko zależności, wymagania rejestrowania, założenia dotyczące kopii zapasowych, wymagania odtwarzania oraz tryby awarii dostawcy.

Po czwarte, należy zaktualizować dowody dotyczące prywatności. SME Polityka ochrony danych i prywatności ustanawia bazowy wymóg:

„5.3.1. Privacy by design i privacy by default muszą być egzekwowane we wszystkich nowych systemach i usługach”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.1.

Zapis projektu powinien obejmować cel, podstawę prawną, rolę administratora lub podmiotu przetwarzającego, decyzje dotyczące minimalizacji danych, reguły retencji, role dostępu, wybory w zakresie szyfrowania, ocenę wpływu na osoby, których dane dotyczą, wymagania przejrzystości, warunki dla podmiotów przetwarzających oraz ścieżki zgłaszania naruszenia ochrony danych osobowych.

Po piąte, należy zarejestrować dowody bezpiecznego wytwarzania oprogramowania. SME Polityka bezpiecznego wytwarzania oprogramowania zawiera zwięzłą listę dowodową odpowiednią dla małych i średnich zespołów:

„5.3 Dyrektor Generalny (GM) musi utrzymywać zapisy dotyczące: 5.3.1 wszystkich aktywnych projektów rozwoju oprogramowania oraz odpowiedzialnych programistów lub dostawców 5.3.2 list kontrolnych bezpieczeństwa stosowanych dla każdego projektu 5.3.3 wykonanych przeglądów kodu oraz osób, które je przeprowadziły 5.3.4 wyników testów przed wdrożeniem 5.3.5 komponentów stron trzecich oraz ich powiązanego statusu licencyjnego lub statusu ryzyka”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.

Po szóste, należy kontrolować wdrożenie jako zmianę. SME Polityka zarządzania zmianami stanowi:

„1.1 Niniejsza polityka zapewnia, że wszystkie zmiany w systemach IT, konfiguracjach, aplikacjach biznesowych lub usługach chmurowych są planowane, oceniane pod kątem ryzyka, testowane i zatwierdzane przed wdrożeniem.”

Z sekcji „Cel”, klauzula polityki 1.1.

Dla portalu onboardingu zgłoszenie zmiany powinno obejmować objęte wpływem usługi, ocenę ryzyka, wyniki testów, plan wycofania zmian, plan monitorowania, zatwierdzenia bezpieczeństwa, akceptację prywatności, gotowość dostawcy, aktualizacje eskalacji incydentów oraz wyzwalacze komunikacji z klientami.

Na koniec należy zmapować obowiązki. SME Polityka zgodności prawnej i regulacyjnej określa zasadę operacyjną:

„5.2.2 Jeżeli regulacja ma zastosowanie do wielu obszarów (np. GDPR dotyczy retencji, bezpieczeństwa i prywatności), musi to zostać jasno zmapowane w Rejestrze zgodności oraz materiałach szkoleniowych.”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.2.

Ten Rejestr zgodności staje się pomostem między zabezpieczeniami ISO/IEC 27001:2022, środkami NIS2 Article 21, obowiązkami DORA w zakresie ryzyka ICT, rozliczalnością GDPR oraz zobowiązaniami umownymi wobec klientów.

Mapowanie jednego pakietu dowodów projektowych na NIS2, DORA, GDPR i NIST CSF 2.0

Najskuteczniejsza strategia zgodności nie polega na dublowaniu pracy. Polega na mapowaniu jednego silnego zestawu dowodów na wiele obowiązków.

Zenith Blueprint, w fazie zarządzania ryzykiem, krok 14, rekomenduje taki rodzaj odwołań krzyżowych:

„Dla każdej regulacji, jeśli ma zastosowanie, można utworzyć prostą tabelę mapowania (np. jako załącznik do raportu), która wymienia kluczowe wymagania bezpieczeństwa danej regulacji oraz odpowiadające im zabezpieczenia/polityki w SZBI.”

Dodaje również, że jest to przydatne, ponieważ pokazuje audytorom i asesorom, „że nie zarządzasz bezpieczeństwem w próżni, lecz uwzględniasz kontekst prawny”.

Clarysec Zenith Controls: The Cross-Compliance Guide wspiera to samo zintegrowane podejście, mapując zabezpieczenia ISO/IEC 27001:2022 na inne ramy, oczekiwania audytowe i potrzeby zgodności. W odniesieniu do ładu zarządczego projektów ICT ujmuje A.5.8, A.8.25 i A.8.32 jako kontrole zapobiegawcze chroniące poufność, integralność i dostępność w obszarach ładu zarządczego, bezpieczeństwa aplikacji, ekosystemu, ochrony oraz bezpieczeństwa systemów i sieci.

Ta tabela nie zastępuje analizy prawnej. Jest akceleratorem ładu zarządczego. Zapewnia, że CISO, DPO, sponsor projektu, osoba odpowiedzialna za zakupy, właściciel systemu i audytor wewnętrzny patrzą na te same dowody.

NIST CSF 2.0 również naturalnie wpisuje się w ten model. Funkcja GOVERN pomaga organizacjom ustanowić polityki, role, apetyt na ryzyko, nadzór oraz świadomość prawną lub umowną. Funkcje IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER pomagają zespołom omawiać aktywa, usługi dostawców, kontrolę dostępu, bezpieczeństwo danych, bezpieczeństwo platform, bezpieczne wytwarzanie oprogramowania, monitorowanie, reagowanie na incydenty i odtwarzanie we wspólnym języku operacyjnym.

Jeden proces dostosowany do ISO 27001, oparty na Załączniku A.5.8, może generować możliwe do obrony dowody dla wszystkich tych oczekiwań.

Bezpieczne wytwarzanie oprogramowania to więcej niż pisanie kodu

Wiele niepowodzeń projektów ICT wynika z tego, że organizacja traktuje bezpieczne wytwarzanie oprogramowania jako coś, czym zajmują się wyłącznie programiści. W 2026 roku bezpieczne wytwarzanie oprogramowania obejmuje również konfigurację SaaS, automatyzację przepływów pracy, infrastrukturę jako kod, integracje API, reguły tożsamości, strefy bazowe chmury, potoki analityczne, robotyzację procesów oraz biznesowe aplikacje low-code.

Zenith Blueprint, w fazie „Zabezpieczenia w praktyce”, krok 20, odnosi się do zabezpieczenia ISO/IEC 27002:2022 8.25 Secure Development Life Cycle:

„To zabezpieczenie ma zastosowanie niezależnie od tego, czy tworzysz własne aplikacje, konfigurujesz platformy takie jak systemy ERP lub CRM, dostosowujesz przepływy pracy SaaS, czy zarządzasz środowiskami infrastruktury jako kodu.”

Wyjaśnia także, że wymagania bezpieczeństwa muszą znajdować się obok wymagań funkcjonalnych, a modelowanie zagrożeń pomaga identyfikować eksponowane części systemu, ryzykowne role użytkowników oraz przepływy danych wymagające wyższego poziomu ochrony.

W nowoczesnym projekcie dowody bezpiecznego wytwarzania oprogramowania mogą obejmować:

• Wymagania bezpieczeństwa powiązane z wymaganiami biznesowymi
• Model zagrożeń lub przegląd bezpiecznej architektury
• Listę kontrolną bezpiecznego kodowania lub bezpiecznej konfiguracji
• Zapisy przeglądu kodu lub przeglądu wzajemnego
• Inwentarz komponentów i status ryzyka zależności
• Decyzje dotyczące zarządzania sekretami
• Projekt kontroli dostępu i zasady najmniejszych uprawnień
• Wymagania dotyczące rejestrowania i monitorowania
• Wyniki skanów podatności i zapisy działań naprawczych
• Testy bezpieczeństwa w środowisku przedprodukcyjnym
• Testy kopii zapasowych, odtwarzania i odporności, gdy są istotne
• Zatwierdzenie wdrożenia i dowody planu wycofania zmian

Celem nie jest przepychanie każdego projektu przez ten sam ciężki proces. Celem jest proporcjonalność. Drobna zmiana wewnętrznego przepływu pracy nie wymaga takich samych dowodów jak migracja podstawowej platformy płatniczej. Każdy projekt powinien jednak zostać sklasyfikowany, oceniony pod kątem ryzyka i objęty ładem zarządczym odpowiednim do wpływu.

Zarządzanie zmianami chroni projekt przed nim samym

Najbardziej ryzykownym momentem w wielu projektach nie jest projektowanie ani kodowanie. Jest nim wdrożenie.

Zespół może przeprowadzić modelowanie zagrożeń, przegląd kodu, ocenę dostawcy i przegląd prywatności, a mimo to spowodować awarię lub naruszenie przez pośpieszną zmianę produkcyjną. Flaga debugowania pozostaje włączona. Reguła zapory sieciowej jest szersza niż zatwierdzono. Skrypt migracyjny kopiuje dane osobowe do środowiska nieprodukcyjnego. Endpoint webhooka strony trzeciej zostaje wdrożony bez uwierzytelniania. Zmiana rejestrowania zapisuje numery dokumentów tożsamości. Zadanie kopii zapasowej po przełączeniu po cichu przestaje działać.

Zenith Blueprint, w fazie „Zabezpieczenia w praktyce”, krok 21, opisuje zabezpieczenie ISO/IEC 27002:2022 8.32 Zarządzanie zmianami wprost:

„Zmiana jest nieunikniona, ale w cyberbezpieczeństwie niekontrolowana zmiana jest niebezpieczna.”

Dalej wskazuje:

„U podstaw skutecznego zarządzania zmianami leży powtarzalny przepływ pracy. Zaczyna się od jasnej propozycji określającej, co się zmienia, dlaczego, kiedy oraz jakie są potencjalne ryzyka.”

Silny zapis zmiany ICT powinien odpowiadać na pytania:

• Jaki system, usługa, przepływ danych, dostawca lub konfiguracja ulega zmianie?
• Jakie ryzyka zidentyfikowano i kto jest ich właścicielem?
• Czy zmiana wpływa na dane osobowe, usługi krytyczne, uwierzytelnianie, rejestrowanie, kopie zapasowe lub reagowanie na incydenty?
• Jakie kontrole bezpieczeństwa, prywatności, odporności i dostawców wykonano?
• Jakie testy zakończono przed wdrożeniem?
• Jakie monitorowanie potwierdzi oczekiwane działanie?
• Jaki istnieje plan wycofania zmian lub odtwarzania?
• Kto zatwierdził ryzyko rezydualne?
• Jakie dowody zostaną zachowane?

W przypadku DORA wspiera to udokumentowane zarządzanie ryzykiem ICT, odporność, ciągłość działania, klasyfikację incydentów i wnioski po zdarzeniach. W przypadku NIS2 wspiera środki zarządzania ryzykiem, bezpieczne wytwarzanie oprogramowania, zapobieganie incydentom i ciągłość działania. W przypadku GDPR pomaga wykazać, że zmiany wpływające na dane osobowe zostały przeanalizowane względem zasad celu, minimalizacji, okresu przechowywania, dostępu i bezpieczeństwa.

Decyzje dotyczące dostawców i chmury muszą być częścią projektu

W nowoczesnych projektach ICT decyzją projektową o najwyższym ryzyku jest często „kupić”, a nie „zbudować”. Usługi chmury obliczeniowej, dostawcy API, platformy weryfikacji tożsamości, procesorzy płatności, dostawcy analityki, dostawcy usług zarządzanych i dostawcy zarządzanych usług bezpieczeństwa stają się częścią powierzchni ryzyka.

NIS2 wyraźnie obejmuje bezpieczeństwo łańcucha dostaw, podatności bezpośrednich dostawców i dostawców usług, praktyki cyberbezpieczeństwa dostawców, procedury bezpiecznego wytwarzania oprogramowania oraz wyniki skoordynowanych ocen ryzyka łańcucha dostaw. DORA idzie dalej w przypadku podmiotów finansowych. Wymaga zarządzania ryzykiem stron trzecich ICT jako części ram zarządzania ryzykiem ICT, utrzymania odpowiedzialności nawet przy outsourcingu usług ICT, rejestrów informacji, ocen przedkontraktowych, analizy ryzyka koncentracji, kontroli umownych, praw do audytu i inspekcji, przesłanek rozwiązania umowy oraz przetestowanych strategii wyjścia dla funkcji krytycznych lub ważnych.

W przypadku portalu onboardingu dostawca weryfikacji biometrycznej nie może zostać zatwierdzony tylko dlatego, że dział zakupów akceptuje cenę, a dokumentacja API jest dobra. Projekt wymaga dowodów due diligence bezpieczeństwa, roli w przetwarzaniu, lokalizacji danych, podwykonawców, zobowiązań dostępnościowych, wsparcia incydentowego, praw do audytu, pomocy przy zakończeniu umowy, wykonalności wyjścia oraz obowiązków monitorowania.

W dojrzałym modelu dowodowym decyzje dotyczące dostawców i chmury znajdują się w pakiecie dowodów projektowych, a nie w odseparowanym folderze dostawcy. Gdy audytor pyta, dlaczego zaakceptowano stronę trzecią, odpowiedź powinna obejmować potrzebę biznesową, ocenę ryzyka, zabezpieczenia umowne, przegląd ochrony danych, wpływ na odporność oraz ciągłe monitorowanie.

Jak audytorzy będą przeglądać dowody security by design

Różni audytorzy patrzą na ten sam projekt ICT z różnych perspektyw. Audytor certyfikacyjny, audytor wewnętrzny, przeglądający DORA, właściwy organ NIS2, audytor prywatności, asesor zorientowany na NIST lub audytor w stylu COBIT/ISACA mogą prosić o podobne dowody, ale interpretować je inaczej.

Audytorzy nie potrzebują efektownej prezentacji projektowej. Potrzebują identyfikowalności. Chcą zobaczyć, że wymagania prowadziły do ryzyk, ryzyka do zabezpieczeń, zabezpieczenia do dowodów wdrożenia, a wdrożenie do przeglądu.

Dlatego Zenith Controls jest przydatny w przygotowaniu do audytu. Pomaga zespołom wyjaśnić, dlaczego Załącznik A.5.8, A.8.25 i A.8.32 są kontrolami zapobiegawczymi, które chronią poufność, integralność i dostępność, zanim przewidywalne niepowodzenia trafią na produkcję.

Minimalny pakiet dowodów projektowych Clarysec

Silny pakiet dowodów security by design nie musi być ogromny. Musi być spójny, proporcjonalny i zmapowany.

Dla projektu ICT o średnim ryzyku Clarysec zazwyczaj rekomenduje następujący minimalny pakiet:

1. Zapis klasyfikacji bezpieczeństwa projektu
2. Notatka dotycząca mających zastosowanie regulacji obejmująca NIS2, DORA tam, gdzie istotne, GDPR oraz obowiązki umowne
3. Mapa przepływów danych i wpływu na aktywa
4. Ocena ryzyka projektu i plan postępowania z ryzykiem
5. Model zagrożeń lub przegląd bezpiecznej architektury
6. Ocena dostawcy i usługi chmurowej, gdy ma zastosowanie
7. Lista kontrolna bezpiecznego wytwarzania oprogramowania lub lista kontrolna konfiguracji
8. Wyniki testów bezpieczeństwa i dowody działań naprawczych
9. Zatwierdzenie zmiany z planem wycofania zmian i planem monitorowania
10. Zapis privacy by design, w tym podstawa prawna i okres przechowywania, gdy występują dane osobowe
11. Aktualizacje reagowania na incydenty i monitorowania
12. Przegląd powdrożeniowy i wnioski z projektu
13. Mapowanie Rejestru zgodności na zabezpieczenia i obowiązki

Zenith Blueprint dostarcza logikę mapy drogowej. Krok 22 wprowadza bezpieczeństwo informacji do wszystkich etapów projektu. Krok 20 wbudowuje bezpieczne wytwarzanie oprogramowania w planowanie, projekt, kod, testowanie i wdrożenie. Krok 21 sprawia, że zarządzanie zmianami jest ustrukturyzowane, identyfikowalne i możliwe do przeglądu. Krok 14 rekomenduje odwołania krzyżowe do GDPR, NIS2, DORA i innych obowiązków, aby wymagania zgodności nie wypadały z procesu.

Polityki ustanawiają reguły operacyjne. Polityka bezpieczeństwa informacji integruje bezpieczeństwo z zarządzaniem projektami, zakupami i nadzorem prawnym. Polityka zarządzania ryzykiem czyni ryzyka projektowe częścią działań SZBI. Polityka bezpiecznego wytwarzania oprogramowania wymaga modelowania zagrożeń. Polityka zarządzania zmianami wymaga zmian planowanych, ocenionych pod kątem ryzyka, testowanych i zatwierdzonych. Polityka ochrony danych i prywatności wymaga privacy by design i privacy by default. Polityka zgodności prawnej i regulacyjnej wymaga mapowania regulacji obejmujących wiele obszarów w Rejestrze zgodności.

Razem narzędzia te przekształcają security by design z aspiracji w możliwy do audytu model operacyjny.

Typowe wzorce niepowodzeń w projektach ICT

Niepowodzenia są zwykle przewidywalne.

Pierwszym jest zbyt późne zaangażowanie bezpieczeństwa. Przeglądy bezpieczeństwa odbywają się po utrwaleniu architektury, podpisaniu umów i publicznym ogłoszeniu terminów dostarczenia. Wtedy bezpieczeństwo staje się blokadą, a nie wejściem projektowym.

Drugim są rozproszone dowody. Projekt ma wyniki testów w jednym narzędziu, przegląd dostawcy w innym, komentarze dotyczące prywatności w poczcie elektronicznej, akceptację ryzyka w nagraniu ze spotkania i zatwierdzenie zmiany w zgłoszeniu. Żaden pojedynczy wątek nie dowodzi ładu zarządczego.

Trzecim są martwe pola dotyczące dostawców. Projekt opiera się na usłudze chmurowej lub dostawcy API, ale nikt nie sprawdza podwykonawców, lokalizacji danych, praw do audytu, wsparcia incydentowego, planów wyjścia ani ryzyka koncentracji.

Czwartym jest dryf prywatności. System zbudowany dla jednego celu zaczyna wspierać analitykę, eksperymenty AI, eksporty marketingowe lub monitorowanie operacyjne bez ponownego przeglądu podstawy prawnej, przejrzystości, minimalizacji albo okresu przechowywania.

Piątym jest nieprzejrzana zmiana. Wdrożenie produkcyjne zostaje zatwierdzone pod względem funkcjonalności, ale nie oceniono go pod kątem dostępu, rejestrowania, szyfrowania, kopii zapasowych, odporności, danych osobowych ani wpływu na raportowanie.

Szóstym jest słaby nadzór kierownictwa. Ryzyka projektowe o wysokim wpływie są akceptowane na zbyt niskim poziomie, bez dowodów, że odpowiedzialny właściciel ryzyka rozumiał konsekwencje regulacyjne.

Tych problemów nie rozwiązuje zakup kolejnego skanera. Rozwiązuje je integracja ładu bezpieczeństwa ze sposobem, w jaki projekty są proponowane, projektowane, zamawiane, budowane, testowane, zmieniane i przeglądane.

Wniosek dla CISO na 2026 rok

Security by design w projektach ICT jest dziś kwestią zarządczą, audytową i regulacyjną. NIS2 czyni zarządzanie ryzykiem cyberbezpieczeństwa zagadnieniem organu zarządzającego. DORA przekształca ryzyko ICT, testowanie odporności, zarządzanie incydentami i nadzór nad stronami trzecimi w ustrukturyzowany obowiązek sektora finansowego. GDPR wymaga rozliczalności za przetwarzanie danych osobowych i odpowiedniego bezpieczeństwa. ISO/IEC 27001:2022 zapewnia strukturę systemu zarządzania, która pozwala operacjonalizować te obowiązki.

Dla CISO szansą jest zakończenie walki z zespołami projektowymi na końcu dostarczenia. Wprowadź bezpieczeństwo do inicjacji, wymagań, projektu, wyboru dostawcy, budowy, testów, zatwierdzania zmian i przeglądu powdrożeniowego.

Dla menedżerów zgodności szansą jest zastąpienie rozproszonych dowodów jednym zmapowanym pakietem dowodów projektowych.

Dla audytorów szansą jest testowanie cyklu życia projektu, a nie tylko końcowego systemu.

Dla właścicieli biznesowych szansą jest szybsze i bezpieczniejsze dostarczanie. Security by design ogranicza przeróbki, zapobiega niespodziankom w obszarze zgodności, poprawia decyzje dotyczące dostawców i daje kierownictwu możliwą do obrony narrację ryzyka.

Jeżeli Twoje projekty ICT poruszają się szybciej niż model dowodowy, zacznij od jednego projektu pilotażowego. Użyj Clarysec Zenith Blueprint, aby zdefiniować bramki bezpieczeństwa projektu, zastosuj polityki Clarysec dotyczące zarządzania ryzykiem, bezpiecznego wytwarzania oprogramowania, zarządzania zmianami i prywatności, a następnie użyj Zenith Controls, aby zmapować ład zarządczy projektów ISO/IEC 27001:2022 na NIS2, DORA, GDPR i NIST CSF 2.0.

Clarysec może pomóc w zbudowaniu pakietu dowodów projektowych wielokrotnego użytku opartego na security by design, dostosowaniu go do SZBI oraz przygotowaniu do audytu wewnętrznego, audytu certyfikacyjnego, gotowości DORA, ładu zarządczego NIS2 i rozliczalności GDPR.

Zacznij od kolejnego istotnego projektu ICT. Jeżeli zmienia systemy, dostawców, dane, dostęp, odporność lub zaufanie klientów, zasługuje na security by design od pierwszego dnia.