This page does not introduce a new feature — it organizes the existing product into a single reading path: what it is, who it is for, why now, what it includes, what is technical, how to verify it, and how to get started. The side menu guides you step by step; each section links to a full, standalone page with details and evidence.
This is not another scanner or another SIEM. It is an Evidence Operating Layer that takes the output of technical tools as an import and translates it into a chain: finding → evidence → owner → regulatory obligation → board pack. Scanners, pentest, SOC, and GRC remain necessary — ipIII works on their output, not instead of them.
Full description of product value, who it's for, and why it works → /wartosc-produktu.
Four audience groups, one data model. Each has its own landing page tailored to its language and regulatory obligations.
Bank, fintech, insurer — an operational/ICT incident must be linked to the DORA reporting clock and its closure evidenced to the board.
SOC/CERT of an entity covered by NIS2 — an alert needs evidence, not just a ticket closed without a trace.
Teams building/deploying AI systems — they need a trail of decisions, prompts, and oversight for AI Act obligations.
AppSec teams, pentest firms, and MSSPs — instead of building their own evidence layer for clients, they import the result into ipIII.
Common denominator: CISO, internal audit, compliance, DPO — they read the output (Board Pack, control mapping, evidence package), regardless of the input industry.
Three regulatory regimes are entering their enforcement phase almost simultaneously: DORA (in force since 2025, ICT operational resilience for the financial sector), NIS2 (national transposition, essential/important entities), and the AI Act (obligations for high-risk systems — the timeline for part of the provisions has been postponed, part is already in force). In each of them, the common denominator is evidence: who detected what, who fixed it, when, with what trail. Today that evidence most often lives scattered across tickets, emails, and spreadsheets — hard to reconstruct under the pressure of a regulator's deadline.
Full analysis of regulatory timing → /why-now.
Five layers of one flow: pentest/scan → evidence → remediation → regulatory → AI-agent security, tied together by a common finding→evidence→owner→control model.
| Layer | What it does | Status |
|---|---|---|
| Connectors | Import from technical tools: Burp, ZAP, Nessus, Qualys, generic CSV, DefectDojo, SARIF, SBOM, secret scanners, cloud posture, RE. | LIVE |
| Evidence | Evidence package with a checksum (sha256), chain of custody, cross-tool dedup, CVE enrichment (offline, seed). | LIVE |
| Remediation | Owner, SLA, incident lifecycle (open→triaged→assigned→fixing→retest→closed), Jira/GitHub ticket builders. | LIVE |
| Regulatory | Legal Trigger Engine (obligations + clocks for DORA/NIS2/GDPR/AI Act), evidence→control mapping (ISO27001/NIST-CSF/CIS), Board Pack (PDF). | LIVE decision-support |
| AI-security | Trail of AI tools/agents, MITRE ATT&CK map (curated submap). | LIVE scope growing |
Category positioning, market analysis, and comparison with scanners:
The full developer reference at /dev-api-reference describes the repository's code — not a target architecture. Summary of figures (verifiable in that document):
routes/ip3-*.jstests/ip3-*.js| Layer | What it does | Status today |
|---|---|---|
| F1 — OIDC | OIDC token validation (RS256+JWKS) alongside the local JWT. | shadow — staging |
| F2 — hash chain + signature | Tamper-evident audit log (modification is detectable) + optional HMAC signature on the evidence package. | shadow — prod |
| F3 — tenancy layer 1 | Query scoping by org_id at the application layer. RLS in PostgreSQL = layer 2, separate. | off/on — staging |
| F4 — transport | Real ticket dispatch (GitHub/Jira/webhook) behind a triple feature-flag gate. | off by default |
/api/ip3/mcp (JSON-RPC 2.0) with
6 ipIII-scoped tools LIVE: ip3_list_incidents, ip3_stats,
ip3_list_playbooks, ip3_get_playbook, ip3_pages_registry,
ip3_doctrine — read-only, verifiable via tools/list in production.
Separately, a general connector /mcp runs at the whole-node K0NSULT level
(k0nsult_status/list_agents/query_agents) — it reads the agent
registry, not incident data. Write access (create/update via MCP) remains ROADMAP.
Deployment: today, SaaS EU (single instance, tenancy layer 1). Private tenant / VPC / on-prem is ROADMAP, not an offer available today.
The service documents its own limits instead of hiding them — this is part of the same evidence model it sells to clients.
Security policy, security.txt, disclosure, RoE rules for purple-team exercises (the service defends itself within the bounds of written Rules of Engagement, without unauthorized offense).
A single register of what ipIII does not yet do (federated auth, mTLS, PAdES/TSA, RLS, online SIEM) — with risk, mitigation, and priority.
A tool that checks the checksum and structure of an evidence package — no login required, on synthetic samples.
Three entry paths — none of them commits you to a purchase.
A controlled pilot on synthetic data or your own scanner export, after RoE/NDA/DPA.
Related: full module hub → /ai-truth/ipIII/ · map of all pages → /mapa-pro · machine-readable page register → /pages.json.