How to Read a VAPT Report

A VAPT report is the deliverable of a vulnerability assessment and penetration testing engagement. It says what was tested, in which environment, at which build, over which dates, by what method, and what was found. Almost everything that decides whether the document is worth anything is settled in the first three pages — and almost nobody reads those first.

Read in this order: scope and asset list, environment and build, dates, methodology and effort — and only then the findings. A severity chart on page two of a report whose scope quietly omits your admin console is a chart about somebody else’s estate.

A VAPT report is the written output of a Vulnerability Assessment and Penetration Testing engagement. VAPT is CERT-In’s own abbreviation, rendered without the conjunction: §13.2.3(i)(a) of its Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) lists the audit types that must be communicated to an auditee before an engagement begins, and the list opens with “VAPT (Vulnerability Assessment Penetration Testing)”. The two halves are different activities and the same document defines each. A vulnerability assessment, at §5(xxi), is the examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation. Penetration testing, at §5(xxii), is a security testing methodology in which individual components or the application as a whole are actively tested to identify and exploit potential vulnerabilities — the objective being to determine whether they can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment. A report that covers only the first half is a vulnerability assessment report, whatever the cover page calls it. Knowing which one you are holding is the first act of reading it.

To read one critically, work from the outside in: scope, environment, build, dates, methodology and effort first, findings second, and what is missing last. The scope decides what every other page means. The environment and the build decide whether the report describes the software you are running. The dates decide whether it describes it now. The methodology and the effort decide whether the findings are the product of testing or of scanning. Only then is the severity chart worth looking at — and even then, an auditor’s severity is a statement about a weakness, not a statement about your risk. The rest of this page walks each part in turn, sets out the clause that requires it, shows what good evidence and a properly rated finding look like, explains how to dispose of a false positive without pretending it never happened, and lists the tells that reveal a thin test from the document alone.

Those two sentences are the whole standard in miniature. The first says the report must describe the work, not just the outcome. The second says every claim in it must be backed by something a decision maker can act on. A document that fails either is not a bad report. It is a different kind of object — a summary of a tool run, wearing a report’s clothes. The tests in this page are all, in the end, tests of those two sentences.

Two rows deserve their own note. The repeat observations row is the fastest way to tell a real programme from an annual ritual: if last year’s findings do not appear anywhere in this year’s report, either they were all fixed — in which case the report should say so — or nobody went back to look. And the exemptions and limitations row is the only part of a report that gets shorter as the engagement gets worse, because a firm that did not test much has less it is willing to write down about what it did not test.

That is the checklist. It is deliberately not the order the document arrives in, which is the subject of the next section.

§13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory, and §13.1.1(d) requires it to be vetted by the internal audit team in consultation with the CISO. §13.2.3(ii)(b) then requires the date to which that inventory was current to be reflected in the audit report. That date is quietly one of the most informative fields in the document: a scope drawn from an inventory last updated eighteen months ago has not omitted your new systems deliberately, but it has omitted them.

§13.1.1(a) describes the scope as covering the entire cyber infrastructure, naming web and mobile applications, networks, operational technology and industrial control systems, cloud, APIs, databases and hosting infrastructure, code review, application security, data security and incident-response testing. §13.1.1(e) puts testing, UAT, development and production assets inside it “to achieve complete audit coverage”, and §13.1.1(f) puts third-party, vendor and supply-chain risk assessment in scope too. A narrow scope is a decision someone made. The report should say who made it and why.

§16.1(iii) is one sentence long and does a great deal of work: all the assets provided in the scope by the auditee organisation must be mentioned in the report. It closes the gap where an asset is scoped, never reached, and simply never mentioned again. §10.1(ii) closes the other half: where an in-scope asset stayed inaccessible, the auditor must inform the auditee, request resolution, and if it is still unresolved, name the asset in the report with the reason — and bring the matter to the notice of CERT-In.

§13.2.3(ii)(c): version-specific details of web and mobile applications must be explicitly mentioned in the audit scope and the report. This is what stops a report from silently covering a build that no longer exists. Paired with §9.5(i) — hash values, versions and timestamps captured by the auditee, shared with the auditor, and prominently featured in the certificate and reports — it is the mechanism by which a reader six months later can tell whether the document still applies.

§14 is titled “Agreeing on the Terms of Engagement and Revisions to the Scope”, and §14.1(ii) requires the agreed terms to be documented in an audit engagement letter signed by authorised representatives of both organisations. §14.2 requires revisions to be in writing with justification, assessed for their impact on timelines, resources and deliverables, approved by both sides, and documented as an addendum or formal amendment. §14.3 names the three things that legitimately trigger a revision: discovery of previously unidentified systems or processes presenting significant risk, changes in organisational structure, ownership or regulatory environment, and security incidents or breaches occurring during the audit period. A scope that shrank quietly is a scope nobody wrote down.

