The Penetration Testing Report: What's In It, and What Auditors Actually Want

A penetration testing report is the deliverable everything else hinges on — it's what you hand to auditors, to enterprise buyers' security reviewers, and to your own engineers. Most reports are a technical PDF that you then have to translate into the language of ISO 27001, SOC 2, NIS2 or DORA yourself. Matproof Sentinel's report is different: every finding arrives with proof-of-exploit, a CVSS 3.1 rating, remediation guidance, re-test verification, and an explicit mapping to the controls your auditor checks. This page explains exactly what a good report contains and why the mapping is the difference between 'a pentest happened' and 'here is the evidence you asked for'.

Get a sample report
MW
Written by Malte Wagenbach
Founder of Matproof Security. Specialized in AI-driven penetration testing and EU compliance (DORA, NIS2, ISO 27001, SOC 2).
Last reviewed: May 17, 2026

Why the report — not the test — is what your auditor and buyer actually judge

Two penetration tests can be technically identical and produce wildly different business outcomes, because what your auditor, your enterprise customer, and your own engineering team interact with is the report — not the testing. A report that lists vulnerabilities without proof-of-exploit gets argued with ('is that a real issue or a scanner false positive?'). A report without risk ratings can't be prioritised. A report without remediation tracking and re-test evidence fails the question every ISO 27001 and SOC 2 auditor asks: 'show me that findings were actually fixed and verified.' And a report written purely in technical language forces someone — usually you — to manually map each finding to ISO 27001 Annex A controls, SOC 2 Trust Services Criteria, NIS2 Art. 21 measures or DORA Art. 24 requirements before it counts as compliance evidence. That translation work is where most of the real cost and delay lives. The entire design premise of the Matproof Sentinel report is to do that mapping at the source: a pure pentest firm hands you a PDF and wishes you luck with the auditor; Matproof hands you evidence already structured the way the auditor will consume it. That is the moat — pentest output that is born audit-ready.

  • Proof-of-exploit per finding ends the 'is this real?' argument — auditors and engineers trust a demonstrated exploit, not a scanner's 'possible' flag.
  • CVSS 3.1 risk ratings let you prioritise and let auditors see you triage by severity, not by whoever shouts loudest.
  • Remediation tracking + re-test evidence is the single thing ISO 27001 and SOC 2 auditors most want to see: proof that high/critical findings were fixed and verified, not just listed.
  • Control mapping is the differentiator: findings tied to ISO 27001 Annex A, SOC 2 TSC, NIS2 Art. 21 and DORA Art. 24 are compliance evidence — an unmapped technical PDF is homework.
  • Enterprise procurement increasingly requests the report itself (often via a security questionnaire) — a clean, well-structured, mapped report shortens sales cycles; a messy one stalls them.
  • A consistent, machine-generated report format means year-over-year comparability for surveillance audits — auditors can see the programme operating continuously, which is exactly what they require.

What's in a Matproof Sentinel penetration testing report

  • Executive summary: posture overview, finding counts by severity, and the headline risk in plain language for management and the board
  • Scope and methodology: exactly what was tested, the methodology used (OWASP Testing Guide / OWASP API Top 10 / NIST SP 800-115), and the testing window
  • Findings register: each finding with title, CVSS 3.1 score and vector, affected asset, and business impact
  • Proof-of-exploit: the concrete steps/request used to demonstrate each finding — not a speculative scanner alert
  • Remediation guidance: specific, actionable fix instructions per finding, not generic advice
  • Re-test verification: status of each finding after remediation (open / fixed / verified-fixed) for the evidence auditors require
  • Control mapping: every finding mapped to ISO 27001:2022 Annex A, SOC 2 Trust Services Criteria, NIS2 Art. 21 and DORA Art. 24 — the audit-ready layer
  • Appendices: full technical detail, affected endpoints, CVE/CWE references, and MITRE ATT&CK technique mapping for your SOC
  • Auditor-shareable format: a clean PDF plus a read-only link auditors and enterprise reviewers can access directly

Sample finding

Info

PDF vs audit-ready evidence: the same finding, two very different reports

Consider one finding — a broken object-level authorization flaw exposing customer records. A typical pentest PDF says: 'IDOR on /api/invoices/{id}, High severity, fix authorization.' The Matproof Sentinel report says the same thing, plus: a proof-of-exploit showing tenant A reading tenant B's invoice, a CVSS 3.1 vector, a re-test confirming the fix, and an explicit line item — 'satisfies ISO 27001:2022 A.8.3 Information Access Restriction evidence; relevant to SOC 2 CC6.1; addresses NIS2 Art. 21 access-control measures.' When your ISO 27001 surveillance auditor asks for evidence that access controls are tested and remediated, the first report needs translating; the second is the answer.

