The report is the only part of a penetration test most people ever see. The testing happens over a few days, mostly out of sight. The report is what lands on the IT manager’s desk, gets summarised for the Board and, if it’s any good, turns into a list of jobs. If it isn’t any good, it turns into a PDF in a folder.
This guide is for the person receiving the report. It sets out what should be in one, seven tests to judge the one you’ve been given, what each reader in your organisation needs from it, and what to do once it arrives. If you’re still at the buying stage, the report is worth checking before you sign, too: ask for a sample, as our 15 questions to ask a penetration testing company suggest.
There’s a published UK standard for exactly this. The NCSC’s Assured CHECK Scheme Standard (opens in a new tab) (v1.1, November 2024) has a whole section, Section C, on what a CHECK report must contain. It’s written for CHECK testing of public sector and critical national infrastructure systems, so it doesn’t bind anyone else. It’s still the best yardstick I know of for any penetration test report, and I’ve used it as one throughout.
What a Penetration Test Report Should Contain
A penetration test report should contain six parts: an executive summary, the scope and its limits, the method, the findings, a fix for each finding, and a record of who wrote it.
| Part of the report | What it should tell you | Benchmark |
|---|---|---|
| Executive summary | Whether the testing met the agreed scope, the overall security posture of what was tested, the worst impact the testers achieved, the key findings and the key recommendations, in language a non-technical reader can use | CHECK Standard, para 37e |
| Scope and limitations | Why the test was run and what it aimed to do, the dates, which hosts or address ranges were in and out, any sampling, any changes during testing and any restrictions you imposed | CHECK Standard, para 39 · NCSC |
| Method | The types of test run, the test basis (how much the testers were told) and how far automated tools were used | NCSC · CHECK Standard, Annex A |
| Findings | Each issue, confirmed rather than guessed, with its impact on your organisation, a risk rating, the affected hosts and ports, and similar issues grouped together | CHECK Standard, paras 40–42 · NCSC |
| Recommendations | A fix for each finding that fits your environment, favours no vendor, and comes with an alternative if the full fix can’t be done in a reasonable time | CHECK Standard, para 43 · NCSC |
| Authorship and handling | Who wrote the report and who signed it off, with no passwords or personal data in the body | CHECK Standard, paras 37c–d |
The NCSC’s own guidance on penetration testing (opens in a new tab) (published August 2017, reviewed January 2022) sets a shorter list for any report. Alongside the issues found, a risk assessment for each and a way to resolve each, it asks for two things most buyers never think to look for. One is an opinion on how accurate your own vulnerability assessment turned out to be. The other is advice on improving your internal vulnerability assessment process.
Those last two tell you whether the test made you better at finding problems yourself, which is the point. The NCSC’s ideal is that you already know what the testers will find before they find it, and a test that only confirms your own list is a good result, not a wasted one.
A report usually arrives with a debrief, or should. The NCSC notes that a debriefing, where the testers walk through their findings and you ask questions, can be useful. Ask for one when you book the test, not after the report lands. How the test itself was run belongs to our guide to penetration testing methodology.
Seven Tests of a Good Penetration Test Report
Judge a penetration test report on seven tests, starting with the one most reports fail: whether your team can fix each finding from what’s written.
1. Can Your Team Fix Each Finding From What’s Written?
A finding your team can’t act on is a finding that won’t get fixed. Think of an MOT. An advisory that says “tyre worn close to legal limit, nearside front” tells you which tyre and what to do about it. One that says “tyres” doesn’t.
The CHECK Standard (para 43) holds recommendations to seven requirements. Each must be accurate, set out technical controls as steps where it can, and point to further information. It must stay vendor-neutral with an eye on value for money, fit your environment, and generally avoid blanket advice. And where the full fix can’t be done in a reasonable time, it must offer an alternative. That last one matters more than it looks, because “upgrade the whole platform” is often correct and rarely possible by Friday.
My dishwasher’s manual has a table of every error code it can show, rated by seriousness, and not one line on what to do about any of them. Some penetration test reports read exactly the same.
2. Is Every Finding Rated for Your Organisation, Not Just Scored?
A score measures the vulnerability. A risk rating measures what it means for you. They’re different numbers, and a good report gives you both.
Most reports use the Common Vulnerability Scoring System (opens in a new tab) (CVSS), a numerical severity score. The NCSC notes that testers often use it at the customer’s request. CHECK reports go further: they must rate risk as HIGH, MEDIUM, LOW or INFORMATIONAL, with CVSS allowed “in addition to (but not in place of)” that rating, according to the NCSC (opens in a new tab). The CHECK Standard (para 42) says the rating should combine the CVSS severity with the impact on the customer and any mitigations already in place.
The NCSC adds that any departure from a finding’s standard rating should be documented and justified by the testing team. So when a report downgrades something, look for the sentence that says why. If it isn’t there, ask. We’ll cover the scoring itself in our guide to CVSS scores.
3. Does it Say What Wasn’t Tested?
Every penetration test has limits, and a good report writes them down. What wasn’t tested is often more useful than what was, because it’s where your next test starts.
The CHECK Standard (para 39) lists what the scope section should cover: the reason for the test and its aim, the dates of testing, the hosts or ranges in and out of scope, any sampling, any changes to the boundaries during testing, and any restrictions you imposed. CREST’s Defensible Penetration Test guidance (opens in a new tab) (June 2023) asks its reports for “A statement of totality against the defined scope”, meaning how much of the scope the testing actually covered.
Two situations should always leave a trace. If the testers found systems outside the scope that affect it, the NCSC says the exclusion can be recorded as a limitation on testing. And under the CHECK Standard (para 15), if a customer insists on a test the provider thinks is inappropriate, the provider must record its advice and the customer’s decision in the report. A report with no limitations section at all hasn’t had a perfect test. It just hasn’t told you. The agreement behind all this is set before testing starts, in the penetration test plan.
4. Are the Findings Confirmed, With Evidence?
A finding should say what the testers actually proved, not what a tool guessed. The CHECK Standard (para 40a) requires testers to confirm a vulnerability is present wherever possible and keep generalisations to a minimum.
Evidence is how you tell the difference. A confirmed finding shows what the tester did and what came back, so your team can reproduce it and check their fix. A finding that reads “the host may be vulnerable to…” is a scanner talking.
The CHECK Standard’s annex on infrastructure testing (para 49) is blunt about this: “heavy reliance on such tools without providing sufficient interpretation will not meet CHECK standards”. Scanning tools are fine. Pasting their output into a report and calling it a penetration test isn’t. The difference between the two services is covered in vulnerability scan vs penetration test.
5. Can a Non-Technical Reader Act on the Executive Summary?
The executive summary is for the people who decide, not the people who fix, and it should read that way. The CHECK Standard (para 37e) requires one aimed at a non-technical audience, covering four things:
- how the testing met the agreed scope
- the overall security posture and the worst impact the testers achieved
- the key technical findings and what they mean
- the key recommendations, relevant to your environment and constraints
If your Board can’t tell from the first page whether things are broadly fine or broadly not, the summary has failed, however good the rest is. Reading the whole report without a technical background is the subject of our guide to reading a penetration test report.
6. Is it Structured So You Can Plan the Fixes?
A report should be laid out for the person planning the remediation, not in the order the testers happened to find things. The CHECK Standard (para 37f) says so in almost those words.
In practice that means three things. Similar findings grouped together (para 40e), so twelve missing patches become one job, not twelve. Every affected host named, with the ports where relevant, and long lists moved to an appendix (para 40d). And a summary table you can turn straight into tickets. Deciding what to fix first is its own problem, covered in prioritising penetration test findings.
7. Does it Say Who Tested, and Under Which Accreditation?
A report should name the people behind it. CHECK reports must name the author and the Primary CHECK Team Leader, who signs the report off (CHECK Standard, para 37c).
Accreditation shows up in the report too. CREST’s Code of Conduct (opens in a new tab) (v26, September 2024) requires a member company to state clearly in the report when a service it delivered isn’t covered by its CREST accreditation (clause 4.3.18). If you bought a CREST test, that’s worth checking. Choosing a provider on accreditation in the first place is covered in our 15 questions to ask a penetration testing company.
What Each Reader Needs From a Penetration Test Report
One report has at least four readers, and each needs a different part of it first.
| Reader | Reads first | Needs to decide | Deciding question |
|---|---|---|---|
| Board or director | Executive summary | Whether the risk is acceptable and what fixing it will take | “What’s the worst that could happen, and are we fixing it?” |
| IT manager | Findings summary and recommendations | Who fixes what, and in what order | “Can I plan the work from this?” |
| Developers and system administrators | Individual findings, affected hosts, evidence | How to reproduce each issue and prove the fix | “Can I reproduce this and test my fix?” |
| Auditor, insurer or customer | Scope, dates and the summary of findings | Whether the test covered what they care about, and when | “Did this cover our systems, and how recently?” |
For the Board
The Board needs one page and a straight answer. If the executive summary does its job (test 5), that’s all most directors will read, and that’s fine. What they should also get is a date by which the serious findings will be fixed. That date comes from you, not the testers.
For the IT Manager
The IT manager is usually the report’s real owner. The findings summary and the recommendations are the working documents. Test 6 matters most here: a report grouped by type and listing every affected host is a plan. One sorted by the day each issue was found is homework.
For Developers and System Administrators
The people doing the fixing need the detail: the evidence, the affected hosts and ports, and the steps. If they can’t reproduce a finding, they can’t prove they’ve fixed it, and the retest will say so.
For Auditors, Insurers and Customers
Outside readers usually want proof that a test happened and what it covered, not the full findings. The scope section and the dates answer that. Because a CHECK report must leave out passwords and personal data (CHECK Standard, para 37d), a well-written report is easier to share safely. Who may see it is a contract question, covered in our guide to penetration testing contract terms. Using the report as evidence is the subject of a separate guide on penetration test evidence for auditors, insurers and clients.
What to Do After the Penetration Test Report Arrives
Treat the report as input to your own risk decisions, not as the decision itself. The NCSC is explicit that “risk assessment and decisions on the application of fixes are your responsibility.”
Hold the debrief whilst the testing is fresh. Walk through the findings with the testers and ask about anything unclear. The questions you don’t ask now tend to surface at the retest.
Re-rate the findings for your business. The NCSC points out that testers may not know everything about a system or the business impact of an attack, so they may rate issues lower or higher than you would. It’s equally clear that this review is for understanding the risk, not for talking findings down.
Look hardest at what you didn’t know. The NCSC says findings that were previously unknown to you deserve special attention, with the aim of spotting that kind of issue yourself next time. That’s the finding that says something about your own processes, not just your systems.
Choose the fix, not just the suggested fix. The testers’ recommendation may not be the only answer. The NCSC’s own example is a patch recommendation where uninstalling unneeded software, adding other controls or extra monitoring might reduce the risk just as well. Take advice from your own technical staff and suppliers.
Retest what you fixed. A fix nobody has checked is a hope. Agree the retest before the report arrives, ideally in the original contract, and ask for a short retest report that updates the status of each finding. The retest itself is the last part of our series, remediation and the retest.
Feed the results into your vulnerability management. The NCSC recommends your vulnerability management group assesses the report in the same way as the results of an internal vulnerability assessment. The report is a check on that process, not a substitute for it. How often to repeat the whole exercise is covered in how often you should do penetration testing.
Warning Signs of a Weak Penetration Test Report
A weak penetration test report usually shows itself in the first ten pages. Six signs are worth looking for:
- No limitations section, or one that says there were none.
- Every finding carries a CVSS score and nothing else, with no view of what it means for you.
- Recommendations that could apply to anyone, such as “apply the latest patches” or “follow best practice”.
- Page after page of tool output with little interpretation.
- Findings written as possibilities (“may be vulnerable”) rather than confirmed results.
- Passwords, personal data or other sensitive material in the body of the report.
Each maps to one of the seven tests above, and each is fixable if you raise it with the provider before the engagement is closed. A longer look at what a report should never look like is in bad penetration test reports.
Penetration Test Report FAQs
Should a Penetration Test Report Include CVSS Scores?
Usually, yes, but not on their own. CVSS measures how severe a vulnerability is in general. A good report adds a risk rating for your organisation, as CHECK reports must, combining that severity with the impact on you and the controls you already have.
Who Owns a Penetration Test Report, and Can You Share It?
Your contract decides, so check it before testing starts. Most buyers expect to own the report and to share it with auditors, insurers or customers, and the contract should say so. A report with no passwords or personal data in it is much easier to share safely.
How Is a Penetration Test Report Different From a Vulnerability Scan Report?
A vulnerability scan report lists what an automated tool detected. A penetration test report says what a tester confirmed, what it means for you and how to fix it. If a report is mostly scanner output with little interpretation, it’s closer to a scan report whatever it’s called.
Should You Ask to See a Sample Penetration Test Report Before Buying?
Yes. Any established provider should be able to show you a sanitised example. Read it against the seven tests above, and above all check whether someone on your team could fix a finding from it.
Before You File Your Penetration Test Report
Read the report against the seven tests in the first week, whilst the testers still remember your systems. Anything missing is easier to get added then than after the engagement is closed. If you’re comparing providers rather than reports, the report line in our guide to comparing penetration testing quotes is the place to start.
If you’ve got a report from any provider and you’re not sure it passes, do get in touch. We’ll tell you what we’d have expected to see, even if the test wasn’t ours.
The test finds the problems. The report decides whether anyone fixes them.