One more thing to look for, and it is specific to applications hosted on somebody else’s infrastructure. §13.1.5 splits the responsibility: where a website runs on a web server owned by another organisation, auditing that server, its operating system, the hosting application software and the backend database software is the responsibility of the organisation that owns and operates the server, while the content owner remains responsible for having the website data and software audited. Two audits, two owners, one go-live date. If your report covers only the application and nobody has the other report, the scope has a hole in it that neither document will admit to. Scoping this properly before testing starts is a subject of its own — see VAPT scoping.

That is the most quotable sentence in the whole instrument. The OWASP Top 10 is an awareness document listing ten categories of risk. It is not a test plan and it does not tell a tester what to do. The OWASP Web Security Testing Guide, by contrast, is a testing methodology with numbered checks, and the Application Security Verification Standard is a set of verifiable requirements arranged in three levels. Name the version when you cite it, because the levels were reorganised at the last major release: in the current stable version, ASVS 5.0.0, Level 1 is described as the minimum set and around twenty per cent of the requirements, and the standard says in terms that it “is not necessarily penetration testable by an external tester without internal access to documentation or code”. Level 2 is the level “most applications should be striving to achieve”. Level 3 is for applications demonstrating the highest level of security. ASVS does not pick your level for you, so a scope of work should name the ASVS version and the level, and the report should say which it verified against.

The tooling question is answered the same way. §8(i) says solely tools-based testing should be discouraged, and gives the reason in the same breath: tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure, which “can result in an incomplete view of the overall security”. The 2018 auditor guidelines put it more bluntly still — auditors must use industry standard methodologies and best practices, and “solely tools based testing should be discouraged”. Tools belong in a VAPT report. Tools as the methodology do not.

One clause is worth raising with a supplier before an engagement rather than after. §8(viii) states that an application developed without any secure design and development practices should not be considered for assessment and audit, and that the auditee organisation should be informed in writing with a copy marked to CERT-In. CERT-In publishes its own application security guidelines and the Cyber Security Audit Baseline Requirements sits on the same site, named at §8(iii) as a document both sides should use to build the audit programme. If the methodology section of a report you are reading names neither a testing guide nor a baseline, there was no programme — there was a scan.

The difference between the two columns is not effort in writing. It is whether the test happened. A tester who actually performed the sequence has the request, the response and the account identifiers sitting in their working notes already, so writing the right-hand column is transcription. A tester who did not cannot produce it at any length. That is why §18(iii) is the most load-bearing clause in the reporting chapter, and why §18(i) — which lets the auditee seek the working notes, with a provision for it in the contract, and the evidence as an appendix to the final report — is the request that settles most arguments about report quality in a single email.

Read together they produce the four combinations that actually drive a remediation queue. High CVSS with high EPSS is the emergency. High CVSS with low EPSS is the thing to schedule properly rather than panic about. Low CVSS with high EPSS is the one teams under-react to, because a modest weakness that is being exploited at scale this month is a live problem. And no CVE at all — the whole category of defects in your own code — is where a penetration test earns its fee, and where neither EPSS nor a public advisory will help you prioritise. There, the ordering comes from what the finding reaches and who can reach it.

A probability is not a percentile. FIRST publishes two numbers per CVE and reports routinely print one while captioning it as the other. The probability is absolute: it is the estimated chance that exploitation activity will be observed in the next thirty days, so 0.05 means five in a hundred. The percentile is relative: a CVE at the 90th percentile scores higher than ninety per cent of everything currently scored. Because the distribution is heavily skewed towards zero, the two look nothing alike — FIRST’s own EPSS FAQ notes that a probability of 0.10 currently sits around the 95th percentile. A finding dismissed in a meeting because “it is only five per cent” may be in the top decile of everything published.

And a printed EPSS value has a shelf life of one day. Scores are recomputed and republished every day, for every scored vulnerability. An EPSS figure in a report is therefore a snapshot, and a snapshot with no retrieval date beside it is a number that has already changed. Ask for the pull date the same way you ask for the test window — and when you sit down to plan remediation, re-pull rather than read. That is a two-minute job against a free daily feed, and it is the cheapest thing on this page that reorders a queue.

Do not let it become the whole rating. FIRST is explicit that EPSS is not a complete risk score: it does not measure the damage successful exploitation would cause, does not know what you run, and does not account for compensating controls. It also defines no bands — there is no EPSS “critical” and no official threshold, and FIRST says so, noting that the 0.10 figure commonly cited in the field carries no authority from EPSS. A report that prints EPSS severity labels has invented them.

A note on how many false positives is too many. There is no published figure and it would be meaningless if there were, because it depends entirely on the estate. What is diagnostic is where they cluster. A handful scattered across a long report is ordinary professional disagreement. A cluster of them in one class — every TLS finding, every version-banner finding — means one tool ran unattended against one part of the scope, and that part of the report was never verified by a person. That is the §8(i) problem, surfacing as a dispute about individual findings rather than as an admission about method.

Item 21 is its twin: reports state all states of security found, not only the failed measures. Item 22 requires metrics based on industry-accepted methods and on a mathematical formula “and not on feelings of the auditor”. Item 19 requires the auditor to notify you whenever the audit plan changes, the source test venue changes, high-risk findings appear, or before running new, high-risk or high-traffic tests — and to provide progress updates at reasonable intervals. Item 23 requires the auditee to be told the report is on its way and to confirm receipt. The 2025 guidelines restate the notification duty almost word for word at §13.2.7(iii).

