How do I read a penetration test report?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

Which sections matter and in what order?

Three passes, in this order. The executive summary tells you what was tested, over which dates, by how many tester-days, and what the testers were able to achieve, and it should be readable by your board without translation. The findings section is the technical core, and each entry should carry a title, the affected asset, reproducible steps, evidence, impact, a specific fix and a severity with a stated reason. The coverage and limitations section is the one most buyers skip and most need, because it names what was out of scope: roles that were not tested, an API that was not authenticated, an internal network that was not assessed at all. An assessment without a coverage section is a claim about a system nobody has described.

How do you tell a real exploit from a scanner alert?

Look for the evidence. A scanner alert gives you a name, a CVE or a plugin, a severity score and possibly a request. A real finding gives you a sequence: what an attacker does, what they get, and what it means for your business. In practice the difference is visible in the fix. A scanner alert produces a generic instruction to update software or change a configuration. A real finding produces a change in your authorisation logic, your workflow or your process, and it explains which of your roles or data sets are exposed. The Indian cases that matter most, broken access control between user roles, business-logic abuse and chained low-severity findings, are exactly the class scanners handle worst, so treat a scanner-only report as a map rather than a diagnosis.

How should you triage the findings?

By exploitability and business impact, not by the severity label. A high-severity misconfiguration on a staging box matters less than a medium-severity flaw that lets a support agent read every customer's file, and a critical finding behind a firewall that blocks the path matters less than a medium one that is directly reachable. Build a list of three things: what an attacker can reach today, what it would cost if they did, and how long each fix takes. Fix the reachable and expensive ones first, and record a decision and a date for the rest, because a finding that is neither fixed nor consciously accepted will be found again at the next audit. India recorded 77 ransomware attacks between January and June 2026 (Cyble CRIL, reported by Fortune India, 23 July 2026), and the entry points were rarely exotic.

What should you do after reading it?

Close the loop in three moves. Assign an owner and a target date to every finding, because an unowned finding is an open finding. Apply the fixes, then ask for the retest, which should list every finding as fixed, partial or open, and the retest is what turns a report into evidence. At AAVETech the retest after your fixes is included as standard on assessment work, and a retest scoped to the findings list keeps the cost small. Finally, keep the report and the retest result for your customers, your auditors and your cyber insurer, because in 2026 the three of them are increasingly asking for the same document, and a report without a closure record is only half the answer.

What are the frequently asked questions?