VAPT stands for Vulnerability Assessment and Penetration Testing. It is not one activity with a long name — it is two activities bolted together, with different methods, different outputs and different reasons for existing. India buys them as a compound. CERT-In defines them as two things, in two clauses, and never defines the compound at all.
Two clauses contradict how most Indian VAPT is sold. §8(i) of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) says solely tools-based testing should be discouraged. §8(ii) says limited lists such as the OWASP Top 10 and SANS Top 25 should not be considered standards or references for audits. Both are quoted in full on this page.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · CERT-In Auditor Guidelines v3.0 (May 2018) · Every clause locator checked 22 September 2026
What is VAPT? Two things, not one
VAPT stands for Vulnerability Assessment and Penetration Testing. A vulnerability assessment examines a defined estate and enumerates the weaknesses in it — breadth, coverage, largely tool-driven. A penetration test takes weaknesses and actively tries to exploit them to see what an attacker could actually reach — depth, consequence, necessarily human. They answer different questions, they are measured differently, and the word “VAPT” is a purchasing label for an engagement that does both.
CERT-In, the Indian Computer Emergency Response Team, defines each half separately and does not define the compound. Its Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) define Vulnerability Assessments at §5(xxi) and Penetration Testing at §5(xxii), and list them again, in identical wording, as two separate classes of engagement at §6(iii) and §6(iv) of the twenty-six that document covers. “VAPT” appears once in the whole instrument, at §13.2.3(i)(a), where it is expanded in brackets as one of nine types of audit a scope of work must declare — a list that ends with “etc.”. So the compound is real, it is used by CERT-In, and it is used as a label for a scope rather than as the name of a technique.
That distinction is not pedantry. It decides what you are buying. An engagement scoped as an assessment tells you what could be wrong and cannot tell you which of it matters, while an engagement scoped as a test tells you what one person reached in the time you paid for and cannot tell you what was covered. The commercial failure this page exists to prevent is the one where a buyer reads “VAPT” as the second thing, a seller prices it as the first, and nobody discovers the gap until an incident or a customer questionnaire forces someone to read the report.
The four things people most often get wrong about VAPT
Each one is addressed in full further down, with the clause behind it.
VAPT is not a synonym for penetration testing.
A penetration test is one of the two halves. Buy a VAPT and receive only a scan and you have paid for depth and been given breadth. Buy a penetration test and expect a coverage statement and you have read a bounded result as an unbounded one. Both mistakes are available in the same purchase order.
A scan is not an audit, and CERT-In says so in terms.
The consequence rather than the clause: a scanner export delivered as a penetration test cannot be defended against §8(i), and the buyer who signs it has paid for consequence and been handed coverage. The clause is quoted whole under “a scan is not an audit” below.
The OWASP Top 10 is not an audit standard.
Again the consequence: a scope of work naming the Top 10 as its audit criterion has no coverage claim available to it, because a ranked list of common categories cannot support one. What to name instead — and the clause that says so — is set out in the same section.
A private-sector VAPT does not produce a statutory certificate.
There is no instrument behind a “VAPT certificate” for a commercial engagement with no Government nexus. A certificate exists for Indian Government websites and applications — the safe-to-host or audit clearance certificate under GIGW 5.3.1 — and only four named bodies may issue it.
Key Takeaways
- VAPT stands for Vulnerability Assessment and Penetration Testing. It names two activities, not one: breadth and enumeration, then depth and exploitation.
- CERT-In defines the halves and not the compound. Vulnerability Assessments and Penetration Testing are defined separately at §5(xxi) and §5(xxii) of the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025), and appear again as separate classes of engagement at §6(iii) and §6(iv) of twenty-six.
- A real engagement is picturable, not adjectival: a dated inventory behind the scope, a test plan in man-hours as well as days, an account at every privilege level, an enumeration handed to the testers before the test window opens, findings scored twice, and a re-test that is already priced.
- The definitions differ in their verbs. A vulnerability assessment “examines”, “identifies”, “predicts” and “confirms”. A penetration test “actively tests to identify and exploit”, to determine whether weaknesses “can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment”.
- Two clauses at §8 decide whether a delivered engagement is defensible: §8(i) on tools-only testing, §8(ii) on limited lists as audit criteria. Together they mean a scanner export cannot be an audit and “tested against the Top 10” cannot be a coverage claim — which is a commercial problem before it is a technical one, because both are how the market prices.
- What §8(ii) names instead is a specification you can paste into a scope of work: ISO/IEC standards, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard at a named version and level, the OWASP Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model.
- A real engagement has a scope derived from a dated asset inventory (§13.1.1(c)), a test plan stating both calendar time and man-hours (§13.2.2(ii)), a named environment (§15.2.3(i)), findings scored with CVSS and supplemented with EPSS and mapped to CWE and CVE (§5(xxiv), §16.2(ii)), closure timelines by severity (§16.3(iii)) and a follow-up audit that verifies closure (§16.3(iv)).
- Frequency is set by §13.1.2: at least once a year as a minimum, and a cyber security audit before implementation of any major change — where “major” is defined by risk, not by size.
- We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.
Vulnerability assessment and penetration testing, in CERT-In’s own words
What is the difference between a vulnerability assessment and a penetration test?
Both definitions below are quoted from the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. Each appears twice in that document in identical wording — once in §5 Definitions and once in §6 Scope of Engagements Covered — which is unusual enough to be worth noticing. Read them for their verbs. The assessment definition is built on examine, identify, predict and confirm. The testing definition is built on actively test, exploit, compromise, access and affect. That is the entire distinction, and CERT-In wrote it into the grammar.
Vulnerability Assessment
“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.”
The verbs
examine, determine, identify, predict, confirm
The shape of it
Breadth. It runs across everything in the defined estate and reports what is there: missing patches, weak configuration, exposed services, outdated libraries, permissive policy. Its quality is measured by coverage — did it look at every asset in the inventory, and can it say so.
How it is performed
Largely tool-driven, and legitimately so. Authenticated and unauthenticated scanning, configuration review, dependency and version analysis, policy inspection. Tools are how you examine ten thousand things without missing the nine thousandth.
What it produces
An enumerated inventory of weaknesses, each one mapped where applicable to a CWE and a CVE, severity-scored with CVSS and supplemented with EPSS, and stated against the asset list the scope was drawn from.
What it cannot tell you
It tells you what could be wrong. It does not tell you which of those things is actually reachable, actually exploitable, or actually consequential in your configuration — which is why a long assessment report and a secure system are entirely compatible, and so are a short one and a breach.
Penetration Testing
“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 is to determine whether these vulnerabilities can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment.”
The verbs
actively test, exploit, compromise, access, affect
The shape of it
Depth. It takes a smaller set of things and pushes on them until something gives or nothing does. Its quality is measured by consequence — what was reached, from where, with what privilege, and what became available once it was reached.
How it is performed
Necessarily human. Business-logic abuse, authorisation boundaries crossed, weaknesses chained into a path, assumptions the developer made that no scanner knows to question. A tool can report that an endpoint accepts a parameter, but a person works out that changing it returns another tenant’s invoice.
What it produces
A demonstrated path, reproducible step by step, with evidence, and a statement of what it would cost the organisation if somebody else walked it. The CVE is not the finding. The consequence is.
What it cannot tell you
It tells you what a tester found in the time you bought. It makes no statement about coverage. A clean penetration test means this tester did not get in this way in this window — a proposition much narrower than “we are secure”, and one that is routinely read, in the boardrooms we sit in, as the wider thing.
One more definition sits beside these two and is worth carrying into any conversation about scope. §5(xxiii) and §6(xvi) define a Red Team Assessment as “an exercise, reflecting real-world conditions, that is conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems”. That is a third thing again: not breadth, not depth against a named target, but an objective-led simulation in which detection and response are part of what is being tested. Three activities, three definitions, one instrument.
What happens when you buy only one of the two
Why is VAPT sold as one engagement instead of two?
The compound term is clumsy, and it points at something real. Breadth without depth produces a list nobody can prioritise honestly, and depth without breadth produces a result nobody can bound. Each half answers a question the other one cannot, and the specific way each one fails on its own is predictable enough to plan around.
| What you bought | What you get | The question it cannot answer | How it fails in practice |
|---|---|---|---|
| Assessment only | A long list, usually generated, ranked by a score that knows nothing about your architecture. Coverage is stated, but consequence is not. | Which of these findings is reachable from the internet, which is neutralised by a control the scanner cannot see, and which one of them a competent attacker would actually use. Everything is a maybe, so everything is triaged by score and the score is generic. | Remediation capacity is spent from the top of a list rather than on the path that actually exists. Teams close four hundred informational findings and leave the broken object-level authorisation in place, because nothing in the assessment told them it was there. |
| Penetration test only | A narrative of what the tester reached, with evidence, and usually a small number of high-quality findings. | What was examined and not found wanting. Without an assessment behind it, a penetration test has no denominator: you cannot tell whether the tester covered the estate and found three things, or covered a tenth of it and found three things. | A clean report is read as an assurance statement. It is not one. It is a statement about one tester, one window, one set of assumptions, and §10.1(i) of the 2025 guidelines is explicit that an auditor’s responsibility is limited to reviewing and reporting on the state of security at the point in time of the audit. |
| Both, run as one engagement | Breadth that establishes coverage, and depth that establishes consequence — with the assessment feeding the test, so the tester starts from an enumerated estate rather than from a guess about where to look. | Whether anything changed after the test window closed. That question is answered by change classification and re-testing, not by the engagement. | The two halves are run by the same person on the same day, and the “penetration test” is the scanner output with the false positives removed. That sequence — breadth and depth collapsed into one pass, with the tool’s output re-labelled — is what §8(i) of the 2025 guidelines is written against. |
There is a sequencing point buried in the third row, and it has a check rather than a hope attached to it. The assessment should run first and feed the test, because a tester who starts from an enumerated estate spends the engagement on the interesting problem rather than on discovery. The artefact that proves it happened is the enumerated asset-and-weakness list the testers were handed, dated before the test window opened and traceable back to the inventory the scope was derived from. Ask for it by name and compare two dates: the date on the enumeration, and the first date in the testing window. If the first is not earlier than the second, the two halves were one pass and the ordering claim in the proposal is decorative. Before you sign, the same question has a commercial form: §13.2.2(ii) requires the test plan to state both calendar time and man-hours, and man-hours divided by the number of surfaces and privilege levels in scope is what each one is actually getting.
Why India says VAPT when the rest of the world says pentest
It is a fair question and it deserves an honest answer, which begins by separating what can be shown from what cannot. No official document explains the origin of the compound, and this page will not invent one. What the record does show is that the two activities are named together across Indian instruments, and that every one of those instruments either keeps them apart or expands the abbreviation when it uses it.
| Instrument | Where | What it says | How to read it |
|---|---|---|---|
| Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025 | §4 Applicability | CERT-In empanels information security auditing organisations “to undertake audits, including vulnerability assessments and penetration testing of computer systems, networks and applications of various organizations of the Government and of other sectors”. | Named separately, in the applicability clause that defines what empanelment is for. Not a compound. |
| Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025 | §5 Definitions and §6 Scope of Engagements Covered | Vulnerability Assessments and Penetration Testing are defined as two separate terms, in identical wording, in both sections — §5(xxi) and §5(xxii) in the definitions, §6(iii) and §6(iv) in the list of engagement classes. | Two definitions, two engagement classes. CERT-In does not define “VAPT” anywhere in the document. |
| Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025 | §13.2.3(i)(a) | The scope of audit “shall clearly define the type of audit to be conducted i.e. VAPT (Vulnerability Assessment Penetration Testing), EAPT (External Attack Penetration Testing), DLA (Device Level Audit), Configuration Audit, Process Audit, Mobile Application Security Audit, Web Application Security Audit, API Security Audit, Compliance audit etc.” | The one place the compound appears — and it appears expanded, as a label for a type of audit you must declare in the scope. Note the list ends with “etc.”, so these nine are not a closed set. |
| CERT-In empanelment process, published on cert-in.org.in | Step-3 of four | The third round an applicant organisation must clear is the “Vulnerability Assessment/Penetration Testing Practical Skill Test (VA/PT PST)”. | A slash, not a word. CERT-In tests the two competences as a pair and still writes them as two things. |
| Guidelines for Indian Government Websites and Apps (GIGW 3.0), manual | Guideline 5.3.2, government organisation action | Servers and network devices used to host the website “should be hardened with latest security patches and periodic Vulnerability Assessment (VA) and Penetration Testing (PT) followed by corrective actions should be performed as per the security policy”. | Expanded, abbreviated separately as VA and PT, and attached to a cadence and a corrective-action duty rather than to a certificate. Take the number from the GIGW 3.0 manual rather than from the live attributes page: that page mis-numbers the third cybersecurity statement as 5.3.2, so 5.3.2 appears on it twice and the second occurrence is the policies statement. In the manual, 5.3.2 is the hosting environment and 5.3.3 is policies. |
This part is our reading, not a sourced fact
Outside India the same work is usually bought as a penetration test, with vulnerability scanning treated as one input to it rather than as a co-equal half of the product. Our reading of why the Indian convention went the other way is procurement: Indian security testing has been shaped by tender language and by an assurance regime that wants coverage stated as well as consequence demonstrated, and a compound that names both halves is a convenient thing to write into a schedule. That is an observation about vocabulary and a plausible explanation, not a finding — no official document we have read gives an account of the term’s origin, and nothing else on this page depends on it. What does matter, and what is on the record, is that CERT-In uses the abbreviation exactly once in sixty-nine pages and expands it in brackets when it does — the behaviour of a document that does not assume its readers agree on what the word means.
VAPT among CERT-In’s twenty-six classes of engagement
What are the types of VAPT?
§6 of the 2025 guidelines is headed “Scope of Engagements Covered” and lists twenty-six classes, opening with a phrase worth quoting because it settles an argument: “The types of cyber security audits and assessments including, but not limited to, those listed below, may be carried out and fall within the scope of this document.” The same sentence continues that auditee organisations “are expected to ensure a comprehensive audit covering all aspects of their Information and Communication Technology (ICT) systems at least once a year” and “may also opt for additional assessments and audits during the year”.
Vulnerability Assessments is item (iii). Penetration Testing is item (iv). They are adjacent and they are separate. What people call a VAPT is, in the vocabulary of this document, an engagement covering classes (iii) and (iv) — and very often several others without anybody naming them.
| The two halves of VAPT | iii. Vulnerability Assessments · iv. Penetration Testing | Defined in identical wording at §5(xxi) and §5(xxii). The engagement most buyers mean. |
| Adjacent classes usually inside the same purchase order | viii. Information Security Testing · ix. Source Code Review · xi. Communications Security Testing · xii. Application security testing, including web applications, mobile applications and APIs · xiii. Mobile Application Security Auditing · xiv. Wireless Security Testing | Worth naming individually in the scope. A scope that says “VAPT of the application” and means source code review as well should say so, because §13.1.1(a) puts code review inside the audit scope in its own right. |
| Infrastructure and platform classes | v. Network infrastructure Audits · xviii. Cloud Security Testing · xix. Industrial Control Systems / Operational Technology Security Testing · xx. Internet of Things (IoT) / Industrial Internet of Things Security Testing · xxi. Log Management and Maintenance Audit · xxii. Endpoint Security Assessment | Cloud Security Testing is defined at §6(xviii) as “evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures” — which is a control-plane engagement, not a web test with the word cloud in the preamble. |
| Classes that are not VAPT and are often confused with it | i. Compliance Audits · ii. Risk Assessments · vi. Operational Audits · vii. IT security policy review and assessment · x. Process Security Testing · xv. Physical Security Testing · xvi. Red Team Assessment · xvii. Digital Forensic Readiness Assessment · xxiv. Vendor Risk Management Audits | A Red Team Assessment at (xvi) is an objective-led simulation, while a compliance audit at (i) evaluates practices against standards and policies. Neither is what a vulnerability assessment or a penetration test does, and buying one when you needed another is the expensive version of this mistake. |
| The newer classes, which is where the instrument is growing | xxiii. Artificial Intelligence (AI) System Audits · xxv. Blockchain Security Audit · xxvi. SBOM, QBOM and AIBOM Auditing | §6(xxiii) defines AI System Audits as “evaluation of AI systems for security, ethical alignment, transparency, data integrity, and resilience to adversarial manipulation”. §6(xxvi) covers bills of materials for software, quantum and AI components, with CERT-In publishing separate technical guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM at version 2.0, dated 9 July 2025 — which §6 names the BOM types without citing, so read the two together rather than treating one as the authority for the other. |
The practical use of that list is as a scoping instrument. Run down it once with the people who own the systems and mark every class that is genuinely in play, then check the statement of work against the marks. The engagements that disappoint are usually not badly executed — they are executed exactly as scoped, against a scope that named two classes when the estate needed six. The sibling page on VAPT scoping works through that exercise in detail, and types of VAPT takes the classes one at a time.
What does a VAPT actually test?
Breadth and depth are the right abstraction and a useless answer to a procurement question. Below is the concrete version: what is done to each kind of asset, which clause or standard names the method, what the tester needs from you before it can happen, and the coverage that goes missing without anyone deciding to drop it. §13.1.1(a) puts every one of these inside the audit scope. The third column is the one to read against your last statement of work.
| Asset | Method, and what names it | What the tester needs from you | The coverage that silently disappears |
|---|---|---|---|
| Public web application or portal | OWASP Web Security Testing Guide for the method and OWASP ASVS at a named version and level for the control set, both named in §8(ii). Programme built from the Cyber Security Audit Baseline Requirements under §8(iii). | A working account at every privilege level, the role matrix that says what each one is meant to be able to do, and a test window agreed with whoever watches the logs. | Authenticated testing at every level. One read-only account removes the whole authorisation class — horizontal movement between tenants, vertical escalation, a role check enforced in the interface and not in the controller. |
| Admin console or back-office module | The same web methodology run against the administrative role matrix, plus a configuration audit of the hosting stack. Configuration Audit is a named audit type at §13.2.3(i)(a). | The hostname or path it lives at, an administrative account that is not shared, and confirmation of whether it is reachable from the internet or only from inside. | The console sits on a different hostname or port, never enters the asset inventory §13.1.1(c) requires the scope to be derived from, and therefore never enters the scope. It is usually the highest-value target in the estate. |
| Mobile application | OWASP Mobile Security Testing Guide, which §8(ii) names “for mobile app audits”. Mobile Application Security Auditing is its own engagement class at §6(xiii) and its own audit type at §13.2.3(i)(a). | The signed build and its version, test devices or an emulator profile, accounts at each role, and the base paths of the APIs the app calls. | Everything except the binary. A mobile audit has to reach local storage, transport security and certificate handling, the inter-process surface, and the APIs behind the app — which are usually a separate system and a separate contract. |
| API tier | API Security Audit is a named audit type at §13.2.3(i)(a), and §6(xii) puts APIs inside application security testing alongside web and mobile. | Base paths enumerated as assets with owners, a current specification or collection, tokens for each consumer role, and a statement of which endpoints are internal-only. | The whole tier. The front end is audited under one work order and the APIs belong to a different integrator, so each scope quietly assumes the other covered them. Enumerate base paths as assets, because an API that is not in the inventory is not in the scope. |
| Cloud account and control plane | CSA Cloud Controls Matrix, which §8(ii) names “for Cloud Security”. Cloud Security Testing is its own class at §6(xviii), defined as evaluating the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures. | Read access to the account or subscription, the tenancy and region list, and a drawn shared-responsibility boundary saying which side of the line each control sits on. | The control plane. A cloud engagement scoped as a web test with the word cloud in the preamble never looks at identity policy, key management, storage exposure or the roles the workloads run under. |
| CI/CD pipeline | OWASP DevSecOps Maturity Model, which §8(ii) names “for assessing Continuous Integration / Continuous Deployment (CI/CD) pipeline security”. | Pipeline definitions, the runner inventory, the secret store, and the list of who can approve a deployment to production. | All of it, almost always. The pipeline is a production system holding deployment rights and long-lived credentials, and a scope that stops at the running application leaves it untested — which is why a good result can be true about a build and not survive the next release. |
| Database | Database configuration audit. §13.1.3(ii) requires the audit of an identified critical database to include, but not be limited to, a database configuration audit. | Identification. §13.1.3(i) puts the duty to identify critical databases and applications on you, and requires the identified ones to be in the audit scope. | Identification itself, which is the step that silently removes the asset. An unidentified critical database is out of scope by omission rather than by decision, and nobody has to say no for it to happen. |
| Source code, DAST and SAST | Source Code Review is class §6(ix) and sits inside the audit scope in its own right under §13.1.1(a). §13.1.3(iii) requires the audit of an identified critical application to include DAST and SAST. | Repository access or a reviewed export, the build toolchain, and — for the procurement leg — an RFP clause requiring it. | The clause most buyers have never read: §13.1.3(iii) also requires that when procuring the application, the auditee “should require that the software developer and/or system integrator supplying the software, perform Static Application Security Testing (SAST)”, and that this “should be clearly stated in the RFPs and tenders”. Integrators offer a binary and call the code proprietary, and the time to close that is the tender, not the audit. |
| Network devices, OT and ICS | Network infrastructure Audits at §6(v). ICS/OT Security Testing at §6(xix), defined as evaluating the posture of industrial control systems and operational technology networks to identify vulnerabilities and threats that could disrupt critical industrial processes. Device Level Audit (DLA) is a named audit type at §13.2.3(i)(a). | A device inventory with firmware versions, network diagrams, and — for OT — a named engineer who can stop the test. | Active testing, and correctly so. §15.2.2(iv) says that in critical environments where availability is a top priority, testing should be conducted in a passive manner. What gets dropped wrongly is the passive work that should replace it: configuration review, firmware currency, segmentation verification. |
Two clauses in that table are worth pulling out because they are the ones buyers have most often never read. §13.1.3(i) puts the duty to identify critical databases and critical applications on the auditee, and requires the identified ones to be in the audit scope — so an unidentified critical database leaves the scope without anybody saying no to it. §13.1.3(iii) then requires the audit of an identified critical application to include DAST and SAST, and adds a procurement duty most organisations discover too late: when buying the application, the auditee “should require that the software developer and/or system integrator supplying the software, perform Static Application Security Testing (SAST)”, and this “should be clearly stated in the RFPs and tenders”. The time to secure access to source code is the tender, not the audit.
A scan is not an audit, and the Top 10 is not a standard
Section 8 of the Comprehensive Cyber Security Audit Policy Guidelines is headed “Applicable standards and Frameworks”. Its first two clauses say something that most of the Indian VAPT market has not absorbed, and they say it about two things that market sells routinely: an automated scan, and a scope written around the OWASP Top 10. Both clauses are reproduced in full below, because paraphrasing them weakens them.
“Auditing organization must utilize industry standard methodologies, best practices for security testing. Solely tools-based testing should be discouraged as tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure. This limitation can result in an incomplete view of the overall security.”
“The limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits. Instead, audits should include discovery of all known vulnerabilities based on the comprehensive standards/frameworks like ISO/IEC, Cyber Security Audit Baseline Requirements, CSA Cloud Controls Matrix (CCM) for Cloud Security, Open Source Security Testing Methodology Manual (OSSTMM3), OWASP Web Security Testing Guide … OWASP Application Security Verification Standard (ASVS) … the OWASP Mobile Security Testing Guide (MSTG) … OWASP DevSecOps Maturity Model …”
What §8(i) rules out
Delivering a scanner export as an audit. Note the reason CERT-In gives, because it is the useful part: tool-based audits “may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure”. The objection is to coverage, not to tools.
What §8(i) does not rule out
Using tools. The word is “solely”. A vulnerability assessment is supposed to be tool-driven — that is how you examine ten thousand assets. What the clause forbids is stopping there and calling the result an audit.
What §8(ii) changes in a scope of work
The audit criterion. A scope that says “tested against the OWASP Top 10” names an awareness list, while a scope that says “tested per the OWASP Web Security Testing Guide, verified against ASVS 5.0.0 Level 2, programme built from the Cyber Security Audit Baseline Requirements” names a method, a requirement set and a baseline.
There is a real tension here and it is better named than smoothed over. The GIGW 3.0 manual — the guidelines for Indian Government websites and apps, whose cybersecurity chapter was formulated by CERT-In — names the OWASP Top 10 among the industry best security practices its cybersecurity chapter preamble requires the host service provider and the developer to adhere to, alongside ISO 27001, OWASP ASVS and CIS benchmarks, and it names the Top 10 and ASVS again in guideline 5.3.1’s government-organisation action. Published certificates go further and print the Top 10 as the audit methodology itself: the Web Security Audit Certificate published by the Indian Institute of Corporate Affairs (Ministry of Corporate Affairs), issued 11 July 2024, concludes that the “Web Application is audited against vulnerabilities including OWASP 2021 Top 10 and is safe for hosting.” Read carelessly, that looks like a contradiction of §8(ii).
Read carefully, the two instruments are doing different jobs, and this distinction is our reading rather than something either document states. GIGW names the Top 10 as a development and hosting practice to adhere to — a thing builders should know about. §8(ii) governs what an audit is conducted against — the criterion against which coverage is claimed. A list of ten common categories can be a perfectly good awareness reference and a poor audit criterion at the same time, for the same reason that a list of the ten commonest causes of house fires is useful to a homeowner and useless as a building inspection standard. Where the two collide in practice is on the certificate, and the honest thing for a buyer to do is to ask for the methodology alongside it. More on that on what a safe-to-host certificate is.
The frameworks §8(ii) points at, and the job it gives each one
Which standards should a VAPT be conducted against?
The clause does not merely say what not to use. It names replacements, and it assigns most of them a purpose in the same breath. Copy the relevant rows into your scope of work with a version number against each, and you have converted an argument about quality into a checkable specification.
| Named in §8(ii) | What it is | The job the guidelines give it |
|---|---|---|
| Cyber Security Audit Baseline Requirements cert-in.org.in | National Security Council Secretariat, publication NSCS-46-16 Rev 1.0, October 2020, published on CERT-In’s website. Its abstract states that it “provides the minimum-security assurance baseline expected across the Cyber Information Infrastructure of organisations and form the criterion for conduct of Cyber Security Audits”. | §8(iii) and §13.1.8(i) both say, in identical words, that it “should be used by auditees and auditing organizations to build their audit program”. This is the document a scope of work should start from, and it is named twice in the guidelines for emphasis. |
| OWASP Web Security Testing Guide (WSTG) | A testing methodology: what to test on a web application and how to test it, organised by category rather than by a ranked list of the year’s most common defects. | §8(ii) names it “for web application security testing”. It is the answer to “which methodology did you follow”, which is a question the OWASP Top 10 cannot answer because it is not a methodology. |
| OWASP Application Security Verification Standard (ASVS) owasp.org | A list of verifiable security requirements at three assurance levels. Level 1 is the lowest and is fully testable from outside. Level 2 is for applications handling sensitive data and is the level recommended for most applications. Level 3 is reserved for applications needing significant verification, such as health and safety, military and critical infrastructure. | §8(ii) names it “for establishing and verifying application security controls”. Name the version as well as the level: the current stable release is ASVS 5.0.0 (May 2025) and the level definitions were restructured between 4.0.3 and 5.0.0, so “ASVS Level 2” without a version is ambiguous. GIGW names ASVS without naming a level at all, which makes the level the department’s choice and puts it in the scope of work. |
| OWASP Mobile Security Testing Guide (MSTG) | The mobile counterpart to the WSTG. | §8(ii) names it “for mobile app audits”. A mobile application audit that reuses a web methodology is not covering the platform-specific surface — storage, inter-process communication, certificate handling, the binary itself. |
| OWASP DevSecOps Maturity Model | A maturity model for the build and deployment pipeline rather than for the application it deploys. | §8(ii) names it “for assessing Continuous Integration / Continuous Deployment (CI/CD) pipeline security”. The pipeline is a production system with deployment rights, and a scope that stops at the running application leaves it untested. |
| Open Source Security Testing Methodology Manual (OSSTMM3) | A testing methodology with a defined measurement approach, spanning more than application testing. | Named in §8(ii) among the comprehensive standards an audit should discover known vulnerabilities against. |
| CSA Cloud Controls Matrix (CCM) | A cloud control framework. | §8(ii) names it “for Cloud Security”. A cloud assessment scoped as a web application test with the word cloud in the preamble is not testing the control plane, and §13.1.1(a) puts cloud inside the audit scope in its own right. |
| ISO/IEC standards, plus CERT-In and regulator directions | §8(ii) names “ISO/IEC” and, at the end of the same sentence, “applicable regulatory framework and directions & guidelines issued from time to time by agencies such as CERT-In, Government and regulatory bodies”. | §8(iv) and §13.1.8(ii) both say, in identical words, that “Guidelines and directions issued by CERT-In and regulators to be included as part of scope of audit by default.” Default means you do not have to ask for it — but you should check it is there. |
One clause adds a requirement that is easy to miss and expensive to discover late. §8(v) provides that for audits of critical applications, databases or platforms of Ministries, Departments, Secretariats and Offices, wherever sensitive personally identifiable information is involved, the auditing organisation “shall verify compliance with the ‘Comprehensive Audit Program Checklist – Cyber and Information Security Audit’” set out in the “Guidelines on Mandatory Features of Cybersecurity Architecture to be Ensured in all Ministries/Departments” issued by the Cyber Security Division of the Ministry of Electronics and Information Technology — a checklist “comprising 282 control points” which “shall form the default mandatory audit scope for such entities”. If you are in that population, 282 control points is your floor and a web application test is a fraction of it.
Scope is the field that decides what the result is worth
What should a VAPT scope of work contain?
§13.1.1 of the 2025 guidelines is titled “Defining and finalizing audit scope” and it uses letters, a) to g), rather than roman numerals. Each letter converts directly into a line of a statement of work, and each one carries a test a buyer can run on a scope they have already signed. This is the clause that separates a VAPT of your systems from a test of your login page.
| §13.1.1(a) | The scope covers the entire cyber infrastructure: web and mobile applications, network, OT and ICS, cloud, APIs, databases and hosting infrastructure, code review, application security, data security and incident-response testing. | Read your last statement of work against that list and mark what is missing, then add the line the clause implies and almost no scope states: how many distinct privilege levels exist in each application, and how many of them will be tested with an account of their own. In the scopes we are asked to review, most name one or two of these surfaces and are silent about the rest — which is a legitimate commercial choice, and a very different thing from the comprehensive audit §6 says an auditee is expected to ensure at least once a year. The silence is the problem, not the narrowness: a scope that says what it excludes is honest, and a scope that simply does not mention the rest is not. |
| §13.1.1(b) | The scope is defined by the auditee in consultation with the auditing organisation. | If the scope arrived as a fixed package from the vendor with a price attached and nobody on your side wrote a line of it, the clause has been inverted. The auditee defines and the auditor advises. |
| §13.1.1(c) and §13.2.3(ii)(b) | The scope “must be derived from the consolidated and updated asset inventory”, and the date to which that inventory was updated must be reflected in the audit reports. | Ask for the as-of date. This single field is what converts a coverage claim into a checkable one: an inventory current to March does not support a May scope, and the report is supposed to say so. |
| §13.1.1(d) | The scope is vetted by the internal audit team in consultation with the CISO. | A scope signed off only by the team that owns the systems being tested is a scope with an obvious incentive problem. The clause puts a second pair of eyes on it deliberately. |
| §13.1.1(e) | Testing, UAT, development and production assets are all included, “to achieve complete audit coverage”. | Ask what your non-production environments hold. Development and UAT systems that carry copies of production data are production systems with weaker controls and a smaller audience of people who remember they exist. |
| §13.1.1(f) | Third-party, vendor and supply-chain risk assessment is part of the scope. | Name the integrations and the dependencies. A test that stops at your own code stops short of where a large share of real incidents start. |
| §13.1.1(g) | The scope of work “should clearly specify the requirement to conduct follow-up audits as part of the engagement”. | Find the re-test in the statement of work and the price. §9.3(iv) puts follow-up audits “within the scope or RFP proposal”, to be conducted after closure of the issues found. An engagement priced without one is priced for half the job. |
Two further requirements attach to the scope once it is fixed. §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be explicitly mentioned in both the audit scope and the report. And §13.1.4(i) requires that where any of the activities to be audited are outsourced, the auditee must ensure that relevant personnel from the outsourced organisation are available at the time of the audit — the clause that saves an engagement from stalling on day three because nobody at the managed service provider will answer the phone.
Fourteen questions to ask before you sign anything
What should I ask a VAPT vendor before signing?
Read these down the phone. Every one has a clause behind it, so none of them is an opinion a supplier can argue with, and the answers to the first three will usually tell you whether to ask the remaining eleven.
- 01 Which of the audit types at §13.2.3(i)(a) is this — VAPT, EAPT, web application, API, mobile, configuration, device level — and will that word appear in the scope of work?
- 02 What are the man-hours, as well as the calendar days, and how are the man-hours split between manual and tool-assisted work? (§13.2.2(ii))
- 03 Which methodology and which verification standard, at which version and level? “ASVS Level 2” without a version does not answer the question. (§8(ii))
- 04 Is the audit programme built from the Cyber Security Audit Baseline Requirements, as §8(iii) and §13.1.8(i) say it should be?
- 05 Which environments will be tested, and at what point does testing move from staging to production? (§15.2.3(i)–(ii))
- 06 How many distinct privilege levels exist in this application, how many will be tested, and who is issuing the accounts? (§15.1.2)
- 07 Which tools will you install, where have they been tested, and when do we review and approve those controlled-test results? (§13.2.2(iii)–(iv))
- 08 Where will our data live during the engagement, which platforms will carry it, and on what date will the deletion certificate be issued? (§10.3)
- 09 Who verifies the audit team’s work, and is that verification team separate from the people doing the testing? (§15.2.5(iii))
- 10 How will critical and high findings reach us during the engagement — on what channel, to which named person, on what timescale? (§16.3(ii), §16.4)
- 11 Is the follow-up audit in scope and in the price, and what does the revalidation cover? (§9.3(iv), §13.1.1(g))
- 12 Do you, or any affiliate or group entity, perform development, implementation or remediation work for us, now or in the last cycle? (§5(xvii), §7)
- 13 Will the working notes and the evidence appendix come with the final report? (§18(i))
- 14 When and how will the report and audit metadata go to CERT-In, and what does that submission contain? (§10.6, §13.2.1(iii))
What should a VAPT scope of work actually say?
Five paragraphs that turn §13.1.1(a)–(g), §8(ii) and §13.1.3 into contract language. Fill the bracketed fields, delete what does not apply, and have your own counsel read it — this is a starting point written from published clauses, not legal advice, and the clause numbers are there so your supplier can check them.
Type of audit. The engagement is a VAPT (Vulnerability Assessment and Penetration Testing) comprising a vulnerability assessment and a penetration test, conducted as two distinct phases in that order, in the sense given to those terms at §5(xxi) and §5(xxii) of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, dated 25 July 2025.
Audit criteria. Testing shall follow the OWASP Web Security Testing Guide. Application security controls shall be verified against the OWASP Application Security Verification Standard, version [X], Level [Y]. Mobile components shall follow the OWASP Mobile Security Testing Guide. Cloud components shall be assessed against the CSA Cloud Controls Matrix. The audit programme shall be built from the Cyber Security Audit Baseline Requirements. Limited lists, including the OWASP Top 10 and SANS Top 25, shall not be used as the audit criterion, in accordance with §8(ii).
Scope and inventory. The scope is set out in Annexure A, derived from the consolidated asset inventory as updated to [date], which date shall be stated in the audit report. Version-specific details of all web and mobile applications shall be stated in both the scope and the report. Critical databases and critical applications identified by [auditee] are listed at Annexure A and attract a database configuration audit and DAST and SAST respectively.
Access and coverage. [Auditee] shall issue temporary test credentials at each of the [N] privilege levels listed at Annexure B, to be revoked immediately on completion. Testing shall be performed on [named environment]. Where the scope is limited to a staging environment, the report shall state expressly that the audit was not conducted on the production environment.
Plan, reporting and closure. The test plan shall state both calendar time and man-hours. Critical and high findings shall be notified as and when found. The report shall carry the contents required by §16.1(ii), severities scored on CVSS and supplemented with EPSS with every observation mapped to CWE and, where one exists, CVE, and closure timelines by severity. A follow-up audit verifying closure is included in this scope of work and in the price.
Two fields do most of the work and are the two most often left blank: the ASVS version and level in the second paragraph, and the number of privilege levels in the fourth. A scope that fixes both has removed the two largest sources of disagreement about what was covered.
Seventeen artefacts a real engagement produces, and the clause that requires each
What are the deliverables of a VAPT?
Quality in this field is usually discussed in adjectives. The guidelines discuss it in artefacts, which is far more useful to a buyer, because an artefact can be asked for by name and its absence is a fact rather than an impression. Every row below is a document, a field or a step that a published clause requires. Ask for them in the scoping call, not in the dispute.
An audit engagement letter
The agreed terms “must be formally documented in an audit engagement letter”, reviewed and signed by authorised representatives of both organisations, serving as “a binding reference point throughout the engagement”. §14.2 requires scope revisions to be in writing with justification, approved by both sides, and documented as an addendum or a formal amendment.
Where it is missing: Scope disputes get settled by whoever remembers the kick-off call better. §14.3 even names the three legitimate triggers for a revision: newly discovered systems or processes presenting significant risk, changes in organisational structure, ownership or the regulatory environment, and security incidents or breaches occurring during the audit period.
A test plan with calendar time and man-hours
“The test plan shared by auditing organization must include both calendar time and man-hours.”
Where it is missing: This is the single most useful commercial check on the page. A three-week calendar window is not a statement of effort. Forty man-hours across three weeks and four hundred across the same three weeks are different engagements at the same duration, and only one of them is a penetration test.
A tool list, with licence and provenance confirmed
A list of tools with written confirmation of intellectual-property and licensing status, and the auditing organisation “must have a thorough understanding of the tools they use, including their origin and functionality”, with those tools “tested in a controlled test environment prior to deployment on the auditee’s systems” and the results “formally reviewed and approved by an authorized representative of the auditee organization”.
Where it is missing: Unlicensed or unexamined tooling is being run inside your estate on your authority. The controlled-test-and-approve step is also the moment you find out whether anybody on the auditor’s side can explain what the tool does.
Written approvals before testing starts
“Appropriate written approvals must be obtained prior to conducting any penetration tests”, with tool installation carried out in the presence of the auditee’s system administrator. Separately, “explicit written permission must be obtained from the auditee organization prior to conducting Denial-of-Service (DoS), Distributed Denial-of-Service (DDoS), or flood testing over the Internet to prevent disruption of services.”
Where it is missing: The protection runs both ways. The auditor is protected against an allegation of unauthorised access, and you are protected against an availability event during business hours that nobody authorised. §15.2.2(iv) adds that in critical environments where availability is a top priority, “testing should be conducted in a passive manner”.
A named environment, and a statement where it was not production
The environment — Test, Development, UAT, Pre-Production or Production — must be specified. Where an audit certificate is to be issued, the auditor is “required to audit and test the website on the staging server or testing environment provided by the hosting service provider prior to issuing the Audit Certificate”, with application hash values and version numbers obtained from the auditee and included in the report. And where the scope was limited to staging, “the report must explicitly state that the audit was not conducted on production environment”.
Where it is missing: Unstated environment is how a clean report ends up describing a build with authentication stubbed out, real integrations replaced by mocks, and no WAF in front of it.
A second team that checked the first
The 2025 guidelines require a maker-checker arrangement in which a separate verification team reviews and validates the work of the audit team. The 2018 auditor guidelines put it more concretely: “Auditors should deploy a verification team (Red Team) to verify the work performed by their audit team (White Team).”
Where it is missing: One layer of assurance where the instruments contemplate two. Ask who verified the testing and what the verification changed. “Nobody” and “nothing” are both answers worth having.
Findings scored with CVSS and supplemented with EPSS, mapped to CWE and CVE
§5(xxiv) defines both frameworks and states that “Auditors are required to implement both CVSS and Exploit Prediction Scoring System (EPSS) frameworks within their audit reports”, with observations categorised on CVSS for severity and supplemented with EPSS for the likelihood of real-world exploitation. §16.2(ii) repeats the duty and adds that “Every reported observation / vulnerability shall be mapped with Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE) number.”
Where it is missing: A severity column with no scoring basis is an opinion. EPSS is the interesting half of this requirement, because it is what stops a 9.8 nobody is exploiting outranking a 6.5 that is being exploited this week.
An executive summary written for the board
The report should carry an executive summary giving a concise overview of the findings including the associated risks and the overall security posture, intended for board members or top management, and it “should translate the technical findings into relevant business risks”.
Where it is missing: The report gets forwarded and not read, and the organisation makes its remediation decisions from a covering email.
Closure timelines by severity, and criticals raised as they are found
Critical and high findings are “required to be notified by the auditor to the auditee organization during the course of audit on as and when found basis”, as well as in the Final Outcome Report. The report must state closure timelines by severity. §16.4 requires high-risk vulnerabilities — discovered breaches, vulnerabilities with known high exploitation rates, unmonitored or untraceable access, or anything posing an immediate risk to life — to be reported to the auditee immediately on discovery, with a recommendation for a practical solution.
Where it is missing: You learn about a live exposure six weeks after the tester did. Note also §15.2.2(i), a different duty in a different clause: high-risk vulnerabilities such as discovered breaches “should be assessed and reported immediately to auditee organisation & CERT-In”. That one runs to the regulator as well, and it does not displace your own six-hour incident-reporting duty under the 2022 Directions.
Working notes and the evidence appendix
The auditee should seek the auditor’s working notes on completion, with provision for it in the contract, and the evidence as an appendix to the final report. §18(iii) requires that all observations be “well supported with objective evidences” compiled carefully and correctly with the report, and presented so that decision makers can use them “in making credible risk-based decisions”.
Where it is missing: You cannot reproduce a finding, which means you cannot verify a fix, which means closure is asserted rather than demonstrated.
A coverage statement, and a named list of what could not be reached
“All the assets provided in the scope by auditee organization must be mentioned in the report.” Where in-scope assets were inaccessible, §10.1(ii) requires the auditor to inform the auditee promptly, request resolution, and if unresolved name them in the report with reasons — and the same “must be brought to the notice of CERT-In”.
Where it is missing: The gap between what you paid to have tested and what was tested is invisible, and it is exactly where the next incident lives.
A follow-up audit that verifies closure
Follow-up audits “should be included within the scope or RFP proposal and must be conducted by the auditing organization after the closure of vulnerabilities or issues identified during the initial audit”. §16.3(iv) requires follow-up audits after remediation “to verify closure of vulnerabilities and non-conformities highlighted in the previous audit”, and §16.3(v) contemplates the final report being issued after closure and completion of the follow-up audit on the production environment.
Where it is missing: The engagement ends at the finding, which is the point at which none of the risk has yet been reduced. Patching is the auditee’s responsibility under §9.3(iii), but verifying that the patch worked is the auditor’s.
A signed NDA, dated before any audit activity
“A Non-Disclosure Agreement (NDA) must be signed by the Information Security Auditing Organization prior to the commencement of any audit activities”, and the auditing organisation and its auditors are described as ethically and contractually obliged to maintain the confidentiality of the auditee’s information and security testing results. CERT-In publishes an NDA template on its own website, which the clause points at by name, and the same clause allows you to add penal and legal liability provisions to the contract, extending them to the individual auditors if you wish.
Where it is missing: Your architecture, your credentials and a working list of ways into your estate are held by a third party under nothing but goodwill. Check the date on it: an NDA signed in week three of a four-week engagement was signed after the thing it was meant to protect had already been handed over.
A report that travels encrypted, to a named list
§13.2.5 requires a report distribution list of official auditee-side email IDs to be obtained before distribution, plus the mobile number of the designated contact for securely sharing the password to a password-protected report. §16.5 then governs the delivery itself: official email IDs only, the audit outcome communicated only to the specified point of contact, “using secure methods such as use of passwords, encryption etc.”, and all delivery channels “end to end confidential”.
Where it is missing: A VAPT report is a map of how to get in, circulated inside your own perimeter. The failure is almost never the auditor’s: it is the internal forward to fifteen people, none of whom were on the distribution list nobody agreed.
The enumerated estate the tester started from
This is the artefact that proves the assessment ran before the test rather than beside it: the enumerated asset-and-weakness list the penetration testers were handed, dated before the test window opened, and traceable back to the asset inventory the scope was derived from. Nothing names it in a single clause — it is what §13.1.1(c), the inventory as-of date at §13.2.3(ii)(b) and the every-asset-mentioned duty at §16.1(iii) produce between them when the sequencing is real.
Where it is missing: The two halves were run in one pass and the ordering claim is decorative. Ask for the handoff artefact by name and check two dates: the date on the enumeration, and the first date in the testing window. If the first is not earlier than the second, the assessment did not feed the test.
An account at every privilege level that is in scope
Privileged testing runs on temporary access — “login credentials, access tokens, certificates, or secure ID numbers” — that the auditee provides and that must be “revoked immediately upon completion of the audit”. The number of accounts is the thing to fix in the scope: one account per distinct privilege level that exists in the application, issued by you, with an expiry.
Where it is missing: The entire authorisation class of findings disappears. Broken object-level authorisation, horizontal escalation between tenants, a role check enforced in the interface and not in the controller — none of these can be found from outside, and none of them can be found from a single read-only login. Count your roles, then count the accounts issued, and write both numbers into the scope of work.
Last cycle’s findings, revalidated and marked as repeats
“The auditing organization must revalidate observations from the previous audit cycle, and any unresolved issues should be recorded as repeat observations in the current audit cycle.”
Where it is missing: A repeat finding presented as a new one hides the only trend that matters. A report with no repeats section is a report that has not looked at last year’s.
The report itself is the artefact everything else hangs from, and reading one properly is a skill of its own — which findings to believe, what the limitations paragraph is telling you, and how to tell a demonstrated path from a scanner entry with a paragraph of prose around it. That is the subject of reading a VAPT report, and closure and re-testing are the subject of VAPT re-testing and closure.
What the severities mean, and what closure each one requires
How are VAPT findings scored, and how long do you have to fix them?
§5(xxiv) of the 2025 guidelines is where the scoring rules live, and it requires two numbers rather than one. CVSS “provides a score from 0.0 to 10.0” which “can then be translated into a qualitative representation (such as low, medium, high, and critical)”, and EPSS “produces a probability score between 0 and 1 (0 and 100%)” estimating the likelihood that a vulnerability will be exploited in the wild. The clause then states plainly: “Auditors are required to implement both CVSS and Exploit Prediction Scoring System (EPSS) frameworks within their audit reports.”
Two things the guidelines deliberately do not do, and the table keeps them apart. They do not print the numeric CVSS bands — those belong to the CVSS specification and its qualitative severity rating scale, alongside the EPSS model. And they do not set the days: §16.3(iii) requires the audit report to “mention appropriate timelines for closure of vulnerabilities according to severity”, which makes the field mandatory and the number negotiable. Fix the numbers in your own policy and put them in the engagement letter, rather than discovering at the report what your auditor assumed.
| Band | Scoring basis | What happens during the audit | What closure requires | Who may accept it instead |
|---|---|---|---|---|
| Critical | CVSS 9.0–10.0 on the CVSS specification’s own qualitative severity scale. §5(xxiv) requires the CVSS score and its translation into a qualitative label, and requires EPSS alongside it, but it does not print the numeric bands itself. | Notified by the auditor during the course of the audit on an as-and-when-found basis under §16.3(ii), and again in the Final Outcome Report. Where it is a discovered breach, a known-high exploitation rate, unmonitored or untraceable access, or a risk to life, §16.4 requires immediate reporting with a recommended practical solution — and §15.2.2(i) adds CERT-In to that same immediate report. | Closed and verified in the follow-up audit. Where a certificate is in view, §16.3(v) contemplates the final report issuing after closure and the follow-up audit on production. | In practice, nobody. There is no route in the guidelines by which an auditor waives a critical finding, and no risk-acceptance form makes an exploited system compliant. |
| High | CVSS 7.0–8.9, weighted by the EPSS probability. | Same as critical under §16.3(ii): notified as and when found, not held for the draft. §16.4 is the clause to quote if your auditor holds a high-risk finding for the report. | Closed and verified. This is the band where a hosting gate, a customer questionnaire or a tender evaluation stops. | Risk treatment is authorised and accepted by the head of the auditee organisation under §9.2. If it is accepted rather than fixed, the acceptance and the authorising office belong in the report. |
| Medium | CVSS 4.0–6.9. Read with EPSS before anything else: a medium with a high exploitation probability is not a medium in practice, which is the whole reason §5(xxiv) and §16.2(ii) require the second score. | No as-and-when-found duty. It reaches you in the draft report with its CWE, its CVE where one exists, and both scores. | Closed, or formally accepted with a date. §16.3(iii) requires the report to state closure timelines by severity, so an open medium carries a date whether or not anyone has looked at it. | The head of the auditee organisation, under §9.2, with the exception recorded. Everything else goes to the risk register and returns next cycle as a repeat observation under §15.2.1(iii). |
| Low and informational | CVSS below 4.0, or observations carrying no score at all — configuration hygiene, missing headers, verbose errors, version disclosure. | Nothing. They appear in the report. | Tracked with a timeline under §16.3(iii). Not a blocker on their own, and they return as repeats if nothing is done. | The normal risk register. Worth noticing in aggregate rather than individually: forty low findings clustered on one component is a statement about that component. |
| Scored medium, high EPSS | The row that exists because §5(xxiv) requires two scores rather than one. CVSS says how bad it would be, while EPSS, on a scale of 0 to 1, says how likely it is to be exploited in the wild. | Nothing automatic, which is the point. Nothing in §16.3(ii) promotes it, so it is on you to read the second column. | Treat the EPSS probability as the sequencing input and the CVSS score as the impact input. This is what stops a 9.8 nobody is exploiting outranking a 6.5 that is being exploited this week. | Nobody should be accepting this one on the CVSS score alone. If your tracker sorts on severity and has no EPSS column, it is sorting on the wrong number. |
One column in that table is the clause-mandated part and the rest is yours. §16.2(ii) requires the scoring and the mapping of every observation to a CWE and a CVE number. §16.3(ii) fixes when criticals and highs must reach you. §16.3(iii) requires closure timelines by severity to be in the report. §9.2 puts risk treatment and exceptions with the head of the auditee organisation. The actual days, the acceptance thresholds and the escalation path are negotiated, and §13.1.7(iii) says the escalation matrix for repeated vulnerabilities belongs in the contract. What that means in practice is simple: a finding still open next cycle is not an engineering item, it is a governance one.
A VAPT engagement, in the order the instruments put it
What is the VAPT process, step by step?
Twelve steps, each one anchored to a clause. Most of them happen before anyone touches a system, which is the opposite of how these engagements are usually planned and the reason so many of them produce a document rather than a reduction in risk.
Decide which audit you are buying, before you ask for a price
§13.2.3(i)(a) requires the scope to state the type of audit — VAPT, external attack penetration testing, device level audit, configuration audit, process audit, mobile application security audit, web application security audit, API security audit, compliance audit and more. Those are different engagements with different deliverables, and the most expensive mistake in this field is discovering at the end that you bought one and needed another.
Build the scope from an asset inventory with a date on it
§13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory, and §13.2.3(ii)(b) requires the date to which that inventory was updated to appear in the audit reports. Version-specific details of web and mobile applications must be explicitly mentioned in both the scope and the report, under §13.2.3(ii)(c). §13.1.3(i) adds the identification duty that decides whether your databases and critical applications are in scope at all.
Have the scope vetted by someone who does not own the systems
§13.1.1(d) puts it with internal audit in consultation with the CISO. Include test, UAT, development and production assets under §13.1.1(e), third-party and supply-chain risk under §13.1.1(f), and the follow-up audit under §13.1.1(g). Count your privilege levels while you are here, because the number of accounts you issue decides whether the authorisation findings are reachable at all.
Name the standards, not the list of defects you hope it finds
§8(ii) is explicit that limited lists such as the OWASP Top 10 and SANS Top 25 should not be considered standards or references for audits, and names what should be used instead. Put the ASVS version and level in the document, because the level is your choice and nobody else will make it. §13.1.7(i)(a) repeats the same framework list as a contract term, which is where it is easiest to enforce.
Sign the NDA, then fix the terms in an audit engagement letter
§13.1.7(ii) requires a Non-Disclosure Agreement to be signed by the auditing organisation before the commencement of any audit activities, and points at CERT-In’s own NDA template. Penal and legal liability provisions may be added to the contract and may extend to the individual auditors. The terms then go into an audit engagement letter signed by authorised representatives on both sides under §14.1(ii). Agree the escalation matrix for both organisations under §13.2.6 and for repeated vulnerabilities under §13.1.7(iii). Agree the report distribution list under §13.2.5, and read it against the delivery rules at §16.5 — official email IDs, the specified point of contact only, passwords or encryption, channels end to end confidential.
Obtain the written approvals before anything is touched
§13.2.2(v) for penetration tests and tool installation, with installation in the presence of your system administrator. §15.2.2(ii) for anything resembling denial of service or flood testing over the internet. §15.2.2(iii) before any process or social-engineering testing, which must use anonymised or statistical techniques against staff inside the agreed group, must not identify or penalise an individual, and must not involve customers, business partners, vendors or other third parties without specific written consent.
Prepare the environment, the accounts and the watchers
§15.2.3(i) requires the environment to be stated, and where a certificate is in view, §15.2.3(ii) requires testing on the staging or testing environment provided by the hosting service provider before the certificate is issued, with hash values and version numbers from you. §15.1.2 covers temporary privileged access — credentials, tokens, certificates or secure ID numbers — revoked immediately on completion. §15.1.1 limits notification of the test to key personnel, generally policy-level staff and the managers responsible for security processes, incident response and security operations, and asks that no unusual or major network changes be made during the window.
Run the assessment first and let it feed the test
Breadth establishes what exists, and depth establishes what it costs. The artefact that proves the sequencing happened is the enumerated asset-and-weakness list the testers started from, dated before the test window opened — ask for it by name. Expect §15.2.1(iii) to be honoured on the way in, with last cycle’s observations revalidated and unresolved ones carried as repeats, and §15.2.1(iv) to be honoured throughout, which requires verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with findings and evidence in the report.
Take the critical findings as they arrive, not at the end
§16.3(ii) requires as-and-when-found notification of critical and high findings, and §16.4 requires immediate reporting of high-risk vulnerabilities with a practical recommended solution. §13.2.7(iii) additionally requires notification of any change to the audit plan or the source test venue, of high-risk findings, before new, high-risk or high-traffic tests, of any testing issues, and progress updates at reasonable intervals. Your side of the same period is §15.1.3: monitor execution and timelines through the scheduled progress meetings, and track closure of the assessment phase, the re-validation phase and overall completion. §15.2.7 puts the review meetings with your SPOCs on the auditor.
Read the report for its limits before you read it for its findings
§16.1(ii) requires the report to cover the audit process, detailed scope, duration, methodologies and standards used, tools, manual process, findings, prioritisation, sampling decisions, manpower involved, exemptions, limitations and other constraints. The limitations paragraph tells you what the conclusion is silent about, and it is the paragraph most often skipped.
Close the findings, then have the closure verified
Patching is yours under §9.3(iii), but the follow-up audit that verifies it is the auditor’s under §9.3(iv) and §16.3(iv). Keep the re-test artefacts with the report, and ask for the working notes and evidence appendix §18(i) contemplates while the team still remembers the engagement. A closure column filled in by the people who wrote the fix is a self-assessment wearing a report’s formatting.
Classify every change from that point on — and give feedback
§13.1.2(i) sets the floor at one audit a year and notes that sectoral regulators may increase the frequency. §13.1.2(ii) says the stated frequency is a minimum. §13.1.2(iii) requires every change to be classified Minor or Major, with a Major Change — “high-risk, impactful to security”, expressly including configuration adjustments affecting sensitive data or critical infrastructure — requiring a cyber security audit before implementation. Note what “major” means there: risk, not size. Then close the loop §11(iii) asks you to close: auditee feedback to CERT-In on completion is described as both a right and a duty, kept confidential and acted on promptly, with the form available from empanelment@cert-in.org.in.
What a real VAPT looks like when you count the days
How long does a VAPT take, from scope freeze to final report?
The engagement below is invented and the numbers are deliberately ordinary — a mid-sized estate, three hostnames, five privilege levels, one mobile build, one critical database. It is here so that the clauses above have a shape you can hold a proposal against. It is not a client, not a sector, and not a claim about outcomes. It is one plausible run of the twelve steps, with the artefact each gate produces and what it looks like when that gate is skipped. Seventy-three days from scope freeze to final report, of which fifteen are testing.
| Day | Gate | Artefact produced | Who owns it | What it looks like when it goes wrong |
|---|---|---|---|---|
| Day −21 | Scope frozen against a dated inventory | Scope schedule: 3 hostnames (public portal, admin console, partner portal), 5 privilege levels, 2 API base paths, 1 mobile build, 1 cloud subscription, 1 database identified as critical. Asset inventory extract marked “updated to 12 March”. | CISO and internal audit, per §13.1.1(c) and (d) | The scope is copied from last year’s annexure. The partner portal, which went live in October, is not on it — and nobody discovers that until the report lists three hostnames. |
| Day −14 | Test plan agreed, in both units | Test plan: 15 calendar days, 240 man-hours, split 70 manual / 170 tooling-assisted across the six surfaces. Five test accounts requested, one per privilege level, with a stated expiry. | Audit lead to the technical point of contact, per §13.2.2(ii) | Only calendar days are quoted. Fifteen days can be 40 man-hours or 400. The invoice looks the same and the engagement is not. |
| Day −10 | NDA, then the audit engagement letter | NDA signed before any activity. Engagement letter carrying the audit criteria (WSTG for method, ASVS 5.0.0 Level 2 for requirements, Cyber Security Audit Baseline Requirements for the programme), the plan, the deliverable structure, the escalation matrix, the revalidation clause, the data-retention terms and the report distribution list. | Authorised representatives of both organisations, per §13.1.7(ii) and §14.1(ii) | A purchase order instead of an engagement letter. §14.2 then has nothing to amend when the scope moves, and it will. |
| Day −3 | Pre-audit discussion closes the expectation gap | Minute recording the audit type, the report format, the standards, the assets, data handling and retention, the timeline, and the disclosure that the report and metadata go to CERT-In within five days. | Both sides, per §13.2.3(i) and §13.2.4(i) | It is skipped as a formality. Every argument it would have settled arrives in week three instead, priced as a change request. |
| Day 1–5 | Assessment: breadth across the whole estate | Enumerated asset-and-weakness list across all six surfaces, dated day 5. Authenticated and unauthenticated scanning, configuration review, dependency analysis. 94 raw observations before triage. | Assessment team | The assessment and the test run in the same pass. The tester then starts from a guess about where to look rather than from an enumerated estate, and the ordering claim in the proposal is decorative. |
| Day 6 | Handoff — the artefact that proves the sequencing | The day-5 enumeration handed to the penetration testers, with 94 observations triaged to 38 worth pushing on and 6 candidate chains marked for manual work. | Assessment lead to test lead | There is no handoff artefact, so there is no way to show afterwards that breadth informed depth. Ask for it by name and check the two dates. |
| Day 6–15 | Penetration test: depth, at every privilege level | 31 confirmed observations, each with CVSS and EPSS and mapped to a CWE, 9 carrying a CVE: 2 critical, 5 high, 11 medium, 13 low. Two of the criticals are authorisation defects reachable only from an authenticated session, which is why five accounts were issued rather than one. | Test team | One read-only account is issued. The authorisation class of findings does not appear, and the report is clean about the part of the application that matters most. |
| Day 8 | A critical, notified the day it was found | Written notification of a broken object-level authorisation defect on the partner portal — changing an identifier in a request returns another partner’s records — with a recommended practical fix, to the named point of contact on the agreed channel. | Audit lead, per §16.3(ii) and §16.4 | It is held for the draft report. You carry the exposure for two more weeks for no reason at all, and the developer gets the fix window compressed. |
| Day 22 | Draft report and exit conference | Draft report with the §16.1(ii) contents, an executive summary written for the board, closure timelines stated by severity, every in-scope asset listed, and one asset named as inaccessible with the reason. | Auditing organisation to senior management, per §16.2(i) and §17(iii) | A PDF arrives and nothing is agreed. Remediation then competes with the delivery backlog and loses. |
| Day 23–40 | Remediation build | One release closes both criticals, 4 of the 5 highs and 7 mediums. The fifth high sits in a shared identity component the team does not own and is escalated to its owner. New build tag, new hash, recorded against the change register. | Engineering, per §9.3(iii) | Findings are closed on a spreadsheet by the people who wrote the fixes, and the tracker records a claim rather than evidence. |
| Day 41–44 | Follow-up audit | Retest confirming closure of both criticals and 4 highs, with the fifth closed by the component owner on day 43 and retested on day 44. Two mediums formally risk-accepted in writing with dates. Two observations carried from the previous cycle are recorded as repeat observations. | Auditing organisation, per §16.3(iv) and §15.2.1(iii) | There is no line item for it in the purchase order, so it becomes a variation order, a finance cycle and three weeks of slip. |
| Day 45–52 | Final report, closure pack, deletion certificate | Final report issued after closure and the follow-up audit, signed by the auditors, a mid-management reviewer outside the audit team and the head of the auditing organisation. Working notes and evidence appendix supplied. Test credentials revoked. Data deletion certificate issued. Feedback filed with CERT-In. Scope freeze to final report: 73 days. | Audit file owner, per §9.5(iii), §10.3(iv), §18(i) and §11(iii) | The deletion certificate is never requested and never issued, and a copy of your exploit paths sits on a laptop for the §10.3(vi) default year. |
Two numbers in that run are the ones worth carrying into a negotiation. Fifteen testing days against 240 man-hours is roughly two people across the window, which is what six surfaces and five privilege levels cost, and twenty-one of the seventy-three days happen before anybody touches a system. An engagement that starts testing the week after the purchase order has not compressed the schedule — it has skipped the scope, the inventory date, the engagement letter and the approvals, which are the four things the report will later be judged on.
What drives the cost and duration of a VAPT
How much does a VAPT cost in India, and how long does it take?
No figures here, and that is a considered position rather than an evasion. A price quoted without a scope is a number attached to nothing, and the whole argument of this page is that the scope is what decides whether the result is worth anything. What is useful is the arithmetic: the drivers below are the variables every honest quote is built from, and once you know them you can read a proposal instead of comparing two totals.
| How many assets, and from which inventory §13.1.1(c), §13.2.3(ii)(b) | Hostnames, package identifiers, API base paths, databases, network devices and cloud accounts are each a unit of work. The inventory the scope is derived from, and its as-of date, decide the count — which is why an out-of-date inventory produces a cheap quote and an expensive surprise. |
| How many privilege levels will actually be tested §15.1.2 | This is the multiplier most quotes ignore. A web application tested unauthenticated is one pass. The same application tested at five privilege levels, with the transitions between them probed, is closer to six — and it is the only version in which the authorisation findings exist. |
| How many environments, and whether any of them is production §13.1.1(e), §15.2.3(i)–(ii) | Test, UAT, development and production are all inside the scope the clause describes. Production work brings change windows, passive techniques where availability is critical under §15.2.2(iv), and coordination with whoever watches the logs. All three cost time rather than skill. |
| Which of the twenty-six classes are genuinely in play §6 | A web application test and a cloud control-plane review are different engagements with different people. Source code review at §6(ix), mobile at §6(xiii), APIs at §6(xii), OT at §6(xix) — each one you add is a specialist, not an extra afternoon. |
| The split between manual and tool-assisted effort §8(i), §13.2.2(ii) | The clause that says solely tools-based testing should be discouraged is, commercially, a statement about labour. Manual depth is the expensive half and the half §8(i) protects, which is exactly why §13.2.2(ii) makes the test plan state man-hours as well as calendar time. |
| Whether the follow-up audit is inside the price §9.3(iv), §13.1.1(g), §12.4(i) | A quote without a re-test is a quote for half the job, and it will always look cheaper than one that includes it. §12.4(i) goes further for critical or high-user-reach applications and recommends a two-to-three-year contract rather than an annual procurement. |
| What your own side has ready on day one §13.1.4(i)–(ii), §15.1.2 | The cheapest engagement is the one that does not wait. Accounts issued at every level, a technical point of contact assigned under §13.1.4(ii), outsourced-provider personnel available under §13.1.4(i), and an environment that exists. Every day the team waits is a day you bought. |
The arithmetic to run on the man-hours number
This page tells you several times to ask for the man-hours, because §13.2.2(ii) requires the test plan to carry them. Here is what to do once you have the figure. Count the surfaces in scope — each hostname, each API base path, each mobile build, each cloud account, each database, treated separately. Count the privilege levels that will actually be tested. Multiply, then divide the quoted man-hours by the result. That is the effort each surface at each level is getting. When the answer is a handful of hours, the engagement is an assessment: enough time to run tooling across the surface, not enough to sit with it. When the answer runs to days, somebody is going to think about your application.
Then ask for the split. A quote of 240 man-hours that is 220 hours of tooling and 20 of manual work is a different product from the reverse at the same price, and it is the one §8(i) is written about. Duration follows the same logic: calendar time is a scheduling statement, and a three-week window means nothing on its own — a week of which is a change freeze and two days of which are waiting for accounts is a five-day engagement wearing a three-week label.
Twelve ways a VAPT produces a document instead of an answer
Why do VAPT engagements fail?
Every one of these is common, every one has a published clause behind it, and every one carries a diagnostic you can run against an engagement you have already bought. None of them requires you to be a tester to spot.
The scan is the deliverable
Surfaces at
Scoping, confirmed at the findings report
The signal
The proposal quotes a calendar window and no man-hours. The report’s findings all carry a tool name in the evidence and none carries a request sequence.
What it costs to recover
The engagement, plus the one you now have to buy properly. There is no way to retrofit manual depth onto a test that has already been billed and closed.
A scanner runs, the false positives are trimmed, severities are copied across from the tool, and the output is bound with a cover page and delivered as a penetration test. A scanner export sold as a test is what §8(i) is written against: solely tools-based testing “should be discouraged” because 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 said the same thing seven years earlier in one sentence.
Diagnostic: Read the findings for evidence of a second request. Business-logic abuse, an authorisation boundary crossed, two weaknesses chained into a path, anything that required the tester to understand what the application is for. A report with none of those is an assessment being sold as a test, whatever the invoice says.
The scope of work names the OWASP Top 10 as the standard
Surfaces at
Scoping — usually invisible until a customer or evaluator reads the report
The signal
The audit criterion line in the statement of work reads “OWASP Top 10” with no methodology and no verification standard beside it.
What it costs to recover
A report whose coverage claim cannot be stated, and an argument with a customer’s security reviewer that you will lose on the document rather than on the security.
§8(ii) could not be plainer: “The limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits.” The Top 10 is an awareness document about categories of risk that were common in a given period. It is not a methodology, it has no coverage claim, and testing “against the Top 10” is a statement about what the tester intended to look for rather than about what the application is.
Diagnostic: Search your last three statements of work for “Top 10”. Where you find it as the audit criterion, replace it with a methodology and a verification standard: the OWASP Web Security Testing Guide for the method, ASVS at a named version and level for the requirements, and the Cyber Security Audit Baseline Requirements for the programme. Keep the Top 10 if you like — as a developer-awareness reference, which is what it is.
Nobody says which environment was tested
Surfaces at
First test pass, discovered when production behaves differently
The signal
The environment line is blank, or reads “as provided”. Production integrations, data volumes and edge components appear nowhere in the findings.
What it costs to recover
A production-side pass, or a result you cannot honestly represent to anyone who asks what it covered.
§15.2.3(i) requires the environment to be specified, and §16.3(v) requires a report limited to staging to say explicitly that the audit was not conducted on production. Silence on this point is how a clean result ends up describing a build with authentication stubbed out, integrations mocked, no WAF, no rate limiting and a database of synthetic rows.
Diagnostic: Ask one question in the scoping call and write the answer down: what does the tested environment lack that production has? Every gap in that answer is a class of finding the audit could not reach.
The firm that built it is the firm that tests it
Surfaces at
Selection — and it never surfaces on its own
The signal
The bid comes from a group entity of your development vendor, or the same proposal prices remediation alongside the audit.
What it costs to recover
Nothing visible, which is exactly the problem. You pay for assurance and buy a second opinion from the first opinion.
§5(xvii) defines conflict of interest and expressly covers “scenarios where the same entity is involved in both the implementation of controls and their subsequent audit, or in conducting audits while also being responsible for remediation activities”, noting that “such overlaps create inherent conflicts that undermine the independence of the audit process”. §7 puts independence, objectivity and professional skepticism at the head of the basic principles, and states that payments “should not be contingent upon the outcome of the audit”.
Diagnostic: Map the entities. If the development vendor, the managed service provider and the auditor are the same group, or the auditor is also contracted for remediation, the finding is structural and no amount of competence fixes it.
The application never had secure design practices to begin with
Surfaces at
First test pass, when the finding count arrives
The signal
Findings clustered on authorisation and input handling, no threat model, no SAST run, and a developer who cannot name a secure-coding standard.
What it costs to recover
Remediation that is a rewrite, on a timeline nobody planned for. §9.4(ii) says the place to fix this is the build RFP.
Two clauses deal with this and they are stronger than most buyers expect. §8(vii) requires auditee organisations to confirm that applications are designed and developed with secure practice before any assessment commences, pointing at CERT-In’s Guidelines for Secure Application Design, Development, Implementation & Operations. §8(viii) goes further: an application developed without any secure design and development practices “should not be considered for assessment and audits”, and the same “should be informed to the auditee organization in writing with a copy marked to CERT-In”.
Diagnostic: Ask the developer for the secure-development evidence before you book the auditor. An audit is not a substitute for having built the thing properly, and on this reading it is not even available as one.
The audit is bought to satisfy a form
Surfaces at
Scoping, visible at the distribution list
The signal
The report goes to procurement and to the customer, and the engineering team that owns the code is not on the list.
What it costs to recover
The findings are never worked. The money is spent, the document exists, and the posture is where it was.
§8(ix) says the auditing process “should be viewed as a tool for the continual process improvement of the auditee organization’s security posture, rather than a mere formality for compliance”, and that audits “must not be conducted solely for the sake of fulfilling regulatory requirements”. An engagement designed to produce a document rather than to find things will succeed at exactly that.
Diagnostic: Look at who receives the report internally. If it goes to procurement and the customer and nowhere near the engineering team that owns the code, the engagement has already been scoped as paperwork.
Availability testing happens without written permission
Surfaces at
Test window, at the moment of the outage
The signal
There is no per-class written permission in the file — just one kickoff signature covering “the engagement”.
What it costs to recover
An availability incident during business hours that nobody authorised, and an argument about liability in which the engagement letter is silent.
§15.2.2(ii) requires explicit written permission before denial of service, distributed denial of service or flood testing over the internet, “to prevent disruption of services”. The 2018 auditor guidelines go further and simply tell auditors to refrain from DDoS testing over the internet, and from “any form of flood testing where a person, network, system, or service, is overwhelmed from a larger and stronger source”. §15.2.2(iv) adds that in critical environments where availability is a top priority, testing “should be conducted in a passive manner”.
Diagnostic: Agree the prohibited classes in the engagement letter, with a named window for anything that could affect availability and a named person on your side who can stop it. Then ask how availability-affecting weaknesses will be evidenced without being exercised — configuration and architecture review is a good answer, silence in the report is not.
Social engineering reaches people who never agreed to it
Surfaces at
Test window, at the first escalation from a manager
The signal
The scope names “employees” rather than a bounded group, and the reporting format is a list of names rather than a rate.
What it costs to recover
An HR problem and a trust problem, neither of which a security finding pays for. §15.2.2(iii) is the clause you will wish you had quoted.
§15.2.2(iii) requires anonymised or statistical techniques so that no individual is identified or penalised, limits the exercise to employees inside the agreed scope, and states that it “must not involve external entities such as customers, business partners, vendors, or other third parties, unless specific written consent is obtained”. The empanelment terms carry the same expectation, in the 2018 lineage, as items 14 and 15 of Annexure I.
Diagnostic: Before any phishing simulation, settle two things in writing: which population is in scope, and what happens to the names of the people who click. The correct answer to the second is that there are no names.
The re-test never happens
Surfaces at
Retest
The signal
The auditor quotes for the retest. That quote is the signal, because it should have been in the original price.
What it costs to recover
A variation order, a finance approval cycle, and weeks of slip on a committed date — which is why §12.4(i) recommends two-to-three-year contracts for critical or high-user-reach applications rather than a fresh procurement each cycle.
The engagement is priced to the report, the findings are closed on a spreadsheet, and nobody ever verifies the fix. §9.3(iv) puts follow-up audits inside the scope or RFP proposal, to be conducted after closure. §16.3(iv) requires them to verify closure of the vulnerabilities and non-conformities from the previous audit. §16.3(v) contemplates the final report being issued after that follow-up on the production environment. Until the re-test happens, none of the risk you paid to discover has actually been reduced. §12.4(i) points at the structural fix: contracts for the audit of applications that are critical or have high user reach “should be awarded by auditee organizations for a period of 2–3 years to enable continuous audits at a defined frequency”, with §12.4(ii) requiring the agreement to let you stop the audit and choose another organisation if the auditor’s credibility becomes unclear.
Diagnostic: Find the re-test line item in your last purchase order. If it is not there, it was not bought, and the closure column in your tracker is self-assessment.
Data leaves India, quietly, through a platform nobody named
Surfaces at
Scoping, discovered at the deletion certificate or not at all
The signal
Nobody can name where the scanning platform, the jump host and the findings tracker are hosted, and no deletion certificate is scheduled.
What it costs to recover
An unquantifiable exposure and a data-residency finding of your own. Cheaper to ask three questions in the scoping call than to reconstruct it afterwards.
§10.3 requires auditee data to be stored only on systems located in India, encrypted on the auditor’s laptop, and wiped on completion so that it cannot be retrieved by any known forensic technique, with a formal certificate of deletion issued to the auditee. Where the agreement is silent, §10.3(vi) sets a default retention of one year from completion of the project, and §10.3(v) limits what may be retained to the audit reports rather than other auditee data. The 2018 guidelines put it in one line: the auditor “will ensure there is no mirroring of data outside the country.” Offshore analysis teams and cloud-hosted testing platforms are where this quietly breaks.
Diagnostic: Name the platforms in the scoping call, in writing, before access is granted. Where is the scanning platform hosted? Where does the jump host sit? In which tenancy region do the ticketing and reporting tools hold the findings? And what is the deletion certificate at closure?
The result is filed as a property of the company rather than of the build
Surfaces at
The next release
The signal
Nobody can put the tested version or hash next to the current release tag inside a minute.
What it costs to recover
A delta re-audit if the change board catches it, a full re-audit at the annual review, and in the meantime a document describing something that is not running.
§9.5(i) requires hash values, versions and timestamps to be captured by the auditee, shared with the auditor and “prominently featured in the audit certificate and reports”, and §16.1(v) restates it. A result is about a named application at a named version in a named environment on a stated date. It is not a statement about the organisation, its other products, or next month’s release.
Diagnostic: Put the tested version or hash next to your current release tag. If nobody in the room can do that in a minute, the result is not being managed as a release artefact and is probably already out of date.
“VAPT” is used to mean whatever the reader already thought it meant
Surfaces at
Scoping, invoiced at the findings report
The signal
Neither the statement of work nor the engagement letter defines the word, and the two sides describe the deliverable differently when asked separately.
What it costs to recover
The arguments the pre-audit discussion would have settled arrive in week five instead, priced as change requests.
Because the compound is not defined in most contracts, the buyer reads it as a penetration test, the seller prices it as an assessment, and both sign. §13.2.4(i) of the guidelines has a name for this — the expectation gap, “the difference between what the auditee perceives or expects from the audit and what the audit professionals understand the engagement to entail” — and requires it to be reduced or eliminated by explaining the audit process, required artefacts and expected deliverables at the outset. §13.2.4(ii) separately requires clear communication about exemptions, limitations and other constraints.
Diagnostic: Write the definition into the contract. Two sentences: what breadth means here, and what depth means here. Then check the man-hours in the test plan against both.
One route of recourse exists and almost nobody uses it. §11(iii) requires the auditee organisation to provide feedback on the audit conducted, to CERT-In as well as to the auditing organisation, on completion. It states that “it is both an auditee organization’s right and duty to provide relevant feedbacks”, that all feedback and complaints are kept confidential and acted on promptly, and that the auditee feedback form may be requested from empanelment@cert-in.org.in. §11(iv) is what sits behind it: where adverse feedback arrives or lapses are observed, action under CERT-In’s Deter and Punish Framework “may be taken without any reminder or notice”. The feedback costs nothing, has no deadline, and is the only mechanism by which a bad engagement improves the next buyer’s shortlist.
Four situations that break the ordinary pattern
Who audits what when the system is not entirely yours?
The main narrative assumes you own the estate, run the systems and hold the contract. Indian engagements frequently do not look like that. Each of the four below has a clause addressed to it, and each one decides scope rather than method.
Your website sits on somebody else’s server
Where a service or website is hosted on a web server owned by another organisation, responsibility for auditing the web server, its operating system, the web hosting application software and any backend database application software lies with the organisation that owns and operates the server — the clause’s own reason being that the website content owner has neither access to nor control over those assets. What stays with you is the website’s own data and software, which it is your responsibility to have audited by a CERT-In empanelled information security auditing organisation of your choosing. The report should explicitly certify that the audited web application, including backend databases and scripts, is free from vulnerabilities and malicious code that could be exploited to compromise or gain unauthorised access, including escalated privileges, to the web server hosting the website. Read that sentence before you sign: it is a certification about your application’s effect on somebody else’s server.
Part of what is being audited is run by an outsourced provider
Where any of the activities to be audited are outsourced, you must ensure that relevant personnel from the outsourced organisation are available at the time of the audit. Availability is a contractual matter, which means it belongs in the outsourcing contract rather than in an email sent the week testing starts. The same clause requires you to assign a technical team as point of contact for assisting and monitoring the auditing organisation, to share its details with the auditors, and to schedule regular interaction between the two. Separately, third-party, vendor and supply-chain risk assessment is part of the audit scope in its own right under §13.1.1(f).
A finding from your last VAPT is still open
The auditing organisation must revalidate observations from the previous audit cycle, and any unresolved issues should be recorded as repeat observations in the current cycle. A repeat observation is a governance signal rather than a technical one, which is why risk acceptance sits with the head of the organisation under §9.2 and why §13.1.7(iii) requires an escalation matrix for repeated vulnerabilities to be defined as part of the audit contract. If your report has no repeats section, it has not looked at last year’s report.
You are a private company with no government customer
Most of this still reaches you, from two directions. §4 describes CERT-In empanelling auditing organisations to undertake audits, including vulnerability assessments and penetration testing, of the systems, networks and applications of organisations “of the Government and of other sectors”, and describes auditee organisations as being in both the public and private sectors. And the CERT-In Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporate and Government organisations alike — with compliance to be verified in every audit assignment under §15.2.1(iv). What a private company rarely needs is a certificate by that name. What it frequently commissions is the audit that would sit behind one.
Is VAPT mandatory, and does it have to be CERT-In empanelled?
This is the question most buyers actually arrive with, and it has four different answers depending on who is asking. The honest version requires care about what the instruments say and what they do not. §2 of the 2025 guidelines states that they are “binding on all CERT-In empanelled auditing organizations and auditee entities covered under the relevant provisions” — and then does not enumerate the relevant provisions, which is worth saying out loud rather than filling in. §4 describes auditee organisations as “organizations in both the public and private sectors that are required to or are seeking to evaluate their cyber security posture”. “Required to or are seeking to” is the document’s own hedge and should not be upgraded into a universal mandate.
| If you are | What is actually required | Who may perform it | What you end up holding |
|---|---|---|---|
| A Government department, PSU or agency taking a website, portal, web application or mobile app into production | A security audit before hosting in the production environment. GIGW 5.3.1 states that the system must have “been Security Audited and an Audit Clearance certificate has been issued … before hosting in production environment”, and the evaluator action requires a valid certificate, not merely a present one. | NIC, STQC, an STQC-empanelled laboratory, or a CERT-In empanelled laboratory. Four bodies, named in the guideline, and no others. | A report and an audit clearance certificate — the deliverable the sector calls a safe-to-host certificate. GIGW’s developer action under 5.3.1 also requires periodic auditing of the web application “at least once in a year or as and when any changes are done in the source code, whichever is earlier”. |
| A private company with no Government nexus, buying a VAPT on its own initiative | Nothing statutory compels the engagement itself. §6 of the 2025 guidelines states the general expectation that auditee organisations ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, and §13.1.2(ii) treats a stated frequency as a minimum rather than a ceiling. | Any competent testing firm. Empanelment is not a legal precondition here — though an empanelled auditor is bound by published rules of engagement, a declared-manpower rule and a five-day reporting duty that an unempanelled one is not, which is why it turns up as a buyer preference in tenders and customer questionnaires. | A report with findings, evidence, severities, closure timelines and a re-test. There is no statutory certificate at the end of a commercial VAPT, and a firm offering one is describing a document with no instrument behind it. |
| An organisation whose customer, tender or sectoral regulator has asked for a VAPT | Whatever the demanding document specifies — read it before scoping anything. The only verified link between empanelment and regulators in the 2025 guidelines is §12.1(i), which says CERT-In’s snapshot information “should be utilized by the organizations or sectoral regulators to identify and select the auditing organizations”. §13.1.2(i) adds that sectoral regulators may increase audit frequency. Neither clause names a regulator, and neither should be read as one. | Determined by that document. Ask the requesting party in writing whether empanelment is a requirement or a preference, because the two produce very different shortlists and prices. | Usually the report, and often closure evidence, rather than a certificate. Ask which artefact satisfies them before you buy one. |
| Any organisation being audited by a CERT-In empanelled organisation, for any reason | You inherit a set of duties on the auditor’s side that apply regardless of who you are. §15.2.1(iv) requires the auditor to include verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with findings and evidence in the report. §10.6 and clause 3.2.2 of the empanelment terms require the report and audit metadata to reach CERT-In within five days of completion, and §13.2.1(iii) requires the auditor to tell you so before the assignment begins. | An empanelled organisation, deploying only manpower declared to CERT-In in its snapshot information under §10.2(vi) and §12.3(iii). | A report that also passes to CERT-In, and — under clause 3.2.2 — a record with CERT-In of any critical vulnerabilities you did not fix even during follow-up audits, along with your details. |
Wherever empanelment is in play, the selection duties sit with you rather than with CERT-In. §12.2(iv) states that it is the auditee organisation’s responsibility to check the domain of audit conducted, previous audits conducted and other relevant details, and to have a clear understanding of the auditing organisation’s methodology, tools, relevant domain experience and the available alternatives before selecting. §12.2(iii) adds a duty to verify identities, official identity cards and designations, and states that auditing organisations “should not field freelancers, interns, freshers, moonlighters, third party consultant or employees who are serving their notice period and the auditee organizations should verify compliance”. Background on the standing itself is on CERT-In empanelment explained, on the agency itself on what CERT-In is, and on checking a document you have been handed on how to verify a CERT-In audit certificate.
One duty in the fourth row belongs to you and is frequently discovered late: the obligation to report cyber incidents to CERT-In within six hours, for the twenty categories listed in Annexure I to the Directions of 28 April 2022. It is not discharged by your auditor and it is not transferable — CERT-In’s own FAQ of May 2022 states that the obligation “is neither transferrable nor indemnified or dispense with [sic]”. A VAPT that finds an active compromise puts both duties in play at once: the auditor’s, under §15.2.2(i), to assess and report it immediately to you and to CERT-In, and yours, under the Directions. The detail is on the CERT-In Directions of 2022, explained.
Six sentences you will hear, and what to say back
The failure modes above are the retrospective version. This is the live one: the moment in a scoping call where a reasonable-sounding sentence costs you the engagement, and the clause that answers it. Each reply is a sentence to say out loud rather than a paragraph to absorb.
“Our VAPT package covers the OWASP Top 10 — that is the standard.”
Say: “CERT-In’s audit policy guidelines say at §8(ii) that limited lists such as the OWASP Top 10 should not be considered as standards or references for audits. Which methodology and which verification standard are you proposing instead?” The clause names the answers, so the question is fair and answerable: WSTG for the method, ASVS at a version and level for the requirements, the Cyber Security Audit Baseline Requirements for the programme. A supplier who cannot name any of the three is working from a template.
“The scope is fixed — it is our standard package.”
Say: “§13.1.1(b) puts the scope with the auditee, defined in consultation with the auditing organisation. Here is our asset inventory and its as-of date. Price against that.” A fixed package is a legitimate commercial product and an inverted clause at the same time. You do not have to argue with the price — you have to make the scope yours before it is priced.
“We will run the assessment and the penetration test in the same week.”
Say: “Then show me the handoff — the enumerated asset list the testers start from, dated before the test window.” Nothing forbids a short engagement. What makes the two halves two halves is that breadth informs depth, and the only way to see whether it did is the artefact and its date. If there is no artefact, you are buying one activity with two names.
“Retesting is a separate purchase order.”
Say: “§9.3(iv) puts follow-up audits within the scope or RFP proposal, and §13.1.1(g) says the scope of work should clearly specify the requirement to conduct them. Please price the re-test inside this engagement.” Until the re-test happens none of the risk has been reduced, so a quote without one is not cheaper — it is incomplete.
“Our development partner will handle the whole audit for us.”
Say: “§9.6(i) says the complete audit process must be undertaken by the auditee organisation itself and that this responsibility must not be delegated — scope, selection, access and closure. External specialist support is expressly allowed while we keep ownership.” And §5(xvii) is the reason the specific proposal is worse than the general one: the same entity implementing controls and then auditing them is the conflict of interest the guidelines define by name.
“The tool output is the report — we have removed the false positives.”
Say: “Show me a finding that required a second request.” Business-logic abuse, an authorisation boundary crossed, two weaknesses chained into a path. §8(i) says solely tools-based testing should be discouraged because it can produce an incomplete view of the overall security. The practical version of that clause is that a report with no manual findings is a report from an engagement that had no manual hours.
The roles, stated plainly
Who performs a VAPT, and who signs the report?
A page arguing that precision in terminology is worth money should be just as precise about roles. Here is who owns each part of an Indian security audit engagement, as CERT-In’s own rules assign it.
| Activity | Who owns it | What everyone else does |
|---|---|---|
| Being empanelled by CERT-In | The empanelled auditing organisation | Empanelment is a standing held by a named legal entity and published by CERT-In. |
| Defining the scope and selecting the auditor | The auditee organisation | §9.6(i) is explicit that the complete audit process “must be undertaken up [sic] by the auditee organization itself” — defining the scope, selecting the auditing organisation, providing access, and ensuring closure of all audit observations — and that “this responsibility must not be delegated”. The same clause adds that the organisation “may seek external support for specialized expertise, while retaining full ownership and accountability”. |
| Performing the audit or penetration test | The empanelled auditing organisation, on engagements where empanelment is required | §10.5(vii) prohibits an empanelled organisation from sub-letting or outsourcing an audit assignment, which is a rule about the auditor’s own work — it does not touch the auditee-side work §9.6(i) describes. |
| Signing the audit report | The empanelled auditing organisation | §9.5(iii) requires reports to be signed only by manpower declared to CERT-In in the organisation’s snapshot information: by the auditors who conducted the audit, then by a designated reviewer from mid-management who was not part of the audit team, then authorised and signed by the head of the auditing organisation. The certificate is signed by both the lead auditor and the head. |
| Issuing a security audit or safe-to-host certificate | One of the four bodies GIGW 5.3.1 names, where a certificate applies at all | For Indian Government websites and applications, GIGW 5.3.1 names four bodies and no others: NIC, STQC, an STQC-empanelled laboratory, or a CERT-In empanelled laboratory. For a private-sector VAPT with no Government nexus there is no statutory certificate at the end at all. |
| Sending the report and metadata to CERT-In within five days | The empanelled auditing organisation | §10.6 of the 2025 guidelines and clause 3.2.2 of the empanelment terms both impose it, and §13.2.1(iii) requires the auditor to tell you about the duty before the assignment begins. Clause 3.2.2 also requires critical vulnerabilities that were identified but not fixed even during follow-up audits to be reported to CERT-In with auditee details. An auditee neither files nor controls those submissions. |
| Patching what the test found | The audited organisation | §9.3(iii) states that the responsibility for patching and correcting vulnerabilities is the auditee’s. §9.2 requires risk treatment decisions and exceptions to be authorised and accepted by the head of the auditee organisation. |
| Verifying that the fix worked | The auditing organisation, in the follow-up audit | §16.3(iv) puts the verification of closure with the auditor. This is the reason the re-test belongs in the scope of work at §13.1.1(g) rather than in a change request six weeks later. |
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.
The primary sources, with the clauses relied on
Every assertion on this page traces to one of the documents below, each named with its issuing body, its version and its date. Every primary-source PDF was fetched and checked on content type and byte count rather than on status code, because cert-in.org.in answers 200 with a small HTML page for unknown paths. Two entries are web pages rather than documents: CERT-In’s empanelment process page, and the OWASP ASVS link, which points at the project’s landing page rather than at a particular release of the standard. Where a later version exists, it supersedes what is written here.
- CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. 69 pages, 20 numbered sections. The instrument this page is built on. Relied on at §2 (binding formula), §4 (applicability), §5(xxi)–(xxiv) (definitions of vulnerability assessment, penetration testing, red team assessment, and severity classification with CVSS and EPSS), §5(xvii) (conflict of interest), §6 (twenty-six classes of engagement and the annual expectation), §8(i)–(ix) (applicable standards and frameworks), §9.3, §9.5, §9.6(i), §10.1, §10.2(vi), §10.3, §10.5(vii), §10.6, §12.1–§12.3, §13.1.1, §13.1.2, §13.1.4, §13.1.8, §13.2.1(iii), §13.2.2, §13.2.3, §13.2.4, §13.2.5, §13.2.6, §13.2.7(iii), §14, §15.1, §15.2, §16 and §18. cert-in.org.in
- CERT-In, Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018. 6 pages, under three headings: People, Technical, Process. The 2018 ancestor of the tools rule — “Auditors must utilize industry standard methodologies, best practices for security testing. Solely tools based testing should be discouraged.” — plus the verification team (Red Team) that checks the audit team (White Team), the prohibition on distributed denial of service testing over the Internet and on any form of flood testing, and the data-residency duties. cert-in.org.in
- CERT-In, Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment, version 7.2, April 2024. 10 pages. Relied on at clause 2.1 (CERT-In is not a party to the auditor–auditee contract), clause 3.2.2 (the five-day submission of report and metadata, and of unfixed critical vulnerabilities with auditee details), clause 4.2 (the single permitted sentence describing the relationship), and Annexure I, whose twenty-four items include the test plan stating calendar time and man-hours, the tool-provenance expectation and the flood-testing prohibition. cert-in.org.in
- National Security Council Secretariat, Cyber Security Audit Baseline Requirements, publication NSCS-46-16 Rev 1.0, October 2020. Named at §8(iii) and again at §13.1.8(i) of the 2025 guidelines as the document auditees and auditing organisations should use to build their audit programme. Published on CERT-In’s website, but issued by the National Security Council Secretariat rather than by CERT-In itself. cert-in.org.in
- CERT-In, Guidelines for Secure Application Design, Development, Implementation & Operations. Named at §8(vii), which requires auditee organisations to confirm that applications are designed and developed with secure practice before any assessment commences. §8(viii) states that an application developed without any secure design and development practices “should not be considered for assessment and audits”, with the auditee informed in writing and a copy marked to CERT-In. cert-in.org.in
- CERT-In, published list of empanelled information security auditing organisations, with snapshot information per organisation. The “snapshot information” §12.1 tells an auditee to use when selecting an auditor, and the roster §10.2(vi) and §12.3(iii) require an auditing organisation to deploy from. Per organisation it carries the audit categories the organisation itself lists with a Yes or No against each, audits performed in the last twelve months by sector, category-wise counts, technical manpower by qualification, and the tools used. cert-in.org.in
- CERT-In, empanelment process page, cert-in.org.in. Four rounds are published as live list items, each linked to its own document. Step-3 is the “Vulnerability Assessment/Penetration Testing Practical Skill Test (VA/PT PST)” — the source for this page’s observation that CERT-In tests the two competences as a pair and still writes them as two things. cert-in.org.in
- Guidelines for Indian Government Websites and Apps (GIGW 3.0), manual, National Informatics Centre with STQC and CERT-In — chapter 5 cybersecurity preamble and guidelines 5.3.1 and 5.3.2. The cybersecurity chapter preamble is where ISO 27001, OWASP ASVS, the OWASP Top 10 and CIS benchmarks are named together as the industry best security practices the host service provider and developer must adhere to. 5.3.1 is the audit-clearance-certificate-before-production statement, names the four bodies that may issue it, names the OWASP Top 10, OWASP ASVS and OWASP MAVS in its government-organisation action, and carries the developer action requiring periodic auditing at least once a year or on any change to the source code, whichever is earlier. 5.3.2 is the hosting-environment statement, which requires periodic Vulnerability Assessment (VA) and Penetration Testing (PT) with corrective actions. Cite the manual for every GIGW number on this page: the live attributes page at guidelines.india.gov.in mis-numbers the third cybersecurity statement as 5.3.2, so that number appears on it twice. GIGW 3.0 manual (PDF)
- Directions under sub-section (6) of section 70B of the Information Technology Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022, including Annexure I. The six-hour incident reporting duty and the twenty mandatorily reportable incident types. §15.2.1(iv) of the 2025 guidelines requires verification of compliance with these Directions in every audit assignment, with findings and evidence in the audit report. cert-in.org.in
- Indian Institute of Corporate Affairs, Ministry of Corporate Affairs — Web Security Audit Certificate, issue date 11 July 2024, published on iica.nic.in. A published certificate on a Government of India domain, cited here for one thing only: it states its conclusion as “Web Application is audited against vulnerabilities including OWASP 2021 Top 10 and is safe for hosting” — which is how the tension with §8(ii) shows up in practice rather than in theory. The issuing auditing organisation is deliberately not named on this page. iica.nic.in
- CERT-In, Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, version 2.0, dated 9 July 2025. Cited on this page for one thing: §6(xxvi) of the 2025 audit policy guidelines names SBOM, QBOM and AIBOM auditing as a class of engagement and does not cite any technical guidance for it. These guidelines are that guidance, published separately by CERT-In. Reading the two together is an inference and is labelled as one where it is made. cert-in.org.in
- CERT-In, FAQ on the Cyber Security Directions of 28.04.2022, May 2022. Linked from CERT-In’s own Directions page. Q13 is the answer this page relies on: “Any entity which notices the cyber security incident, shall report to CERT-In. The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with [sic].” The FAQ carries its own limitation, which should be quoted whenever it is relied on: it “is not a legal document and in no way whatsoever replaces, amends or alters any part of the IT Act, 2000” or the CERT-In Rules, 2013. cert-in.org.in
- CERT-In, Model Non-Disclosure Agreement. Named at §13.1.7(ii) of the 2025 guidelines, which requires an NDA to be signed by the auditing organisation before the commencement of any audit activities and points at this template, which may be customised to the project. The same clause allows penal and legal liability provisions to be added to the auditor–auditee contract, extending where desired to the individual auditors. cert-in.org.in
- CERT-In, Policy Guidelines for Handling Audit related Data, version 1.0, June 2014. Required by name at §10.3(vii) of the 2025 guidelines. It is the instrument behind the data-residency material on this page: devices used for the audit secured including by encryption, access on a need-to-know basis, storage only on systems located in India, no sharing with an overseas partner unless specifically authorised by the auditee, and — usefully — that an audit report should not be shared or hosted on online file services, sharing platforms or cloud services unless the service is under the auditing organisation’s own technical and administrative control or the auditee specifically authorises it. cert-in.org.in
- FIRST, CVSS v3.1 specification document, and the EPSS model. Cited only for the numeric bands in the severity table. §5(xxiv) of the 2025 guidelines requires both frameworks and describes the CVSS 0.0–10.0 range and its translation into low, medium, high and critical, and the EPSS probability between 0 and 1 — but it does not print the numeric band boundaries, which belong to the CVSS specification’s own qualitative severity rating scale. first.org
- OWASP Application Security Verification Standard (ASVS). Named at §8(ii) of the 2025 guidelines for establishing and verifying application security controls. Three verification levels. The current stable release is ASVS 5.0.0 (May 2025) and the level definitions were restructured between 4.0.3 and 5.0.0, which is why a scope of work should name the version as well as the level. The link goes to the OWASP project page rather than to a particular release of the document. owasp.org
One document is named on this page and deliberately not linked. §15.2.1(iv) of the 2025 guidelines directs organisations to a document it calls “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” and prints a cert-in.org.in path for it. That path did not serve the document when it was last checked on 22 September 2026: it returns a small HTML page rather than a PDF. We name the document as the guidelines name it, and we do not render it as a working link. Clause locators throughout this page were checked against the PDFs on 22 September 2026. If you find one that has moved, we would rather correct the page than be quoted accurately on something stale.
Frequently Asked Questions
What is VAPT?
What does VAPT stand for?
Is VAPT the same as penetration testing?
What is the difference between a vulnerability assessment and a penetration test?
Does CERT-In define VAPT?
Is VAPT mandatory in India?
Is testing against the OWASP Top 10 enough?
Can an automated vulnerability scan count as a VAPT?
What should a VAPT report contain?
How often should a VAPT be done?
Does a VAPT produce a certificate?
Do I need a CERT-In empanelled auditor for a VAPT?
What is the difference between VAPT and a red team assessment?
What is EAPT, and how does it differ from VAPT?
Who is responsible for fixing what a VAPT finds?
Does my VAPT report go to CERT-In?
What is the VAPT process, step by step?
How much does a VAPT cost in India?
How long does a VAPT take?
Is VAPT done on staging or on production?
What access and credentials does a VAPT tester need?
Will a VAPT take our systems down?
What is the difference between black-box, grey-box and white-box VAPT?
Can our internal security team do the VAPT?
My customer has asked for a VAPT — what do I actually send them?
What tools are used in a VAPT, and who approves them?
How do I tell a serious VAPT proposal from a cheap one?
Where to go next. The sibling pages in this cluster take the subject apart: VAPT vs penetration testing vs red teaming on the three definitions and when each is the right purchase, VAPT scoping on turning §13.1.1 into a statement of work, types of VAPT on the engagement classes one at a time, reading a VAPT report on what to believe and what to question, and VAPT re-testing and closure on the half of the engagement that actually reduces risk. On the certificate side, start with how to get a safe-to-host certificate and why applications fail safe-to-host.
Related Reading
The Types of VAPT
Web, network, mobile, API, cloud configuration and wireless — what each can and cannot find.
Read moreScoping a VAPT
Assets, environments, credentials, exclusions and the rules of engagement to agree before testing starts.
Read moreVAPT vs Pen Test vs Red Team
Four activities that get quoted against each other, and what actually distinguishes them.
Read moreHow to Read a VAPT Report
Scope, severity, evidence and the parts that reveal a weak test.
Read moreRules of Engagement for an Empanelled Auditor
What the auditor must do, must not do, and needs your written permission for.
Read moreWhat Is CERT-In?
The national agency under section 70B of the IT Act — what it does, and what empanelment actually means.
Read more