How to Write a Penetration Testing Report (Structure + Template) The client never watches you work — they read the document

What Goes Into a Penetration Testing Report?

A penetration testing report has four parts: an executive summary for management, the scope and methodology, the detailed findings with evidence and severity, and remediation guidance. The Penetration Testing Execution Standard splits the same material into an executive section and a technical section. Everything else in a report supports one of those four jobs.

Hold that four-part shape in your head while you write, because it maps onto two completely different readers. The executive summary is read by someone who controls a budget and will never open the technical half. The findings are read by the developer or sysadmin who has to change something by Friday. Writing one document for both is the actual skill.

Why Does the Report Decide Whether You Get Hired?

The report is the only part of a penetration test a client ever sees, which is why interviewers ask for a writing sample. On 24 September 2026 Naukri listed 487 penetration testing vacancies in Hyderabad and Secunderabad. Across the twenty listings on page one, not one skill tag named report writing or documentation.

We went looking for that on purpose. The skill tags on those listings name tools relentlessly — Burp Suite, Nmap, Nessus, Kali Linux, OWASP, OSCP, CEH, SQLMap, Metasploit. Not one named the deliverable. And yet every one of those roles ends each engagement by producing a document, and the two exams Indian employers name most, OSCP and PNPT, both fail candidates on the report rather than the exploitation.

There is a practical reading of that 487-to-14 gap. Very few Hyderabad employers will hand a fresher a live client engagement. What they will do is read a portfolio. Three well-written reports on machines you solved yourself is the cheapest way an inexperienced candidate has ever had to demonstrate judgement, and it is the one thing a certificate cannot show. Our guide to becoming a penetration tester covers the rest of that path.

What Is the Standard Structure of a Penetration Testing Report?

Use the Penetration Testing Execution Standard: an executive summary covering background, overall posture, risk ranking, general findings, recommendation summary and strategic roadmap, then a technical report. The technical half runs from introduction and information gathering through vulnerability assessment, exploitation, post-exploitation, risk and exposure, and a conclusion. Thirteen sub-sections, in that order.

Naming PTES in your methodology section does something small and useful: it tells a reviewer you are following a published standard rather than improvising, and it saves you from inventing a structure under deadline pressure. Most consultancy templates in India are recognisably PTES with the headings renamed.

How Do You Write the Executive Summary?

Write the executive summary last, in plain business language, for a reader who will never read the technical half. Keep it to one or two pages. State why the test happened, what the overall security posture looks like, how many findings fell into each severity band, and what the three highest-priority fixes are.

The failure mode here is predictable and it is always the same: the tester writes the summary in tester vocabulary. “We achieved NT AUTHORITY\SYSTEM on the domain controller via a Kerberoasting attack against an over-privileged service account.” Accurate, and useless to the person deciding whether to approve a budget. The business version is “a weak service-account password let us take full control of the system that manages every employee login, in under two hours.”

What Does a Single Finding Look Like, Written Properly?

A complete finding has nine parts: title, severity and CVSS vector, affected asset, description, business impact, proof of concept, steps to reproduce, remediation, and references. Miss any one and the developer who has to fix it will come back with a question. The comparison below shows the same SQL injection written badly and then properly.

This is the section every guide on the first page of Google describes and none of them demonstrates. So here is a real one, in the two versions we see most often when students submit their first capstone report at our KPHB campus.

One rule underneath all nine: write the finding so that it survives you leaving the company. Six months later, nobody will be around to explain what you meant. Everything needed to understand, reproduce and fix the issue has to be on the page.

How Do You Rate Severity Without Getting It Wrong?

Score every finding with CVSS v4.0, then adjust the business risk separately. FIRST’s specification sets five bands: None at 0.0, Low from 0.1 to 3.9, Medium from 4.0 to 6.9, High from 7.0 to 8.9, and Critical from 9.0 to 10.0. CVSS measures technical severity, not what the asset is worth.

That last sentence is where most arguments with a client start. A CVSS 9.8 on a staging server nobody can reach from the internet is less urgent than a 6.5 on the payment page. Professional reports handle this by carrying two columns: the CVSS score, which is objective and reproducible, and a risk rating that takes exposure and asset value into account. Show both, and say which one drove your ordering.

What Evidence Should You Include, and What Must You Leave Out?

Include enough evidence for someone else to reproduce the finding, and redact everything that would turn the report into an attack manual. Screenshots with the URL bar visible, the exact request and response, and timestamps all help. Full password hashes, complete customer records and working exploit chains against live production do not.

