In this guide 6 sections
Read the executive summary first, then sort each finding by how easy it is to attack and what it exposes. Give every item one owner and a date. At the retest, mark each finding closed, open or accepted. Keep the evidence beside it.
Read the report in the right order
Start with the summary and scope page. Check what was tested, which accounts were used and which dates the work ran; a finding means little when you do not know what was left out. Missing scope is a finding in itself.
Then read the findings table. Each row shows a title, a rating and the affected host. It should also carry the steps to reproduce and a suggested fix. Look for the screenshots or raw HTTP requests that prove the tester got in, so your developer can repeat the attack.
Ask the tester to walk you through the top five. Twenty minutes on a call saves weeks of guessing. Bring the developer who will fix them. Context travels faster in a room.
- Scope and out of scope systems
- Test accounts and roles used
- Severity scale and how it was scored
- Reproduction steps for each finding
- Retest terms in the contract
What the severity label does and does not tell you
Ratings such as critical, high, medium and low usually come from a scoring method like CVSS. Treat them as a general guide. They describe the flaw in general. They cannot know your customer list sits behind that login. CWE numbers name the weakness type, such as injection or broken access control. They help when you search for a fix.
A medium flaw on the page holding payment records can matter more than a high one on a forgotten test server. Treat the label as a starting point, not a verdict. Context beats label.
Informational notes are not noise. Verbose stack traces, an open CORS rule or a missing Content-Security-Policy header all appear here. A missing security header rarely hurts alone, yet it costs almost nothing to fix in one release.
Sort by ease of attack and business exposure
Draw a simple grid. One axis asks how easy the attack is, from needing no login at all, through needing a customer login, to needing inside access to the network. The other asks what is exposed. Nothing sensitive. Internal data. Customer records. Money movement. It fits on one whiteboard.
Findings in the easy and sensitive corner go first. Think of a JWT that never expires, a storage bucket open to the public or a password reset link that can be guessed. A bypassed login, an exposed admin panel or a SQL injection on a public enquiry form usually land there, and each deserves a named owner today. Findings that need a rare setup and expose little can wait for the next sprint. Default credentials on a router are cheap to fix. Spend the day. Weak TLS settings on an internal host can wait.
Group related items. Burp Suite or Nessus output often lists the same root cause five times under different URLs. Five findings about missing input validation may share one root fix in a common library, which turns a long list into a single afternoon of work.
- Easy and sensitive: fix this week
- Easy but low exposure: schedule in the next release
- Hard but sensitive: plan with design review
- Hard and low exposure: log and review quarterly
Give every finding one owner and a date
A finding owned by a team has no owner. Put one name against each row, such as the backend lead, the infrastructure admin or the vendor contact for a bought package. Ownership closes gaps.
Add a target date. Add one line on the intended fix. Say so when it is a configuration change. If it needs a code change in a third party product, record the vendor’s support ticket number beside it and set a date to chase. Cross-site scripting fixes often live in a template. Server hardening fixes live in a build script.
Hold a weekly check until the critical items close. Keep it short. Keep it standing.
Record closed, open or accepted at retest
Ask the tester to retest once the fixes are in. Each finding then carries one of three states. Closed means the attack no longer works. Open means it still does. Accepted means you chose to live with it. Keep the dates in the register.
Accepted needs a name, a reason and a review date. Without a sign off it is an open item in disguise, and auditors and insurers notice the difference when they ask to see the file. Insurers ask for exactly this trail.
Book the retest before you start fixing. The date pulls the work forward.
Penetration test fix register
A single page table with a row for each finding. Columns hold the finding number, title, tester severity, ease of attack, exposure, owner, target date, planned fix, retest result and evidence link. The retest column offers three tick boxes: closed, open, accepted. Accepted rows add an approver name and a review date.
Open a blank worksheet to printQuestions owners ask
Do I need to fix everything in the report?
No. Fix what is easy and exposed first, and record a reasoned decision for the rest; accepted items need a named approver and a date to look again.
What if I disagree with a severity rating?
Ask the tester for the reasoning and the attack steps. Ratings can change. Show the tester a control they could not see, such as a network rule.
Who should receive the report?
Keep it narrow: the owner, the engineering lead and whoever signs off risk; the document describes live weaknesses, so store it with restricted access.
How soon should a retest happen?
Once the critical and high items are fixed. Waiting for every item delays the ones that matter most.