Jedna strona zbierająca wszystko, czego potrzebuje CISO i zespół procurement, żeby ocenić ipIII przed pilotażem: zakres PoC, zasady pracy na danych, retencję, RBAC, audit-log, program CVD, dokumenty prawne (RoE/DPA/NDA), znane ograniczenia, tryby wdrożenia i model SLA. Doktryna claim ≤ proof: co działa jest oznaczone LIVE, co jest planowane — ROADMAP.
ipIII to warstwa evidence i orkiestracji nad istniejącymi skanerami i procesami bezpieczeństwa — dziś w fazie dowiedlnego MVP (import → incydent → evidence-package → retest → close, z JWT/RBAC/audit na żywej PostgreSQL). Ta strona prowadzi CISO i procurement przez osiem obszarów, z których każdy ma swoją dedykowaną podstronę ze szczegółami, dowodami i dokumentami do pobrania.
Każdy pilotaż ipIII zaczyna się od pisemnego uzgodnienia zakresu: które systemy (lub ich syntetyczne odpowiedniki) są objęte, jaki jest horyzont czasowy, kto po stronie klienta jest punktem kontaktowym i jakie kryteria sukcesu decydują o przejściu do fazy produkcyjnej. PoC nie jest testem penetracyjnym ofensywnym — to weryfikacja, czy warstwa evidence (import wyników skanerów, normalizacja incydentów, budowa evidence-package, generowanie board-packu) działa na danych klienta w jego środowisku integracyjnym.
Import z istniejących skanerów (Burp/ZAP/Nessus/CSV), normalizacja do incydentów, evidence-package z sumą kontrolną, board-pack PDF, ścieżka retest→close.
ipIII nie wykonuje skanowania ofensywnego, nie generuje ani nie uruchamia payloadów, nie zastępuje testu penetracyjnego zlecanego zespołowi red-team.
Uzgodnione wspólnie przed startem: liczba przetworzonych raportów, czas od importu do evidence-package, kompletność audit-logu. Wynik = raport z dowodami, nie deklaracja gotowości produkcyjnej.
Pełny opis zakresu, przykładowego harmonogramu i checklisty przygotowawczej dla zespołu klienta znajduje się w Procurement Pack — dokumencie przeznaczonym do przekazania zespołowi zakupowemu razem z ofertą.
W fazie pilotażu ipIII pracuje domyślnie na danych syntetycznych lub zanonimizowanych. Jeśli klient chce przetestować rzeczywiste raporty skanerów zawierające dane osobowe lub wrażliwe biznesowo, wymaga to odrębnej umowy powierzenia przetwarzania danych (DPA) i jawnego określenia podstawy prawnej. Zasady minimalizacji, retencji i usuwania danych po zakończeniu PoC są opisane szczegółowo na dedykowanej stronie.
| Obszar | Zasada w PoC | Status |
|---|---|---|
| Typ danych wejściowych | Syntetyczne / zanonimizowane raporty skanerów (domyślnie) | LIVE |
| Dane osobowe / wrażliwe | Wyłącznie po podpisaniu DPA i ustaleniu podstawy prawnej | warunkowe |
| Retencja evidence-package | Zgodnie z harmonogramem uzgodnionym w RoE; usuwanie na żądanie po zakończeniu pilotażu | LIVE |
| Lokalizacja przechowywania | PostgreSQL zarządzana przez K0NSULT (region EU); szczegóły w Data Processing | LIVE |
| Eksport / prawo do usunięcia | Klient może zażądać eksportu evidence-package i usunięcia danych po zakończeniu współpracy | procedura ROADMAP |
Pełny opis podstaw prawnych, ról administratora/procesora i mapy przepływu danych → Przetwarzanie danych.
Dostęp do ipIII jest kontrolowany rolami (RBAC) — każdy użytkownik ma przypisaną rolę (np. analityk, reviewer, administrator) ograniczającą, jakie akcje może wykonać: import, przegląd incydentu, generowanie evidence-package, zamknięcie z dowodem. Każda akcja zapisywana jest w audit-logu z znacznikiem czasu, identyfikatorem użytkownika i typem operacji — na żywej instancji PostgreSQL, nie w plikach tekstowych.
Role i uprawnienia egzekwowane na poziomie API (JWT + middleware autoryzacji).
Każda operacja na incydencie i evidence-package zapisana z aktorem i czasem.
Dziś JWT wystawiany lokalnie; federacja tożsamości (Keycloak/JWKS) w planie — patrz Znane ograniczenia.
Dziś jedna organizacja per instancja; Row-Level Security dla wielu klientów na jednej instancji planowana.
ipIII prowadzi program odpowiedzialnego zgłaszania podatności. Badacze bezpieczeństwa i partnerzy mogą zgłosić znalezioną lukę przez formularz na stronie /zglos lub kanał opisany w Security Pack. Zasada: zero publikacji szczegółów exploitacyjnych przed uzgodnioną naprawą, komunikacja wyłącznie o tym, co zostało przetestowane i jaki dowód sukcesu naprawy został dostarczony — bez payloadów ani instrukcji ataku w treściach publicznych.
Szczegóły programu, kanału zgłoszeniowego i deklarowanego czasu reakcji → Security Pack.
Każde zaangażowanie z elementem testowym (PoC, pilotaż, warsztat) jest poprzedzone kompletem dokumentów:
To narzędzia decision-support dla stron umowy — nie zastępują przeglądu przez własnego radcę prawnego klienta ani K0NSULT. Kompletny zestaw szablonów i checklisty prawnej → Procurement Pack.
ipIII nie udaje systemu klasy bankowej. Rejestr siedmiu znanych ograniczeń (federacja tożsamości, mTLS, formalny podpis PAdES/TSA, multi-tenant, świeżość CVE online, konektor SIEM, granica Legal Trigger Engine) jest udokumentowany w całości, z nazwanym ryzykiem, mitygacją i priorytetem domknięcia (P0/P1) na osobnej stronie. Żadne z tych ograniczeń nie jest ukrywane ani przedstawiane jako gotowe.
ipIII może być uruchomiony w różnych topologiach w zależności od wymagań rezydencji danych i integracji klienta — od instancji współdzielonej (multi-tenant, ROADMAP) po dedykowaną instancję per klient (dziś domyślny model dla pilotaży bankowych/instytucjonalnych). Wybór trybu wpływa na SLA, koszt i harmonogram wdrożenia.
| Tryb | Opis | Status |
|---|---|---|
| Dedykowana instancja (single-tenant) | Osobna baza i środowisko per klient, izolacja fizyczna danych | LIVE |
| Współdzielona instancja (multi-tenant + RLS) | Jedna instancja, separacja logiczna przez Row-Level Security | ROADMAP |
| On-prem / VPC klienta | Wdrożenie w infrastrukturze klienta zamiast hostingu K0NSULT | ROADMAP |
Pełne porównanie topologii, wymagań sieciowych i kosztowych → Tryby wdrożenia.
Model wsparcia opisuje kanały kontaktu, deklarowane czasy reakcji na zgłoszenia (w podziale na krytyczność) oraz zakres godzin wsparcia dostępny w fazie pilotażu i po jego zakończeniu. Szczegółowa macierz czasów reakcji, eskalacji i okien konserwacyjnych → SLA / Support.
Dla zespołów GRC i risk management, które muszą sklasyfikować ipIII jako dostawcę zewnętrznego (third-party risk assessment), przygotowany jest zestaw odpowiedzi na standardowe pytania kwestionariusza dostawcy: lokalizacja danych, podwykonawcy, ciągłość działania, plan reagowania na incydent. To materiał wejściowy do własnego procesu oceny ryzyka klienta, nie substytut tego procesu → Vendor Risk.
Pełny przegląd polityk zaufania, certyfikatów w toku i dowodów LIVE.
Zakres PoC, checklisty prawne, szablony RoE/DPA/NDA gotowe dla zespołu zakupowego.
Rejestr siedmiu ograniczeń z ryzykiem, mitygacją i priorytetem — zero ukrytych luk.
Powiązane: przetwarzanie danych i podstawy prawne → /data-processing · program bezpieczeństwa i CVD → /security-pack · tryby wdrożenia → /deployment-modes · SLA i support → /sla-support · ocena ryzyka dostawcy → /vendor-risk.