Key takeaways
- The report is the deliverable. Everything else in the engagement is method, and the document is the only artefact that outlives the access.
- A finding is complete when someone who was not on the test can reproduce it, understand what it costs you, and fix it without asking a question.
- A CVSS base score describes the flaw. It does not describe your exposure until someone applies the environmental metrics to your deployment.
- Ask for the draft and read it as an assessor would. An unreproducible finding, an unargued severity, or a remediation line reading 'apply vendor patch' are all things to send back.
The report is the thing you keep
A test ends. The access is revoked, the test accounts are closed, the testers move on to the next engagement. What is left is a document, and every decision you make afterwards comes out of it: which fix goes first, what the board is told, what gets handed to an assessor eighteen months later. That makes the report the product rather than a record of one.
NIST SP 800-115 treats it that way. Its assessment process runs planning, discovery, attack and reporting, and reporting is a phase with its own work rather than a summary typed on the last afternoon (NIST SP 800-115). When you buy a penetration testing engagement, you are buying that phase as much as the days on the keyboard, so it belongs in the statement of work with the same specificity as the target list.
One practical consequence: ask to see a redacted sample report before you sign, from work resembling yours. A firm that cannot produce one is asking you to buy the single part of the engagement you have no other way to inspect in advance.
The parts, and the question each one answers
Reports differ in shape and layout, and that matters less than it looks. What matters is that every question below has an owner somewhere in the document, because a question with no section is a question nobody answered. Scope itself is settled long before delivery, and how to scope a penetration test covers that half; the report's job is to restate the agreed scope accurately enough that a reader a year from now can tell what was never looked at.
The failure to watch for is a section that exists but says nothing. A methodology page listing tool names. An executive summary that restates the finding counts as sentences. A remediation column that says 'apply vendor patch' for a design flaw. Each of those passes a table of contents check and answers nothing, which is why the middle column below is the one to read the document against.
Read the table as a checklist for the draft rather than a template you impose on the tester. A firm with a house format that answers all six is fine. A firm whose format has no place for an attack narrative is telling you the findings will arrive as a list of unrelated items.
| Part | The question it answers | The thin version |
|---|---|---|
| Scope and dates | What was in reach, in what state, on which days | A product name with no environment, version or date |
| Methodology | How the testing was done, and against which published standard | A list of tool names |
| Executive summary | What a non-technical decision maker should do this quarter | The finding counts, restated in prose |
| Findings | What is wrong, what it costs, how to reproduce it, how to fix it | A severity label and a paragraph |
| Attack narrative | How separate issues chained into something worse than either | Absent |
| Retest terms | What happens after you fix it, and by when it is included | Absent, or a fresh quote |
One finding, written out
The unit of a report is the finding, so judge a report by one of them rather than by its page count. Below is a constructed example. It is illustrative and generic, not taken from any engagement, and it shows the fields a finding has to carry before it is usable.
Every row there is doing a distinct job. Prerequisites separate a flaw an anonymous visitor reaches from one that needs a valid account, which is often the whole of the severity argument. Reproduction lets your engineers confirm a fix rather than take it on trust. Impact is written in your terms, in your data, not in the tester's vocabulary. Remove any one row and someone has to send an email to act on the finding.
Traceability is the other half. The OWASP Web Security Testing Guide gives every test a stable identifier, in the form WSTG-ATHZ-02, so a finding can name the test that produced it and you can see which tests ran and returned nothing (OWASP WSTG). Coverage you can point at is what turns a list of problems into evidence, and it is a reasonable thing to require of an application-focused test.
| Field | What it says |
|---|---|
| Title | Horizontal authorisation bypass on the invoice detail endpoint |
| Affected | Invoice detail route, production API, tested 14 to 16 May |
| Prerequisites | Any authenticated tenant account. No administrative role needed. |
| What happens | The identifier in the path is trusted. Substituting another tenant's identifier returns that tenant's invoice, including bank details. |
| Reproduction | Four numbered steps, the exact request, both identifiers used, the response excerpt |
| Impact | Any customer can read every other customer's billing records. No privilege escalation required. |
| Rating | CVSS v4.0 vector, plus one line on why the environmental metrics move it here |
| Fix | Authorise on the object, not the route. Confirm the session's tenant owns the record before returning it. |
Severity is an argument, not a number
CVSS v4.0 separates its metrics into Base, Threat, Environmental and Supplemental groups for a reason. The base group describes the flaw as it exists in the abstract; the environmental group is where your deployment, your data and your compensating controls enter the calculation (CVSS v4.0 specification). A report that ships base scores alone has rated the software, not your exposure to it.
A finding rated High should therefore carry a sentence saying why it is High here. The same flaw, internet-facing and unauthenticated on the system holding card data, is a different number from the one it earns on an internal tool two people use. If the report will not make that argument, you will make it yourself, with less information than the person who ran the test had.
Rated output with no analysis behind it is the tell of a tool run sold as an engagement, which is the distinction drawn in penetration test or vulnerability scan. The presence of severity labels proves nothing on its own. A scanner emits those by default; what it cannot emit is the reason the label is right for you.
Evidence, and what happens after the fix
Evidence is quietly expensive to produce and quietly easy to leave out. A screenshot of a tool banner is not evidence. The request and the response, the identifiers used, the account it was performed under and the timestamp: that is what lets your team reproduce the issue on Monday without booking a call, and it is what makes a finding defensible if a supplier or an auditor questions it.
Ask for a weakness class alongside each instance. A CWE identifier (CWE) lets you sort findings by the mistake rather than by the host, and six findings sharing one identifier are one engineering decision rather than six tickets. On an infrastructure test that grouping is frequently the difference between patching thirty hosts and fixing the build image they all came from.
The retest belongs in the report as terms, not as a follow-up sale. Get it in writing: what a retest covers, how long after delivery it stays included, and whether you receive a reissued document marking each finding fixed, partially fixed or open. That reissued version is the one an assessor asks for, and it is the one that is awkward to obtain six months later if nobody agreed it up front.
Read the draft the way an assessor will
You should get a draft, and you should read it with three questions. Can an engineer who was not involved reproduce every finding from what is written here? Does every severity have a stated reason attached to it? Does anything in the document contradict the scope that was agreed? Send back what fails, in writing, while the report is still a draft, because a correction after delivery arrives as a second document that has to be filed next to the first.
Two further asks are worth making. First, whether the activity was noticed: a report that records no alert firing during the testing window is telling you something the finding list cannot, and it is the argument for a purple teaming exercise before another test. Second, ask for machine-readable output alongside the document, so the findings reach your tracker without a person retyping them and dropping the severity rationale on the way.
What the report has to survive in Dubai and Abu Dhabi
The report is the artefact a UAE regulator or a customer's procurement team actually sees, and it is read by people who were not in the room when the test ran. Banks and licensed financial institutions answer to the Central Bank of the UAE. Dubai government entities and the suppliers serving them work to the standard published by the Dubai Electronic Security Center. Abu Dhabi healthcare providers are held to ADHICS, and the Information Assurance Standards published federally by NESA apply more widely still. Four regimes that name security testing, four audiences for the same document.
In practice that means dates, scope and a named methodology, because the first question an assessor asks is what was tested and when. It means findings traceable to a fix, because the second question is what you did about them. And it means a retest record, because the third question is whether any of it is still true.
There is a difference between the two emirates worth planning for. A Dubai free zone company selling into a Dubai government customer will be asked for the report as part of supplier assurance, so the document leaves your organisation and what can be redacted matters at the point it is written. An Abu Dhabi healthcare provider is more often reading the same report against an internal control set, where traceability from finding to control reference is what saves the time. One test, two audiences, and the writing has to be clear enough that neither of them has to call you to understand it.
Frequently asked questions
How long should a penetration test report take to arrive?
Agree the delivery date in the statement of work rather than assuming one. A draft within one to two weeks of the final day of testing is a reasonable thing to negotiate for a short engagement, and critical findings should be reported on the day they are found rather than held for the document. A firm that will not commit to a date in writing has answered the question.
What should I do if a finding in the report cannot be reproduced?
Send it back before the report is finalised. A finding nobody can reproduce is either written badly or wrong, and either way it is the tester's to resolve. Ask for the exact request, the account used and the time it was performed. If it still does not reproduce, ask for it to be withdrawn or reclassified, because an unfixable finding sits open in your tracker indefinitely.
Is a CVSS score enough to prioritise remediation?
No. A CVSS base score describes the flaw in the abstract, and the environmental metric group is where your deployment, your data and your compensating controls change it. A report should show the vector and add one line explaining why the rating holds in your environment. Without that line you are prioritising someone else's risk in your own backlog.
Can I share a penetration test report with a customer or a regulator?
Often you will be asked to, so check what your contract says about disclosure before you do. The full report contains reproduction steps that work as instructions against your systems, so it is not a document to circulate freely. Ask the tester for a summary letter confirming the scope, the dates and the retest status instead; that answers a supplier assurance request without handing over anything exploitable.
