How it works

From raw tool output to a report you can defend

Everything on this page is what FindingsHub does today. Anything still to come is in the roadmap section at the bottom, clearly marked.

Request a quote

Import a report

Drop in Burp or Metasploit output, a CSV export, a PDF report or a Markdown write-up. FindingsHub reads the file, pulls out findings, affected assets and severities, and records what it imported and when.

Findings de-duplicated and scored

The same issue reported by three tools becomes one finding with three sources against it. Each one carries a CVSS v3.1 vector with a live score, plus the business risk context your client actually reads.

Clear the CDPT readiness checklist

Before a report can be generated, the checklist tells you exactly what is missing — scope statements, tester credentials, activity log entries, a CVSS vector, remediation advice. Nothing leaves the building half-finished.

Generate the reports

An executive report for the board, a CDPT-structured technical report for the security team, and a remediation and closure report. Each exports as a PDF carrying your firm's logo.

Record the re-test and close the finding

Log the re-test date, the tester, what changed, the attack method retried and the outcome. The closure report is written from that record, not from memory.

The difference

The CDPT readiness checklist

Most reporting tools will happily produce a document with the scope missing and the tester unnamed. FindingsHub will not. The readiness checklist is modelled on the CREST Defensible Penetration Test criteria, so it asks the questions a UK assessor asks: was the scope agreed and recorded, were constraints and deviations captured, who did the work and under what accreditation, what was actually run and when, and is each finding scored and remediable.

You see the outstanding items as a list, with a link straight to the field that fills each one. The report generates when the list is clear. That is the whole point: a report that is defensible before it is sent, not after someone challenges it.

Evidence and audit trail

Screenshots, request captures and supporting files are stored against the individual finding, not in a shared folder somewhere. Every import is recorded — what file, how many findings, how many merged as duplicates, who did it. The activity log records what was run against what, and when.

What your client gets today

The reports you issue them, and their own login to a view containing only their engagements. A client sees their data and nothing else — segregation is enforced by the database, not by hiding buttons. Evidence stays invisible to them until you release the technical report.

Coming next

Planned, not built. Listed with the period we are aiming at so you can judge for yourself.

Branded client portal
Target: Q2 2027
Clients claiming fixes, testers validating them
Target: Q1 2027
Assurance summary across a 12-month programme
Target: Q2 2027
QA review and release workflow
Target: Q1 2027
Firm-wide findings library and cross-engagement search
Target: Q2 2027
Notifications on claims, re-tests and releases
Target: Q1 2027

Prefer the numbers first? See pricing.