Prace z zakresu cyberbezpieczeństwa dzielą się na cztery odrębne działania: testy penetracyjne działających systemów, przegląd kodu źródłowego i architektury, ocenę procesu wytwarzania pod kątem zapobiegania błędom oraz decyzje dotyczące ryzyka. Każde z nich odpowiada na inne pytanie, a łączenie ich bez wyraźnego celu kończy się raportem, z którego nikt nie korzysta.
Zakres testów opieramy na publicznych katalogach, a nie na własnej, zamkniętej metodyce. Ustalenia z testów aplikacji webowych i API odnosimy do OWASP Top 10:2025 oraz API Security Top 10, głębokość weryfikacji do OWASP ASVS 5.0, a symulację działań napastnika do taktyk MITRE ATT&CK. Dzięki temu każde ustalenie ma identyfikator rozpoznawalny dla audytorów i innych dostawców.
Przegląd kodu i architektury sięga tam, gdzie test działającego systemu nie dociera: do decyzji projektowej, która umożliwia powstanie całej klasy błędów. Ma to znaczenie, gdy to samo ustalenie wraca w kolejnych wydaniach — poprawka należy wtedy do procesu wytwarzania, a nie do pojedynczego zgłoszenia, a powtarzany test będzie jedynie potwierdzał objaw.
Ustalenia zasilają obowiązki, które i tak obowiązują. Dowody zebrane podczas testu wspierają zabezpieczenia A.8.8 i A.8.29 normy ISO 27001, środki zarządzania ryzykiem wymagane przez art. 21 dyrektywy NIS 2 oraz art. 32 RODO — pod warunkiem że powstają z myślą o ponownym wykorzystaniu, co oznacza odnotowanie, co i kiedy testowano, a nie tylko co znaleziono.
