How to Read a Penetration Test Report UK — A Plain-English Guide for Non-Technical Managers

You Have the Report. Now What?

A penetration test report arrives as a PDF — sometimes 30 pages, sometimes 150. It is written primarily for technical audiences: developers, security engineers, DevOps teams. If you are a business owner, operations director, or non-technical manager who commissioned the test, reading it can feel like staring at a foreign language.

This guide explains how to read a penetration test report, what each section actually means, and how to decide what to do next.

The Structure of a Penetration Test Report

Most reputable UK penetration testers follow a standard report structure. You will typically find:

**Executive Summary** — Written for non-technical readers. This is where you start. It summarises what was tested, the overall security posture, the headline findings, and the key recommendations. If the report does not have this section, ask your testing firm for one.

**Scope and Methodology** — What was included in the test (which URLs, which IP ranges, which user roles), what was excluded, and which testing methodology was followed (OWASP, PTES, CHECK). This matters because a test that only covered your marketing site is not a test of your customer portal.

**Findings Summary** — A table or list of all vulnerabilities found, typically with severity ratings and page references. Use this as your index.

**Detailed Findings** — One section per vulnerability, with full technical details, proof-of-concept reproduction steps, screenshots or HTTP request/response examples, and remediation recommendations.

**Appendices** — Raw tool output, full request/response logs, or supporting technical evidence. Usually only relevant to developers implementing fixes.

Understanding Severity Ratings

Every finding is assigned a severity rating. There are several scales in use — CVSS (Common Vulnerability Scoring System), a simple Critical/High/Medium/Low/Informational scale, or a risk-based rating that factors in both likelihood and impact. Most UK reports use one of these:

**Critical** — The vulnerability can be exploited immediately, without authentication, and results in complete compromise of data or systems. Examples: unauthenticated SQL injection exposing your entire database, remote code execution. Fix within 24–48 hours.

**High** — Serious vulnerability requiring either some authentication or some user interaction to exploit, but with significant impact. Examples: authenticated SQL injection, stored XSS that executes for all users, broken access control allowing one customer to view another's data. Fix within one week.

**Medium** — Moderate vulnerability where exploitation is limited, impact is partial, or exploitation requires specific conditions. Examples: reflected XSS, missing CSRF protection on non-critical functions, weak session token entropy. Fix within 30 days.

**Low** — Minor issues with limited exploitability or impact. Examples: missing security headers, verbose error messages, low-risk information disclosure. Fix as part of normal development cycles.

**Informational** — Observations that are not vulnerabilities but represent best-practice gaps or potential future risk. Examples: use of outdated but not yet vulnerable software versions, configuration choices that reduce defence in depth. Address in longer-term roadmap.

Understanding CVSS Scores

If your report uses CVSS scores, each finding has a numerical score from 0 to 10:

- 9.0–10.0 = Critical - 7.0–8.9 = High - 4.0–6.9 = Medium - 0.1–3.9 = Low

CVSS scores are calculated from several factors: how complex is the attack? Does it require authentication? What interaction from a user is needed? What is the impact on confidentiality, integrity, and availability? A score of 9.8 means the vulnerability is straightforward to exploit with no authentication and causes complete data compromise.

Be cautious about CVSS in isolation. A CVSS 7.5 vulnerability on your internal admin tool used only by two people is less urgent than a CVSS 6.0 vulnerability on a checkout page processing thousands of transactions a day. Context matters — the CVSS score measures inherent vulnerability severity, not business risk.

How to Prioritise Remediation

Read the executive summary first. It should tell you the one or two things you need to fix immediately.

Then work through findings in this order:

1. **Critical findings** — Fix now. These represent immediate, exploitable risk. If you have a critical finding, your developer or IT team should be aware of it today, not next sprint.

2. **High findings** that affect systems handling payment data, personal data, or authenticated user sessions — Fix this week.

3. **High findings** on lower-risk systems — Fix within a month.

4. **Medium findings** — Schedule for the next development sprint.

5. **Low and Informational** — Address during routine maintenance.

Ask your testing firm which finding concerns them most if you can only fix one thing first. They have context you may not have from reading the report alone.

What to Ask Your Developer

When you hand the report to your development team, useful questions to ask:

- **Which findings are you planning to fix first and by when?** Get specific dates, not "soon." - **Are any of these findings related to each other?** Chained vulnerabilities sometimes have a single root cause that fixing once addresses multiple findings. - **Are there any findings you do not understand or disagree with?** False positives happen. If your developer thinks a finding is wrong, ask them to raise it with the testing firm directly. - **Do any findings require infrastructure changes rather than code changes?** Some fixes (firewall configuration, server hardening) fall to hosting or DevOps rather than application developers.

Verification and Retesting

A good penetration test report includes a retesting offering or recommends a retest after remediation. This matters. Remediation can introduce new vulnerabilities if not done carefully, and sometimes fixes are incomplete.

Automated scanning is an efficient way to verify that common fixes were implemented correctly. After your team says a finding is fixed, running Yrzo AI's automated scanner against the same application checks the vulnerability classes that were found and confirms the fix is in place — at £399 per scan, far cheaper than a full manual retest for verification purposes.

The Report Is the Start, Not the End

Receiving a penetration test report is not the end of a security exercise — it is the beginning of a remediation process. The most common mistake UK businesses make is filing the report, making a few fixes, and not following up.

Keep the report. Track remediation progress against each finding. Schedule a follow-up scan or retest. The report has value as a benchmark — your next test should show fewer findings and lower severity than this one.