ipIII (Evidence & Resilience Orchestrator) is an evidence-and-regulatory layer — the connector between the technical output of pentest/AppSec/SOC and what the board, audit and regulator actually need: structured, verifiable evidence, not another CSV file. This page shows what it is, why it fills a real gap, and who it is for — based on numbers you can check in the code.
/api/ip3/ssot — they should not drift apart.
/api/ip3/ssot and verifiable on live registries — /pages.json
and /dev-api-reference. Any mention of market size,
demand size or potential revenue is flagged separately as an estimate model — an assumption
for discussion, not a forecast or a commitment. Regulatory topics (DORA/NIS2/GDPR/AI Act) are addressed
in decision-support mode: the final legal qualification rests with the client's legal counsel/DPO.
Scanners (SAST/DAST/SCA), pentests and SIEM produce findings. GRC systems produce risk
registers and policies. Between these two worlds there is a gap: by default, no one turns a single
finding into time-anchored evidence, tied to a specific regulatory obligation, ready to present to
an auditor or supervisor. ipIII closes this flow: import → incident → evidence-package → retest →
close, with chain-of-custody and an integrity hash at every step.
None of the existing tools do this by themselves:
Produce a technical finding (CVE, vulnerability, exploit path). They do not say which regulatory obligation is at stake or whether the evidence will survive an audit.
Sees events in real time. It does not build a coherent evidence package with chain-of-custody for a single incident for audit purposes.
Manages the risk register and policies at the organization level. It typically does not reach down to granular technical evidence (which specific test, which retest, which file hash).
Connects the finding to the obligation and to the evidence: coverage score, evidence package with hash and signature, mapping to DORA/NIS2/AI Act, a ready Board Pack for the board.
In other words: ipIII is a complementary, new category in the security→compliance chain, not a competitor to Burp Suite, Nessus, SIEM or classic GRC. It operates downstream of these tools (importing their output) and upstream into the board/audit/regulator (evidence package, Board Pack).
| Segment | Regulatory context | What they get from ipIII |
|---|---|---|
| Financial institutions | DORA (operational resilience) | Mapping of the incident to DORA requirements, an evidence package for operational resilience testing and TIBER-type exercises — as decision-support, not as an assurance of compliance. |
| Essential/important entities | NIS2 | An incident register with chain-of-custody consistent with NIS2 reporting obligations; the Legal Trigger Engine flags deadlines — to be confirmed by compliance/legal counsel. |
| AI providers and deployers | AI Act | AI-risk pack: agent register, human-oversight trail, model risk inventory — an evidence layer supporting classification and AI Act obligations (MVP, some modules on ROADMAP). |
| Cyber / pentest / MSSP firms | service delivery to their own clients | Import of their own tools' output (Burp, Nessus, DefectDojo, SARIF, SBOM) and automatic assembly into a Board Pack — less manual work reporting to the client. |
| CISO / internal audit / compliance / DPO | oversight and accountability | A single source of truth for evidence status (coverage score, verify hash+signature) instead of scattered spreadsheets and emails between teams. |
The module figures below (pages, endpoints, parsers, modules, MCP tools) are loaded from
/api/ip3/ssot, an endpoint that counts them directly from the repo files on every call — they
are not hand-typed into the page. The values shown immediately are the last-known fallback (progressive
enhancement); the test-suite count is static (SSOT does not count tests). Click through to verify.
routes/ip3-*.js — parsers, transport, tenancy, MCP, legal, PDFtests/ repo (static figure, outside SSOT)ip3_list_incidents, ip3_stats and othersfigures refreshed from /api/ip3/ssot — values above are the fallback (last-known state); loading live…
source: /api/ip3/ssot · technical matrix with full evidence (code+test per module): /przeglad-produktu (PL).
Per the claim ≤ proof doctrine, we do not say "bank-ready" until we have evidence for it. Below is the current state of four key foundational layers (details and full status: known limitations and status matrix).
| Layer | What it does | Status today |
|---|---|---|
| F1 — OIDC/JWKS | Identity federation, signature validation of tokens from an external IdP. | E2E on staging — verified with end-to-end tests, not yet confirmed on a bank's production environment. |
| F2 — audit hash-chain + HMAC signature | Integrity chain of audit events with an HMAC signature. | shadow LIVE (prod) — running in parallel in production in observation mode, ahead of full cutover. |
| F3 — multi-tenant isolation | Data separation between organizations; IDOR/BOLA tests. | E2E on staging — attempts to cross the tenant boundary result in 404 in tests; full multi-client production rollout is not yet in place. |
| F4 — real-world transport (GitHub/Jira/webhook) | Bidirectional integration with the client's ticketing systems. | E2E on staging — connection to real APIs works in tests; production rollout at a client requires their configuration. |
Regulatory packs (DORA / NIS2 / GDPR / AI Act) today have MVP status: the obligation→evidence mapping works, but it is decision support, not automatic compliance certification — every pack requires review by legal counsel or compliance before use in contact with a regulator.
No. It is a complementary layer that accepts the output of these tools as import (Burp, Nessus, SARIF, SBOM and others) and turns it into evidence tied to a regulatory obligation plus a ready package for the board. Scanners, pentest and SIEM remain necessary — ipIII operates on their output.
No. ipIII supports the evidence workflow and decision-support for compliance — it helps collect, link and present evidence. The final assessment and legal qualification is always performed by the client's legal counsel, DPO or compliance function.
Module figures (pages, endpoints, parsers, modules, MCP tools) are loaded runtime from
/api/ip3/ssot, the same endpoint used on /przeglad-produktu —
they are not hand-typed into the page. Full page list: /pages.json,
full endpoint list: /dev-api-reference. The test-suite count
(81) is a static figure from the tests/ repo. These are not figures from a sales deck.
Yes — the lowest entry threshold is a PoC on synthetic data described at /pricing, submitted via /pilot-intake, with the full scope of the vendor's trust and security posture at /trust-center.
Related: technical module matrix with evidence → /przeglad-produktu (PL) · full page registry → /pages.json · API contract → /dev-api-reference · a pentest evidence example → /pentest-report-board-pack · vendor trust and security → /trust-center · pilot submission → /pilot-intake · engagement models → /pricing.