Penetration Testing Hub › Penetration Testing Explained
Sample Penetration Test Report
This page presents an example deliverable and carries no how-to steps — but the principle behind all our work still holds: legitimate testing only ever runs against systems the client owns or has authorised in writing, under the Criminal Justice (Offences Relating to Information Systems) Act 2017.
Almost no Irish provider will show you a report before you buy. We think that's backwards. The report is the entire product — everything else is process to produce it — so you should be able to see the standard before you spend a cent. Below is a redacted sample from a real engagement, and a guide to reading it.
Download the sample
It's fully redacted, with no real client, systems or data, but the structure, depth and tone are exactly what you'd receive. Open the sample report (PDF)
How to read a pentest report
A good report is built in layers, each for a different reader. Here's what to look for, and what its presence or absence tells you about the provider.
1. Executive summary
Plain language, for people who won't read the technical detail — your board, your directors. It should tell the story: what was tested, how bad the overall picture is, and the two or three things that matter most. If you can't understand the executive summary without a security background, the report has failed its first job.
2. Scope and methodology
What was tested, what wasn't, when, and following which methodology. This is what makes the test repeatable and defensible for compliance. A vague scope section is a warning sign.
3. Findings, rated by severity
The core. Each finding rated (usually CVSS), described in enough detail for an engineer, with the business impact spelled out. Look for prioritisation — a good report tells you what to fix first, not just an unranked list of everything.
4. Reproduction steps
For each finding, enough detail for your team to see it for themselves. This is where a real test separates from an automated scan — a scan says 'port open', a test shows the exact steps from that port to your data.
5. Remediation guidance
Specific, actionable fixes — not 'apply security best practice', but what to change and how. This is the part that actually improves your security.
6. The attack narrative
The best reports include the story of how findings chained together — 'from the guest network, to the print server, to the domain'. This is what a scan can never give you and what makes the risk real to a non-technical reader.
What a report should not be
- A raw scanner export with a cover page.
- An unranked wall of low-severity findings that buries the one thing that matters.
- So technical that no decision-maker can act on it, or so vague that no engineer can.
- Missing reproduction steps, so nobody can verify or learn from the findings.
- Silent on remediation and re-testing.
Why we publish ours
Two reasons. First, it's the honest thing to do — you're buying something you can't see until it's delivered, and that's an unfair position to put a buyer in. Second, we're confident in the standard. A provider who won't show you a sample is asking for trust they haven't earned. Read ours, compare it to anyone else's you can get, and judge for yourself.
If the sample looks like the standard you want, here's how a CyberLabs engagement works — and you'll receive a report built exactly like the one you've just read.
No prices on this page and no hard sell.
This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test. · ↑ Back to top