Four audiences, four reports, one assessment
A board does not want request and response pairs. An engineer does not want a risk narrative. An auditor wants control mapping, and a developer wants the file and the fix.
One assessment produces all four, plus exports in five formats, including SARIF, which puts findings directly in the pull request.
Executive · Technical · Compliance · Developer · Custom branding available
Overview
Reporting is where most security tooling reveals whether it was built by people who have run a security programme.
The tell is a single report. One document, produced for whoever the vendor imagined the buyer to be, which then has to be reworked by hand for everyone else. The security team extracts the findings for engineering, rewrites the summary for leadership, and rebuilds the control mapping for the auditor: three derivative documents, each drifting from the source, none of them versioned.
That reworking is not incidental. In most programmes it is a meaningful share of the time the programme costs, and it produces nothing that did not already exist.
AIPTx generates four report templates from one assessment, each written for a specific reader, plus five export formats for the systems that consume findings rather than read them. The underlying data is identical, so the versions cannot drift, and nobody rebuilds anything.
The four templates
- Step 01
Executive Report
A high-level summary for leadership and stakeholders, focused on business impact and risk metrics. It carries the overall risk score and rating, an overview of critical findings, a business impact assessment, comparative trend analysis against previous scans, and strategic recommendations. Written for someone deciding where effort and money go, not what to change.
- Step 02
Technical Report
Detailed findings with proof-of-concept code and remediation guidance. Each entry carries the vulnerability and its severity, technical description, affected location, potential consequences, exploitation evidence, remediation steps and references to OWASP, CWE and CVE material.
- Step 03
Compliance Report
Findings mapped to compliance frameworks with control assessments and gap analysis. Written for the audit conversation rather than the engineering one.
See Compliance Mapping - Step 04
Developer Report
A code-centric format with file references and fix examples. The version an engineer can act on without translating anything.
See AI Recommendations
The section structure
Every report is built from the same components, included according to audience:
- Executive summary
- Overall risk scoring and ratings, critical findings overview, business impact assessment, trend comparison against previous scans, strategic recommendations
- Findings summary
- Vulnerability counts by severity level and remediation status
- Detailed findings
- Identification and severity, technical description, affected locations, potential consequences, exploitation evidence, remediation steps and references
- Risk analysis
- A composite score from 0 to 100 derived from critical and high findings, exposure level and asset criticality weighting
Five export formats
PDF for presentations, board packs and compliance audits. HTML as an interactive report with navigation, expandable sections and search. JSON for machine consumption and tool integration. CSV for spreadsheets and tracking system imports. SARIF for IDE and CI/CD pipeline integration, the format that puts a finding in front of a developer in their editor rather than in a document they will not open.
Generation and delivery
Reports can be branded to your organisation, filtered by severity and category so a report can be scoped to an audience or a team, scheduled for automated delivery by email or Slack, and shared through time-limited links with access controls, which matters when the recipient is a customer or an auditor who should not have permanent access.
From the command line:
aiptx report generate --scan-id abc123 --format pdfCapabilities
Four report templates
Executive, Technical, Compliance, Developer.
Executive summary
Risk scoring and ratings, critical findings, business impact, trend comparison, strategic recommendations.
Findings summary
Counts by severity and remediation status.
Detailed findings
Severity, description, affected location, consequences, exploitation evidence, remediation steps, references.
Risk analysis
Composite 0–100 score from critical and high findings, exposure level and asset criticality.
Five export formats
PDF, HTML, JSON, CSV, SARIF.
Interactive HTML
Navigation, expandable sections, search.
Custom branding
Your identity applied to generated reports, for the versions that go to a customer or an auditor.
Filtered generation
Scope a report by severity and category, so a team receives its own findings rather than everyone's.
Scheduled delivery
Automated delivery by email or Slack on the cadence you set, without anyone remembering to produce it.
Time-limited shareable links
Access-controlled links for recipients outside the workspace, expiring rather than granting permanent access.
Trend analysis
Comparative analysis against previous scans, like-for-like because the methodology does not change between runs.
Compliance mapping
Across PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS, with control assessment and gap analysis.
Evidence inline
Syntax-highlighted proof-of-concept code within interactive reports.
CLI generation
aiptx report generate --scan-id <id> --format <format>.
REST API
Report generation and retrieval programmatically, across the same four templates and five formats.
Benefits
- 01
Nobody rebuilds the report.
Four audiences served from one assessment, so the derivative-document work disappears along with the drift it caused.
- 02
SARIF puts findings where work happens.
In the editor and the pull request rather than in a PDF somebody will open next quarter.
- 03
Trend means something.
Because the methodology does not change between runs, comparing this assessment to the last is a like-for-like exercise. That is what turns a series of reports into a trajectory.
- 04
Audit evidence is generated, not assembled.
Control mapping and gap analysis come out of the assessment rather than out of a fortnight of preparation.
- 05
Reports can be shared safely.
Time-limited links with access controls mean a customer or auditor gets what they need without permanent access to your findings.
- 06
Scoped reporting for scoped audiences.
Filtering by severity and category means a team receives their findings rather than everyone's.
- 07
The board slide writes itself.
A tracked composite score with business impact and trend, backed by finding-level detail, is the artefact executive reporting actually needs.
- 08
Evidence remains connected to the source.
Every finding stays linked to the request, response and validation that produced it, so reviews focus on decisions rather than reconstructing how a result was obtained.
One assessment, four Monday mornings.
Illustrative example. Not a customer account.
A Standard assessment completes against a customer-facing platform on Friday. It produces 34 findings (three critical, nine high, the remainder medium and low) and a composite risk score of 71.
- 01
The CTO opens the Executive Report. Two pages: risk score 71, down from 84 at the previous assessment; three criticals summarised in business terms; a note that the improvement came from closing an authentication issue that had been open for two quarters; strategic recommendations for the next cycle. No request and response pairs anywhere.
- 02
The AppSec lead works from the Technical Report. Every finding with its evidence, severity, affected location, exploitation proof and remediation steps, with OWASP and CWE references for the two findings whose classification is worth discussing.
- 03
The compliance manager exports the Compliance Report ahead of a SOC 2 window. Findings mapped to controls, gap analysis attached, retest history showing which items closed since the last cycle and when.
- 04
The engineering team never opens a report at all. Findings arrived as SARIF in their pull requests and as Linear tickets with the fix examples attached. The Developer Report exists if anyone wants it; mostly nobody needs to.
- 05
A month later an enterprise prospect asks for evidence of testing. The security team generates a filtered PDF (criticals and highs only, branded) and shares it through a time-limited link that expires after the review.
The point.
One assessment. No document was rewritten, no findings were re-keyed, and every version says the same thing because they are all views of the same data.
FAQ
Frequently Asked Questions
What report formats do you support?
PDF for presentations and audits, HTML as an interactive report with navigation and search, JSON for machine consumption, CSV for spreadsheets and tracking systems, and SARIF for IDE and CI/CD integration.
Can we brand reports with our own identity?
Yes, custom branding is supported on every generated report.
Can we generate a report for one team or one severity level?
Yes, report generation can be filtered by severity and category, so a report is scoped to a team, an environment or a threshold rather than covering everything.
Can reports be delivered automatically?
Yes, on a schedule by email or Slack, which is what makes a monthly executive summary or a weekly technical digest arrive without anyone remembering to produce it.
How do we share a report with a customer or auditor?
Through a time-limited shareable link with access controls, so the recipient gets what they need for as long as they need it rather than permanently.
Will the report satisfy an auditor?
The Compliance Report maps findings to controls with gap analysis across PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS and retest history evidences remediation, though sufficiency depends on the framework and the auditor, some of whom require a named human tester.
How does trend comparison work?
Reports carry comparative analysis against previous scans and findings carry a first_seen timestamp with persistent status, and because the methodology does not change between runs the comparison is like-for-like.
Can we pull reports programmatically?
Yes, via the REST API and from the CLI with aiptx report generate --scan-id <id> --format <format>.
Is the risk score the same as finding priority?
Related but not the same number: the composite 0–100 score describes the environment, while individual findings are ranked by weighted factors.
Which report goes to which audience?
Four templates — executive summary for the board, findings summary for the security lead, detailed findings for whoever is fixing them and risk analysis for deciding where effort goes — all produced from the same assessment, so the figures agree across them.
The platform capabilities behind this feature
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
The audit question, answered before it is asked
Findings mapped to PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS controls, with gap analysis and retest history generated per run.
The fix arrives with the finding
Every finding arrives with the fix: a summary, the vulnerable and secure code side by side, and references. Not a link to a generic advisory.
Sixty criticals is not a plan
Findings ranked by exploitability, impact, asset value and exposure, with the weights published, so the order can be defended.
See what lands at the end
Run an assessment and generate all four reports from it: executive, technical, compliance and developer.
Five export formats · Custom branding available