Fix: When you commission any penetration test, require these in the deliverable before you start: proof-of-exploit per finding, CVSS 3.1 ratings, remediation guidance, free re-test of high/critical findings, and explicit mapping to your compliance framework(s). If a provider can't map to ISO 27001 / SOC 2 / NIS2 / DORA, budget for the translation time internally. Matproof Sentinel includes all of the above in every report by default — see a sample from the free scan.

Reference: ISO 27001:2022 A.8.8 / A.8.29 evidence requirements · SOC 2 CC4.1 / CC7.1 · NIS2 Art. 21 · DORA Art. 24 · NIST SP 800-115 Technical Guide to Information Security Testing

Report quality: free scan vs Matproof Sentinel vs traditional PDF

Free scanMatproof SentinelTraditional consultancy
Automated scan engine✓ (3-min preview)✓ Full scan✗ Manual only
OWASP Top 10 coveragePartial✓ Complete✓ Complete
Proof-of-exploit evidence✓ Per finding✓ Per finding
Regulatory mapping (DORA/NIS2/ISO 27001)✓ Automated✓ Manual
Audit-ready PDF report✓ Instant✓ 2–4 weeks delivery
Continuous / recurring scans✓ Per deploy✗ Annual engagement
Time to first result~3 min~30 min full scan2–4 weeks
Price€0From €149€8,000–€25,000
Source code review (SAST)✓ On Growth plan✓ Scoped engagement
API testing (REST/GraphQL)✓ Automated✓ Manual

Get an audit-ready report

Single Run
€149 one-time
  • 1 full pentest scan
  • AI-prioritized findings with CVSS 3.1
  • Proof-of-exploit per finding
  • Audit-ready PDF report
  • Regulatory mapping (DORA, NIS2, ISO 27001)
Buy single run
Recommended
Starter
€299 / month
  • Unlimited scans (up to 3 domains)
  • Continuous monitoring
  • CI/CD integration (GitHub, GitLab)
  • All regulatory mappings
  • Priority support
Start Starter
Growth
€799 / month
  • Unlimited scans + domains
  • Authenticated / White-Box testing
  • API & cloud infrastructure tests
  • Dedicated security account manager
  • 24h SLA response time
Contact for Growth

Frequently asked questions about penetration testing reports

What should a penetration testing report contain?

A complete penetration testing report contains: an executive summary, scope and methodology, a findings register with CVSS 3.1 ratings, proof-of-exploit per finding, specific remediation guidance, re-test verification status, and — critically for compliance — a mapping of each finding to the relevant controls (ISO 27001 Annex A, SOC 2 TSC, NIS2 Art. 21, DORA Art. 24). Technical appendices with CVE/CWE references and affected endpoints round it out.

What do ISO 27001 and SOC 2 auditors look for in a pentest report?

Auditors look for evidence of a functioning process, not just a list of bugs: findings that are risk-rated, each with a treatment decision, with high/critical findings remediated and re-tested within a reasonable timeframe, and proof that results were reviewed by management. A clean finding register with no overdue critical/high items, plus evidence of continuous testing over the audit period, is the goal. The Matproof Sentinel report is structured to provide exactly these artefacts.

Why does control mapping matter so much?

Because an unmapped technical report is not yet compliance evidence — someone has to translate each finding into the language of your framework before an auditor accepts it. That translation is slow, error-prone, and usually falls on your internal team. A report that maps each finding to ISO 27001 / SOC 2 / NIS2 / DORA at the source is audit-ready immediately. This is the core difference between Matproof and a pure pentest firm: we produce the evidence already in the auditor's format.

Can I share the report directly with an auditor or customer?

Yes. The Sentinel report is available as a clean PDF and as a read-only shareable link, so auditors and enterprise security reviewers can access the evidence directly — which reduces the back-and-forth email cycle that slows audits and security reviews.

Can I see a sample penetration testing report?

Yes — run the free 3-minute scan and you'll receive a sample report showing the structure, finding format and control mapping. A full audit-ready report (with proof-of-exploit and re-test) is available from €149.

Related

Go deeper — related blog articles

Get a report your auditor accepts the first time

Run a free 3-minute scan to see a sample report, or get a full audit-ready penetration testing report — proof-of-exploit, CVSS ratings, re-test, and mapping to ISO 27001, SOC 2, NIS2 and DORA — from €149.

Get a sample report