A penetration testing report is the written record of an authorized attack on your systems. It states what was tested, how, and which weaknesses were proven exploitable.
Each finding carries evidence, severity, business impact, and a specific fix. A good report also records retest results, so an auditor or customer can see that findings were closed.
What CodeAnt AI solves here: CodeAnt AI runs black box, gray box, and white box pentests that prove what is exploitable, then links each finding to its root cause in code, cloud, or internal systems. Reports arrive within 48 hours and are mapped to SOC 2 and ISO 27001.
The table below is the short version of this whole guide. Each row is a section a strong report needs, and the last column shows what the weak version looks like.
Section | Question it answers | Primary reader | What the weak version looks like |
|---|---|---|---|
Executive summary | How exposed are we, and what matters first? | Leadership, auditors, customers | A count of findings by color with no narrative |
Scope and rules of engagement | What was tested, and what was off limits? | Auditors, security lead | A domain list with no dates, accounts, or exclusions |
Methodology | How did the tester work, and to what standard? | Auditors, engineers | A paragraph naming a framework and nothing else |
Findings with severity | What is broken, and how bad is it here? | Engineers, security lead | Scanner titles with default CVSS scores |
Evidence | How do we know it is real? | Engineers | No requests, no screenshots, no reproduction steps |
Impact | What could an attacker do with it in our business? | Leadership, engineers | Generic text copied from a vulnerability database |
Remediation | What exactly should we change? | Engineers | “Apply vendor patches” for every finding |
Retest results | Which fixes held? | Auditors, customers | Missing entirely |
Appendix | What else do reviewers need? | Auditors, engineers | Hundreds of pages of raw tool output |
If your report matches the weak column in more than two rows, you paid for a scan with a cover page.
Wondering whether your own app would produce findings worth reporting? Run a free scan and see what is exploitable on your app.
What a Penetration Testing Report Is For
A pentest report serves at least three readers. Leadership wants a risk decision, and engineers want enough detail to reproduce and fix.
Auditors and customers want something else again. They need proof that testing happened, was scoped sensibly, and led to remediation. The report is also the only artifact that outlives the engagement. The tester leaves and access is revoked. Six months later, someone asks why a finding was rated Medium. The report has to answer that without a phone call.
Reporting standards say the same thing in their own words. The Penetration Testing Execution Standard (PTES) splits the report into an executive summary and a technical report. The PCI Security Standards Council’s penetration testing guidance goes further. Its suggested outline adds scope, limitations, a testing narrative, and cleanup steps.
Still deciding between a vulnerability assessment and a full pentest? The components of VAPT change what the report can honestly claim. A scan can list possible issues. Only a test can show which ones an attacker can actually use.
The Anatomy of a Strong Pentest Report
Each section below has a job. When a section fails, the reader who depends on it makes a worse decision, so read each one with that reader in mind.
Executive summary
The executive summary is one to two pages that a non-specialist can act on. It names the overall posture and the two or three findings that matter most. Each top finding gets its business consequence in plain language. A useful summary also says what went well.
If the tester spent two days trying to cross tenant boundaries and failed, that is evidence a control works. Leadership should hear it. Watch for summaries that only restate counts. “3 High, 7 Medium, 12 Low” says nothing about whether the High findings share a root cause or sit on an unreachable admin panel.
Scope and rules of engagement
This section lists exactly what was in scope. That means domains, IP ranges, applications, APIs, cloud accounts, and test user roles. It also lists what was excluded and why. The testing window and any limits on technique or traffic belong here as well.
Auditors read this section first, because a clean report on a narrow scope proves very little. If the scope was set in a statement of work, the report should match it.
Our guide to a penetration testing scope of work covers how to write that agreement before testing starts. Limitations belong here too. The PCI SSC guidance treats a “Statement of Limitations” as its own section, covering restrictions such as allowed hours or bandwidth caps.
Methodology
The methodology section explains how the work was done and against which reference. That might be PTES, the OWASP Web Security Testing Guide, or the tester’s own documented process. Naming a framework is the minimum. A strong section also states the test perspective (black box, gray box, or white box) and which roles and credentials were used.
It should show roughly how time was split across the attack surface, too. For a comparison of the main frameworks, see our guide to penetration testing methodology frameworks.
Findings with severity
Each finding is a self-contained record. It has a descriptive title, the affected asset, a severity rating with the scoring vector, and a description of the weakness. References such as a CWE or CVE identifier go in the record where one applies. Titles matter more than they look.
Good titles describe the consequence, like “Any authenticated user can read other tenants’ invoices.” Weak titles name a scanner check, like “Missing security header.” The first tells an engineer what to protect. The second tells them which tool ran.
Evidence
Evidence separates a finding from an opinion. It includes the relevant requests and responses with secrets redacted, screenshots, timestamps, and the account or role used. Reproduction steps should let a competent engineer confirm the issue in minutes. They describe the conditions and the observable result.
The PCI SSC guidance also expects evidence such as screenshots and raw output to be retained and handled securely. A pentest report is itself sensitive data.
Impact
Impact explains what an attacker could do with the weakness in your environment. Generic database text does not do this job. A stored cross-site scripting bug in an internal wiki and the same bug in your billing portal share a CVSS base score. Their consequences are very different.
Chained findings belong here. Two Medium issues that together let an outside attacker reach production data deserve a combined narrative. Our explainer on vulnerability chaining shows why chains change priorities.
Remediation
Remediation guidance should be specific enough to turn into a ticket. It names the control to change, the layer where the fix belongs, and how to verify the fix.
The best reports also separate the quick mitigation from the durable fix. A WAF rule might buy a week. Moving an authorization check from the client into the service layer closes the whole class of bug. That distinction saves a repeat finding next year.
Retest results
A retest section lists each original finding, the date it was retested, and its new status. Typical statuses are fixed, partially fixed, or still open.
PCI SSC guidance for a retest report asks for the original test date, the retest date, the original findings, and the retest results. Without this section, a report proves that problems were found. Auditors and customers care whether they were fixed.
Our penetration test retest guide covers how to schedule and scope a retest.
Appendix
The appendix holds what a reviewer may need but most readers will skip. Typical contents are the full asset list, tools used, tester names and credentials, and the severity model definition.
Cleanup deserves a line of its own. Test accounts, uploaded files, and changed settings should be listed and confirmed removed. PCI SSC lists “Cleaning up the Environment Post-Penetration Test” as a report section for exactly this reason.
How to Rate Severity in a Pentest Report
Severity ratings start with CVSS, but they should not end there. FIRST published CVSS v4.0 with an initial publication date of 1 November 2023. CVSS scores the technical characteristics of a vulnerability. The CVSS v4.0 specification defines this qualitative scale.
Rating | CVSS v4.0 score |
|---|---|
None | 0.0 |
Low | 0.1 to 3.9 |
Medium | 4.0 to 6.9 |
High | 7.0 to 8.9 |
Critical | 9.0 to 10.0 |
The scale is the shared vocabulary. It does not know which of your systems hold customer data.
CVSS v4.0 also names score types by the metric groups used. CVSS-B means Base only, and CVSS-BTE means Base, Threat, and Environmental.
A report that prints a CVSS-B score as “the risk” has skipped the threat and environment context that v4.0 explicitly supports. A defensible report severity combines three inputs. The table below is the model to ask your tester to document in the appendix.
Input | What it captures | Example values | Where it comes from |
|---|---|---|---|
Technical severity | How bad the weakness is in the abstract | CVSS v4.0 vector and score | Tester, using the FIRST specification |
Exploitability | Whether it was actually exploited in this test | Proven, plausible with stated preconditions, theoretical | Tester’s evidence |
Business impact | What breaks for you if it is used | Data class exposed, tenant boundary crossed, privileged action, availability | Tester plus your asset owners |
The takeaway is easy to apply. A proven exploit against a tenant boundary outranks a theoretical one with a higher CVSS score.
PCI SSC guidance makes the same point from the auditor’s side. It asks that reports explain how each severity rating was derived, especially when custom scoring is used. For third-party CVEs found during the test, exploit likelihood and known exploitation data help too. Our guide to CVSS, EPSS, and KEV prioritization covers how to combine them.
What Auditors Check in a Pentest Report
Auditors rarely read every finding. They check whether the report proves a process happened and closed, as summarized below for three common frameworks.
Framework | What the auditor is trying to confirm | Report sections they lean on |
|---|---|---|
SOC 2 | Independent testing of controls happened in the audit period, and issues were tracked to closure | Dates, scope, findings, remediation status, retest |
ISO 27001 | Technical vulnerabilities are identified, assessed, and treated through a defined process | Methodology, severity model, remediation plan, retest |
PCI DSS | Testing covered the cardholder data environment and segmentation controls, using a defined method | Scope (CDE vs non-CDE), methodology, segmentation results, retest |
The pattern across all three is consistent. Auditors want dates, scope, a method, and evidence of remediation. For SOC 2, the report becomes evidence in your control narrative. The testing dates should fall inside the period under audit.
Our breakdown of SOC 2 penetration testing requirements covers what auditors ask for in practice.
PCI SSC guidance adds two report sections other frameworks stress less. One is segmentation test results, which show that out-of-scope networks really are isolated. The other is a statement of scope explaining how the cardholder data environment was defined. Our PCI DSS penetration testing requirements guide has the full picture.
Red Flags of a Weak Pentest Report
Some reports look thorough and say very little. These patterns are worth catching before a report goes to an auditor or a customer.
Red flag | Why it matters | What to ask the tester |
|---|---|---|
Findings read like scanner output | Suggests no manual validation or chaining | “Which findings did you exploit by hand?” |
No evidence per finding | Engineers cannot reproduce, auditors cannot verify | “Can you add requests, responses, and screenshots?” |
Default CVSS scores everywhere | Severity ignores your data and architecture | “How did you adjust for exploitability and business impact?” |
Scope section is vague | A clean result on a narrow scope proves little | “Which roles, APIs, and environments were tested?” |
No negative results | You cannot tell what was tried and held | “Which attack paths did you attempt that failed?” |
No retest | Proves discovery, not remediation | “When can you retest, and will it be in the same report?” |
Remediation is generic | Fixes stall in triage | “What exact change closes this, and at which layer?” |
A report with three or more of these flags is a scan summary. Treat its findings as leads that still need validation. The most expensive flag is the missing negative result. Without it, next year’s tester repeats the same work and nobody learns which controls held.
Penetration Test Report Template
Here is a copyable outline you can hand to a tester or use for an internal report. It contains structure and placeholder text only.
Two notes on using it. Keep evidence fields to what an engineer needs to confirm the issue, and store the finished report with the same care as credentials.
How to Read a Pentest Report as a Buyer
Start with the scope section, not the findings. If scope misses the roles, APIs, and environments your customers actually use, a clean result tells you little.
Next, read two findings end to end. Pick one High and one Medium, and check each for evidence, business-specific impact, and a fix an engineer could ticket today.
Then look for the narrative. A tester who chained findings or described failed attack paths actually thought about your system.
A flat list of unrelated issues usually came from a tool. That matters when you pay for human judgment.
Finally, check the dates and signatures. Customers and auditors will ask when testing happened, who did it, and whether retesting followed.
If those answers are missing, request a revised version before the report goes into a security questionnaire. For web-heavy products, our guide to web application penetration testing explains what good coverage of authentication, authorization, and business logic looks like.
How to Act on a Penetration Testing Report
A report only reduces risk once its findings turn into merged fixes. NIST SP 800-115 frames the same step as analyzing findings and developing risk mitigation techniques to address weaknesses. The NIST guide also recommends root cause analysis after an assessment. In practice, the work happens in three steps.
Triage within days
Hold a triage meeting within a few days of delivery, with the tester available. Confirm each finding, assign an owner, and agree on severity.
Disputes are cheaper to settle while the tester still remembers the context. Group findings by root cause rather than by title. Five IDOR findings across five endpoints usually mean one missing authorization layer. One fix beats five patches.
Set remediation targets
Write remediation targets down by severity, because auditors will compare your closure dates against your own policy. The table below is an example starting point, not a standard. Adjust it to your risk appetite and contractual commitments.
Severity | Example target to remediate | Example target to retest |
|---|---|---|
Critical | Days | Immediately after fix |
High | Within a sprint or two | With the next retest window |
Medium | Within a quarter | With the next retest window |
Low | Backlog, reviewed quarterly | Next scheduled test |
Whatever numbers you pick, the policy has to exist and your closure dates have to follow it.
Retest and close
Retest every Critical and High finding, and record the results in the same report or a formal addendum. A finding is closed when the retest confirms the fix. A ticket moving to Done does not count.
If fixes keep failing retest, check the remediation guidance quality first. Vague guidance produces partial fixes, and partial fixes come back as next year’s findings.
What a CodeAnt Pentest Report Looks Like
CodeAnt’s reports are built for the readers above. Each finding is tied to proof that it is exploitable and to its root cause in your code, cloud, or internal systems. Engineers get a fix path, and auditors get evidence. Reports arrive within 48 hours and are mapped to SOC 2 and ISO 27001.
Testing depth can be black box, gray box, or white box. Repository, cloud, or internal access is added only for the assessments you authorize.
You can judge the format yourself before talking to anyone. Open the CodeAnt pentest sample report and hold it against the red flags table above.
One customer described the depth this way. “CodeAnt went deeper than any penetration test we’ve ever commissioned. The most thorough offensive security platform we’ve used,” said Jeson Patel, CTO at 11x.
Where This Leaves You
A penetration testing report is worth what it lets you prove. Scope, method, evidence, business impact, and closed retests serve leadership, engineers, and auditors at once. If yours is a list of scanner titles, ask for more before you file it. Use the template above as the bar for every future report.
Try it on your app: Run a free scan and get a pentest report in 48 hours, or book a pentest. Want to see the output first? Open the sample report.
