What a penetration test report should contain

A penetration test report is the document a testing team delivers at the end of an engagement. It states what was tested, which weaknesses were confirmed and how, how serious each one is, and what to fix first. The testing period depends on the agreed scope; afterwards, the report is what your team, your management and often your customers work from.

If your company commissions a test — because a customer, a partner bank or your own board asked for one — most of the work happens against your systems, on a schedule and with progress updates agreed before it starts. What stays is the document. Your IT team needs the evidence and the repair guidance; management needs the business impact and the proposed priorities; a customer or auditor uses it to confirm the test took place. Use this guide to agree what you will receive, and to review the report when it arrives.

What a penetration test is, and what it is not

"A test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system."

NIST SP 800-53 Rev. 5, glossary definition

The constraints are the scope and the rules you agree before testing starts. Circumventing means the tester does not stop at pointing out a possible problem; they try to use it, within those limits. That separates a penetration test from a vulnerability scan, which reports what might be wrong; we compared the two in vulnerability scan vs penetration test. The definition itself is in NIST's glossary.

It is not a certification either. A penetration test describes what a team found within a given scope and time. It does not declare a system secure, and a short list of findings — the security issues the team identified — describes what was found under those conditions rather than proving there was nothing else to find.

Types of penetration testing

Three scoping decisions shape a test: the target, the information the testers get, and who is told.

By target

• External: systems reachable from the internet, such as websites, mail servers and the VPN or remote-access portals your staff log in through.
• Internal: what someone already inside the network could do, for example from an employee's laptop.
• Web applications and APIs: the logic, permissions and data handling of a specific application.
• Social engineering: how people and processes respond, for example to a phishing email.

By what the testers know

• Black box: the team starts with little or no knowledge of the system's internals, like an outside attacker.
• Gray box: the team receives partial information, such as documentation or, where you provide them, test accounts; with accounts it can test what a signed-in user sees.
• White box: the team has access to code, architecture or configuration, which can free more of the time for testing important functions.

By who is told

NIST's testing guide separates overt testing, done with the knowledge of the IT staff, from covert testing, done without the IT staff's knowledge but with upper management's permission. Covert testing shows how the organization responds to an attack, but it does not aim to find each vulnerability, and NIST's 2008 guide describes it as slower and more expensive (NIST SP 800-115, section 2.4.2). Agree the approach before testing starts.

How to scope a penetration test

Agree the scope with the testing team: it decides which systems and which questions the assessment covers. In NIST's description of the planning phase, the testing team and your management agree the rules and the goals and record the authorization; no testing happens yet.

• What is in: domains, IP ranges, applications and APIs (the interfaces other software uses to talk to your systems), each with an owner on your side.
• What is out, and why: third-party systems you are not authorized to test, and whether denial-of-service testing is excluded: testing that tries to make a system unavailable or unacceptably slow for its legitimate users, for example by overloading it.
• When: the testing window, and the hours when production must not be touched.
• With what: test accounts for each role, API documentation, and whether testing runs on a staging copy or on production.
• Who to call: a technical contact who is reachable if something stops responding, the conditions for stopping the test, and how an urgent finding reaches you before the report.
• On whose authority: written authorization for the test, and who on your side can approve adding a target once it has started.
• What happens after: whether a retest of the fixes is included, and within what time.

The agreed asset list may already be incomplete. Our piece on reconciling the declared and the actual perimeter describes a test where, two hours in, the list no longer matched what was reachable from the internet.

What a penetration test report should contain

There is no single mandatory format, but public guidance agrees on the essentials. The OWASP Web Security Testing Guide suggests four parts: introduction, executive summary, findings and appendices (OWASP WSTG v4.2, Reporting). NIST asks that internal reports include the test methodology, the results, the analysis and a plan of action and milestones (NIST SP 800-115, section 8.2).

Introduction and scope

Who tested, when, what was in scope and what was not, and any limitations met along the way. Check this section before drawing conclusions from a report with few findings: limited access, an environment that differs from production or areas left untested all change what the result covers.

Executive summary

A short part for management: what the test set out to answer, the main findings in plain language, and the recommended next steps. Someone who reads only this section should know whether to act, and where.

Each finding

Each finding should carry:

• an identifier and a clear title;
• the affected system or function;
• a severity, and how it was rated;
• evidence: the requests and responses, screenshots and the steps to reproduce it;
• the impact in business terms, not only technical ones;
• a recommendation specific enough to act on;
• whether it was confirmed, and how: by exploitation, by inspecting a configuration or by reviewing code.

A finding is not finished when the report arrives. Give each one an owner on your side and a target date, agree whether the fixes will be retested and when, and record what stays unresolved and why. If a customer asked for the report, agree with the testing team which version they receive: a summary of the scope and the results usually travels better than the full technical document, which carries reproducible evidence.

Reports may express severity using CVSS, the Common Vulnerability Scoring System. Its current version, 4.0, was published by FIRST in November 2023, and its user guide warns that base scores "are designed to measure the severity of a vulnerability and should not be used alone to assess risk" (CVSS v4.0 User Guide). A good report explains why a finding matters in your environment, not only its number.

Methodology, limitations and appendices

How the testing was done, how severity levels are defined and, where it helps, relevant tool output — cleaned, with sensitive data removed — so someone can reproduce a finding. The appendices hold the technical material behind the findings.

What a short report looks like

A fictional example, to show how the parts fit together. It is not a real engagement and not a sample of our own reports.

• Scope and limitations: the customer portal at portal.example.com and the invoice API behind it, tested between 3 and 7 March from an agreed address. The payment provider was out of scope, and two administrative functions could not be reached with the accounts provided.
• Executive summary: one confirmed finding lets a signed-in customer read another customer's invoices; two lower findings concern session expiry and an outdated component. The first should be fixed before the next release.
• Findings overview: F-07 high, F-11 medium, F-14 low, each with the affected function, an owner on the customer's side and a target date.
• One finding in full: set out like the F-07 example above.
• Retest: the fixes were retested on 28 March. F-07 and F-11 were confirmed fixed; F-14 was accepted as a risk, with the reason recorded.

Questions to ask about the report

1. Was everything in scope tested, and what could not be tested?
2. Which findings are confirmed with evidence, and which are suspicions?
3. Is there an attack path: findings that together lead further than any one of them alone?
4. What gets fixed first, and who does it: your team, your provider or a third party?
5. How will you check that the fixes worked?

Signs of a weak report

• Scanner output under a different logo: hundreds of lines and no manual evidence.
• Severities copied from a tool without context; NIST advises assessors to set the risk level themselves (SP 800-115, section 4.3).
• Findings with no steps to reproduce them.
• No mention of limitations or of what was left out.
• Generic advice such as "apply patches" or "strengthen security".

What an IntruForce penetration test delivers

In IntruForce Expert Services, a penetration test runs within an agreed scope and can focus on your external perimeter, selected internal systems or specific business-critical assets. You receive a report with confirmed findings, evidence of significant attack paths, an explanation of their possible impact and prioritized recommendations for fixing them.

If you are planning one, tell us what you need to protect or verify in the request form on the services page. Our team replies by email to clarify what you want the test to answer and to agree the scope. Sending a request does not commit you to buying a service, and tests that interact with your systems are agreed separately.