Remember where the document ends up. It gets emailed, forwarded to a vendor, attached to a compliance file and occasionally uploaded to a shared drive with loose permissions. Treat every page as though it will be read by someone you did not intend. Mask the middle of a hash, blur customer names, and show the proof of exploitation rather than the payload that achieves it when the payload adds nothing.

How Do You Write Remediation Advice Developers Will Actually Use?

Give the specific fix for the specific code or configuration, not a link to a generic best-practice page. Name the parameter, the file, the setting or the version to upgrade to. Add a short-term mitigation the team can ship this week, and a permanent fix, and say which one you are recommending.

“Implement input validation” is not remediation advice. It is a category. The developer reading it already knows input validation exists; what they do not know is which of the four places that parameter is handled needs changing. If you cannot name the place, say so honestly and describe how to find it — that is still more useful than a cheat-sheet link.

Two extras separate a good remediation section from a great one. The first is a retest note: state what you would need to see to consider the finding closed. The second is an honest effort estimate — a configuration change, a library upgrade, or an architectural change — because that is what determines whether the fix gets scheduled or quietly deferred.

What Is Different About a VAPT Report in India?

Indian reports often have to satisfy a regulator as well as the client, which fixes parts of the format for you. BSE India publishes a prescribed VAPT Report Format that market entities submit on the auditing organisation’s letterhead, and CDSL carries the same format. CERT-In empanelment of the testing firm is the usual credibility requirement.

Not one page ranking for this search in India mentions any of that, because they are all written for a consultancy audience in the United States. If your first real report is for an Indian bank, broker, depository participant or listed company, the shape of the document is partly decided before you write a word of it.

None of this changes the craft. The executive summary, the nine-part finding and the evidence rules are identical. What changes is that a second reader with no interest in your technique is checking whether the paperwork holds up, and that reader is unforgiving about missing dates, missing signatures and missing closure status. If you want the wider context first, our explainer on what VAPT actually involves covers the assessment phases that feed this document.

What Are the Most Common Mistakes in a First Pentest Report?

The five that show up most often are raw scanner output pasted in, no business impact, severity copied from the tool, missing reproduction steps, and an executive summary written in tester vocabulary. All five are fixable in an afternoon. None of them are about your technical ability, which is why they are so frustrating to lose marks on.

There is a sixth that is less obvious and costs more: writing the report at the end. By the time you sit down, the details are gone — which port, which payload worked on the third attempt, what time you got the shell. Professional testers write as they go, into whatever tool they trust, and assemble afterwards. The habit is worth more than any template.

How Good Is Your Draft Report Right Now?

Twelve checks separate a report a client will act on from one that gets filed and forgotten. Run them against your own draft, or against a sample report an institute shows you. The scorecard below scores as you tick. Nothing is stored and nothing is sent anywhere; it runs entirely in your browser.

How Do You Practise Report Writing Before You Have a Client?

Write a full report for every lab machine you solve, using the same template you would use for a paying client. OffSec publishes a sample PWK report, and TryHackMe runs a free room on pentest reporting. Three finished practice reports in a GitHub portfolio beat a certificate with nothing behind it.

Make it harder on purpose. Solve the box, wait two days, then write the report from your notes alone without touching the machine again. Whatever you cannot reconstruct is exactly what your note-taking is missing, and you will only find that out by being unable to write the sentence.

Read other people’s reports too. There is a well-known public repository of real penetration test reports published by consulting firms, and reading three of them side by side teaches tone faster than any guide — including this one. Notice how short the findings are, how plain the language is, and how little of the document is about the exploit.

Where Does Report Writing Sit in the AimNxt VAPT Curriculum?

Report writing is Module 15 of the AimNxt VAPT & Ethical Hacking programme, and the four-month course ends in a capstone that is delivered as a professional report and a presentation. Module 15 covers professional penetration testing reports, vulnerability documentation, executive summary writing, remediation recommendations, and building a GitHub portfolio.

We put it at the end deliberately, because you cannot document findings you have not learned to produce. The fourteen modules before it exist to give you something worth writing up; the capstone then forces you to do the whole cycle once, under review, before anyone asks you to do it for a client.

Two things we will not claim. AimNxt is an independent training provider, not a certification body — EC-Council, OffSec and CompTIA set, mark and issue their own exams, and we prepare you for them; what you receive from us is an AimNxt certificate of completion. And the AimNxt Job Interview Guarantee program guarantees interview opportunities through our hiring-partner network, not a job offer or any salary. What happens in the interview depends on your skills, your portfolio and your performance on the day — which, for this role, largely means your reports.

If you are still deciding which exam to aim at, our comparison of VAPT certifications for 2026 covers CEH, OSCP, eJPT and PNPT, and our guide to the types of penetration testing explains which engagement type produces which kind of report.