GRC na żywym organizmie - implementacja PDCA

Dlaczego zbudowałem własną platformę?

Przez ponad kilkanaście lat pracy w obszarach jakości, bezpieczeństwa informacji, zarządzania ryzykiem oraz zgodności obserwowałem, że największa różnica pomiędzy teorią a praktyką pojawia się w momencie wdrożenia. Dlatego stworzyłem SecureHaveNET - własną platformę, która pełni rolę poligonu doświadczalnego, gdzie mogę testować i doskonalić podejścia związane z GRC, ISO/IEC 27001, PDCA oraz zarządzaniem ryzykiem w rzeczywistym środowisku.

SecureHaveNET powstał z prostej potrzeby sprawdzenia teorii w praktyce. Sprawdzenie swoich umiejętności w różnych rolach, a w końcu spisanie tych doświadczeń nie tylko dla siebie, ale też dla innych.

GRC w praktyce a może to abstrakcja?

Dla wielu GRC to tylko zbiór reguł.

Ja czuję to inaczej: dla mnie to system operacyjny mojego projektu.

Zarządzanie domeną i strukturą SecureHaveNET nie ograniczyło się do wrzucenia prostego pliku index.html na serwer. To był wybór świadomej hierarchii i architektury. W tym kontekście GRC stało się dla mnie zestawem pytań o cel, ryzyko i zgodność.

Governance (Zarządzanie): To moja wizja. Czy ta nazwa, ta struktura i ten szkielet serwisu faktycznie realizują cel, jakim jest stworzenie merytorycznego poligonu wiedzy? Przystań, która nie tylko mnie rozwija, ale też inspiruje i jest użyteczna dla czytelników.

Risk (Ryzyko): To umiejętność przewidywania, co może zniszczyć tę wizję - od błędów w architekturze, przez problemy z wydajnością, po brak merytorycznych treści dla czytelnika.

Compliance (zgodność): To identyfikacja mających zastosowanie wymagań prawnych, umownych i przyjętych zasad oraz sprawdzanie ich spełnienia. Własne oczekiwania jakościowe oceniam dodatkowo jako kryteria projektu.

Dopiero gdy zdefiniowałem GRC w ten sposób, mogłem przejść do realnej budowy - i właśnie tutaj, w procesie ciągłego sprawdzania tej spójności, narodziło się moje podejście oparte na PDCA. Poniżej przedstawiam, jak przekułem te założenia na konkretne obszary ryzyka i techniczne rozwiązania.

PDCA w praktyce

Jednym z powodów, dla których projekt okazał się tak wartościowy, była możliwość obserwowania działania cyklu PDCA w praktyce, gdzie każda faza jest kluczowa.

Plan (Planowanie)

W mojej ocenie jednym z najczęściej zaniedbanych elementów planowania jest analiza wymagań oraz analiza ryzyka. Pomysł sam w sobie nie jest jeszcze projektem. Musi zostać przełożony na wymagania, ograniczenia oraz oczekiwane rezultaty.

Zarządzanie ryzykiem zaczyna się od pierwszej decyzji

Budowa platformy od początku była dla mnie ćwiczeniem. Każda decyzja projektowa wiązała się z określonymi korzyściami, kosztami oraz potencjalnymi zagrożeniami.

Dlatego zarządzanie ryzykiem było obecne od samego początku jako część etapu planowania. Nie w formie formalnego rejestru, ale jako ciągły proces identyfikacji, oceny i podejmowania decyzji.

Choć nie prowadziłem formalnego rejestru ryzyk, sposób podejmowania decyzji był bardzo zbliżony do podejścia stosowanego podczas realizacji projektów biznesowych. Najpierw identyfikacja zagrożeń. Następnie ocena wpływu. Na końcu wybór odpowiednich działań ograniczających ryzyko. Oczywiście zanim wybrałem ostatecznie rozwiązanie odpowiednie dla mnie testowałem różne opcje, analizowałem plusy i minusy, a także brałem pod uwagę długoterminowe konsekwencje każdej decyzji.

W przypadku SecureHaveNET etap planowania obejmował wybór technologii oraz architektury platformy, a także określenie wymagań dotyczących bezpieczeństwa, wydajności, zgodności z przepisami oraz zapewnienia użytkownikom intuicyjnej i komfortowej obsługi

Powiązania z załącznikiem A są orientacyjne i odnoszą się do wybranych aspektów projektu. Nie zastępują oceny ryzyka, uzasadnienia doboru zabezpieczeń ani weryfikacji ich skuteczności.

Do (Wykonanie)

Po zakończeniu etapu planowania rozpoczyna się właściwa realizacja projektu. To właśnie tutaj teoria spotyka się z praktyką.

W trakcie budowy SecureHaveNET wielokrotnie okazywało się, że rozwiązania poprawne technicznie nie zawsze spełniały oczekiwania dotyczące wydajności, ergonomii czy spójności wizualnej.

