Pentester, który dziś testuje albo doradza w sprawie bezpieczeństwa instytucji finansowej (bank, ubezpieczyciel, fintech), a jednocześnie ma prywatną relację z K0NSULT/ipIII (konto testowe, feedback, udział w PoC), musi mieć jasno rozdzielone role. Ta strona to szkielet checklisty — do wypełnienia i podpisania po obu stronach, zanim jakikolwiek dowód z pracy nad instytucją trafi w pole widzenia K0NSULT.
Jeśli pentester bierze udział w PoC/testach ipIII prywatnie, a zawodowo pracuje nad bezpieczeństwem instytucji finansowej — te dwie role muszą pozostać rozłączne. K0NSULT nie chce, nie potrzebuje i nie przyjmuje żadnych danych, wyników testów, nazw systemów ani informacji poufnych należących do banku czy jego klientów.
| # | Punkt | Dlaczego to ważne | Stan dowodu |
|---|---|---|---|
| 1 | Udział w ipIII (konto, PoC, feedback, testy) jest prywatną aktywnością pentestera, nie zleceniem ani obowiązkiem służbowym wobec pracodawcy. | Bez tego rozdziału każda uwaga „jak by to wyglądało w moim banku" może zostać odczytana jako nieautoryzowany transfer wiedzy o realnym środowisku pracodawcy. | do podpisania przez uczestnika |
| 2 | Pentester nie przekazuje K0NSULT żadnych danych, logów, zrzutów ekranu, nazw systemów, adresów IP ani innych informacji identyfikujących instytucję finansową, u której pracuje lub z którą ma kontrakt. | To jedyna twarda granica, która chroni K0NSULT przed nieświadomym przyjęciem informacji poufnej objętej NDA klienta pentestera. | deklaracja pisemna wymagana |
| 3 | Pentester nie reprezentuje pracodawcy ani jego klienta w kontakcie z K0NSULT — działa wyłącznie we własnym imieniu, jako osoba testująca produkt. | Zapobiega sytuacji, w której feedback/PoC zostałby błędnie zinterpretowany jako stanowisko czy zamówienie instytucji finansowej. | deklaracja pisemna wymagana |
| 4 | Jeśli pracodawca pentestera ma politykę zgłaszania konfliktu interesów lub wymóg zgody na aktywność zewnętrzną — pentester potwierdza, że dopełnił własnych wewnętrznych procedur przed udziałem. | K0NSULT nie weryfikuje polityk wewnętrznych pracodawcy pentestera — to odpowiedzialność uczestnika, ale checklist wymusza świadome oświadczenie, że temat został przemyślany. | oświadczenie własne (self-attestation) |
| 5 | Wszelkie testy w ramach ipIII odbywają się na danych syntetycznych/demo lub w środowisku testowym K0NSULT — nigdy na infrastrukturze pracodawcy pentestera, nawet „na próbę". | Miesza role: PoC narzędzia GRC nie może stać się nieautoryzowanym testem bezpieczeństwa realnego banku. Zgodnie z regułą RoE z Rules of Engagement. | zasada egzekwowana w RoE ipIII (LIVE jako polityka) |
| 6 | Pentester informuje K0NSULT, jeśli w trakcie udziału pojawi się realny konflikt (np. pracodawca rozważa zakup/wdrożenie ipIII) — wtedy rola prywatna kończy się, a dalszy kontakt przechodzi w tryb biznesowy (osobny kanał, osobna umowa). | Konflikt interesów nie jest zakazany — jest zarządzalny, jeśli zostanie ujawniony na czas. | procedura eskalacji — do zdefiniowania |
| 7 | K0NSULT nie żąda i nie zbiera nazwy pracodawcy pentestera jako warunku udziału w PoC — udział jest możliwy anonimowo/pod pseudonimem technicznym. | Minimalizacja danych chroni pentestera — mniej informacji po stronie K0NSULT to mniejsze ryzyko przypadkowego ujawnienia powiązania. | zasada minimalizacji danych — LIVE jako polityka |
| 8 | Checklist jest podpisywana jednorazowo przed pierwszym udziałem i odświeżana przy istotnej zmianie sytuacji zawodowej pentestera (zmiana pracodawcy, nowy kontrakt z instytucją finansową). | Konflikt interesów nie jest stanem statycznym — checklist musi nadążać za zmianą roli zawodowej. | mechanizm odświeżania — ROADMAP |
Zgodnie z regułą §16 (claim ≤ proof): checklist jako dokument jest gotowa do użycia od razu (skopiuj/podpisz/wyślij). Zautomatyzowany formularz z zapisem oświadczenia w bazie ipIII v1 (audit log, timestamp, wersjonowanie) to ROADMAP — dziś brak kodu/endpointu, więc nie oznaczamy tego jako LIVE.
Skoro checklist wprost zabrania przekazywania danych pracodawcy/klienta, samo uczestnictwo w PoC ipIII nie tworzy śladu, który mógłby zostać odczytany jako wyniesienie informacji poufnej.
Pisemne oświadczenie o rozdziale ról jest dowodem dobrej wiary — w razie pytania pracodawcy pentester ma dokument pokazujący, że zgłosił temat i działał zgodnie z zasadami.
Brak wymogu podawania nazwy pracodawcy oznacza, że K0NSULT fizycznie nie posiada informacji, którą mógłby przypadkowo ujawnić lub powiązać z konkretną instytucją.
K0NSULT nie może wyciekiem ani niewłaściwym użyciem naruszyć poufności banku, jeśli nigdy nie otrzymał od pentestera żadnych danych tej instytucji.
Jasna zasada „pentester działa we własnym imieniu" chroni K0NSULT przed sytuacją, w której feedback zostałby przedstawiony jako oficjalne zainteresowanie instytucji finansowej bez pokrycia.
Podpisana checklist to dowód należytej staranności K0NSULT — istnieje procedura, nie tylko dobra wola.
Powiązane: zasady zaufania i zakresu → /trust-center · zgłaszanie podatności → /disclosure · macierz statusów → /status-matrix.