Anatomy of a Pentest Report

Clients do not pay for shells. They pay for the report. Every host you compromised and every clever pivot you pulled off is worthless to the organization until it is written down in a form they can understand and fix. Communicating your findings clearly is, bluntly, one of the most important things you do as a tester — and it is the part that most separates a professional from someone who simply knows how to run tools.

It is also a serious chunk of the job. Depending on who you ask and how the engagement is run, writing the deliverable can consume anywhere from 30% to 80% of the total time. If you scoped a week of testing and budgeted nothing for the write-up, you have mis-scoped the engagement. Treat the report as a deliverable with its own timeline, not an afterthought you cram in on the last afternoon.

Here is a thing that surprises newcomers: there is no official, universal standard for what a penetration-test report must contain or how it is laid out. No governing body publishes "the" outline. What exists instead is convergence — firms have independently arrived at very similar structures because the same structure keeps working. Established providers publish their own templates; the one used by the OSCP's makers differs in detail from the one used by other respected shops, but line them up side by side and the same bones show through.

Two consequences follow. First, nothing here is "right" or "wrong" in an absolute sense — the real test is whether the client can digest the information and whether your information is accurate. Second, because there is no standard handed to you, you build your own template and refine it engagement after engagement. The sections below are the common skeleton almost every good deliverable shares. Make them yours.

It is worth reading widely here. Pull a handful of published example reports from different firms, line up their tables of contents, and note what they share and where they diverge — that comparison teaches the shape of a report faster than any single template can.

A solid deliverable is built from a recognizable set of components. Each one answers a different reader's question, which is why each one is written in a different voice. Here is the skeleton, mapped to who it is for and what it is doing:

Two of these — the executive summary and the findings — carry the most weight and have their own lessons later in this phase. The executive summary is where you win or lose leadership's attention (08.03); the findings are where you prove you actually understood what you broke (08.02). The rest of this lesson covers the connective tissue between them.

The methodology section answers the questions every technical reader has: how did you go about this? What kinds of attacks were you most interested in? How much did you know going in? Be explicit about whether the engagement was black box (no inside knowledge), grey box (some), or white box (full access to documentation and source). Then list the desired actions concretely: identify live hosts, enumerate listening services, cross-reference reported software versions against known exploits, test authentication prompts for default credentials, and so on. A reader should be able to see the engagement's intent from this list alone.

The attack narrative is where the report briefly stops being a reference document and becomes a story. It should read like a short account that summarizes exactly what you did as an attacker, with specific details — describing, in linear fashion, how you went from a single foothold to control of the environment with nothing but a list of IP ranges to start from. The narrative is the section both audiences can follow: the executive gets the arc, the engineer gets the sequence. Whether you illustrate it with screenshots or keep it text-only is personal preference; what matters is that it is honest, specific, and linear.

The technical observations — the findings — are the substance of the report. Each documents a specific weakness, typically falling into one of three families: authentication, configuration, or patching. Because a finding has a strict internal anatomy of its own — title, severity, observation, impact, evidence, affected assets, recommendation — it gets the dedicated treatment of the next lesson. For now, just know that this is where most of the report's pages and most of its value live.

The appendices are supplemental, but they are not filler — they are where you put the material that supports the findings without cluttering them. Most deliverables carry four:

• Severity definitions — the scale you used, spelled out, so the client knows exactly what "High" means in your report.
• Hosts and services — a record of every host, port, and service you identified. This is the inventory the engagement was built on.
• Additional references — external links to authoritative standards and hardening guides from bodies like NIST, CIS, and OWASP, so the client can go deeper.
• Tools used — clients ask about this constantly. A one-page list of the tools you ran (and links to them) is an easy win that adds real credibility to the deliverable.

The NIST SP 800-115 technical-testing guide is a good external anchor for this structure, and severity throughout the report should lean on a single metric like CVSS — defined once in the appendix, used everywhere.

Knowing the sections is not the same as knowing how to fill them. A report does not get better by being stared at — it gets better through a deliberate process. A reliable one looks like this:

• Plan. Decide what this report needs and what it does not. Which sections apply to this engagement? What is in scope to write about?
• Review your captured detail. During testing you took notes and captured a great many screenshots. Go back through them and organize your thoughts before you draft — the quality of your notes sets the ceiling on the quality of your report.
• Rough draft. Get the large structure down. Categorize and summarize the key findings; do not polish yet.
• Revise. Dot the i's and cross the t's. Make sure each section is pitched at the right reading level for its audience — the executive summary must not read like the findings, and vice-versa.
• Organize and proofread. One last pass: eliminate redundancy, fix errors, and move anything non-critical out of the body and into the appendices.

Report writing is one of the places where AI is changing the job fastest. Because so much of a report is structured, repetitive prose — the same finding shapes, the same audiences, the same translation from technical detail to business language — it is exactly the kind of work large language models are good at accelerating. Teams are already wiring up pipelines that take raw notes and draft findings, or even whole report skeletons, automatically. Used well, this turns the slowest part of the engagement into a fast first draft.

With the skeleton in hand, the next lesson zooms into the single most important component: how to write a finding that a client can actually act on.