Istotnym elementem były również prototypy i testowanie różnych wariantów rozwiązania. Dzięki temu część błędnych decyzji została wyeliminowana jeszcze przed rozpoczęciem właściwej implementacji (chociaż nie wszystkie).

Dlatego realizacja nie polegała wyłącznie na pisaniu kodu. Obejmowała również testowanie różnych koncepcji, analizę rezultatów oraz ciągłe dostosowywanie projektu do założonych celów.

Optymalizacja: Performance vs. UX

Wielu optymalizatorów wpada w pułapkę usuwania wszelkich interakcji, by zyskać milisekundy. Ja postawiłem na kompromis. Zrozumiałem, że strona ma być nie tylko szybka, ale i użyteczna. Wyniki pokazują, że da się to pogodzić - zachowując animacje i dynamikę, osiągnąłem istotny progres

Świadome bezpieczeństwo (Supply Chain Security)

Własny kod i biblioteki utrzymuję lokalnie, aby ograniczyć zależność od zewnętrznych CDN podczas ładowania strony. Nie usuwa to ryzyka związanego z pochodzeniem kodu, jego aktualizacją ani konfiguracją hostingu. Witryna nadal korzysta z usług zewnętrznych, m.in. Google Analytics ładowanego po zgodzie użytkownika. Lokalizacja plików jest jednym z elementów kontroli, a nie gwarancją bezpieczeństwa.

Profesjonalizm budowany na detalach: Od ogółu do szczegółu

Prawdziwy profesjonalizm nie kończy się na wizji - realizuje się w detalach. Moje podejście, oparte na zasadzie top-down design, łączy strategiczne ramy z optymalizacją techniczną. To suma "niewidocznych" decyzji buduje efekt finalny.

• Bezpieczeństwo: Wdrożenie HTTPS, konfiguracja CSP ograniczająca dozwolone źródła zasobów (Content Security Policy) oraz zabezpieczenia przed atakami typu tabnabbing (rel="noopener").
• Wydajność (Performance): Optymalizacja zasobów i sposobu ładowania strony, oceniana na podstawie raportów opisanych w sekcji Check. LCP i TBT opisują różne aspekty wydajności; same wyniki nie wskazują udziału każdej zmiany w poprawie.
• Semantyka i Dostępność: Wdrożenie czystej struktury HTML, która poprawia indeksowanie (SEO) oraz dostępność (A11y).
• Zarządzanie ryzykiem: Transparentna komunikacja disclaimerów i segregacja wizerunkowa, traktowane na równi z zabezpieczeniami technicznymi.

Paradoks PDCA: Dlaczego przestałem gonić za mikronami i sekundami

Jako osoba wywodząca się z jakości, naturalnie dążę do perfekcji. Szybko jednak zauważyłem, że niekończące się iteracje PDCA mogą stać się pułapką - prowadzą do "zamrożenia" projektu przez analizę. W moim projekcie kolejne poprawki zaczęły opóźniać zakończenie pracy. Potrzebowałem kryterium, które pozwoli odróżnić potrzebną zmianę od dalszego dopracowywania szczegółów. Moje podejście zmieniło się w technikę małych kroków: Wdrażam rozwiązanie, które jest "wystarczająco dobre" (nie idealne). Mierzę wyniki. Jeśli wymaga poprawy - ulepszam. Akceptuję fakt, że zawsze znajdzie się coś do poprawy, jeśli mam na to czas.

Zrozumiałem, że nie gonię za mikronami, lecz za wartością. Ukończony projekt, który działa poprawnie, jest wart więcej niż idealny prototyp, który nigdy nie ujrzał światła dziennego.

Przykład decyzji: lokalne zasoby i usługi zewnętrzne

Problem: zależność ładowania witryny od zewnętrznych dostawców kodu. Decyzja: własne skrypty i biblioteki są udostępniane lokalnie, a potrzebne usługi zewnętrzne pozostają odrębnymi zależnościami. Weryfikacja: odnośniki do zasobów i kod inicjalizacji analityki pozwalają sprawdzić ten podział; testy działania wymagają również przeglądarki. Ograniczenie: nadal trzeba kontrolować wersje bibliotek, zmiany usług i konfigurację hostingu. Lokalny plik sam w sobie nie potwierdza bezpieczeństwa kodu.

Check (Sprawdzenie i samoocena)

Etap Check obejmował samodzielną analizę wyników automatycznych testów Google PageSpeed Insights, wykorzystujących Lighthouse. Wyniki pomagały identyfikować obszary do poprawy i oceniać efekty kolejnych iteracji projektu.

Zarówno formalne oceny audytowe (np. klasy zgodności), jak i bieżące wskaźniki procesowe stanowią realne narzędzia, które precyzyjnie wskazują, co wymaga poprawy. (ISO/IEC 27001:2022, punkt 9.1 Monitorowanie, pomiar, analiza i ocena).

