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 merytorycznego kontentu dla czytelnika.

Compliance (Zgodność): To weryfikacja, czy to, co wdrażam, jest zgodne z założonymi standardami jakości i moimi własnymi oczekiwaniami.

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 cześć 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

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 trakcie budowy podjąłem decyzję o rezygnacji z zewnętrznych bibliotek (CDN) na rzecz lokalnych zasobów. W dobie ataków typu supply chain attack ("koń trojański" w zewnętrznym kodzie), uznałem, że przeniesienie wszystkich skryptów na własny serwer to jedyna droga do pełnej kontroli. Takie podejście wymusiło na mnie lepszą organizację kodu, ale dało mi spokój ducha – jeżeli coś nie zadziała, to temat jest mój a nie dostawcy.

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, rygorystyczna konfiguracja CSP (Content Security Policy) oraz zabezpieczenia przed atakami typu tabnabbing (rel="noopener").
• Wydajność (Performance): Optymalizacja LCP z 6,2 s do 0,7 s dzięki precyzyjnemu dostosowaniu wątku głównego (TBT) i formatów zasobów.
• 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ę. Zrozumiałem, że to naukowo udowodnione: ciągła pogoń za ideałem zabija postęp. 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.

Check (Sprawdzenie, Audyt)

Audyt to dla mnie nie tylko formalność, ale przede wszystkim okazja do weryfikacji i nauki (ISO/IEC 27001:2022, punkt 9.2 Audyt wewnętrzny). Oczywiście można zlecić audyt zewnętrzny, ale w tym przypadku zdecydowałem się na samodzielną weryfikację. W praktyce oznaczało to analizę wskaźników takich jak czas ładowania, liczba zapytań, bezpieczeństwo linków, a także ocenę zgodności z wymaganiami. Wyniki audytu — niezgodności i uwagi do poprawy — otwierają drogę do realnego doskonalenia.

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

• 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).

Podsumowując – wyniki potwierdzają skuteczność wdrożonych optymalizacji. Wzrost wydajności dla desktop (+24 pkt) i mobile (+41 pkt) oraz SEO +8 pkt dla obu dowodzi słuszności założeń projektowych. Obecnie priorytetem pozostaje stabilność techniczna i wysoki standard UX. Pozostałe obszary wymagające poprawy zostały ujęte w backlogu i będą realizowane w kolejnym cyklu PDCA.

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ą.

W moim procesie decyzyjnym fakty są kluczowe. Zawsze zestawiam opcje: jakie ryzyko niesie rozwiązanie A, a jakie rozwiązanie B? Jaki jest koszt ich wdrożenia i – co dla mnie najważniejsze – czy istnieje bardziej kreatywna ścieżka? Jestem zwolennikiem poszukiwania rozwiązań optymalnych; wiem, że wyższy koszt nie zawsze przekłada się na większe bezpieczeństwo czy lepszą jakość.

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.

Z kolei cykl PDCA jest jak kompas i dźwignia w jednym. To mechanizm, którego używasz w codziennej pracy, aby przybliżać się do wyznaczonego celu. Dzięki etapom Check i Act, PDCA pozwala na bieżąco korygować kurs, weryfikować wydajność systemu oraz wdrażać niezbędne optymalizacje.

Wartości tych obszarów dopełniają się – jedno bez drugiego jest niewystarczające. GRC bez PDCA pozostaje tylko teorią, natomiast PDCA bez GRC staje się błądzeniem bez celu.

W ciągu zaledwie kilku miesięcy SecureHaveNET przekształcił się z prostego projektu technicznego w środowisko umożliwiające praktyczne testowanie zagadnień z zakresu GRC, bezpieczeństwa informacji, analizy ryzyka oraz ciągłego doskonalenia. Dzięki mierzalnym wskaźnikom, regularnym przeglądom i metodologii PDCA, projekt ten stał się żywym dowodem na skuteczność mechanizmów, które wykorzystuję w codziennej pracy zawodowej.

Źródła i dokumenty odniesienia

• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements.
• ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls.