How to read a pen test report without a security degree.

The report only makes sense once you know what produced it. Four things get mixed up.

• Penetration test. The UK National Cyber Security Centre (NCSC) describes it as gaining assurance by "attempting to breach some or all of that system's security", using the tools and techniques an adversary might. NIST SP 800-115, the US government's 2008 guide to security testing, covers how such tests are planned and run, and NIST's glossary summarizes it as security testing in which evaluators "mimic real-world attacks".
• Vulnerability scan. An automated tool checks systems against a list of known weaknesses. The NCSC says scanning "cannot compare to manual processes such as penetration testing" for breadth and depth, but it is a cost-effective way to catch common issues often. Scanners can also report problems that do not exist, called false positives.
• Red team exercise. The NCSC calls this adversary simulation. It focuses on "the efficacy of an organisation's technical controls and detection", while a pen test is "more focused on identifying all technical vulnerabilities". A red team gets only minimal starting information, and its report shows how weaknesses were combined to reach a goal rather than listing every flaw. NIST's glossary adds that a red team's aim is to show the impact of successful attacks and what works for defenders.
• Bug bounty. A standing offer to pay outside researchers for valid vulnerability reports. It is continuous and open-ended, with no fixed report for you to read. It usually sits alongside a published disclosure policy: see the NCSC's Vulnerability Disclosure Toolkit. CISA's template notes that a basic disclosure policy does not promise payment, and that bounties are a separate, optional program.

Formats vary, but the community-maintained Penetration Testing Execution Standard (PTES) splits reporting into two parts for two readers: an executive summary for people who run the program and a technical report for the people who will fix things. The OWASP Web Security Testing Guide, a free manual for testing websites and APIs, also has a reporting section. Here is what each part should do for you.

1. Executive summaryWhy the test was done, how it went overall, the overall risk, the headline findings and a prioritized plan. You should be able to read it in five minutes and know what to ask for budget for.
2. Scope and datesWhich systems, apps and accounts were tested, what was excluded, who approved it and the test window. Without this you cannot tell what the clean parts really cover.
3. MethodologyThe standards followed, such as PTES, the OWASP guide or NIST SP 800-115, and what the tester could see: no information, a normal user account, or full documentation.
4. FindingsOne entry per problem: what it is, where it is, how it was found and what an attacker could do with it.
5. EvidenceScreenshots, request and response samples or logs that prove the finding is real. PTES describes confirming vulnerabilities and showing the business impact, such as access to critical data.
6. Risk ratingA severity for each finding and how it was decided. The NCSC says reports should rate each issue HIGH, MEDIUM, LOW or INFORMATIONAL, may add CVSS scores, and should document and justify any departure from a standard rating.
7. RemediationA specific fix for each finding. The NCSC adds that you should not assume the suggested fix is the only option, since removing unneeded software or adding monitoring can also work.
8. RetestA later check that the fixes worked, with results added to the report or issued as a short addendum.

Most reports use the Common Vulnerability Scoring System, or CVSS. The CVSS 4.0 specification from FIRST, the forum that maintains it, bands scores as None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0).

That number is a starting point. The base score describes the flaw itself, as seen by whoever maintains the affected software. FIRST says people who use CVSS "should enrich the Base metrics" with threat metrics, which reflect how attackers are using a flaw over time, and environmental metrics, which reflect your own controls and how important the asset is. It also describes the score as the severity of a flaw relative to other flaws, and places wider organizational factors outside CVSS's scope.

Two free sources help add that context.

• EPSS, the Exploit Prediction Scoring System, is a statistical model that estimates the probability that a published vulnerability will be exploited in the wild in the next 30 days. It applies to known, catalogued vulnerabilities (those with a CVE number). A flaw in your own custom code will not have one.
• The CISA Known Exploited Vulnerabilities catalog lists flaws that attackers have used in real attacks. CISA advises organizations to use it "as an input" to their prioritization, not as the whole process. A KEV listing moves a finding up your list quickly.

Your own facts do the rest. Is the system reachable from the internet? Does it hold customer data, payment details or the keys to other systems? Would the fix break something important?

This finding is invented for illustration. It does not describe a real client, and the score is a made-up figure to show the layout. Real reports differ in format but should carry the same elements.

• Title and ID: F-03, Password reset links can be reused. Plain, specific and numbered so you can track it.
• Severity: High, illustrative CVSS 7.5. Check that the report states how it arrived at the rating.
• Where: the customer portal, the password reset page, tested on the staging copy on the dates in the scope section.
• What the tester did: requested a reset link for a test account, used it once, then used the same link again an hour later. Both worked.
• Evidence: two request and response captures with timestamps, and a screenshot showing the second login.
• Impact: anyone who finds an old reset email, for example in a shared mailbox, could take over that account. The tester did not access real customer data.
• Fix: expire a reset link after one use and a short time, and invalidate older links when a new one is requested.
• Retest note: blank until the fix is deployed. Later it should say "Fixed, verified" with a date, or "Not fixed" with the new evidence.

Now apply your context. If the portal holds invoices and personal data and is on the internet, this goes near the top of your list. If the same flaw sat in an internal tool used by three people, you might schedule it. Either way, you can decide, because the report gave you evidence and a fix.

The NCSC notes that test quality "depends heavily" on the skill of the testers, and for UK government and critical national infrastructure work it points to its CHECK scheme of assured providers. Outside those sectors you judge by the report. A good one reads like a clear account from someone who tried things and watched what happened. A weak one reads like a printout.

• Scope, dates and tester namedYou can tell what was tested, when and by whom, and what was left out.
• Every finding has proofEvidence a developer can reproduce, not just a title and a score.
• Impact in business termsWhat an attacker could reach, such as customer records, money or admin access.
• Fixes you can act onSpecific steps, with alternatives where the obvious fix is hard.
• Ratings explainedThe report says how severity was set, and why any score was changed.
• Positive results tooWhat was tested and held up, so you do not have to guess what was missed.

Red flags:

• Scanner output pasted in. Pages of tool logs with no human analysis suggest a scan sold as a pen test. The NCSC tells buyers of scanners to check how often they report problems that do not exist.
• No proof of exploitation. "May be vulnerable" is a scanner's phrase. A pen test should show what was actually done.
• No scope, dates or method. You cannot rely on a result you cannot place.
• Every finding is Critical, or none is. Both suggest ratings were not thought through.
• No retest offered. You will have nothing to show that fixes worked.
• Generic advice. "Apply patches" repeated on every page is not a recommendation.

The NCSC says a debrief meeting with the testers is useful. Use it. Bring the people who will do the fixing, and ask:

• What would an attacker do first, and what could they reach in one day?
• Which three findings would you fix first here, and why?
• Which findings did you chain together to reach more than any one gave you alone?
• What did you not test, and what could not be tested in the time?
• Did you change anything, create accounts or leave test data behind that we should clean up?
• Which ratings did you adjust from the default score, and what was the reasoning?
• Can a developer ask you questions while fixing, and for how long?
• What does a retest cover, when can it happen and is it included in the price?

The NCSC is blunt that "risk assessment and decisions on the application of fixes are your responsibility", and that mitigation should not be left wholly to the test team. A simple routine:

• Sort every finding into three groupsFix now, fix on a date, or accept with an owner and a review date. Use the severity score plus your own context, and check KEV for anything with a known CVE.
• Give each item one owner and one dateA shared spreadsheet is enough. Findings with no owner are the ones that return in next year's report.
• Fix the cause, not just the exampleIf one form lacks a check, others may too. Ask the developer to look for the same pattern.
• Look at alternatives where a fix is hardThe NCSC lists removing unneeded software, adding other controls or increasing monitoring as options.
• Retest the fixesAsk the tester to confirm each one, and record the result against the finding.
• Keep the trailReport, ticket, change record and retest result, together. This is what you will show an auditor.

Enterprise buyers and auditors increasingly ask for evidence that you test your security, often in a questionnaire. What to hand over is your decision, within your contract.

• Do not send the full report casually. It lists weaknesses in detail. If a buyer insists, offer a call, a supervised read or a copy under a non-disclosure agreement.
• Ask the tester for a summary letter or attestation. A one or two page statement on the tester's letterhead covering who tested, what scope, which dates, the method and the overall result, with a note on whether findings were fixed and retested. Ask for this when you sign the engagement, since not every tester issues one by default.
• Be honest about open items. "All critical and high findings fixed and retested, two low items accepted with a review date" is a strong answer. "Zero findings" looks suspicious.
• Know the formal frameworks. Audit frameworks such as SOC 2 and ISO 27001 are where these requests often come from. See our comparison, ISO 27001 vs SOC 2: which first, and check with your auditor which report they will accept, since this varies.

The buyer on the other side is often asking a related question: how safe is the vendor they are trusting? Our vendor risk checklist shows the questions from their side.