Wyjaśnienie skali:

• 0-49: Krytyczne (Wymaga interwencji)
• 50-89: Wymaga optymalizacji
• 90-100: Optymalny

Nowy pomiar: 29.09.2026

Wyniki dla strony głównej https://securehavenet.ovh/, desktop: 16:54 CEST, mobile: 16:59 CEST, Lighthouse 13.5.0. Skala: 0-100 punktów.

PageSpeed Insights - Desktop · PageSpeed Insights - Mobile

To wyniki automatycznego testu pojedynczego adresu, a nie potwierdzenie pełnej zgodności z WCAG ani audyt bezpieczeństwa całej witryny. Raport nie zawiera danych terenowych CrUX. Wyniki kolejnych uruchomień mogą się różnić.

• Wydajności (Performance) - Szybkość ładowania i responsywność strony (kluczowe dla UX).
• Ułatwienia dostępu (Accessibility) - Inkluzywność i dostosowanie strony do osób z niepełnosprawnościami (WCAG).
• Sprawdzone metody (Best Practices) - Higiena kodu i bezpieczeństwo techniczne (m.in. HTTPS, brak przestarzałych bibliotek).
• SEO - Widoczność w wyszukiwarkach (struktura strony, indeksowanie, meta-dane).

Pomiary pokazują postęp projektu: wynik wydajności desktop wzrósł z 39 do 100 punktów, a mobile z 49 do 100 punktów. Wyniki historyczne zachowano jako zapis wcześniejszych iteracji; różnice warunków i wersji Lighthouse ograniczają ich bezpośrednią porównywalność. Kolejne działania obejmują utrzymanie wyników i ręczną weryfikację obszarów nieobjętych testami automatycznymi.

Act (Doskonalenie)

Każdy audyt i wskaźnik to dla mnie wejście do procesu doskonalenia oba są istotne i uzupełniają się. Skoro nie wiemy, co wymaga poprawy, nie możemy się rozwijać.

Często słyszę: »po co kolejny audyt, skoro było dobrze?«. Dla mnie to nie czepialstwo, lecz szansa na weryfikację: czy jest bezpieczniej, szybciej, lepiej? Audyt dla samego audytu to strata czasu. Prawdziwa wartość leży w fazie Act, gdzie wyniki audytu przekuwa się na konkretne działania.

Najważniejsze lekcje

Wiele się nauczyłem, ale poniżej przedstawiam dwie, moim zdaniem, najważniejsze lekcje.

Projekt SecureHaveNET potwierdził obserwację, którą dostrzegam na co dzień: sukces rzadko zależy od pojedynczego narzędzia, technologii czy procedury. Znacznie większe znaczenie ma sposób podejmowania decyzji, umiejętność identyfikacji ryzyk oraz konsekwencja w ciągłym doskonaleniu rozwiązań.

Niezależnie od tego, czy budujemy stronę internetową, rozwijamy systemy OT, wdrażamy wymagania ISO/IEC 27001, czy przygotowujemy organizację do audytu TISAX®, podstawowe zasady pozostają niezmienne:

Teoria istnieje po to, by stosować ją w praktyce, a każdy wybór powinien być świadomą kalkulacją.

Porównuję rozwiązania pod kątem ryzyka, kosztu wdrożenia i oczekiwanych rezultatów. Droższe rozwiązanie nie musi zapewniać lepszego bezpieczeństwa ani jakości.

Lekcje te pozwalają mi lepiej rozumieć wyzwania organizacji. W tym projekcie zmierzyłem się z istotą GRC: jak połączyć rachunek zysków i strat z redukcją ryzyka, dysponując ograniczonymi możliwościami technicznymi.

Podsumowanie

GRC traktuję jako mapę. Governance wyznacza kierunek i granice (ramy), informując, dokąd zmierzasz oraz jakich standardów musisz przestrzegać, aby utrzymać zgodność i bezpieczeństwo.

Korzystam z PDCA, aby planować zmiany, testować je i oceniać wyniki. Etapy Check i Act pomagają mi zdecydować, co zachować, a co poprawić.

W tym projekcie GRC pomagało określić kierunek, ryzyka i wymagania, a PDCA uporządkować kolejne zmiany oraz ocenę ich efektów. To opis mojego sposobu pracy, a nie warunek skuteczności każdego projektu.

SecureHaveNET pozwala mi testować zmiany techniczne z uwzględnieniem oceny ryzyka i wymagań bezpieczeństwa. Wskaźniki i regularne przeglądy pomagają mi oceniać wyniki i planować kolejne usprawnienia.

Ostatecznie coraz bardziej utwierdzam się w przekonaniu, że systemy mają wspierać ludzi, a ludzie tworzyć wartość. Technologie, procesy i normy są jedynie narzędziami służącymi temu celowi.

Systems support people - people create value