One page collecting everything a CISO and procurement team need to evaluate ipIII before a pilot: PoC scope, data handling principles, retention, RBAC, audit log, the CVD program, legal documents (RoE/DPA/NDA), known limitations, deployment modes and the SLA model. Doctrine claim ≤ proof: what works is labeled LIVE, what is planned — ROADMAP.
ipIII is an evidence and orchestration layer on top of existing scanners and security processes — today at the stage of a demonstrable MVP (import → incident → evidence package → retest → close, with JWT/RBAC/audit on a live PostgreSQL instance). This page walks the CISO and procurement team through eight areas, each with its own dedicated subpage containing details, evidence and downloadable documents.
Every ipIII pilot begins with a written agreement on scope: which systems (or their synthetic equivalents) are covered, the time horizon, the client-side point of contact, and the success criteria that decide whether the engagement moves to a production phase. The PoC is not an offensive penetration test — it verifies whether the evidence layer (importing scanner output, normalizing incidents, building the evidence package, generating a board pack) works on the client's data within their integration environment.
Import from existing scanners (Burp/ZAP/Nessus/CSV), normalization into incidents, an evidence package with a checksum, a PDF board pack, and the retest→close path.
ipIII does not perform offensive scanning, does not generate or execute payloads, and does not replace a penetration test commissioned to a red-team.
Agreed jointly before the start: number of reports processed, time from import to evidence package, completeness of the audit log. The output is an evidence-backed report, not a declaration of production readiness.
A full description of scope, a sample timeline and a preparation checklist for the client team is available in the Procurement Pack — a document intended for handoff to the purchasing team alongside the proposal.
During the pilot phase, ipIII works by default on synthetic or anonymized data. If the client wants to test real scanner reports containing personal or business-sensitive data, this requires a separate data processing agreement (DPA) and an explicit legal basis. Rules on data minimization, retention and deletion after the PoC ends are described in detail on a dedicated page.
| Area | PoC rule | Status |
|---|---|---|
| Input data type | Synthetic / anonymized scanner reports (by default) | LIVE |
| Personal / sensitive data | Only after a signed DPA and an established legal basis | conditional |
| Evidence package retention | Per the schedule agreed in the RoE; deletion on request after the pilot ends | LIVE |
| Storage location | PostgreSQL managed by K0NSULT (EU region); details in Data Processing | LIVE |
| Export / right to deletion | Client can request export of the evidence package and data deletion after the engagement ends | procedure ROADMAP |
Full description of legal bases, controller/processor roles and the data flow map → Data Processing.
Access to ipIII is role-controlled (RBAC) — each user is assigned a role (e.g. analyst, reviewer, administrator) that limits which actions they can perform: import, incident review, evidence package generation, close with evidence. Every action is recorded in an audit log with a timestamp, user identifier and operation type — on a live PostgreSQL instance, not in text files.
Roles and permissions enforced at the API level (JWT + authorization middleware).
Every operation on an incident and evidence package recorded with actor and timestamp.
Today JWT is issued locally; identity federation (Keycloak/JWKS) is planned — see Known Limitations.
Today one organization per instance; Row-Level Security for multiple clients on a single instance is planned.
ipIII runs a responsible vulnerability disclosure program. Security researchers and partners can report a discovered vulnerability via the form on the /zglos page or the channel described in the Security Pack. Rule: zero publication of exploit details before an agreed fix, communication limited strictly to what was tested and what evidence of a successful fix was provided — no payloads or attack instructions in public content.
Details of the program, the reporting channel and the stated response time → Security Pack.
Every engagement that includes a testing component (PoC, pilot, workshop) is preceded by a complete set of documents:
These are decision-support tools for the contracting parties — they do not replace review by the client's own legal counsel or K0NSULT's. Full set of templates and a legal checklist → Procurement Pack.
ipIII does not pretend to be a bank-grade system. A register of seven known limitations (identity federation, mTLS, formal PAdES/TSA signature, multi-tenant, live CVE freshness, SIEM connector, Legal Trigger Engine boundary) is documented in full, with named risk, mitigation and closure priority (P0/P1) on a separate page. None of these limitations is hidden or presented as already resolved.
ipIII can run in different topologies depending on the client's data residency and integration requirements — from a shared instance (multi-tenant, ROADMAP) to a dedicated instance per client (today the default model for banking/institutional pilots). The choice of mode affects SLA, cost and deployment timeline.
| Mode | Description | Status |
|---|---|---|
| Dedicated instance (single-tenant) | Separate database and environment per client, physical data isolation | LIVE |
| Shared instance (multi-tenant + RLS) | One instance, logical separation via Row-Level Security | ROADMAP |
| On-prem / client VPC | Deployment on client infrastructure instead of K0NSULT hosting | ROADMAP |
Full comparison of topologies, network and cost requirements → Deployment Modes.
The support model describes contact channels, stated response times by severity, and support hours available during and after the pilot phase. Detailed response time matrix, escalation and maintenance windows → SLA / Support.
For GRC and risk management teams that must classify ipIII as a third-party vendor (third-party risk assessment), a set of answers to standard vendor questionnaire questions is prepared: data location, subprocessors, business continuity, incident response plan. This is an input to the client's own risk assessment process, not a substitute for it → Vendor Risk.
Full overview of trust policies, certifications in progress and LIVE evidence.
PoC scope, legal checklists, RoE/DPA/NDA templates ready for the purchasing team.
Register of seven limitations with risk, mitigation and priority — zero hidden gaps.
Related: data processing and legal bases → /data-processing · security program and CVD → /security-pack · deployment modes → /deployment-modes · SLA and support → /sla-support · vendor risk assessment → /vendor-risk.