Jedna strona wejścia zamiast rozproszonych ofert: jak zacząć współpracę z ipIII — jako partner (MSSP, zespół pentest, kancelaria, integrator) albo jako klient (bank, fintech, podmiot krytyczny objęty DORA/NIS2). Ścieżka jest jedna dla obu: Controlled Pilot — kontrolowany PoC na danych syntetycznych, dopiero potem pilot na danych zanonimizowanych po podpisanym RoE.
ipIII to warstwa dowodowo-regulacyjna między pentestem/AppSec/SOC/GRC a zarządem, audytem i regulatorem — komplementarna wobec istniejących narzędzi, nie ich zamiennik. Oferta poniżej nie sprzedaje funkcji, których dziś nie ma: tryb SaaS w UE działa dziś (LIVE) w kontrolowanym pilocie; private tenant / VPC / on-premise jest jawnie oznaczony jako ROADMAP (patrz /known-limitations).
MSSP, zespoły pentest / red team, kancelarie i działy prawne, integratorzy SOC. Wchodzicie z findingami klientów lub własną praktyką testów bezpieczeństwa i chcecie spiąć wynik z dowodem, właścicielem i pakietem dla zarządu klienta.
Banki, fintechy, podmioty krytyczne objęte DORA/NIS2/AI Act. Potrzebujecie warstwy, która łączy finding ze skanera/SIEM z dowodem, właścicielem, terminem i mapowaniem regulacyjnym — jako wsparcie decyzji, nie automatyczną certyfikację.
Niezależnie od tego, czy wchodzisz jako partner czy klient, proces jest ten sam i celowo wąski — zanim dotknie danych innych niż syntetyczne, przechodzi przez formalne bramki.
Cel takiego modelu: transparentność zamiast przydziału „kto pierwszy, ten lepszy" albo uznaniowości — oraz zaangażowanie środowiska pentest w budowę wspólnych evidence-package. Proponowane kryteria wyboru priorytetu, gdyby okno pilotów się przepełniło:
| Kryterium | Co oceniamy | Dlaczego |
|---|---|---|
| Gotowość | Podpisany komplet NDA/RoE/DPA, zdefiniowane kryteria sukcesu, wyznaczona osoba decyzyjna po stronie zgłaszającego. | Pilot bez formalnych bramek nie może ruszyć — gotowość skraca czas do wartości. |
| Zakres | Wąski, konkretny, odwracalny zakres PoC — nie „wszystko naraz". | Węższy zakres = szybszy, bezpieczniejszy pilot z mierzalnym wynikiem. |
| Wkład dowodowy | Czy zgłaszający wnosi realne findingi/scenariusze testowe (np. z własnej praktyki pentest) zamiast wyłącznie oczekiwać gotowego wyniku. | ipIII to warstwa dowodu — pilot ma sens, gdy jest czym zasilić evidence-package. |
Jeżeli ten model zostanie kiedyś rozbudowany o narzędzie (np. panel zgłoszeń z widocznym rankingiem kryteriów), będzie to jawnie oznaczone jako osobna, nowa funkcja LIVE — nie zostanie po cichu podmienione pod istniejącą ofertą. Do tego czasu priorytetyzacja odbywa się ręcznie, w rozmowie z operatorem.
PoC · Pilot 5 dni · Pilot 30 dni · Licencja · Partner (MVP) — orientacyjne, na zapytanie, zero kwot wiążących publikowanych na stronie.
5 typów partnera (pentester, MSSP, kancelaria, integrator, SOC), onboarding, wspólny pilot, evidence-package jako element współpracy.
Security questionnaire i vendor risk (MVP) — kontrole LIVE z dowodem oraz jawny rejestr braków przed etapem enterprise.
Status systemu, responsible disclosure, znane ograniczenia — jedno źródło dla działu bezpieczeństwa i due diligence po stronie klienta.
W odróżnieniu od modelu rynkowego powyżej, poniższe liczby pochodzą wprost z kodu repozytorium — możesz je zweryfikować samodzielnie pod /dev-api-reference i /pages.json.
Nie. To jawnie oznaczony koncept/model transparentnego wyboru priorytetu przy nadmiarze zgłoszeń w tym samym oknie — kryteria: gotowość, zakres, wkład dowodowy. Bez automatycznej aukcji, bez licytacji ceną, bez zobowiązania do konkretnej kolejności.
Nie. To punkt startu rozmowy przez /pilot-intake. Realna umowa powstaje w drodze negocjacji, z przeglądem prawnika po obu stronach.
Liczby produktu (endpointy, moduły, konektory, strony) — z kodu repozytorium, weryfikowalne pod /dev-api-reference i /pages.json. Liczby rynkowe/popytowe — model szacunkowy z jawnymi założeniami, nie prognoza.
Nie dzisiaj. SaaS w UE jest trybem LIVE w pilocie. Private tenant / VPC / on-prem to ROADMAP — patrz /known-limitations.
Wybierz ścieżkę adekwatną do Twojej roli — obie prowadzą do tego samego, kontrolowanego procesu intake opisanego wyżej.
Powiązane: intake pilota → /pilot-intake · modele współpracy → /pricing · partner program → /partner-program · procurement → /procurement · referencja dev/API → /dev-api-reference · board pack z pentestu → /pentest-report-board-pack · trust center → /trust-center · uczciwy rejestr ograniczeń → /known-limitations.