A pentest or AppSec report does not by itself change a board decision — it needs to go through normalization, ownership assignment, proof of remediation, and a summary that can be read in five minutes at a risk committee. This page describes the evidentiary MVP path in ipIII: import → severity normalization → evidence (hash + chain-of-custody) → owner/SLA → retest → close → Board Pack → Regulatory Pack. Every step here carries an explicit LIVE or ROADMAP status — in line with the claim ≤ proof doctrine.
The problem this path solves is not technical — it is communicational. The security team has a PDF/JSON report from a scanning tool or from a pentester. The board and internal audit need something different: who is responsible, by when, what evidence shows the issue was actually fixed, and whether a regulatory deadline is at risk. ipIII connects these two worlds with one pipeline, without manually re-typing data from one spreadsheet into another.
The entry point is the output of work security teams already do: an AppSec scan, a pentest report, an export from a DAST/SAST tool. ipIII does not replace those tools or pentesters — it consumes their output. LIVE connectors parse Burp, ZAP, Nessus, and generic CSV formats; a description of the parsers, their tests, and supported scope is on the /connectors page. If a scanner format is not yet supported, manual CSV import remains a fallback path (it does not block a pilot).
Burp Suite (XML), OWASP ZAP (XML/JSON), Nessus (.nessus), generic CSV (column mapping).
Finding title, description, affected asset/endpoint, the tool's original severity, references (CVE/CWE where present), scan timestamp.
We do not run a scan or a penetration test. Import requires an existing, authorized result delivered by the client or its test provider.
Every scanner has its own scale: Burp says "High/Medium/Low/Info", Nessus computes a base CVSS score, a
pentester's PDF report may use a descriptive category such as "Critical". Without normalization, comparing
findings from three different sources in a single Board Pack makes no sense — priorities would be inconsistent.
ipIII maps the incoming severity onto a shared scale of critical / high / medium / low / info, with
mapping rules per source (e.g., CVSS ≥ 9.0 → critical), and — where a finding is linked to a CVE — attaches an
offline CVSS/EPSS/KEV hint from a seed dataset (documented in the known-limitations register as periodically
refreshed data, not real-time).
This normalization step is the one that most often gets lost when Excel sheets from three teams are stitched together by hand — and it is what most affects the credibility of the final Board Pack before an audit.
A finding on its own is a claim ("port X is open", "endpoint Y is vulnerable to Z"). A claim without evidence
does not survive an auditor's question: "how do we know this, and was the data changed afterward?" That is why
every import and every retest in ipIII generates an evidence package: a content manifest, a
sha256 hash of the whole package, and a chain-of-custody record (who did what operation on a
given piece of evidence, and when) in the database. This makes it possible to demonstrate data integrity between
the moment of import and the moment of presentation in the Board Pack — without altering the original source
file.
An important distinction, per the known-limitations register: sha256 proves the content of the
package has not changed, but it is not a qualified electronic signature (PAdES) nor a TSA timestamp — both
of those are marked today as ROADMAP, not LIVE. Anyone who wants to verify the
hash of a specific evidence package independently of the ipIII interface can do so on the
/verify page.
A finding without an owner is a finding that will never be fixed on time. Every imported and normalized finding is assigned to an owner (a person or a team) with an SLA deadline calculated from severity — critical and high findings get a shorter window than medium and low ones. This assignment is what turns "a list of problems" into "a remediation plan with accountability". A detailed description of the assignment mechanics, SLA-breach escalation, and integration with ticketing systems is on the /remediation page.
A finding is not considered closed on the basis of a "fixed" declaration. Closing requires a retest — a new examination of the same asset — plus new evidence confirming the vulnerability condition no longer exists (or that the risk was formally accepted by the owner with a documented justification, if a fix is not possible within the given timeframe). Only that full set — finding + import evidence + retest evidence + owner decision — moves to "closed" status in the register.
This is the difference between "a workflow for managing a list" and an actual evidence chain: an auditor asking "how do we know this critical finding is genuinely closed" gets an answer in the form of a concrete evidence package with a hash, not just a status change in a text field.
The Board Pack is a generated document that aggregates the state of all findings in a given time window: the number of critical/high findings in progress, the percentage closed on time (SLA compliance), a list of overdue findings with a named owner, and a trend summary against the previous period. The board and the risk committee do not read the raw pentest report — they read this summary, with a link to the full evidence for each item if they need to dig deeper. The generation mechanics and a sample structure of the Board Pack are described on the /ciso-board-pack page; a ready sample document (synthetic data) can be viewed at /samples.
The quality of a Board Pack is measured not only by completeness, but also by evidentiary coverage — how many of the presented claims are backed by a real evidence package rather than just a table entry. This indicator is calculated and shown separately on the /coverage-score page.
Some findings trigger a notification duty to an authority (for example under DORA, NIS2, or GDPR in the case of a personal-data incident) — with a hard deadline measured in hours, not weeks. The Legal Trigger Engine in ipIII maps the incident type to a potential duty and a suggested deadline, but this is decision-support, not legal advice. Every draft notification to an authority requires review by a lawyer or law firm before it is sent — this limitation is permanent by design and is not something planned to be "fully automated" in a future version.
| Pipeline step | What works today | Status |
|---|---|---|
| Import (Burp/ZAP/Nessus/CSV) | Parsers with unit and integration tests against a live PostgreSQL instance. | LIVE |
| Severity normalization | Source→shared-scale mapping + offline CVSS/EPSS/KEV hint from a seed dataset. | LIVE offline data |
| Evidence (hash + chain-of-custody) | sha256 of the package, manifest, operation record in the database. |
LIVE |
| PAdES signature / TSA timestamp | Not implemented — today only an integrity hash. | ROADMAP (P1) |
| Owner / SLA | Assignment and deadline calculation by severity, on a live database. | LIVE |
| Retest / close-with-evidence | Closing requires a new evidence package from the retest. | LIVE |
| Board Pack | Generated board summary document, with links to evidence. | LIVE |
| Regulatory Pack (authority draft) | Legal Trigger Engine suggests a duty/deadline — requires legal review. | LIVE draft decision-support |
| SIEM ingestion (event stream) | Today: import from export files, not a stream from a detection center. | ROADMAP |
One place to see the status of all findings from all sources, with an owner and SLA — instead of asking the team every week "what stage is this at".
A Board Pack with a link to the evidence for each item, instead of a raw pentester PDF that nobody in the room has time to read in full.
A Regulatory Pack draft as a starting point for assessing a notification duty — with a clear decision-support disclaimer, not a ready-made decision.
The ability to deliver a report in the tool's standard format (Burp/ZAP/Nessus) without manually re-typing results into the client's spreadsheet.
A full description of what is evidence-backed (code, tests, a live endpoint) versus what is a planned statement is centralized on the /trust-center page. The rule is simple: an element without evidence is marked ROADMAP, never LIVE — regardless of how much that shortens the sales pitch.
Related: assignment and SLA mechanics → /remediation · evidentiary coverage indicator → /coverage-score · input formats and parsers → /connectors · full Board Pack structure → /ciso-board-pack.