VAPT & Penetration Testing
What to do after you get a penetration test report
Got a long pentest report? Here is how to read it, fix the risks in the right order, ask for a re-test and keep records.
A penetration test report can run to dozens of pages. The way to handle it is simple. Read it through once, fix the findings that put your business at most risk first, give each fix to a named person, and ask for a re-test when the work is done.
This guide is for the owner or developer who is holding a report and does not fully follow it. It explains severity ratings, shows how to read one finding, and covers how to explain the whole thing to a boss who is not technical. If you have not yet had a test, start with penetration testing.
Read the whole report before you fix anything
Do not start on page one and fix as you go. Read the summary first, then skim every finding, then go back to the detail. Two reasons.
- Findings often share a cause. One missing check in your code can show up as five separate findings. Fixing the cause once is faster than patching five symptoms.
- Some fixes depend on others. A new login system makes older login findings disappear.
Most reports have the same parts.
- Summary for management. What was tested, when, and the overall picture in plain words.
- Scope and method. The systems covered and the kind of testing done. Check that it matches what you agreed. If a system you expected is missing, ask why.
- Findings. One entry per issue, with severity, evidence and a fix.
- Appendices. Raw detail, tool output, test accounts used.
Mark anything you do not understand and send the list back to the tester. A good report is a starting point for questions. A tester should be happy to explain a finding.
How severity ratings work
Each finding gets a severity, usually Critical, High, Medium, Low or Informational. The rating reflects how likely a problem is to be misused and how much damage follows. Many reports also quote a CVSS score. CVSS is a public scoring system for vulnerabilities, run by FIRST. The CVSS specification (opens in a new tab) explains how the score is built.
Treat the rating as a guide, not a verdict. A score is calculated for the flaw in general. It does not know your business. A medium flaw on the page that holds all your customer records can matter more than a high flaw on a test server with no data. Ask the tester to confirm the rating in your setting if you think it is off.
Informational items are not flaws. They are observations, such as a missing header or an outdated page, that may be worth tidying later.
Example finding: how to read one entry
The finding below is an example, invented to show the layout. It is not from a real client or a real test.
| Field | Example entry |
|---|---|
| Title | Example: Customers can open other customers' invoices |
| Severity | Example: High |
| Where | Example: the invoice download page of the customer portal |
| Evidence | Example: signed in as test user A, the tester changed the invoice number in the address and received test user B's invoice. Screenshot attached in the appendix. |
| Business impact | Example: any logged-in customer could read other customers' billing details. |
| Fix | Example: before returning an invoice, check that it belongs to the signed-in user. Return a "not found" response if it does not. |
| Owner | Example: lead developer |
| Target date | Example: set by your team |
| Status | Example: open |
Read it from the top. The title and severity tell you how urgent it is. The evidence shows it is real and not a guess. The impact tells you why it matters to the business. The fix tells your developer what to do. The last three rows, owner, date and status, are usually blank in the report. You fill them in.
Fix by business impact, not list order
The report lists findings by severity, which is a good start, but the order of work should also reflect your business. Ask three questions of each finding.
- What does it expose? Customer data, payment details and admin access come before cosmetic issues.
- How easy is it to reach? A flaw on a public page is more urgent than one that needs a staff login.
- How hard is the fix? A one-line change can go out the same day, even if the rating is only medium.
A practical order is to fix Critical and High findings that touch customer data first, then quick fixes of any rating, then the rest. Where a fix needs a big change, such as redesigning login, agree a short-term protection with the tester while the real work is planned.
Who should own each fix
A finding with no name beside it does not get fixed. Give every finding one owner.
- Developers own code issues, such as missing checks or unsafe input handling.
- Whoever runs your servers or cloud account owns settings, open ports and permissions. This could be a contractor or your hosting provider.
- The business owner owns decisions, such as accepting a risk or paying for a bigger change.
- Third parties own issues in tools you buy. Raise these with the vendor and note the date.
Some findings you may choose not to fix, because the cost is higher than the risk. That is a valid decision if the right person makes it on purpose and writes it down. Note who accepted the risk, why, and when to look at it again.
Explaining the report to a non-technical boss
Skip the technical detail. Give four things on one page.
- What was tested, and when.
- How many findings sit at each severity.
- The top few findings, each in one sentence of plain business terms, such as "any customer could read another customer's invoice".
- What you need from them: a decision, time or budget.
Add the plan with owners and dates. Offer the full report for anyone who wants it.
Ask for a re-test
A re-test checks that your fixes worked. Fixes can fail quietly. A developer closes a hole in one place and misses the same hole in another. After you have fixed the findings, there is a re-test.
In general, a re-test has limits you should know.
- It shows that the specific findings no longer work as described, on the date of the check.
- It does not show that the system is secure overall. New code, new features and new settings after the test are not covered.
- It does not replace a new test when the application changes a lot.
Before you ask, make sure the fixes are live in the environment that was tested. Send the tester a short list of what you changed.
Keep the report and the proof of fixes
Keep a folder with the final report, your list of owners and dates, and proof for each fix. Proof can be a code change note, a screenshot of a changed setting, or the re-test result. Store it somewhere with limited access. A pentest report is a map of your weak points, so do not email it around or leave it in a shared drive open to everyone.
These records help in three ways. New staff can see what was fixed and why. Customers or partners who ask about your security practices get a straight answer. And the next tester can start from where the last one finished.
When to test again
Run a new test after a major change, not only on a calendar date. Good moments include a new payment flow, a new login method, a move to a different host, a large new feature, or a redesign of how data is stored. Some contracts and standards set a regular schedule. Check the ones that apply to you for the actual rule.
Between tests, keep your software updated and fix small issues as they appear.
Next step
If you have a report to work through or want a test with a re-test after fixes, see penetration testing. Findings come ranked by risk, each with a clear fix.