An unknown is not a failure of the engagement. It is a fact about the engagement, and there are always some: a system that was unreachable for two of the five days, a third-party component whose behaviour could be observed but not inspected, a test that stayed passive because §15.2.2(iv) says that in critical environments where availability is the top priority, testing should be conducted in a passive manner, and a control the developer described and nobody could exercise. The problem is never that unknowns exist. The problem is a report that reads as if they do not.

The 2025 guidelines carry the same principle in three other places, which is a good sign that it is meant. §16.1(ii) requires exemptions, limitations and other constraints in the report. §13.2.4(ii) requires the auditor to communicate any exemptions, limitations and constraints to the auditee — a duty distinct from §13.2.4(i), which is the expectation-gap clause requiring the audit process, required artefacts and expected deliverables to be explained at the outset. And §18(vi) applies the same rule to forensic work: where a digital forensic investigation faces constraints because evidence or logs are unavailable or inadequate, the report should explicitly bring that out and recommend the log detail that should be captured.

A pattern worth naming, because it explains most of the table at once. A thin test produces a report that is long in the middle and empty at both ends: lots of findings, because findings are what a tool produces in volume, and very little scope, environment, method, effort, evidence, limitation or closure detail, because all of those describe work rather than output. When you pick up a report and the first three pages are thin while the finding section runs to eighty, you already know the shape of what happened, before you have read a single vulnerability. A test that was genuinely performed is easier to describe than to summarise.

Step five is the one people are most tempted to skip, and it is the highest-yield minute in the exercise. Criticals get attention: they are written up carefully because everyone knows they will be read aloud in a meeting. A medium is where the firm’s actual standard lives. If the mediums have locations, evidence and specific remediation, the report is sound all the way down. If they collapse into one-line descriptions with a generic fix, the top of the report is a display case.

Twelve observations, none of which required access to the testing, the testers or the tooling. They produced six questions. The answers are where the exercise stops being an audit of the document and starts being a conversation about the engagement.

What the read was worth. Not the 47 findings. The read turned 47 into 17 by sorting on a field the report was required to carry and did not, surfaced six risks that were a year older than the document admitted, and identified one defect — the missing build identity — that no revised report can repair, which is the difference between a conversation about this engagement and a decision about the next one. It took an afternoon, and every question in it quoted a clause rather than an opinion. That is the whole method.

Where the engagement is one that requires an independent issuer — an Indian government website, web application, portal or mobile app going into production, most obviously — read the requirement as GIGW writes it. Guideline 5.3.1, at guidelines.india.gov.in, requires an audit clearance certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory before hosting in the production environment. Four issuers, one of which is CERT-In empanelment. Where the requirement is specifically a CERT-In empanelled organisation — because a tender, a regulator or a customer contract says so — the empanelment check has its own method and its own failure modes, set out on how to verify a CERT-In audit certificate. What empanelment is, and what it is not, is on CERT-In empanelment explained. The agency itself is described on what CERT-In is. And if what you have been handed is a certificate rather than a report, the distinction and what each one carries is covered on what a safe-to-host certificate is and safe-to-host versus a security audit certificate.

One caution about claims made around the document rather than in it. An empanelled auditor is permitted exactly one sentence about its relationship with CERT-In — that the organisation is empanelled by CERT-In for providing information security auditing service — and no other words without CERT-In’s prior written permission, with the logo prohibited on publicity or promotional material on the same terms. A cover page carrying the CERT-In emblem, or a covering email describing the firm as “CERT-In certified”, tells you how that organisation treats claims generally, before you have read a single finding. Claims about the newer audit monitoring platform are worth the same scepticism, and are set out on AMBAK.

Send it to the point of contact named in the engagement, over the channel the engagement uses. §16.5 requires reports to be communicated through official email IDs only, to the specified point of contact, with password protection or encryption and end-to-end confidential delivery channels, and §13.2.5 requires a distribution list of official email IDs — plus a mobile number for sharing report passwords — to be obtained before distribution. If you are the auditee, keep the request and the reply with the report. They are part of the record of what you were told, and they are the first thing anyone will ask for if a finding that was closed on paper turns out not to have been.

Most of the time the eleven lines are answered, because a firm that did the work has the material to hand. When they are not, there is a ladder, and it is worth knowing that it ends somewhere. Work down it in order and stop when the problem is fixed.

One thing that is not on the ladder, deliberately. Do not renegotiate the fee against the findings, in either direction. §7 of the audit policy guidelines puts independence first among the basic principles and states that payments to the auditing organisation should not be contingent upon the outcome of the audit — whether favourable or unfavourable — nor tied to the submission or approval of any closure report, and that fees should be based on predefined scopes, deliverables and timelines. A discount negotiated because the report was disappointing creates exactly the incentive the clause exists to prevent, on the next engagement rather than this one.

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us, or read more about our security testing services.