Jak ipIII (Evidence & Resilience Orchestrator) przechodzi od pierwszego kontaktu do stałej współpracy: siedem etapów, od publicznego demo po docelowy model enterprise i white-label. Liczby o produkcie (strony, endpointy, parsery, moduły, testy) są realne i weryfikowalne w kodzie. Liczby o przychodzie i rynku — jeśli się pojawiają — są jawnie oznaczonymi założeniami, nie prognozą ani zobowiązaniem.
Ścieżka jest stopniowa i odwracalna — każdy kolejny etap zakłada, że poprzedni dostarczył widoczną wartość na danych syntetycznych lub zanonimizowanych, w granicach pisemnych Rules of Engagement. Dziś dowodliwie działa warstwa evidence: import → incydent → evidence-package → retest → close, z JWT/RBAC/audytem na żywej PostgreSQL. Elementy klasy enterprise (multi-tenant, OIDC/federacja, mTLS, PAdES/TSA, pełny MSSP i white-label) są w różnym stopniu zaawansowania — część jako szkielet za flagą, część jako ROADMAP.
Kolumna Monetyzacja opisuje mechanizm rozliczenia proponowany dla danego etapu, nie konkretną kwotę. Data weryfikacji: 2026-07-05.
| Etap | Zakres | Dla kogo | Monetyzacja (model) | Dostępność |
|---|---|---|---|---|
| Demo | Publiczny dostęp do stron demonstracyjnych i danych symulacyjnych (source:"simulation") —
dashboard, mapa incydentów, przykładowy Board Pack — bez logowania i bez danych klienta. |
Pierwszy kontakt: ocena mechaniki produktu przed rozmową. | Brak opłaty — generowanie zainteresowania, zgłoszenie dalej przez /pilot-intake. | LIVE |
| PoC | Krótki dowód wartości na danych syntetycznych: import z jednego konektora (Burp/ZAP/Nessus/CSV) → incydent → evidence-package (JSON/PDF z hash i chain-of-custody). | Zespół bezpieczeństwa / GRC oceniający szkielet przed decyzją o pilocie. | Opłata jednorazowa, orientacyjnie lub na zapytanie — najniższy próg wejścia. | MVP |
| Kontrolowany Pilot 5 / 30 dni |
Pełna ścieżka evidence na danych syntetycznych lub zanonimizowanych, w granicach pisemnych RoE; opcjonalnie wsparcie decision-support przy dokumentacji DORA/TIBER (nie porada prawna). | Organizacje przed decyzją zakupową; przygotowanie do ćwiczenia blue/GRC. | Stawka za sprint lub za okres, orientacyjnie / na zapytanie. | MVP |
| Licencja | Dostęp okresowy do instancji evidence-orchestratora: JWT/RBAC/audyt na PostgreSQL, konektory parserów, evidence-package, close-with-evidence, regulatory packs jako decision-support. | Zespoły kontynuujące korzystanie po udanym pilocie. | Subskrypcja okresowa (np. roczna), na zapytanie. | MVP |
| Enterprise | Docelowy model dla dużych instytucji: izolacja multi-tenant (RLS), OIDC/federacja tożsamości, mTLS, podpisy PAdES + znacznik czasu TSA, konektory SIEM. | Banki / duże instytucje wymagające pełnej izolacji i formalnych dowodów. | Wycena po ustaleniu zakresu i harmonogramu domknięcia funkcji. | ROADMAP |
| Partner / MSSP | Partner co-delivery — pentesterzy, kancelarie, integratorzy współdzielą licencję i przekazują wyniki wspólnym klientom (warunki dwustronne). MSSP multi-client mode — jeden panel obsługujący wielu klientów z rozdzielonymi danymi — zależy od pełnego domknięcia izolacji tenantowej (warstwa RLS), dziś w budowie. | Firmy pentest / doradztwo GRC / MSSP chcące oferować evidence-workflow swoim klientom. | Revenue-share lub prowizja od co-delivery, ustalane indywidualnie. | Partner: MVP · MSSP: ROADMAP |
| White-label | Branding partnera (logo, kolory, stopka) na Board Pack, przy czym hash i chain-of-custody dowodu pozostają niezmienne i weryfikowalne niezależnie od warstwy prezentacji. | Partnerzy chcący oferować produkt pod własną marką klientom końcowym. | Licencja white-label lub revenue-share, do ustalenia. | ROADMAP |
W przeciwieństwie do modeli monetyzacji powyżej, poniższe liczby opisują dziś istniejący kod i są weryfikowalne niezależnie od tej strony: /pages.json (pełny rejestr stron) i /dev-api-reference (pełna lista endpointów).
/pages.json (PL+EN)routes/ip3-*.jstests/routes/ip3-mcp.js — podpięcie AI/agentówFundament, na którym opiera się cała ścieżka pakietów — bez tych warstw etapy Enterprise i pełne MSSP nie mogą bezpiecznie wystartować.
| Warstwa | Opis | Status |
|---|---|---|
| F1 — OIDC/JWKS | Walidacja tożsamości przez zewnętrzny IdP, równolegle z JWT-legacy. | E2E staging |
| F2 — hash-chain audytu + podpis HMAC | Integralność łańcucha zdarzeń audytowych (wykrywalna modyfikacja wpisu). | shadow LIVE prod |
| F3 — izolacja multi-tenant | Scoping po organizacji + testy IDOR/BOLA → oczekiwane 404 między kontekstami. | E2E staging |
| F4 — transport GitHub/Jira/webhook | Realny eksport zdarzeń do systemów zewnętrznych, za flagą i sekretami klienta. | E2E staging |
| MCP server | 6 tools read-only (incydenty, statystyki, playbooki, rejestr stron, doktryna). | LIVE |
| Regulatory packs | DORA / NIS2 / RODO / AI Act — mapowanie obowiązków na dowody, jako decision-support. | MVP |
Pełny, aktualny rejestr wszystkich elementów wraz z ryzykiem i priorytetem domknięcia → /known-limitations.
Trzy metryki, którymi opisujemy efekt działania produktu. To cele projektowe formatu i mechanizmu, nie zmierzony ani gwarantowany wynik dla każdego wdrożenia — rzeczywisty rezultat zależy od danych, procesów i decyzji klienta.
Format Board Packu (skrót + odnośniki do dowodu zamiast surowego PDF-a od skanera) jest projektowany do odczytu przez komitet w ok. 5 minut. To cel konstrukcji dokumentu — nie zmierzony, jednolity czas dla każdej organizacji. Przykład formatu → /pentest-report-board-pack.
Wskaźnik pokrycia dowodowego — jaka część incydentów ma potwierdzony, powiązany dowód (evidence CONFIRMED) wobec otwartych. Liczony na żywych danych z bazy klienta, wg jawnej formuły — nie jest to porównawczy benchmark rynkowy ani ocena bezpieczeństwa organizacji jako całości.
Czas od otwarcia incydentu do zamknięcia z dowodem (reguła close-with-evidence egzekwowana w bazie: bez ≥1 evidence CONFIRMED zamknięcie jest odrzucane). Mierzony per wdrożenie na danych klienta — produkt nie publikuje dziś ustandaryzowanego benchmarku międzybranżowego.
Cztery mechanizmy rozliczenia towarzyszące ścieżce pakietów z sekcji 1. Kalkulator wartości (widełki na jawnych założeniach, nie prognoza) → /roi; pełna symulacja metodologiczna → /revenue-simulation.
Powiązane: modele współpracy bez sztywnych kwot → /pricing · kalkulator wartości → /roi · pełna symulacja przychodu (metodologia) → /revenue-simulation · zgłoszenie PoC/pilota → /pilot-intake · bezpieczeństwo dostawcy → /trust-center · pełna lista endpointów → /dev-api-reference · przykładowy Board Pack → /pentest-report-board-pack · granice dojrzałości → /known-limitations.