After the VAPT Report: Fix, Retest and Close Findings

Ask for a call where the tester explains the findings to the people who will fix them. Developers and system owners learn more from twenty minutes of live explanation than from reading a finding alone, and they can ask how an attack actually worked. Bring the person who can approve time and budget, so priorities are set in the same meeting.

Put the findings in the tracker your team already uses, with a single named owner for each, a target date and a link to the evidence in the report. A finding assigned to "the development team" has no owner. Group findings that share a cause: one change to how permissions are checked may close six findings, and a single base image update may close a dozen.

For each finding decide, and write down, which of three paths you are taking:

• Fix: change the code or setting so the weakness no longer exists. This is the default.
• Reduce: add a control that lowers the risk while a full fix is planned, such as a firewall rule, a network restriction or a monitoring alert. Mark it temporary.
• Accept: decide the risk is tolerable, with the name of the person who accepted it, the reason and a date to review. Accepting a risk is a business decision and should never be a silent default.

To order the work, use exposure and impact as well as the rating; our article on ranking findings with CVSS, EPSS and KEV shows how.

A report shows one request that exposed another customer's record. If you correct that request and leave the rest, the same flaw is probably waiting in other endpoints. Ask the tester what pattern lies behind the example and look for it across the whole application. Add an automated test or a code review rule so the mistake is caught next time.

A retest checks the findings again after you say they are fixed. It confirms that the original attack no longer works, and it catches fixes that moved the problem somewhere else. A retest is not a new full test: it covers the findings from the report, so new features added since then need their own testing. How many retests a proposal includes, and for what scope, should be agreed in writing before work begins. Read the retest terms in the proposal and ask if they are unclear. Our guide to choosing a VAPT company lists this among the questions worth asking.

Close a finding only when something shows it is fixed: a retest result, a code change reference or a changed setting you can point to. Keep a short register of what was found, who fixed it and when. Customers who send security questionnaires, and auditors, will often ask for exactly this record, and our article on sharing a test report with customers covers how to present it.

Put the next test in the calendar now, tied to events such as a major release, a new integration or a change of hosting, as well as to time. The guide on how often to do VAPT explains how to choose the interval.

Our reports are written to be worked from, with the steps to reproduce and the fix for each finding. See the sample VAPT report for the layout, or send an inquiry to discuss your next test.