Learn · VAPT & CERT-In

The Types of VAPT and What Each One Can and Cannot Find

VAPT is not one engagement. It is a family of them — web application, external and internal network, mobile, API, cloud configuration, wireless, endpoint, operational technology and connected devices — and each one reaches a different surface and misses a different thing. Choosing between them is a scoping decision, and the gaps that matter are the ones a combination of types leaves behind.

The instrument behind the vocabulary: CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) list twenty-six classes of engagement at §6, framed as “including, but not limited to”, and name nine audit types at §13.2.3(i)(a) — a list the guidelines themselves end with “etc.”. VAPT is a type label in the second list, not a class in the first.

Talk to a Compliance Advisor How VAPT Scoping Works

10engagement types, scoped and compared

26classes of engagement listed at §6

9audit types named at §13.2.3(i)(a)

Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · Empanelment terms v7.2 (April 2024) · Auditor guidelines v3.0 (May 2018) · GIGW 3.0 · Every clause locator checked 22 September 2026

The short answer

What is VAPT, and what are its types?

What does VAPT stand for, and what does it actually include?

VAPT stands for Vulnerability Assessment and Penetration Testing. It is not a single test: it is two distinct activities, usually bought together, applied to one or more of ten surfaces — a web application, the external network, the internal network, a mobile application, an API, a cloud account’s configuration, the wireless estate, the endpoint build, an industrial control or operational technology network, or a connected-device fleet. Each surface is its own engagement with its own scope, its own evidence and its own blind spot. The expansion is not a marketing coinage. CERT-In writes it out in its own instrument: §13.2.3(i)(a) of the Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) requires an auditing organisation to tell the auditee, before commencement, which type of audit is being conducted, and lists “VAPT (Vulnerability Assessment Penetration Testing)” first among them.

The practical question is never “do we need VAPT”. It is which of the ten types your estate requires, and what the combination you have bought leaves untested. A web application test with no API test behind it cannot produce object-level authorisation findings. A cloud configuration review cannot tell you whether the misconfigurations it found are reachable. An external network test cannot see a flat internal network, and an internal one cannot tell you whether the foothold it started from was achievable. None of those is a failure of the engagement. Each is a property of what that engagement is, and every one of them is avoidable at scoping.

“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. Auditee organizations, which are expected to ensure a comprehensive audit covering all aspects of their Information and Communication Technology (ICT) systems at least once a year, may also opt for additional assessments and audits during the year.”

— CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025, §6, opening words. Twenty-six classes follow. cert-in.org.in/PDF/Comprehensive_Cyber_Security_Audit_Policy_Guidelines.pdf

Read as a buyer, that sentence sets the shape of the year: one comprehensive exercise covering all aspects of the ICT estate, assembled from whichever types the asset inventory requires, with additional assessments during the year where risk warrants them. It does not say “buy a package”, and the guidelines nowhere define a package. They define classes of engagement, and they require you to name which one you are commissioning.

Key Takeaways

VAPT expands to Vulnerability Assessment and Penetration Testing. CERT-In prints the expansion itself, as "VAPT (Vulnerability Assessment Penetration Testing)", at §13.2.3(i)(a) of the Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025.
The two halves are separate classes with separate definitions at §6(iii) and §6(iv). A vulnerability assessment measures breadth. A penetration test actively tests and, where authorised, exploits, to establish reachable impact.
There is no CERT-In list of "types of VAPT". §6 lists twenty-six classes of engagement, framed as "including, but not limited to", and §13.2.3(i)(a) names nine audit types, a list ending in "etc.".
Ten engagement types cover what the market actually buys. Web application, mobile application, API, wireless, endpoint, ICS and OT, and IoT and IIoT all map to named §6 classes. External and internal network testing and cloud configuration review map only partially, and a scope of work should say so.
A cloud configuration review is not a penetration test. §6(iv) defines penetration testing as active testing to identify and exploit vulnerabilities and to determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure.
The most expensive gap in the market is a web or mobile engagement with the API tier out of scope, because object-level authorisation is the defect class a front-end-driven test structurally cannot produce.
Duration is driven by roles, operations, builds, accounts and sites — not by page counts, address-space size or device counts. §13.2.2(ii) requires the test plan to carry both calendar time and man-hours.
Whatever the type, the report must state the environment tested (§15.2.3(i)), score with CVSS and EPSS and map every observation to a CWE and a CVE (§16.2(ii)), and state its sampling decisions, exemptions, limitations and other constraints (§16.1(ii)).
Sixteen of the twenty-six §6 classes sit outside the ten. Source code review, physical testing, red teaming, forensic readiness, log management, AI system audits, vendor risk, blockchain and BOM auditing are named engagements in their own right, and no amount of VAPT reaches them.
OT, ICS and IoT are classes of their own at §6(xix) and §6(xx), and §13.1.1(a) puts OT and ICS inside the audit scope. §15.2.2(iv) then changes how they are tested: in critical environments where availability is a top priority, testing should be conducted in a passive manner.

The two words inside VAPT

Vulnerability assessment and penetration testing answer different questions

What is the difference between vulnerability assessment and penetration testing?

The short version is below, because this page cannot discuss which of the ten types delivers which half without it. The fuller treatment of the distinction itself, including where adversary simulation sits, is on VAPT versus penetration testing versus red teaming. What follows here is this page’s own question, which no sibling answers: which half of VAPT each engagement type actually delivers.

Both definitions below are quoted from §6 of the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. They are items (iii) and (iv) of twenty-six, and they are not two names for one activity. Buying them as a compound word is normal, but reporting one as the other is not.

§5(xxi) and §6(iii)

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 question it answers

What is wrong, and how much of it is there?

What you get

Breadth. An enumerated, deduplicated, verified list of deficiencies across the scope, each one scored and mapped.

What it does not give you

It does not establish that a deficiency is reachable and usable by an attacker in your configuration. Severity is a property of the weakness. Exploitability is a property of your system.

§5(xxii) and §6(iv)

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 question it answers

What can actually be done with what is wrong?

What you get

Depth. Demonstrated impact — chains, reachable data, achieved privilege — with the evidence §18(iii) requires each observation to be supported by.

What it does not give you

It is not a census. A tester who spends four days proving one chain has not enumerated the estate, and the report has to say so under §16.1(ii), which requires sampling decisions, exemptions, limitations and other constraints to be stated.

Two consequences follow for a scope of work. First, a report that enumerates four hundred findings and demonstrates none of them is a vulnerability assessment, whatever the cover page says — and that is a legitimate purchase, if that is what you wanted. Second, a report that demonstrates one impressive chain and covers a fraction of the estate is a penetration test, and §16.1(ii) requires it to say so: the report must carry its sampling decisions, exemptions, limitations and other constraints alongside the findings. If you want both properties you buy both activities, and the plan says how the hours split. More on writing that scope in how VAPT scoping works, and on the boundary with adversary simulation in VAPT versus penetration testing versus red teaming.

Which half of VAPT does each type actually deliver?

This is where the distinction stops being a definition and starts costing money. The word VAPT promises both halves. The engagement you bought delivers a particular mix, and the mix is a property of the type rather than of the invoice.

Engagement type	Which half it delivers	Why, and what to ask
Web application security audit	Both, genuinely	Enumeration across the reachable surface is §6(iii) work. Authorisation and business-logic abuse are §6(iv) work and cannot be reached any other way. Ask what share of the man-hours at §13.2.2(ii) goes to each.
External network penetration test	Assessment by default, testing by permission	Discovery and version enumeration are §6(iii). Exploitation happens only where the scope and the written approvals at §13.2.2(v) permit it, so an external engagement without those approvals is a vulnerability assessment with a penetration-test cover page.
Internal network penetration test	Predominantly §6(iv)	The deliverable is a chain from a drop point to an asset, which is demonstrated impact by definition. It is not a census of the internal estate, and §16.1(ii) requires the sampling decision to be stated.
Mobile application security audit	Both, weighted to §6(iii) on the artefact	Static examination of the binary and its storage is assessment work. The §6(iv) half lives behind the API, which is why a mobile scope with the backend excluded delivers mostly the first half.
API security audit	Predominantly §6(iv)	Object-level and function-level authorisation findings are demonstrations — this identifier, this role, this response. An enumeration of endpoints without that is an inventory, not an audit.
Cloud configuration review	§6(iii) only	Read-only credentials, posture measured against a baseline. It does not identify and exploit, which is what §6(iv) requires, and the canonical statement of that substitution is below.
Wireless security testing	Both, on a short scope	Enumerating SSIDs and authentication methods is assessment. Association, segmentation checks after association and any evil-twin work are active and need the authorisation written into the scope.
Endpoint security assessment	Predominantly §6(iii)	A control review against a baseline. The one genuinely §6(iv) element is escalation from standard user to local administrator on the build, which is worth naming separately because it is the test that decides whether the rest holds.
ICS and OT security testing	§6(iii) by rule	§15.2.2(iv) requires passive testing in critical environments where availability is a top priority. That is a deliberate choice of the assessment half, and it belongs in the scope as a decision rather than arriving as a disappointment.
IoT and IIoT security testing	Both, on owned units	Firmware and hardware work is active on units you own and have authorised. The cloud and application tiers split exactly as cards 01 and 05 do.

Types of VAPT at a glance

Ten engagement types, and the one thing each cannot do

What are the types of VAPT?

The full treatment of each is further down. This table is the version to put in front of a project board: what the engagement is for, what it structurally cannot reach, what actually multiplies its cost, and — so the table is usable in a scope of work on its own — the CERT-In class and audit-type label to write next to it.

Type	What it is for	Its defining blind spot	What multiplies the cost	Class of engagement (§6)	Audit type label (§13.2.3(i)(a))
Web application security auditApplication tier	Authenticated and unauthenticated testing of one application — its request handling, its authentication, its authorisation model and its business logic — from the browser inward.	Anything on a hostname that is not in the scope. The admin console on a second host, the file service on a third and the identity provider on a fourth are separate assets, and §16.1(iii) requires the report to list the assets you provided — not the ones you did not.	Not page count.	§6(xii) Application security testing	Web Application Security Audit
External network penetration testNetwork tier	Testing of the perimeter as an unauthenticated attacker on the public Internet sees it — what is exposed, what version it is, what it will accept and where it can be pushed past its intended function.	Anything reachable only from inside. A flat internal network, a domain-wide privilege path, a file share readable by every employee: all invisible from outside, by construction.	Live hosts and answering services, not the size of the CIDR block.	§6(v) Network infrastructure Audits, §6(iv) Penetration Testing	EAPT — External Attack Penetration Testing
Internal network penetration testNetwork tier	Testing from a position inside the network — an assumed-breach foothold, a plugged-in port, a compromised laptop, a contractor VLAN — to establish how far a presence inside travels.	Whether the foothold it starts from was achievable in the first place. An assumed-breach internal test answers "how bad is it once someone is in", not "can someone get in". Those are two engagements, and buying one and reporting the other is the most common misread in this whole field.	Identity complexity and segment count, not host count.	§6(v) Network infrastructure Audits, §6(iv) Penetration Testing	DLA for device-level work, but no label for the position itself
Mobile application security auditApplication tier	Testing of the installed application on a real device and of its traffic — the binary, what it writes to the device, how it protects that data, and how it talks to the backend.	Server-side authorisation defects, unless the API tier is in the scope as its own asset. §6(xii) names APIs expressly and §13.1.1(a) puts them inside the audit scope. The full argument is under “A web application test with no API test behind it” in the scope-gaps section below, which is where this page states it once.	Platforms times build variants, then the depth of the runtime work.	§6(xiii) Mobile Application Security Auditing, also §6(xii)	Mobile Application Security Audit
API security auditApplication tier	Testing of the interface itself — every endpoint, method, parameter and object identifier — as a client that does not run your front end and is not bound by it.	Anything on an endpoint that was not enumerated. An API test is exactly as wide as the inventory of base paths and operations it was given. Undocumented endpoints are the ones that matter and the ones nobody hands over.	Operations times roles, where an operation is a method on a path and not a path.	§6(xii), which names APIs expressly	API Security Audit
Cloud configuration reviewPlatform tier	An authenticated, read-only review of how the cloud account itself is configured — identity, network, storage, logging, encryption and the posture of the managed services in use.	Exploitability. This is the central honest point of this page: a configuration review is not a penetration test. §6(iv) defines penetration testing as a methodology in which components or the application as a whole are actively tested to identify and exploit potential vulnerabilities, to determine whether they can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment. A read-only review does not do that and cannot claim to have done it.	Accounts, subscriptions or projects times regions in use, then the number of distinct managed services.	§6(xviii) Cloud Security Testing	Configuration Audit
Wireless security testingNetwork tier	On-site testing of the radio estate at a named location — the enterprise network, the guest network, the authentication method behind them, and whatever else is transmitting in the building.	Anything at a site nobody visited. Wireless testing is per-location and does not generalise: one floor of one office tells you about that floor.	Sites, then floors, then SSIDs and authentication methods.	§6(xiv) Wireless Security Testing	No dedicated abbreviation — name the class
Endpoint security assessmentPlatform tier	Assessment of the standard build and its controls — what a laptop, server or mobile device is configured to resist, and whether the controls you have licensed are actually enforcing anything.	Whether detection would fire against a determined adversary across a full intrusion chain. That is §6(xvi) Red Team Assessment — an exercise, reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems. An endpoint assessment is a control review, not an adversary simulation.	Distinct builds and operating-system families, not device count.	§6(xxii) Endpoint Security Assessment	DLA — Device Level Audit
Industrial control systems and operational technology security testingOperational technology tier	Testing of the environment that runs a physical process — the control network, the engineering workstations, the historians, the protocol gateways and the path between the plant and the corporate estate — conducted under a rule that availability comes first.	Anything that requires an active check on a live process. §15.2.2(iv) is the governing sentence: in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid any potential downtime or service disruption. On a running plant the aggressive half of the methodology is the half you have agreed to lose, and the report has to say so.	Sites and cells, then protocols, then how much has to be passive.	§6(xix) ICS/OT Security Testing	No dedicated abbreviation — name the class
Internet of Things and Industrial Internet of Things security testingOperational technology tier	Testing of a connected product as a system — the device and its firmware, the radio or wired link it speaks over, the cloud service it registers with, and the application that controls it.	Anything about a variant you did not supply. Hardware revisions, regional SKUs and firmware branches are separate assets, and a finding on one revision is not a statement about the fleet.	Device variants times firmware branches, then how much hardware work is authorised.	§6(xx) IoT/IIoT Security Testing	No dedicated abbreviation — name the class

Two things are deliberately absent from that table. There are no day counts, because a duration without a scope is a number with no content — and §13.2.2(ii) requires the auditing organisation’s test plan to carry both calendar time and man-hours, which is the pair of numbers to ask for. And there are no prices, for the same reason, with one constraint worth knowing: §7 requires fees to be based on predefined scopes, deliverables and timelines, and says payments must not be contingent on the outcome of the audit, whether favourable or unfavourable, nor tied to the submission or approval of any closure reports. The two sections that follow are the substitute for both absences: a table that turns your asset register into a list of types, and a set of clause-anchored tests that let you compare two quotes without either of them naming a number.

From the asset register to the scope

One inventory, and the types it selects

Which types of VAPT do we actually need?

§13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory. That clause tells you where to start and not what to do next. This table is the missing step: take each row of your register as it is actually written, and read across. The fourth column is the fact about the row that makes a type non-optional. The last is what goes untested if you leave it out — which, under §16.1(iii), is invisible in the report, because the report lists the assets you provided rather than the ones you did not.

The row in your inventory	Types that reach it	The §6 class outside the ten it triggers	What makes it non-optional	What goes untested if you skip it
Public web portal or citizen-facing application	Web app · API · External network	§6(ix) Source Code Review where the code is yours or your integrator’s	Reachable from the Internet and has more than one authenticated role.	Horizontal and vertical authorisation defects, and the edge the portal is published through.
Admin console or back-office module on a second hostname	Web app · External network	§6(ix) Source Code Review	Holds the highest-privilege role in the estate and lives on its own hostname.	The most privileged application in the estate, which is also the one most often missing from the scope annexure.
Internal-only business application on the intranet	Web app · Internal network	§6(ix) Source Code Review	Not routable from the Internet, so no external engagement reaches it at all.	The entire application, silently — an external scope cannot see it to omit it.
REST or GraphQL API base path with its operations	API	§6(xxiv) Vendor Risk Management Audits where partners consume it machine to machine	Holds records the front end does not render, and accepts identifiers.	Object-level authorisation. See the canonical statement of this gap below — it is the most expensive omission on this page.
Previous API version, still routable	API	—	It answers. Deprecation in documentation is not deprecation in routing.	A live copy of your data tier, frequently on the authentication model you replaced.
Android artefact, and separately the iOS artefact	Mobile app · API	§6(xiii) Mobile Application Security Auditing is the class, so name the version	A signed build ships to a store. Two platforms are two rows, not one row with a note.	Local storage, transport pinning and the platform component surface for whichever platform was left out.
Public IP range, edge appliance or remote-access gateway	External network	§6(v) Network infrastructure Audits	It answers from the public Internet, whether or not you meant it to.	Exposed management interfaces and unpatched edge software — the two findings that start most incidents.
Internal network segment, directory domain or forest	Internal network	§6(v) Network infrastructure Audits	It carries identity, or it carries traffic between tiers that should not meet.	Segmentation as built rather than as drawn, and the distance from an ordinary laptop to the crown jewels.
Cloud account, subscription or project, with its regions	Cloud configuration	§6(xviii) Cloud Security Testing is the class, and §6(xxi) Log Management and Maintenance Audit where logging is the question	It holds identity, storage and network configuration you can change.	Over-broad roles, publicly readable storage and logging that is off in the region nobody watches.
Container platform or Kubernetes cluster	Cloud configuration · Internal network	§6(xviii) Cloud Security Testing	It runs workloads and has an access-control model of its own.	The path from a compromised workload to the account, and the orchestration role model behind it.
CI/CD pipeline and artefact registry	Cloud configuration · Internal network	§6(ix) Source Code Review, and §6(xxvi) SBOM, QBOM and AIBOM Auditing for what the build pulls in	It can deploy to production, and it holds credentials that can.	The route that rewrites the build you audited. §9.5(i) ties the certificate to a hash, and the pipeline is what changes it.
Vendor-hosted SaaS tenancy you configure	None of the ten reaches the product itself	§6(xxiv) Vendor Risk Management Audits	You own the configuration and the data, and somebody else owns the software.	Your own tenancy settings. §13.1.1(f) puts third-party, vendor and supply-chain risk assessment inside the audit scope, so this row is in scope even though no test of the vendor’s code is.
Database identified as critical	Internal network · Cloud configuration	§13.1.3 requires a database configuration audit for critical databases, and DAST and SAST for critical applications	It is critical — and §13.1.1(b) puts the scope in the auditee’s hands, defined in consultation with the auditing organisation and derived under (c) from the consolidated and updated asset inventory. A critical database nobody entered in that inventory is out of scope without anyone deciding it should be.	The configuration audit the guidelines require for exactly this row.
Payment, settlement or dispatch integration	API · Web app	§6(xxiv) Vendor Risk Management Audits for the processor relationship	A request on it causes an irreversible side effect in the physical or financial world.	Business-logic abuse — and, worse, the carve-outs get discovered mid-test instead of agreed in the scope.
Office or site with Wi-Fi, listed with its SSIDs	Wireless	§6(xiv) Wireless Security Testing, and §6(xi) where the radio carries more than Wi-Fi	It has a street address. Wireless does not generalise between sites.	Guest-to-corporate segmentation, the authentication method, and coverage outside the building.
Standard laptop build, or a server gold image	Endpoint	§6(xxii) Endpoint Security Assessment	It is a build, not a device. Count images, not machines.	Local escalation from standard user to administrator, and whether the policy you licensed is in enforce mode or still in audit mode.
Plant control network, SCADA estate or substation	ICS and OT	§6(xix) is the class, and §6(xxi) Log Management where the historian is the question	It runs a physical process, so §15.2.2(iv) makes availability the governing constraint.	The conduit between the corporate and process networks, which is the route every OT incident of consequence has used.
Connected product or deployed device fleet	IoT and IIoT · API · Mobile app	§6(xx) is the class	You ship hardware that registers with a service you operate.	Per-device identity and the update path — the two things that make a recall a recall.
Third-party and open-source components inside a shipped build	No type on this page reaches it directly	§6(xxvi) SBOM, QBOM and AIBOM Auditing, and §6(ix) Source Code Review for the code you wrote around them	You ship somebody else’s code inside your product.	The component inventory that turns a published advisory into a decision instead of a fire drill.
AI or machine-learning model behind a product feature	API	§6(xxiii) Artificial Intelligence (AI) System Audits	It takes untrusted input and produces an output somebody acts on.	Everything §6(xxiii) covers — security, ethical alignment, transparency, data integrity and resilience to adversarial manipulation. An API test measures the interface, not the model behind it.

Two rows above route to nothing on this page, and that is the point of including them. A vendor-hosted tenancy and a shipped third-party component are both real lines in a real register, and neither is served by any of the ten types — they belong to §6(xxiv) and §6(xxvi) respectively, and §13.1.1(f) already puts third-party, vendor and supply-chain risk assessment inside the audit scope. A scope that quietly drops the rows no type reaches has made a decision without recording one.

Reading the proposal

Two quotes, and no price to compare

How do we compare two VAPT quotes?

This page will not publish a day count or a price, for the reason given above: a duration without a scope is a number with no content, and a price attached to an unnamed scope is worse. What it can give you is the set of tests that separate two proposals without either of them naming a figure. Every one of them is answerable from the document in front of you, and every one is anchored to a clause you can quote back.

The test	Clause	What a good answer looks like	What should stop you
Does the plan carry two numbers?	§13.2.2(ii), Annexure I item 10 of the empanelment terms	Calendar time and man-hours, stated separately, per type.	A day rate and a total. One number cannot tell you whether four people worked for three days or one person worked for twelve.
Is the retest inside the price?	§13.1.1(g), §9.3(iv), §16.3(iv)	The follow-up audit is named as a deliverable in the scope of work, with its own line.	Retest quoted as a variation, or absent. §13.1.1(g) requires the scope of work to specify follow-up audits as part of the engagement.
Is the fee contingent on anything?	§7	Fees based on predefined scopes, deliverables and timelines, invoiced against phases.	A milestone that pays on certificate issued, on closure-report approval, or on a finding count. §7 states that payments must not be contingent on the outcome of the audit, whether favourable or unfavourable, nor tied to the submission or approval of any closure reports.
What is the named standard?	§8(ii)	A comprehensive standard or framework: ISO/IEC, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM 3, the OWASP Web Security Testing Guide, ASVS with a version and a level, the Mobile Security Testing Guide, the OWASP DevSecOps Maturity Model.	"OWASP Top 10" as the methodology. §8(ii) states that limited lists such as OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits.
Which audit type is named, in writing, before commencement?	§13.2.3(i)(a)	One or more of the nine named types, per asset — Web Application Security Audit, API Security Audit, Mobile Application Security Audit, EAPT, DLA, Configuration Audit, Process Audit, Compliance audit, or VAPT — alongside the §6 class.	The word "VAPT" alone, applied to an estate of mixed asset types. It is a type label, not a scope.
Which environment?	§15.2.3(i), §15.2.3(ii), §16.3(v)	Named per asset — test, development, UAT, pre-production or production — with the staging-first sequence and the production follow-up both in the plan.	Silence. A report that does not state the environment is not a report about your production system, and you cannot tell which it is about afterwards.
Who actually does the work?	§12.2(ii)–(iv), §12.3(iii), §9.5(iii)	Named people whose credentials you may verify on arrival, drawn from the manpower declared to CERT-In, with the report signature chain stated.	Silence on staffing. §12.2(iii) states that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving their notice period, and that the auditee organisation should verify compliance.
What does the quote say it will not do?	§13.2.4(ii), §16.1(ii)	An exclusions paragraph naming the assets, environments and activities outside scope, which then reappears as the report’s limitations paragraph.	No exclusions. Every scope has them. A quote that names none has not thought about them, and you will meet them at the findings report.

What should a VAPT scope of work contain, per asset?

Ten lines, repeated once for every asset in the scope rather than once for the engagement. A scope written this way answers most of the tests above before anybody has to ask them, and it is what §14.1(ii) expects to be carried into the audit engagement letter both sides sign.

01 Asset identifier, exactly as it appears in the inventory, with the version or build where the asset has one (§13.2.3(ii)(c) for web and mobile applications).
02 The as-of date of the inventory extract the scope was drawn from (§13.2.3(ii)(b) requires it to be reflected in the report).
03 Audit type label from the nine at §13.2.3(i)(a), and the §6 class the engagement falls in.
04 Environment: test, development, UAT, pre-production or production (§15.2.3(i)).
05 Credential and role position: how many accounts, at which roles, and whether two accounts per role are provided for horizontal access testing.
06 Standard and, where it applies, the ASVS version and verification level (§8(ii)).
07 Approvals required before start: penetration-testing approval and tool installation approval (§13.2.2(v)), plus any separate written permission for DoS, DDoS or flood testing over the Internet (§15.2.2(ii)) or for process and social-engineering testing (§15.2.2(iii)).
08 Carve-outs: the side effects that may not be triggered and the downstream systems that are live.
09 Retest included: yes or no, and against which findings (§13.1.1(g)).
10 Deliverables and their format, agreed before commencement (§16.1(i)).

The application tier

Web application, mobile application, and the API between them

What does a web application VAPT cover?

Authenticated and unauthenticated testing of one application, from the browser inward: request handling, authentication, the authorisation model and the business logic. Card 01 below sets out the whole of it, including the part buyers most often lose — the authorisation class, which needs two accounts at every role and disappears silently when it does not get them.

Does a web application VAPT include API testing?

No, not unless the APIs are named as assets in their own right. A browser-driven test exercises the endpoints the front end calls, with the identifiers the front end supplies, which is structurally the wrong shape for object-level authorisation findings. §6(xii) names APIs expressly and §13.1.1(a) puts them inside the audit scope, so this is a departure from the instrument rather than merely from good practice. The canonical statement of the gap is under a web application test with no API test behind it.

§6(xii) puts all three inside one class — application security testing, including web applications, mobile applications and APIs — and then §6 gives mobile its own class at (xiii). Read as a buyer, the useful division is not by document but by client: the browser, the installed app, and the interface that answers both. Each is scoped and tested differently, and the interface is the one most often left out.

01 · Application tier · Web application security audit

What is a web application security audit, and what does it include?

Authenticated and unauthenticated testing of one application — its request handling, its authentication, its authorisation model and its business logic — from the browser inward.

What it covers

Input handling on every reachable parameter: injection into the data store, the template engine, the operating system, the mail header and the log.
The authentication surface: registration, login, multi-factor enrolment and bypass, password reset, session issue, session fixation, session expiry, logout and concurrent sessions.
The authorisation model, which is where the expensive findings live — horizontal access across peer records, vertical access across privilege levels, and function-level access to endpoints the interface never renders for that role.
Business logic: negative quantities, replayed state transitions, race conditions on a limited resource, workflow steps taken out of order, client-side price or discount trust.
File upload and download paths, export and reporting features, and anything that renders user-controlled content back to another user.
Client-side security posture as it affects this application: cookie flags, framing, content security policy, exposed source maps, secrets shipped to the browser.

What it provably cannot find

Anything on a hostname that is not in the scope. The admin console on a second host, the file service on a third and the identity provider on a fourth are separate assets, and §16.1(iii) requires the report to list the assets you provided — not the ones you did not.
Server, operating-system and hosting-stack weaknesses outside the application, unless a network or configuration engagement runs alongside. Where the application sits on a web server somebody else owns, §13.1.5 puts the server, its operating system, the hosting software and the backend database software on the server owner.
A flaw in a role nobody gave it credentials for. One read-only test account removes the entire authorisation class of findings and leaves the report looking clean.
Defects in code paths that were unreachable during the window — a feature behind a flag, a seasonal workflow, an integration pointing at a stub rather than a sandbox.
Whether the build running in production is the build that was tested. That link is carried by version and hash, which §15.2.3(ii) requires the auditor to obtain from you and put in the report.
Anything after the test window closes. §10.1(i) limits the auditor to reviewing and reporting on the state of security at the point in time of the audit.

What actually drives the duration

Not page count. The multiplier is authenticated roles times distinct workflows: every role has to be driven through every state-changing workflow, and then across roles for horizontal and vertical access. A six-role application with eight workflows is a different engagement from a two-role application with eight workflows, at identical page counts. Second multiplier: the number of distinct request-handling stacks behind one front end — a legacy module and a rewritten module are two applications wearing one domain name.

What the tester needs from you before the first packet

A staging or testing environment that matches production in configuration, integrations and data shape. §15.2.3(ii) requires website testing on the staging server or testing environment provided by the hosting service provider before the audit certificate issues.
Two working accounts per role, not one — horizontal access testing needs a peer to reach across to.
The role matrix as a document: which role may perform which action on which object. Without it the tester is inferring your intent from your interface, which is the thing under test.
Version string and artefact hash with the algorithm, recorded on your side at the moment the build is handed over (§9.5(i), §15.2.3(ii)).
Integrations pointed at sandboxes rather than stubbed out, and a named contact who can reset state when a test run consumes it.
Written approval before the penetration-testing phase and before any tool is installed (§13.2.2(v)), and the environment named in writing (§15.2.3(i)).

Finding classes it produces

Injection (CWE-89, CWE-79, CWE-22), broken authorisation (CWE-862, CWE-863, CWE-639), authentication and session defects (CWE-287, CWE-384), unrestricted upload (CWE-434), deserialisation (CWE-502), server-side request forgery (CWE-918), sensitive information exposure (CWE-200, CWE-209), and configuration-class findings that belong to the application rather than the host.

Tested against

OWASP Web Security Testing Guide and OWASP Application Security Verification Standard, both named at §8(ii), read with the Cyber Security Audit Baseline Requirements.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xii) Application security testing (including web applications, mobile applications and APIs), and Web Application Security Audit is one of the nine audit types §13.2.3(i)(a) requires you to name before commencement.

04 · Application tier · Mobile application security audit

What does a mobile app VAPT include?

Testing of the installed application on a real device and of its traffic — the binary, what it writes to the device, how it protects that data, and how it talks to the backend.

What it covers

Static examination of the shipped artefact: hard-coded secrets, API keys and endpoints, debug and logging left enabled, third-party libraries and their known vulnerabilities, code obfuscation and anti-tamper as claimed versus as present.
Local data storage: databases, preference stores, caches, logs, screenshots and backups, and whether anything sensitive survives logout or a device backup.
Transport security in practice: certificate validation, pinning and whether pinning can be bypassed, cleartext fallbacks, and what the application does when it is handed an untrusted certificate.
Platform integration: permissions requested versus used, exported components, deep links and custom URL schemes, clipboard and inter-process leakage, keyboard caching, screen capture on sensitive views.
Runtime posture: behaviour on a rooted or jailbroken device, debugger and hooking resistance, and whether client-side controls are enforced anywhere other than the client.
Authentication and session handling as the app implements it, including biometric unlock, token storage and token lifetime.

What it provably cannot find

Server-side authorisation defects, unless the API tier is in the scope as its own asset. §6(xii) names APIs expressly and §13.1.1(a) puts them inside the audit scope. The full argument is under “A web application test with no API test behind it” in the scope-gaps section below, which is where this page states it once.
Anything on the platform you did not put in scope. Android and iOS are two engagements with two artefacts, two storage models and two sets of platform controls — one report covering "the mobile app" without naming both is covering one.
Defects in a build other than the one submitted. §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be stated in both the audit scope and the report, and app stores ship a new build every fortnight.
Backend business logic, rate limiting or fraud controls, which live behind the API and are only visible when the API is tested as an API.
Whether the store-signed release matches the tested artefact, unless you recorded the hash of what you handed over and can reconcile it (§9.5(i)).

What actually drives the duration

Platforms times build variants, then the depth of the runtime work. Two platforms is two engagements. Beyond that, the cost driver is anti-tamper: an application with pinning, root and jailbreak detection and obfuscation takes materially longer to reach a testable state than one without, and that time is spent before any finding is produced. Third driver is whether the API tier is in the same scope, which roughly doubles the useful output and the effort together.

What the tester needs from you before the first packet

The signed artefacts for every platform and variant in scope — the APK or AAB and the IPA — with version, build number and hash recorded on your side.
Test accounts at every role, on a backend the tester may hit, and a statement of which backend that is: production, staging or a dedicated test tier.
Provisioning for iOS testing on a real device, which is a procurement item and a lead-time item, not a detail.
Documentation of the anti-tamper controls in place and a decision on whether the tester may bypass them. If the answer is no, the report is about the wrapper, not the application.
The API inventory behind the app, even if the API is out of scope — so that the limitation appears in the report as a limitation rather than as silence (§16.1(ii)).

Finding classes it produces

Cleartext or weakly protected local storage (CWE-312, CWE-311), hard-coded credentials and keys in the artefact (CWE-798), improper certificate validation (CWE-295), exported component and deep-link exposure (CWE-926 class issues on Android), insufficient transport protection, sensitive information exposure through logs and caches (CWE-200), and client-side enforcement of a control the server does not enforce.

Tested against

The OWASP Mobile Security Testing Guide is named at §8(ii). Note a drafting difference worth carrying into a scope of work: GIGW 3.0 guideline 5.3.1 names OWASP MAVS in its government-organisation action, where CERT-In names the MSTG. Name the document and its version in the scope rather than the initialism.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xiii) Mobile Application Security Auditing is a class of its own, and §6(xii) names mobile applications inside application security testing. Mobile Application Security Audit is also one of the nine types at §13.2.3(i)(a).

05 · Application tier · API security audit

What is API VAPT, and why is it scoped separately?

Testing of the interface itself — every endpoint, method, parameter and object identifier — as a client that does not run your front end and is not bound by it.

What it covers

Object-level authorisation across every endpoint that accepts an identifier, which is the defining API finding class and the one a front-end-driven test structurally misses.
Function-level authorisation: endpoints the interface never calls for a given role, undocumented methods on documented paths, and administrative routes left routable.
Property-level exposure: responses that return more fields than the client renders, and requests that accept more fields than the client sends — mass assignment in both directions.
Authentication on the API as distinct from authentication on the app: token issue, scope, audience, expiry, refresh, revocation, and what happens to a token after a password change.
Resource controls: rate limiting, pagination limits, payload size limits, expensive query protection, and batching or GraphQL-style endpoints where one request can become ten thousand.
Versioning and deprecation — the previous major version, still routable, still unauthenticated, still returning data.

What it provably cannot find

Anything on an endpoint that was not enumerated. An API test is exactly as wide as the inventory of base paths and operations it was given. Undocumented endpoints are the ones that matter and the ones nobody hands over.
Front-end-only defects — stored cross-site scripting rendered in a browser context, framing, content security policy — unless a web application engagement runs alongside.
Behaviour of the API gateway or management layer as a control, unless it is named as an in-scope asset. Testing through a gateway and testing the gateway are different scopes.
Whether the machine-to-machine consumers behave. The API test covers the interface, while partner integrations and their credential handling are vendor risk work (§6(xxiv)).
Business-logic abuse that requires a valid downstream side effect the tester was not allowed to trigger — payment capture, dispatch, irreversible state change. Those get carved out, and the carve-out belongs in the report.

What actually drives the duration

Operations times roles, where an operation is a method on a path and not a path. Two hundred endpoints across four roles is eight hundred authorisation checks before anything creative happens. The second driver is how the inventory arrives: a current specification file makes enumeration a morning. Reconstructing the surface from traffic capture makes it a week, and leaves the result incomplete in a way the report has to state.

What the tester needs from you before the first packet

A current machine-readable specification, or a collection export, or traffic capture — in that order of preference, and with an honest statement of its completeness.
Credentials or tokens at every role, plus at least one second account per role for object-level authorisation testing.
The base paths of every version still routable, including the ones you intended to retire.
A statement of which side effects are off limits and which downstream systems are live, so the carve-outs are agreed rather than discovered.
Rate-limit posture for the test window: if production limits stay on, the report measures the limit. If they come off, note it, because the report must describe the environment tested (§15.2.3(i)).

Finding classes it produces

Broken object-level and function-level authorisation (CWE-639, CWE-862, CWE-863), missing authentication on a critical function (CWE-306), excessive data exposure (CWE-200), mass assignment (CWE-915 class issues), unrestricted resource consumption (CWE-770), injection reached through a parameter no front end sends (CWE-89), and server-side request forgery from a URL-accepting field (CWE-918).

Tested against

OWASP Web Security Testing Guide and ASVS (§8(ii)), applied against the specification rather than against a rendered interface.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xii) names APIs expressly inside application security testing, §13.1.1(a) requires APIs to be inside the audit scope, and API Security Audit is one of the nine types at §13.2.3(i)(a).

The network tier

Outside, inside, and over the air

What is the difference between internal and external VAPT?

The starting position, and nothing else. An external engagement works from the public Internet and answers “what is exposed, and can it be pushed past its intended function”. An internal engagement works from a defined position inside — a plugged-in port, a contractor VLAN, an assumed-breach foothold — and answers “how far does a presence inside travel”. They are different questions, and the second one does not tell you whether the first was possible. Buying one and reading it as though it answered both is the most common misread in this field, which is why an external test with no internal test has its own entry in the scope-gaps section.

These three are separated by the tester’s starting position, and the starting position determines the result more than the tester does. §6(v) Network infrastructure Audits reaches all three. §13.2.3(i)(a) gives the external case its own label, EAPT. §6(xiv) makes wireless a class in its own right. The combination people buy — external only — answers the narrowest of the three questions.

02 · Network tier · External network penetration test

What is an external network VAPT, and what does it reach?

Testing of the perimeter as an unauthenticated attacker on the public Internet sees it — what is exposed, what version it is, what it will accept and where it can be pushed past its intended function.

What it covers

Discovery and enumeration across the ranges and hostnames in scope: what actually answers, on which ports, with which service and which version banner.
Exposed management and remote-access surfaces — administration panels, remote desktop, database ports, hypervisor and backup consoles, development and staging hosts that were never meant to be reachable.
Transport security on everything that terminates TLS: protocol versions, cipher suites, certificate validity and chain, and hosts still answering on plaintext.
Known-vulnerable versions of edge software, with exploitation attempted where the scope and the written approvals permit it (§6(iv) defines penetration testing as active testing to identify and exploit potential vulnerabilities).
Authentication weaknesses reachable from outside: default credentials, weak password policy at the edge, absent lockout or rate limiting.
The gap between the asset inventory and reality — the finding most external tests actually produce, which is that the estate is larger than the register.

What it provably cannot find

Anything reachable only from inside. A flat internal network, a domain-wide privilege path, a file share readable by every employee: all invisible from outside, by construction.
Application-layer authorisation defects. The perimeter test reaches the login page, but it does not have six roles and a mandate to cross between them.
Denial-of-service resilience. §15.2.2(ii) requires explicit written permission before DoS, DDoS or flood testing over the Internet, and the 2018 auditor guidelines 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. Absent that permission, the answer to "will it stay up" is not in the report.
What a phishing email would achieve. That is process security testing, and §15.2.2(iii) fences it: anonymised or statistical technique, only the agreed internal group, and no customers, partners, vendors or other third parties without specific written consent.
The behaviour of assets behind a content delivery network or scrubbing service, where the tester is measuring the intermediary rather than your origin — unless the origin is separately in scope and reachable.

What actually drives the duration

Live hosts and answering services, not the size of the CIDR block. A /16 that is ninety-nine per cent dark is faster than a /24 that is fully populated. The second driver is verification: every automated finding has to be confirmed by hand, because §8(i) discourages solely tools-based testing on the stated ground that tool-based audits may focus primarily on automated processes and overlook non-automated or manual components.

What the tester needs from you before the first packet

The authoritative list of ranges, hostnames and cloud-hosted addresses you own, with the as-of date — §13.2.3(ii)(b) requires that date to appear in the report, and §13.1.1(c) requires the scope to be derived from a consolidated and updated asset inventory.
Written authorisation for any asset hosted by a third party, because you cannot authorise testing of infrastructure you do not own.
Source addresses whitelisted or, better, not whitelisted but known. §13.2.7 contemplates the auditor disclosing identity, mobile number and/or IP addresses for remote and high-risk testing. Annexure I item 6 of the empanelment terms puts the same point differently, as the origin of remote testing being made known by telephone numbers and/or IP addresses. Both instruments give alternatives, not a cumulative list — ask for whichever identifies the traffic in your logs.
A decision, in writing, on whether protective controls stay on. Testing through a web application firewall measures the firewall, while testing behind it measures the application. Both are legitimate, but only one is what you think you bought.
A named contact reachable during the window, and a commitment under §15.1.1(ii) that no unusual or major network change lands mid-test.

Finding classes it produces

Exposed services and management interfaces (CWE-284, CWE-1188), default and hard-coded credentials (CWE-1392, CWE-798), missing authentication on a critical function (CWE-306), weak transport security (CWE-327, CWE-311, CWE-295), unpatched software carrying published CVEs, and information disclosure from banners, error pages and metadata (CWE-200).

Tested against

OSSTMM 3 and the Cyber Security Audit Baseline Requirements, both named at §8(ii) and §8(iii).

Mapping to CERT-In’s classes of engagement

Partial

§6(v) Network infrastructure Audits and §6(iv) Penetration Testing both reach it, and §13.2.3(i)(a) names EAPT — External Attack Penetration Testing — as a type of audit in its own right. There is no §6 class called "external network penetration test", so name the class and the type, not the market phrase.

03 · Network tier · Internal network penetration test

What is an internal network VAPT, and when do you need one?

Testing from a position inside the network — an assumed-breach foothold, a plugged-in port, a compromised laptop, a contractor VLAN — to establish how far a presence inside travels.

What it covers

Segmentation as built rather than as drawn: what the user VLAN can actually reach in the server VLAN, whether the payment segment is isolated, whether the out-of-band management network is really out of band.
Directory and identity weaknesses: credential exposure in shares and scripts, delegation and trust misconfiguration, service accounts with excessive rights, stale privileged accounts nobody owns.
Lateral movement and privilege escalation paths, which is the output that matters — the chain from initial foothold to the asset the business actually cares about.
Internal-only services: file shares, print and backup infrastructure, monitoring, jump hosts, internal web tooling, databases reachable without an application in front of them.
Whether the host build resists what it is supposed to resist, and whether detection fires — although detection testing has to be named in the scope or it is not being measured.

What it provably cannot find

Whether the foothold it starts from was achievable in the first place. An assumed-breach internal test answers "how bad is it once someone is in", not "can someone get in". Those are two engagements, and buying one and reporting the other is the most common misread in this whole field.
Anything on a segment the tester was not placed on. The drop point is a scope decision, and it determines the result more than the tester does.
Availability limits. §15.2.2(iv) is explicit that in critical environments where availability is a top priority, testing should be conducted in a passive manner — so on an operational technology or hospital network the aggressive checks are the ones you have agreed to lose.
Whether the paths found are the shortest ones, unless the scope and the calendar allowed the estate to be covered rather than sampled. §16.1(ii) requires the report to state sampling decisions, exemptions, limitations and other constraints, and that paragraph is the one worth reading first.
Physical access weaknesses. §6(xv) Physical Security Testing is a separate class of engagement.

What actually drives the duration

Identity complexity and segment count, not host count. A single domain with clean tiering is quick. Multiple forests, historical trusts and twelve years of merged estates are not. The second driver is how much of the work has to be passive: on a critical-availability segment under §15.2.2(iv), the same coverage takes materially longer because the fast checks are off the table.

What the tester needs from you before the first packet

A defined drop point, or several, each named in the scope with what it represents — employee laptop on the user VLAN, contractor device, compromised server in the DMZ.
Network and segmentation documentation, and the honest statement of where it is out of date. §13.1.4(ii) asks you to assign a technical team as point of contact to assist and monitor the auditing organisation during the audit.
Temporary privileged credentials where the scope requires them, which §15.1.2 requires to be revoked immediately on completion.
A decision on who knows. §15.1.1(i) limits notification to key personnel, glossed in the instrument as policy-making level plus the managers responsible for security processes, incident response and security operations.
Change freeze for the window, and an escalation matrix agreed in advance under §13.2.6 — internal testing is where something breaks.

Finding classes it produces

Improper access control and privilege management (CWE-284, CWE-269), credential exposure in files, scripts and shares (CWE-798, CWE-312), weak or absent authentication on internal services (CWE-306), incorrect permissions on critical resources (CWE-732), legacy protocol and cryptography weaknesses (CWE-327), and unpatched internal software carrying published CVEs.

Tested against

OSSTMM 3 and the Cyber Security Audit Baseline Requirements (§8(ii), §8(iii)), with configuration baselines for the platforms in scope.

Mapping to CERT-In’s classes of engagement

Partial

§6(v) Network infrastructure Audits and §6(iv) Penetration Testing. §13.2.3(i)(a) names EAPT for the external case and DLA — Device Level Audit — for device-level work, but the instruments do not carry a matching abbreviation for the internal engagement, so describe it by position and drop point rather than by a label.

07 · Network tier · Wireless security testing

What does wireless VAPT test?

On-site testing of the radio estate at a named location — the enterprise network, the guest network, the authentication method behind them, and whatever else is transmitting in the building.

What it covers

Authentication and encryption in use per SSID: the enterprise authentication method and its certificate validation, pre-shared keys and their handling, management-frame protection, and legacy fallbacks left enabled for one old device.
Segmentation after association: what a guest gets to, what a corporate device gets to, and whether the two are actually separated or only differently named.
Rogue and unauthorised access points, including the consumer device someone plugged in, and the evil-twin exposure of the corporate SSID where testing of that is authorised.
Client-side behaviour: preferred network lists, automatic association, and devices that will connect to an SSID name anywhere in the world.
Coverage and bleed, which is a physical finding — where the corporate network is reachable from outside the perimeter, the car park included.
Non-Wi-Fi radio in scope where it has been named: building management, badge readers and similar, which are usually somebody else’s asset and need their own authorisation.

What it provably cannot find

Anything at a site nobody visited. Wireless testing is per-location and does not generalise: one floor of one office tells you about that floor.
Anything about the wired network beyond the first hop the wireless segment lands on, unless an internal network engagement is in scope.
Denial-of-service resistance in the radio layer. Jamming and deauthentication flooding fall inside the 2018 auditor guidelines’ flood-testing bullet, which names no medium — refrain from any form of flood testing where a person, network, system, or service is overwhelmed from a larger and stronger source. The nearest written-permission analogue is §15.2.2(ii), but read it as an analogue rather than as authority: its own words are scoped to DoS, DDoS or flood testing "over the Internet", and radio-layer flooding is on-site. The permission you actually need is the auditee’s own written authorisation for the activity, named in the scope.
Whether users would fall for a rogue network, unless human-facing testing is separately authorised under §15.2.2(iii) — anonymised, statistical, agreed group only.
The state of the estate next month. Access points get added by facilities teams who are not on the change board.

What actually drives the duration

Sites, then floors, then SSIDs and authentication methods. Travel and site access are usually the larger half of the calendar time — which is why §13.2.2(ii) requires the test plan to carry both calendar time and man-hours, and why a wireless line item priced on man-hours alone will be wrong.

What the tester needs from you before the first packet

Site addresses, access arrangements, and a named escort. This is a physical-attendance engagement.
The SSID inventory with the intended purpose and intended segmentation of each, and the authentication method in use.
Written authorisation from the building owner where you are a tenant, because the radio estate in a shared building is not all yours.
A decision on evil-twin and deauthentication activity, in writing, with the safety carve-outs — this is the wireless engagement’s equivalent of the DoS permission at §15.2.2(ii).
Test credentials for the enterprise network at a normal user level, plus a guest credential if the guest network is gated.

Finding classes it produces

Weak or legacy authentication and encryption (CWE-327, CWE-326), missing certificate validation in enterprise authentication (CWE-295), weak pre-shared credentials (CWE-521), improper access control where guest and corporate traffic meet (CWE-284), and unauthorised devices as an inventory and governance finding rather than a CWE-scored one.

Tested against

OSSTMM 3, whose scope includes communications and wireless security, read with §6(xi) Communications Security Testing where the radio estate carries more than Wi-Fi.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xiv) Wireless Security Testing is a named class in its own right. Wireless networks are also named expressly in the CERT-In Directions of 28 April 2022, Annexure I item (ix), among the incident types that must be reported.

The platform tier

The cloud account, and the machine on the desk

Is cloud VAPT the same as a cloud configuration audit?

They are not the same, and in the Indian market the phrase “cloud VAPT” is almost always sold as the configuration audit. A configuration review uses read-only, audit-scoped credentials and measures posture against a baseline. It maps to §6(xviii) Cloud Security Testing and to the Configuration Audit type at §13.2.3(i)(a). Penetration testing is defined at §6(iv) as active testing to identify and exploit potential vulnerabilities and to determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure and environment — which a read-only review does not do and cannot claim to have done. Both are worth buying for a material estate. The full argument is under a cloud configuration review presented as a penetration test.

Both of these are configuration work, and both are routinely mis-sold as something more active than they are. §6(xviii) Cloud Security Testing and §6(xxii) Endpoint Security Assessment are real classes with real value, but neither is a penetration test, and neither is an adversary simulation.

06 · Platform tier · Cloud configuration review

What is a cloud configuration review, and is it a penetration test?

An authenticated, read-only review of how the cloud account itself is configured — identity, network, storage, logging, encryption and the posture of the managed services in use.

What it covers

Identity and access management: roles and policies, wildcard and administrative permissions, cross-account trust, key age and rotation, absence of multi-factor on privileged principals, and the human accounts that should be federated and are not.
Storage and data services: public or over-broad access, encryption at rest and key custody, versioning, lifecycle and backup configuration, snapshot sharing.
Network construction: security groups and firewall rules, publicly routable resources, peering and transit paths, private endpoints where they should exist and do not.
Logging and monitoring: whether audit logging is enabled across regions and accounts, whether it is protected from the identity being audited, and whether retention meets the 180-day rolling requirement direction (iv) of the CERT-In Directions of 28 April 2022 places on logs. Direction (iv) reads that logs shall be maintained within the Indian jurisdiction. CERT-In’s own FAQ of May 2022 then glosses it at Q35 — "The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time." A region choice is a decision for that sentence, not against it, and the FAQ states of itself that it is not a legal document and does not replace, amend or alter the IT Act, 2000 or the CERT-In Rules, 2013.
Managed-service posture: database, container orchestration, serverless and secret-management configuration against the platform baseline and against the CSA Cloud Controls Matrix.
The shared-responsibility boundary written down — which is not a finding but is the artefact that makes findings actionable.

What it provably cannot find

Exploitability. This is the central honest point of this page: a configuration review is not a penetration test. §6(iv) defines penetration testing as a methodology in which components or the application as a whole are actively tested to identify and exploit potential vulnerabilities, to determine whether they can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment. A read-only review does not do that and cannot claim to have done it.
Application-layer defects in anything running on the platform. A perfectly configured account will happily host an application with broken authorisation.
Anything outside the accounts, subscriptions or projects enumerated. Shadow accounts are invisible, and they are common.
Runtime compromise or persistence already present. Configuration review is a posture assessment, not an incident-response or forensic-readiness exercise (§6(xvii) covers the latter as its own class).
Whether the posture holds tomorrow. Infrastructure as code redeploys. A review of the live account at a point in time is exactly that, under §10.1(i).

What actually drives the duration

Accounts, subscriptions or projects times regions in use, then the number of distinct managed services. One account in one region is a day of collection and a day of judgement. Forty accounts across three regions with a service catalogue of thirty is a programme. The judgement half does not shrink with tooling — §8(i) discourages solely tools-based testing precisely because automated output misses the non-automated components.

What the tester needs from you before the first packet

A read-only, audit-scoped identity in every account in scope, and the complete list of accounts. The list is the deliverable most likely to be wrong.
The organisational structure: which accounts are production, which are shared services, which belong to a team that left.
Your own baseline or benchmark selection, so that findings are measured against a standard you have adopted rather than a standard the tester likes.
Data residency position in writing. GIGW guideline 5.3.2 requires government organisations to ensure hosting of the web infrastructure within the geographical boundaries of India, and §10.3(ii) separately requires your audit data to be stored only in India.
A clear statement of whether any active testing is authorised, and of what. If none is, say so — so the report cannot be read as a penetration test by anyone downstream.

Finding classes it produces

Incorrect permission assignment for a critical resource (CWE-732), incorrect default permissions (CWE-276), improper access control (CWE-284), missing encryption of sensitive data (CWE-311), insecure default initialisation (CWE-1188), insufficient logging, and exposure of sensitive information through a publicly readable store (CWE-200).

Tested against

CSA Cloud Controls Matrix, named at §8(ii) for cloud security. For hardening, GIGW 3.0 guideline 5.3.2 requires servers and network devices to be hardened with the latest security patches and subjected to periodic vulnerability assessment and penetration testing, but it names no benchmark. The benchmarks sit in the preamble to GIGW chapter 5.3, which asks the government organisation to ensure the host service provider and the developer adhere to industry best security practices and guidelines such as ISO 27001, OWASP ASVS, OWASP Top 10 vulnerabilities and CIS benchmarks as per the prevailing security policy.

Mapping to CERT-In’s classes of engagement

Partial

§6(xviii) Cloud Security Testing covers it — the definition is evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures — and §13.2.3(i)(a) names Configuration Audit as a type. It does not map to §6(iv) Penetration Testing, and a scope of work that treats the two as interchangeable is describing an engagement nobody is going to perform.

08 · Platform tier · Endpoint security assessment

What is an endpoint security assessment?

Assessment of the standard build and its controls — what a laptop, server or mobile device is configured to resist, and whether the controls you have licensed are actually enforcing anything.

What it covers

The build itself against a hardening baseline: local administrator rights, disk encryption, screen lock, firewall, boot protection, patch level and patch cadence.
Application control and execution policy: whether unsigned or user-writable-path execution is prevented, and whether the policy is in enforce mode or in the audit mode it was deployed in eighteen months ago.
Endpoint protection and detection as configured: coverage across the fleet, tamper protection, exclusion lists, and whether the console reflects the devices that actually exist.
Credential exposure on the device: cached credentials, stored browser secrets, scripts and configuration files, and what a local user can read.
Removable media, peripheral and data-egress controls where those are claimed.
Escalation from standard user to local administrator on the standard build, which is the test that tells you whether the rest of the controls hold.

What it provably cannot find

Whether detection would fire against a determined adversary across a full intrusion chain. That is §6(xvi) Red Team Assessment — an exercise, reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems. An endpoint assessment is a control review, not an adversary simulation.
Fleet-wide truth from a sample. §16.1(ii) requires sampling decisions to be stated in the report, and an endpoint assessment is almost always a sample — the golden image plus a handful of real devices.
Anything about devices outside your management: personal devices, contractor laptops, unmanaged servers, the machine in the lab that never enrolled.
Server and workload posture, unless servers are separately in scope. Workstation build and server build are two baselines and usually two teams.
Whether the controls survive the next policy change. Endpoint posture drifts faster than any other asset class because it is governed by policy objects, not by releases.

What actually drives the duration

Distinct builds and operating-system families, not device count. Three Windows images, a Mac build and a Linux server baseline is five assessments. The second driver is evidence access: assessing a policy from the console is quick, proving it is enforced on a device is not, and the second is the only one that answers the question.

What the tester needs from you before the first packet

One representative device per build, provisioned as a normal user would receive it — not a lab machine with policies excluded.
A standard user account on each, and a statement of whether local administrator rights are normally granted.
The hardening baseline you claim to apply and the policy exports behind it, so that the assessment measures you against your own standard.
Console read access for coverage figures, and the device inventory to reconcile against — the reconciliation is usually the first finding.
A statement of which controls may be actively tested and which may only be reviewed, so the report can say which is which.

Finding classes it produces

Improper privilege management and local escalation (CWE-269, CWE-250), incorrect default or resource permissions (CWE-276, CWE-732), missing encryption of data at rest (CWE-311), credential exposure on the device (CWE-798, CWE-312), unpatched software carrying published CVEs, and control-coverage gaps recorded as governance findings.

Tested against

The Cyber Security Audit Baseline Requirements (§8(iii)), with ISO/IEC standards named generally at §8(ii). For the build baseline itself, the preamble to GIGW 3.0 chapter 5.3 names ISO 27001, OWASP ASVS, OWASP Top 10 and CIS benchmarks as the industry practices a government organisation is to ensure its host service provider and developer adhere to. Guideline 5.3.2 requires the hardening and the periodic VA and PT, and leaves the choice of benchmark to the prevailing security policy.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xxii) Endpoint Security Assessment is a named class, and §13.2.3(i)(a) names DLA — Device Level Audit — as a type of audit to be communicated before commencement.

The operational technology tier

The plant, and the thing you shipped

What is OT or ICS VAPT, and is it the same as IT penetration testing?

§6(xix) makes Industrial Control Systems and Operational Technology Security Testing a class in its own right, and §6(xx) does the same for Internet of Things and Industrial Internet of Things testing. §13.1.1(a) puts OT and ICS inside the audit scope alongside applications, networks, cloud, APIs and databases, so a scope that covers a plant’s corporate network and stops at the process boundary has departed from the clause it is quoting. These are not IT engagements with a different word in front of them: one rule changes everything about how they run, and it is §15.2.2(iv) — in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid any potential downtime or service disruption.

That single sentence is the trade. You keep the plant running and you give up the active half of the methodology, which means the engagement has to be scoped, explained and read as a §6(iii) vulnerability assessment rather than a §6(iv) penetration test. Both of these classes also appear on the incident side: attacks on critical infrastructure, SCADA and operational technology systems are Annexure I item (ix) of the CERT-In Directions of 28 April 2022, and attacks on Internet of Things devices and associated systems are item (xiii) — both mandatorily reportable to CERT-In within six hours of being noticed.

09 · Operational technology tier · Industrial control systems and operational technology security testing

What does an ICS or OT security audit actually test?

Testing of the environment that runs a physical process — the control network, the engineering workstations, the historians, the protocol gateways and the path between the plant and the corporate estate — conducted under a rule that availability comes first.

What it covers

The boundary between the corporate network and the process network: the firewall rule set, the jump host, the remote-access path the vendor uses, and whether the conduit is a conduit or a hole.
Passive discovery of what is actually on the control network — devices, firmware versions, protocols in use, undocumented engineering laptops, and the cellular modem somebody fitted for a commissioning visit in 2019.
Authentication and access on the supervisory layer: engineering workstations, the human-machine interface, historian and reporting servers, and the shared credentials that keep a shift running.
Protocol exposure where the protocol has no authentication by design, and whether anything between the supervisory layer and the controller would notice an instruction it did not send.
Patch and lifecycle reality: vendor-frozen operating systems, support status, and the compensating controls that are supposed to make that acceptable.
Backup, recovery and configuration custody for controller logic — the question that decides how long a plant is down rather than how it was reached.

What it provably cannot find

Anything that requires an active check on a live process. §15.2.2(iv) is the governing sentence: in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid any potential downtime or service disruption. On a running plant the aggressive half of the methodology is the half you have agreed to lose, and the report has to say so.
Controller-level behaviour under stress. Fuzzing a programmable controller on a live line is not a test, it is an outage, and the 2018 auditor guidelines separately tell auditors to refrain from testing and exploiting high-risk vulnerabilities such as discovered breaches or anything that may put immediate lives at risk.
Anything on equipment you do not own or cannot authorise. Skid-mounted plant, vendor-managed turbines and leased medical devices belong to somebody else, and their owner’s written authorisation is a procurement item rather than an assumption. Separately, §13.1.4(i) requires that where activities to be audited are outsourced, the auditee organisation ensures the relevant personnel from the outsourced organisation are available at the time of the audit — availability, which is a contractual matter and belongs in the maintenance contract rather than in an email sent the week testing starts.
Safety-instrumented function integrity. A safety system is certified on its own regime and is not a penetration-testing target. A security review can say whether it is reachable, not whether it will trip.
Whether the site matches the other eleven sites. OT estates are built by different integrators in different decades, and a finding at one plant is a hypothesis everywhere else.

What actually drives the duration

Sites and cells, then protocols, then how much has to be passive. A single-line facility with one protocol family and a documented conduit is a week. A multi-site estate with four integrators, three protocol families and no current network diagram is a programme whose first phase is drawing the diagram. Travel and shutdown windows are the other half of the calendar, which is exactly why §13.2.2(ii) requires the test plan to carry calendar time as well as man-hours.

What the tester needs from you before the first packet

A written availability position: which systems are critical-availability under §15.2.2(iv), what passive means for each, and who may authorise an active check and when.
Site access, a named escort from operations, and the shutdown or maintenance window if any active work is agreed. Operations owns the calendar here, not security.
The network diagram as built, the asset register for the control estate with its as-of date (§13.2.3(ii)(b)), and an honest statement of where both are wrong.
Vendor authorisation in writing for equipment under a maintenance contract, and the vendor personnel §13.1.4(i) requires to be available during the audit.
The standard you are testing against, named in the scope. §8(ii) names ISO/IEC standards generally and the Cyber Security Audit Baseline Requirements at §8(iii), but the instruments do not name an OT-specific methodology, so you choose one and write it down.
An escalation matrix agreed in advance under §13.2.6, with a stop condition that anybody on site can call.

Finding classes it produces

Missing authentication on a critical function (CWE-306), improper access control between the corporate and process networks (CWE-284), use of hard-coded or shared credentials (CWE-798, CWE-1392), cleartext transmission of sensitive information on control protocols (CWE-319), unpatched software carrying published CVEs on supervisory hosts, and insufficient logging and recovery capability recorded as governance findings.

Tested against

ISO/IEC standards named generally at §8(ii) and the Cyber Security Audit Baseline Requirements at §8(iii). No OT-specific methodology is named in the instruments read for this page, so the choice belongs in the scope of work. CERT-In’s own Working Group on Indian Standards for Cybersecurity Auditing, presented at SAMVAAD 2026, states an aim of delivering standardised reporting formats, RFP templates and scope templates for audit types including ICS and OT environments — that work is stated as an aim, and no published template has been read for this page.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xix) Industrial Control Systems/Operational Technology Security Testing is a class in its own right, defined as evaluating the cyber security posture of ICS and OT networks, specifically designed to identify vulnerabilities and potential threats that could disrupt critical industrial processes, impacting safety, production, and overall system availability within a facility. §13.1.1(a) puts OT and ICS inside the audit scope, and attacks on critical infrastructure, SCADA and operational technology systems are a reportable incident class at Annexure I item (ix) of the Directions of 28 April 2022. §13.2.3(i)(a) has no dedicated abbreviation for it, so name the §6 class.

10 · Operational technology tier · Internet of Things and Industrial Internet of Things security testing

What does IoT VAPT cover, and how is it scoped?

Testing of a connected product as a system — the device and its firmware, the radio or wired link it speaks over, the cloud service it registers with, and the application that controls it.

What it covers

The device itself: exposed debug and serial interfaces, bootloader and secure-boot posture, firmware extraction, secrets recovered from storage, and whether the device can be made to accept an image it should refuse.
Provisioning and identity: how a device gets its first credential, whether that credential is unique per device, how it is rotated, and what a stolen device yields about the fleet.
The link layer in use — whichever it is — and whether the device authenticates the peer it talks to rather than only being authenticated by it.
The cloud tier the fleet registers with: per-device authorisation, whether one device can address another device’s topics or records, and the management interface behind it.
The update path end to end: image signing, rollback protection, and what happens to a device that misses an update for a year.
The companion application and the API between the two, which are the same engagement types as cards 04 and 05 pointed at a different backend.

What it provably cannot find

Anything about a variant you did not supply. Hardware revisions, regional SKUs and firmware branches are separate assets, and a finding on one revision is not a statement about the fleet.
Silicon-level and invasive hardware attacks unless they are named, authorised and budgeted. Decapsulation, glitching and side-channel work are a different discipline with a different cost, and their absence belongs in the limitations paragraph §16.1(ii) requires.
Fleet behaviour at scale. A bench test of three units says nothing about what a hundred thousand devices do to the cloud tier on a simultaneous reconnect.
Anything on a device in a customer’s home or a partner’s plant. The tester works on units you own and authorise. Deployed devices are somebody else’s property.
The safety consequence. Where the device actuates something physical, the availability rule at §15.2.2(iv) applies to it exactly as it applies to a plant, and an active check on a deployed actuator is not on the table.

What actually drives the duration

Device variants times firmware branches, then how much hardware work is authorised. Getting a shell on the first unit is the long pole — a device with locked debug interfaces and a signed bootloader can absorb a week before the first finding. After that, the cloud and application tiers are ordinary API and application work and are priced as such.

What the tester needs from you before the first packet

Several physical units per variant, which you should expect not to get back, plus the firmware image and the version of each.
A test tenancy in the cloud service, or written authorisation to work against production with the blast radius agreed in writing.
The architecture as built: which component authenticates which, where the device identity lives, and who operates each tier when more than one supplier is involved.
A statement on hardware-invasive testing — permitted, not permitted, or permitted on a sacrificial unit — so the scope and the report agree.
The API inventory for the fleet backend, on the same terms as card 05, because that is where per-device authorisation actually fails.

Finding classes it produces

Hard-coded or shared credentials across a fleet (CWE-798, CWE-1392), missing authentication on a critical function (CWE-306), improper access control between devices and tenants (CWE-284, CWE-639), cleartext transmission (CWE-319), missing or improper verification of a cryptographic signature on an update (CWE-347), exposed debug interfaces recorded against improper access control, and unpatched third-party components carrying published CVEs.

Tested against

No IoT-specific methodology is named in the instruments read for this page. §8(ii) names ISO/IEC standards generally. The application and API tiers are tested against the OWASP Web Security Testing Guide and ASVS as ordinary application work, and the Cyber Security Audit Baseline Requirements apply at §8(iii). Name the device-side methodology you are using in the scope, because the guidelines do not pick one.

Mapping to CERT-In’s classes of engagement

Genuine

§6(xx) Internet of Things (IOT)/Industrial Internet of Things Security Testing (IIOT) is a named class. Attacks on IoT devices and associated systems, networks, software and servers are a reportable incident class at Annexure I item (xiii) of the Directions of 28 April 2022, where CERT-In’s own explanation names cameras, routers, DVRs and wearables, describes a compromised device as acting as an intrusion point, and names botnets such as Mirai. There is no abbreviation for it at §13.2.3(i)(a), so name the §6 class and enumerate the tiers.

The platform-specific parts of a mobile audit

Android and iOS are two engagements, not one with a checkbox

Do we need separate VAPT for Android and iOS?

Yes, in practice. They are two artefacts with two storage models, two sets of platform components and two runtime-protection stacks, and a finding on one rarely transfers to the other. §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be explicitly mentioned in the audit scope and in the report, so a scope that says “the mobile app” without naming platform, build and version has not identified the asset it is about to test.

The methodology is shared, but almost nothing else is. The right-hand column is the one that matters for scoping, because it lists what neither platform’s work answers — and every item in it belongs to the API tier, to the backend, or to a document you have to produce.

Area of the audit	Android	iOS	What neither answers
The artefact you hand over	APK, or an AAB plus the split APKs a device actually installs. Decompiles readably. Resources, manifest and native libraries all inspectable.	IPA, which needs a provisioned device and usually a decrypted binary before static work starts. Lead time, not difficulty.	Neither tells you what the store-signed release contains unless the hash of the submitted artefact was recorded and reconciled (§9.5(i)).
Local storage	Application-private directories, SQLite databases, SharedPreferences, external storage, and anything written to a world-readable path by an older library.	Application sandbox, Keychain items and their accessibility attributes, Core Data stores, NSUserDefaults, and the caches directory that survives more than people expect.	Neither answers what the backend retains. Device hygiene and server-side retention are separate questions with separate owners.
Platform attack surface	Exported activities, services, broadcast receivers and content providers, intent handling, deep links, custom permissions, and WebView configuration and JavaScript bridges.	Custom URL schemes and universal links, app extensions and shared containers, pasteboard behaviour, and WKWebView configuration.	Neither covers the other platform. A report headed "mobile application" that names one artefact has audited one application.
Runtime protections	Root detection, debugger and emulator detection, integrity checks, obfuscation, and how each of them fails when bypassed.	Jailbreak detection, anti-hooking, certificate pinning implementations, and the same bypass question.	Neither is a substitute for server-side enforcement. Every control on the device is advisory. The only enforcement that counts happens behind the API.
Transport	Network security configuration, cleartext traffic policy, pinning implementation and the fallback behaviour when pinning fails.	App Transport Security exceptions declared in the bundle, pinning implementation, and the same fallback question.	Neither tests the API as an API. Observing traffic through the app reaches the endpoints the app calls, in the order the app calls them, with the values the app sends.

Two scoping items come out of this table and both are usually missed. The first is version identity: §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be explicitly mentioned in the audit scope and in the report, and §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. An app that ships fortnightly needs that link recorded at handover or the report describes a build nobody can find. The second is the anti-tamper decision: pinning, root and jailbreak detection and obfuscation all have to be bypassed before testing begins, and if you decline to permit that, the engagement measures the wrapper.

One vocabulary note worth carrying into a scope of work. §8(ii) of the 2025 guidelines names the OWASP Mobile Security Testing Guide, while GIGW 3.0 guideline 5.3.1 names OWASP MAVS in its government-organisation action, alongside the OWASP Top 10 and ASVS. Two Government of India instruments, two names for the mobile reference. Name the document and its version in the scope rather than the initialism, and the ambiguity disappears.

The combinations that leave a real gap

Scopes that look complete on a purchase order

What does a VAPT miss?

Each of these is a real combination, bought regularly, that produces a clean report about a system other than the one you run. None of them is a bad engagement. Each is a good engagement asked to answer a question it was not built for. The first and the third are the two this page returns to most, so they are stated in full here once and cross-referenced everywhere else.

A web application test with no API test behind it

The tester drives the browser, so the endpoints exercised are the endpoints the front end calls, with the identifiers the front end supplies. Object-level authorisation is the defect class that does not appear that way, because the front end never asks for a record belonging to somebody else.

What is left untested

Every endpoint the interface does not call for that role, every identifier the interface does not let you edit, every field the interface does not render, and every API version still routable behind the current one.

What closes it

Enumerate base paths and operations as assets with owners, and scope the API as its own engagement even when the same team performs it. §6(xii) names APIs expressly and §13.1.1(a) puts them in the audit scope.

A mobile audit with the backend out of scope

The commercially convenient split — the app belongs to one system integrator and the API to another — becomes a security split. Each scope assumes the other covered the tier in between.

What is left untested

Server-side authorisation, rate limiting, token revocation and business-logic abuse: everything that holds the data, as opposed to everything that displays it.

What closes it

Buy the app and the API in the same scope, or name the exclusion in the scope so §16.1(ii) carries it into the report as a stated limitation rather than a silence.

A cloud configuration review presented as a penetration test

Read-only posture review and active exploitation answer different questions. §6(iv) defines penetration testing as active testing to identify and exploit vulnerabilities and to determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure. A review with read-only credentials does none of that.

What is left untested

Whether the misconfigurations found can be chained into access. A permissive role and a reachable workload are a finding together and two observations apart.

What closes it

Name the engagement correctly in the scope and in the report, and buy both where the account is material — configuration review for coverage, penetration testing for reachability.

An external test with no internal test

The perimeter question and the post-foothold question are different engagements. A clean external report is frequently read as though it answered both.

What is left untested

Segmentation, identity architecture, lateral movement, and the distance between an ordinary user device and the asset the business runs on.

What closes it

Run an assumed-breach internal engagement on a defined drop point. State in the scope that the foothold is assumed, so the report is not read as evidence that it was achievable.

An internal test that never reaches wireless

Wireless is assumed to be part of "the network" and is then out of scope in practice, because the engagement is remote and wireless is a site visit.

What is left untested

Guest-to-corporate segmentation, the authentication method and its certificate validation, rogue access points, and coverage bleeding outside the building.

What closes it

Scope wireless per site with travel in the plan. §6(xiv) makes it a class of its own for a reason, and §13.2.2(ii) requires the test plan to carry calendar time as well as man-hours.

An endpoint assessment read as proof that detection works

Console coverage figures and policy exports show what is deployed. They do not show what fires. Deployment and detection efficacy are different measurements.

What is left untested

Whether a full intrusion chain would be detected and responded to — which is §6(xvi) Red Team Assessment, a simulated adversary exercise reflecting real-world conditions.

What closes it

Keep the two apart on the purchase order. An endpoint assessment tells you the controls exist and are enforced. A red team tells you whether they matter.

Source code out of scope while "code review" stays in the methodology list

The integrator supplies a binary and calls the source proprietary. The methodology section of the proposal still names code review, because it was copied from a template.

What is left untested

Everything static analysis finds that dynamic testing does not reach. §6(ix) Source Code Review is a class of engagement, and §13.1.3(iii) requires DAST and SAST for critical applications, with SAST required of the developer or system integrator and stated in the RFP.

What closes it

Put SAST on the builder in the build contract, and make the output an input to the audit rather than a deliverable that never arrives.

A staging-only engagement treated as production assurance

§15.2.3(ii) requires website testing on the staging server or testing environment the hosting service provider supplies before the audit certificate issues — which is the correct sequence, not a shortcut. The error is in what happens afterwards.

What is left untested

Production configuration, production data volumes, production integrations and production access paths. §16.3(v) requires the final report to issue after closure and the follow-up audit on production, and requires an explicit statement where the scope was limited to staging.

What closes it

Read the environment line. If it says staging and there is no production follow-up, the certificate is describing a system other than the one your users reach.

There is a structural reason these recur. §13.1.1(a) sets the expectation that the scope covers the entire cyber infrastructure — systems, web and mobile applications, network infrastructure, operational technology and industrial control systems, cloud architecture, APIs, databases and hosting infrastructure, code review, application security, data security and incident-response testing — and §13.1.1(c) requires it to be derived from the consolidated and updated asset inventory. Every gap above is an inventory failure wearing a scoping failure’s clothes. The fix is upstream of the auditor, which is why scoping is the step worth spending on.

Mapping to CERT-In’s classes of engagement

Where the market name matches the instrument, and where it does not

Which CERT-In audit type is our VAPT?

Two lists exist and they are not the same list. §6 of the 2025 guidelines gives twenty-six classes of engagement. §13.2.3(i)(a) gives nine audit types that have to be communicated to the auditee before commencement. A scope of work that names one of each is unambiguous, but one that names a market phrase is not. The at-a-glance table above carries the class and the label for each of the ten types. This table is the different question — the market phrases that do not resolve cleanly, with the verdict and what to write instead.

What the market calls it	Class of engagement (§6)	Audit type label	Verdict	What to write instead
VAPT, as a single engagement	No single class	VAPT (Vulnerability Assessment Penetration Testing) — §13.2.3(i)(a)	Not a class	§6 carries Vulnerability Assessments at (iii) and Penetration Testing at (iv) as two classes with two different definitions. VAPT appears as a type label in the list of audit types to be communicated before commencement, not as a class of engagement. Buy both deliberately or state which one you bought.
Web application VAPT	§6(xii) Application security testing	Web Application Security Audit — §13.2.3(i)(a)	Genuine	Both the class and the type label exist and mean what the market means. Name the application version too: §13.2.3(ii)(c) requires version-specific details of web and mobile applications in the scope and the report.
External network penetration test	§6(v) Network infrastructure Audits, §6(iv) Penetration Testing	EAPT (External Attack Penetration Testing) — §13.2.3(i)(a)	Partial	EAPT is the instrument’s own external label and is the closer match. There is no class named for the external case, so use the class and the type together.
Internal network penetration test	§6(v) Network infrastructure Audits, §6(iv) Penetration Testing	DLA (Device Level Audit) for device-level work — §13.2.3(i)(a)	Partial	The internal engagement is described by its starting position rather than by a label. Write the drop point into the scope, because it determines the result more than any other variable.
Mobile app VAPT	§6(xiii) Mobile Application Security Auditing, §6(xii)	Mobile Application Security Audit — §13.2.3(i)(a)	Genuine	A class of its own. Name the platform and the build, because "the mobile app" is two artefacts on two platforms.
API security testing	§6(xii) Application security testing (including APIs)	API Security Audit — §13.2.3(i)(a)	Genuine	§13.1.1(a) additionally requires APIs to be inside the audit scope, so a scope that omits them is departing from the instrument, not merely from good practice.
Cloud VAPT	§6(xviii) Cloud Security Testing	Configuration Audit — §13.2.3(i)(a)	Partial	Cloud Security Testing covers configuration review. Calling a read-only configuration review a penetration test conflicts with the definition at §6(iv). Two different engagements, frequently sold as one.
Wireless assessment	§6(xiv) Wireless Security Testing	No dedicated abbreviation	Genuine	A named class. Wireless networks also appear in Annexure I item (ix) of the Directions of 28 April 2022 as a reportable incident class.
Endpoint / EDR assessment	§6(xxii) Endpoint Security Assessment	DLA (Device Level Audit) — §13.2.3(i)(a)	Genuine	A named class. It is not §6(xvi) Red Team Assessment, and the two are routinely conflated in proposals.
Red teaming	§6(xvi) Red Team Assessment	No dedicated abbreviation	Genuine, but not a bigger VAPT	Defined as an exercise reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems. The objective is detection and response, not coverage. Note also that the 2018 auditor guidelines use "Red Team" in a different sense — the verification team that checks the audit team’s work.
Phishing simulation	§6(x) Process Security Testing	Process Audit — §13.2.3(i)(a)	Genuine, heavily fenced	§15.2.2(iii) requires anonymised or statistical technique, no individual identified or penalised, only employees inside the agreed scope, and no customers, business partners, vendors or other third parties without specific written consent.
Source code review	§6(ix) Source Code Review	Named inside the scope of work	Genuine	§13.1.3(iii) requires DAST and SAST for critical applications and requires SAST of the developer or system integrator, stated in RFPs and tenders.

The full list, for reference

§6 of the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025, in the document’s own order and wording. The ten types on this page sit on classes (iii), (iv), (v), (xii), (xiii), (xiv), (xviii), (xix), (xx) and (xxii). The sixteen that remain are the reason this page is a survey and not a complete account of Indian security auditing, and the section immediately below says what triggers each of them.

i. Compliance Audits
ii. Risk Assessments
iii. Vulnerability Assessments
iv. Penetration Testing
v. Network infrastructure Audits
vi. Operational Audits
vii. IT security policy review and assessment
viii. Information Security Testing
ix. Source Code Review
x. Process Security Testing
xi. Communications Security Testing
xii. Application security testing (including web applications, mobile applications and APIs)
xiii. Mobile Application Security Auditing
xiv. Wireless Security Testing
xv. Physical Security Testing
xvi. Red Team Assessment
xvii. Digital Forensic Readiness Assessment
xviii. Cloud Security Testing
xix. Industrial Control Systems/Operational Technology Security Testing
xx. Internet of Things (IOT)/Industrial Internet of Things Security Testing (IIOT)
xxi. Log Management and Maintenance Audit
xxii. Endpoint Security Assessment
xxiii. Artificial Intelligence (AI) System Audits
xxiv. Vendor Risk Management Audits
xxv. Blockchain Security Audit
xxvi. SBOM (Software Bill of Materials), QBOM (Quantum Bill of Materials), and AIBOM (Artificial Intelligence Bill of Materials) Auditing

Outside the ten

What a VAPT does not reach, however many types you buy

Which CERT-In audit classes are not VAPT?

Ten of the twenty-six classes are the engagement types above. These are the ones that are not, listed with the fact about your organisation that makes each one yours. None of them is served by buying more VAPT, and each is a named class you can put on a purchase order in its own right. §6 frames its own list as “including, but not limited to”, so even this is not the end of it.

§6(ix) Source Code Review

Yours when

You or your integrator wrote the code, and the application is one §13.1.3(iii) would call critical.

§13.1.3(iii) requires DAST and SAST for critical applications, requires SAST of the developer or system integrator, and requires that to be clearly stated in RFPs and tenders. Dynamic testing reaches what is reachable at runtime. This class reaches the rest. Put it on the builder in the build contract, and make the output an input to the audit rather than a deliverable that never arrives.

§6(x) Process Security Testing

Yours when

You want to know what a phishing email or a pretext call would achieve.

Heavily fenced. §15.2.2(iii) requires anonymised or statistical technique, no individual identified or penalised, only employees inside the agreed scope, and no customers, business partners, vendors or other third parties without specific written consent. §13.2.7 additionally requires written permission. It is a separate engagement with its own authorisation, not a line item inside a network test.

§6(xv) Physical Security Testing

Yours when

The question is whether somebody can walk in, plug in, or walk out with something.

A distinct class. An internal network test that begins from a supplied drop point has assumed away exactly the question this class asks.

§6(xvi) Red Team Assessment

Yours when

You have a detection and response capability and want to know whether it works against a goal-directed adversary.

Defined as an exercise, reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems. It measures response, not coverage, and it is a poor first purchase: a red team against an estate that has never had a web application audit will find the front door open and tell you nothing you could not have learned for less.

§6(xvii) Digital Forensic Readiness Assessment

Yours when

You want to know whether you could reconstruct an incident afterwards.

Its own class, and the natural companion to direction (iv) of the 2022 Directions on 180 days of logs. §18(vi) describes what happens when it is neglected: where a forensic investigation faces constraints due to unavailability or inadequacy of evidence or logs, the report should explicitly bring that out and recommend the log details to be captured.

§6(xxi) Log Management and Maintenance Audit

Yours when

You need to demonstrate the logging position §15.2.1(iv) requires to be verified in every audit assignment.

Direction (iv) of the Directions of 28 April 2022 requires logs of all ICT systems to be enabled and maintained securely for a rolling 180 days, and states that they shall be maintained within the Indian jurisdiction. CERT-In’s FAQ of May 2022 then answers at Q35 that logs may be stored outside India as long as the obligation to produce them to CERT-In in a reasonable time is met. Q37 gives CERT-In’s non-exhaustive sense of which logs are meant. This class is where that gets examined as a subject rather than as a checkbox inside another engagement.

§6(xxiii) Artificial Intelligence (AI) System Audits

Yours when

A model takes untrusted input and produces an output somebody acts on.

Defined as evaluation of AI systems for security, ethical alignment, transparency, data integrity, and resilience to adversarial manipulation. Note also that attacks and malicious activity affecting systems related to artificial intelligence and machine learning are already a mandatorily reportable incident class at Annexure I item (xx) of the Directions of 28 April 2022, where CERT-In describes attacks that target machine-learning models with the intention to cause a malfunction, using techniques such as deceptive data and environment manipulation.

§6(xxiv) Vendor Risk Management Audits

Yours when

A supplier holds your data, or their failure is your outage.

§13.1.1(f) already puts third-party, vendor and supply-chain risk assessment inside the audit scope, and §13.1.4(i) requires relevant personnel from an outsourced organisation to be available at the time of the audit. This is the class for the rows in your inventory that you configure but do not own.

§6(xxv) Blockchain Security Audit

Yours when

You operate a distributed ledger or the contracts running on one.

A named class in its own right. Nothing on this page reaches it.

§6(xxvi) SBOM, QBOM and AIBOM Auditing

Yours when

You ship third-party or open-source components inside your product.

Defined as auditing to ensure transparency, traceability and integrity of components used in software, quantum computing and AI systems, focused on known vulnerabilities, licensing issues and supply-chain risks, and verifying adherence to secure development lifecycle practices and regulatory compliance. CERT-In separately publishes Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM at version 2.0, dated 09.07.2025. §6(xxvi) names the BOM types without citing that document, so read the two together rather than treating the link as stated.

Six of the twenty-six are absent from both lists because they are the vocabulary rather than the engagement: (i) Compliance Audits, (ii) Risk Assessments, (vi) Operational Audits, (vii) IT security policy review and assessment, (viii) Information Security Testing and (xi) Communications Security Testing are broad classes that several of the ten types sit inside. Name the narrow class where one fits. The broad one is not wrong, it is just less useful in a scope of work.

What every type carries regardless

Ten things that are true of all ten types

What must every VAPT report contain, whatever the type?

Whatever the surface, the same clauses govern how the work is done and what the report has to say. These are the ten to hold any engagement to, and the ten that separate an audit from a scan with a cover page.

The standard is named, and it is not a top-ten list

§8(ii) is unusually direct: the limited lists such as OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits. The audit is built instead from comprehensive standards and frameworks — ISO/IEC, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM 3, the OWASP Web Security Testing Guide, ASVS, the Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model. A proposal whose methodology is "OWASP Top 10" has named an awareness document, not a test.

Tooling is discouraged as the whole method

§8(i) says solely tools-based testing should be discouraged, and gives its reason: 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 say the same in their own words and add that the auditor should deploy a verification team to verify the work performed by the audit team.

The environment is stated, whatever the type

§15.2.3(i) requires the environment — test, development, UAT, pre-production or production — to be specified. The 2018 guidelines put it as clearly stating the environment in which the application was tested. This single line decides how much of a report is true about the system your users reach.

Findings are scored and mapped the same way

§16.2(ii) requires CVSS for severity and EPSS for real-world exploitation likelihood, and requires every reported observation or vulnerability to be mapped with a CWE and a CVE number. That is what makes findings from a network engagement and an application engagement comparable on one risk register.

Critical and high findings do not wait for the report

§16.3(ii) requires critical and high findings to be notified to the auditee during the course of the audit on an as-and-when-found basis as well as in the final outcome report. §16.4 requires high-risk vulnerabilities — discovered breaches, known high exploitation rates, unmonitored or untraceable access, or anything posing an immediate risk to life — to be reported immediately on discovery with a recommended practical solution.

The 2022 Directions are verified in every assignment

§15.2.1(iv) requires the auditing organisation to include verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with findings and relevant evidence in the report. Practically: clock synchronisation to the NTP server of NIC or NPL, whose hostnames CERT-In gives in its May 2022 FAQ at Q43 as samay1.nic.in and samay2.nic.in for NIC and time.nplindia.org for NPL, with CERT-In’s own hedge that those are the details "currently". Logs enabled and retained for a rolling 180 days within Indian jurisdiction, where Q37 gives CERT-In’s non-exhaustive sense of what that means — firewall, intrusion prevention, SIEM, web, database, mail, FTP, proxy, event, application, ATM switch, SSH and VPN logs, recording both successful and unsuccessful events. A designated point of contact. Readiness to report a listed incident within six hours. The clause names a method-of-verification document, but as at 22 September 2026 the path printed in the guidelines does not serve it.

The plan carries calendar time and man-hours

The report states what it did not do

This is the canonical statement of §16.1(ii) on this page. Every other mention of it cites back here. The report must carry sampling decisions, exemptions, limitations and other constraints alongside the findings, as part of a contents list that also requires all details of the audit process, the detailed scope, the duration of the audit, the methodologies and standards used, tools, manual process, findings, prioritisation and manpower involved. Annexure I to the empanelment terms adds two checks most reports fail: reports include all unknowns clearly marked as unknowns, and reports state all states of security found rather than only the failed measures. The limitations paragraph is the most informative page in any VAPT report, and it is the paragraph that tells you which of the ten types you actually bought.

Closure and retest belong in the scope from the start

§13.1.1(g) requires the scope of work to specify follow-up audits as part of the engagement, and §9.3(iv) requires them after closure of the vulnerabilities identified. §16.3(iv) requires the follow-up audit to verify closure, and §16.3(iii) requires the report to state closure timelines by severity. A retest quoted as a variation was a scoping failure a month earlier.

Your data stays in India

§10.3 requires audit data to be stored only on systems located in India, encrypted on auditor devices, wiped after completion so it cannot be retrieved by any known forensic technique, with a certificate to that effect issued to you. The 2014 Policy Guidelines for Handling Audit related Data add that the report must not be hosted on general online file-sharing or cloud services unless under the auditing organisation’s technical and administrative control or specifically authorised by you.

How are VAPT findings scored, and what has to close when?

§16.2(ii) requires two numbers and two identifiers per finding, and each does a different job. CVSS scores how bad the weakness is, while EPSS estimates how likely it is to be exploited in the wild, which is why the clause requires both rather than one. A CWE identifier names the kind of weakness — every CWE number in the finding-class descriptions on this page is a lookup you can perform at cwe.mitre.org — and a CVE identifier names a specific published vulnerability in a specific product. A finding with neither identifier is an opinion with a severity attached to it.

One caution on the table below: the CVSS bands are CVSS’s own qualitative severity ratings, not CERT-In’s. The guidelines require the scoring system and do not print the ranges. Everything in the remaining columns is the guidelines’.

Band	CVSS	What EPSS adds here	Notification duty	Closure expectation	Who may accept the residual risk
Critical	CVSS 9.0–10.0	A high EPSS probability turns a critical into an active incident waiting on a calendar. A low one does not downgrade it: reachability, not probability, is what a critical means.	§16.3(ii) requires it to be notified to you during the audit on an as-and-when-found basis, not held for the draft. §16.4 adds that high-risk vulnerabilities — discovered breaches, known high exploitation rates, unmonitored or untraceable access, or anything posing an immediate risk to life — are reported immediately on discovery with a recommended practical solution, and §15.2.2(i) runs the auditor’s duty on discovered breaches to CERT-In as well as to you.	Closed and verified in the follow-up audit (§16.3(iv)). §16.3(iii) requires the report to state closure timelines by severity, so the date is in the document rather than in an email.	Nobody, in practice. §9.2 puts risk treatment and exceptions with the head of the auditee organisation, and this is the band where that person should expect to be told the answer is remediation.
High	CVSS 7.0–8.9	This is where EPSS earns its place in §16.2(ii). A high with a published exploit and a high probability is scheduled differently from a high that requires a research programme.	Same as critical: notified as and when found under §16.3(ii), and immediately under §16.4 where it meets that clause’s description.	Closed and verified. A high still open at the follow-up audit is the finding that stops a hosting or release gate.	§9.2 — the head of the auditee organisation authorises and accepts the treatment. An exception on an application is authorised by the head of the organisation that owns it.
Medium	CVSS 4.0–6.9	A medium with a high exploitation probability is not a medium in practice, and reading the two numbers together is precisely why §16.2(ii) requires both rather than one.	Carried in the report rather than notified mid-audit.	Closed, or formally accepted with a date. §16.3(iii) means an open medium carries a closure timeline, not an intention.	§9.2, through your normal risk register, with the authorisation recorded.
Low and informational	CVSS below 4.0, or observations with no score	Usually not the deciding input. Configuration hygiene, missing headers and verbose errors rarely carry a meaningful probability.	Reported in the findings list.	Tracked with a timeline. §15.2.1(iii) is the reason to bother: the auditor must revalidate the previous cycle’s observations and record unresolved ones as repeat observations, and a low that survives three cycles has stopped being a low and started being a governance finding.	The asset owner, through the risk register.

The rules-of-engagement side of the same relationship — written approvals, tooling, prohibited tests, who may sign the report — is set out in full on what a CERT-In empanelled auditor may and may not do. What the report should look like when it arrives is on reading a VAPT report, and what happens after it on retesting and closure.

Choosing the types

Six decisions, in the order the guidelines put them

How do we choose which types of VAPT to scope?

Nothing here is about choosing an auditor. This is the work that happens before one is engaged, and it is the work that decides whether the types you buy reach the estate you own. The mechanics of writing the scope itself — boundaries, exclusions, how to word an asset schedule — are on how VAPT scoping works. What follows is only the part that selects the types.

Build the asset inventory first, and date 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 up to which that inventory was updated to be reflected in the audit reports. Enumerate hostnames, application versions, mobile artefacts per platform, API base paths and operations, cloud accounts and regions, network ranges, wireless sites and SSIDs, and endpoint builds. Every type on this page is scoped from a different column of that inventory, which is why one inventory produces every scope and no inventory produces none of them.

Choose the types from the inventory, not from a package

Read the inventory and ask which of the ten types reaches each row. The routing table above does this for twenty of the rows a register actually carries — asset line, the types that reach it, the §6 class outside the ten that it triggers, and what goes untested if you skip it. Anything no type reaches is out of scope by omission rather than by decision, and §16.1(iii) will only list the assets you provided. §13.1.1(a) sets the expectation the other way round: the scope covers the entire cyber infrastructure including web and mobile applications, network infrastructure, OT and ICS, cloud architecture, APIs, databases and hosting infrastructure, code review, application security, data security and incident-response testing.

Have the scope vetted, then agree the terms in writing

§13.1.1(d) requires the scope to be vetted by the internal audit team in consultation with the CISO. §14.1(ii) then requires the agreed terms to be documented in an audit engagement letter reviewed and signed by authorised representatives of both organisations. §13.2.3(i) lists what has to be communicated before commencement: the type of audit, the report format, the standards or frameworks, the assets covered, data handling and retention, the timeline, and the requirement to share metadata and reports with CERT-In within five days of completion.

Settle the approvals and the carve-outs before anything starts

Written approval before penetration tests and before tools are installed, with a tool list and written confirmation of intellectual property and licensing, tools tested in a controlled environment and that testing formally reviewed and approved by your authorised representative, and installation in the presence of your system administrator (§13.2.2(iii)–(v)). Removal afterwards comes from a different instrument: the 2018 Guidelines for CERT-In Empanelled Information Security Auditing Organizations v3.0 require the auditor to ensure removal of tools after completion of the task and to get the auditee’s acceptance of that removal in the presence of the auditee system administrator. Separate explicit written permission for DoS, DDoS or flood testing over the Internet (§15.2.2(ii)), for process and social-engineering testing (§15.2.2(iii)) and for the remote and high-risk scenarios at §13.2.7.

Hand over an environment the engagement can actually run in

§15.2.3(ii) requires website testing on the staging server or testing environment provided by the hosting service provider before the audit certificate issues, with hash values and version numbers obtained from you and included in the report. In practice this step is where dates slip: accounts at every role, integrations pointed at sandboxes, a device per build, read-only identities in every cloud account, site access booked for wireless. §15.1.1(ii) asks that no unusual or major network change land during the window.

Close, retest, and read the limitations paragraph

Patching is yours (§9.3(iii)). Risk treatment is authorised by the head of the auditee organisation (§9.2). The follow-up audit verifies closure (§16.3(iv)), and the final report issues after closure and the follow-up audit on production, with an explicit statement where the scope was limited to staging (§16.3(v)). Then read the limitations, exemptions and sampling paragraph that §16.1(ii) requires — it tells you which of the ten types you actually bought, and how much of your estate it reached.

One more decision sits alongside these and is worth making explicitly: the ASVS verification level, where ASVS is in the methodology. The standard defines three levels — level 1 the lowest and fully penetration-testable from outside, level 2 for applications handling sensitive data and recommended for most applications, level 3 the highest and reserved for applications requiring significant verification. GIGW guideline 5.3.1 names ASVS without naming a level, and the level definitions were restructured between release 4.0.3 and 5.0.0 — which the OWASP project page gave as the latest stable release when it was checked for this page on 22 September 2026. So a scope of work should name the ASVS version as well as the level. That single line moves more testing effort than any other sentence in a scope document.

A worked hypothetical

One estate, and the arithmetic behind its scope

What does a scoped VAPT look like, end to end?

Everything above says duration is driven by multipliers and never performs one. This section performs them. The estate is a hypothetical lending platform: no client, no engagement, no real figures, and nothing here is a case study. The arithmetic is the deliverable, and the point of it is that the numbers that matter are not the ones a buyer usually counts.

Step one — the inventory extract, dated

§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 it was updated to to be reflected in the audit reports. Treat that date as part of the artefact: an inventory without one is a claim about a moment nobody can identify.

Inventory row	What the row actually says	The type it selects
Citizen lending portal, one hostname	6 authenticated roles, 9 state-changing workflows, one request-handling stack	Web application security audit, and the hostname also enters the external scope
Operations console, second hostname	2 roles, 4 workflows, same codebase, different authorisation surface	Web application security audit — a second asset, not a second page
Android build 4.18.2 and iOS build 4.18.1, plus a white-label variant of each	2 platforms × 2 build variants = 4 signed artefacts, each with its own hash	Mobile application security audit
3 API base paths carrying 41 operations	4 consuming roles, 1 previous major version still routable	API security audit — the single highest-value line in this inventory
2 cloud accounts across 2 regions	14 distinct managed services in use, one account inherited from a team that left	Cloud configuration review
One public /26 and 3 edge appliances	19 of 64 addresses answering on the day the inventory was taken	External network penetration test
One corporate directory domain, 3 VLANs	Finance, engineering and a contractor segment that was meant to be temporary	Internal network penetration test, from a defined drop point on the user VLAN
One office, 3 SSIDs	Corporate, guest, and a legacy SSID kept alive for two label printers	Wireless security testing, at that one site
2 laptop images and 1 Linux server baseline	410 devices, but 3 builds — the device count is not the unit of work	Endpoint security assessment
Collections tool, vendor-hosted SaaS	You configure it, but the vendor owns the software and the infrastructure	None of the ten. §6(xxiv) Vendor Risk Management Audits, and §13.1.1(f) puts it in scope

Step two — which types that inventory does not select, and why

Eight of the ten. Two are out: this organisation runs no physical process, so §6(xix) ICS and OT testing has no asset to point at, and it ships no hardware, so §6(xx) IoT testing has no fleet. Both of those are decisions rather than omissions, and the difference is that a decision is written down. Add one kiosk estate in branches, or one card-reader fleet, and the second row comes back — which is why the inventory, not the package, is what selects the types.

The multipliers, performed

Type	The multiplier	The arithmetic on this estate
Web application — portal	Roles × state-changing workflows, then role pairs	6 × 9 = 54 role-workflow passes. Crossing roles for horizontal and vertical access adds the 15 distinct role pairs, each needing two accounts at the lower role. Account requirement: 12, not 6.
Web application — console	Same shape, smaller numbers	2 × 4 = 8 passes, 1 role pair. Cheap — and the pair that matters most in the estate, because it crosses the privilege boundary.
API	Operations × roles	41 × 4 = 164 function-level authorisation checks before any object-level work. Object-level testing needs a second account per role, so 8 accounts. The retired major version adds a second enumeration pass at a different base path.
Mobile	Platforms × build variants	2 × 2 = 4 artefacts. Anti-tamper is the hidden line: pinning plus root and jailbreak detection has to be defeated on each platform before the first finding exists, and that time is spent producing nothing.
Cloud configuration	Accounts × regions, then distinct services	2 × 2 = 4 account-region pairs, against 14 service baselines. Collection is fast, but the judgement half does not shrink, which is what §8(i) is describing when it says solely tools-based testing should be discouraged.
External network	Answering services, not address space	19 live hosts, not 64 addresses. Every automated finding is then confirmed by hand, which is the half of the work that does not appear in a scanner licence.
Internal network	Identity complexity and drop points	1 domain, 1 drop point, 3 segments. Adding a second drop point on the contractor VLAN roughly doubles the useful output, because it is the segment nobody has modelled.
Wireless	Sites, then SSIDs and authentication methods	1 × 3 SSIDs × 2 authentication methods. Travel and site access are the larger half of the calendar time and none of the man-hours — which is exactly why §13.2.2(ii) requires both numbers.
Endpoint	Distinct builds	3 builds, 1 representative device each, provisioned the way a joiner receives one. 410 devices is a coverage-reconciliation question, not a testing question.

Step three — the two numbers the plan must carry

§13.2.2(ii) requires the test plan shared by the auditing organisation to include both calendar time and man-hours, and item 10 of Annexure I to the empanelment terms says the same. On the estate above those two numbers diverge sharply and for a reason you can point at: the wireless site visit and the iOS provisioning lead time consume calendar and almost no man-hours, while the 164 API authorisation checks consume man-hours and almost no calendar. A single blended figure hides both. Ask for the pair, then ask which multiplier produced each line — the answer to that second question is what tells you whether the plan was built from your inventory or from a template.

What eight types still leave untested here

This is the row a proposal never carries and the one worth writing into your own scope. A complete VAPT programme on the estate above still ends with six open questions, and none of them is a criticism of the testing.

The credit bureau and KYC integrations. Their systems are not yours to test. §6(xxiv) Vendor Risk Management Audits is the class, and §13.1.1(f) already puts third-party and supply-chain risk assessment inside the audit scope.
The source code. Eight engagement types on a binary and a running system reach what is reachable at runtime. §6(ix) Source Code Review and the SAST duty at §13.1.3(iii) reach the rest, and both belong in the build contract.
Whether anything would have been detected. Eight types measure weakness. §6(xvi) Red Team Assessment measures response, and the endpoint assessment proves deployment rather than efficacy.
Physical access to the office, and therefore to the contractor VLAN. §6(xv) Physical Security Testing is its own class, and the internal engagement assumed away exactly that question by starting from a supplied drop point.
Whether the estate could reconstruct an incident afterwards. §6(xvii) Digital Forensic Readiness Assessment, read with direction (iv) of the 2022 Directions on 180 days of logs and §6(xxi) Log Management and Maintenance Audit.
The collections SaaS tenancy configuration, which is yours even though the software is not — the one inventory row above that no type on this page reaches.

What goes wrong

Eight ways to get a clean report about the wrong system

Why did our VAPT come back clean?

Usually for one of these eight reasons, and almost never because the estate is clean. Every one of them is a decision made weeks before the testing starts, surfacing at the point where it is expensive to fix. The signal column is what you can actually see at the time — and the section that follows this table is what to do about it if you are reading this mid-engagement.

Failure	What happens	Stage	The signal	What it costs
One test account, one role	The application has six roles. The tester is given one. Horizontal and vertical access testing both require at least two accounts per role, and the entire authorisation finding class silently leaves the engagement.	Environment handover	The credentials email contains one username.	A clean report on the defect class that causes the breaches. Re-run the authorisation work with proper accounts. The rest of the engagement stands.
The scope says "the application" and the estate is four hostnames	The portal is in scope. The admin console on a second host, the file service on a third and the identity endpoint on a fourth are not, because nobody enumerated them. §16.1(iii) then lists exactly the assets you provided.	Scoping — visible only at the findings report	The asset annexure has one row and your DNS zone has forty.	A second engagement and a second procurement cycle, usually against a committed go-live date.
Automated output delivered as an audit	A scanner report, reformatted, with severities untouched and nothing verified by hand. §8(i) discourages solely tools-based testing precisely because automated processes overlook the non-automated components, and the 2018 guidelines require a verification team to check the audit team’s work.	Findings report	Every finding is a template. No finding has a request, a response or a screenshot behind it, against §18(iii), which requires observations to be supported by objective evidence compiled with the report.	False positives you will spend a sprint disproving and false negatives you will never see.
The API was somebody else’s contract	The front end is audited under one work order and the API tier belongs to a different system integrator. Each scope assumes the other covered it, and the tier holding the data is tested by neither — the gap set out under “A web application test with no API test behind it” above.	Scoping	No base paths appear in any scope annexure, and the mobile findings are all client-side.	The most expensive gap on this page, because it is the tier that holds the records.
Protective controls left on, and not recorded	Testing runs through a web application firewall in blocking mode. The findings describe the firewall’s behaviour. The application behind it is unmeasured, and the report does not say which was tested.	Test window	Low finding counts, many time-outs, and no line in the report describing the network path the test took.	A report that is true about a control and silent about the asset. Decide in writing and record the decision under §15.2.3(i).
A configuration review invoiced as a penetration test	Read-only credentials, a posture report, and a document title that says penetration test. The buyer files it as evidence of exploitability, which it is not, against the definition at §6(iv) — set out under “A cloud configuration review presented as a penetration test” above.	Proposal	The methodology names a benchmark and no exploitation, while the title names a penetration test.	Nothing visible, which is the problem — until the finding that was never chained is chained by somebody else.
Retest priced as a variation	The work order covers one pass. When findings come back there is no contractual basis for the follow-up audit, so the closure evidence §16.3(iv) requires does not exist.	Retest	The auditor quotes for the retest. That quote is the signal.	A finance approval cycle and weeks of slip, on a deliverable that should have been in the original price under §13.1.1(g).
The application was never securely designed	Thirty-plus findings on a first pass, clustered on authorisation and input handling, with no threat model and no SAST output. §8(viii) says an application developed without secure design and development practices should not be considered for assessment and audit, and that the auditee should be told in writing with a copy marked to CERT-In.	First test pass	The remediation plan is a rewrite and the finding list reads like a curriculum.	A release cycle, at least. Put secure design into the build contract and SAST on the developer, as §13.1.3(iii) requires.

The engagement is already going wrong — what to do this week

Most of the failures above are recoverable while the engagement is running and expensive afterwards. The clause is what turns the conversation from a complaint into a compliance question: an email citing §14.3(i) gets a different answer from an email saying the scope feels thin. Each step below names what to observe, the clause it engages, what to send, and what a firm running the engagement properly produces in response.

You discover mid-engagement that the API tier is out of scope

§14.3(i), §14.2, §13.2.3(ii)(a)

Do not start a second procurement. §14 is titled "Agreeing on the Terms of Engagement and Revisions to the Scope", and §14.3 lists discovery of previously unidentified systems or processes that present significant risk as the first criterion for a revision. Email the audit partner today with the base paths, ask for the scope revision in writing with its impact on timelines, resources and deliverables evaluated by both parties, and require it to be documented as an addendum to the audit engagement letter under §14.2 — before the report drafts, not after.

What a good answer looks like

A firm running the engagement properly returns a scope addendum with a revised plan carrying both calendar time and man-hours, not a fresh proposal.

You realise the tester was given one account and the application has six roles

§16.1(ii), §13.2.4(ii)

Ask for the re-run with two accounts per role. If the calendar will not carry it, ask instead — in writing — for the limitation to be stated in the report: which roles were not exercised, and that the authorisation finding class was therefore not covered. §16.1(ii) requires sampling decisions, exemptions, limitations and other constraints in the report, and §13.2.4(ii) requires the auditor to communicate exemptions, limitations and constraints to you. A gap on the record is recoverable next cycle, but a gap that reads as a clean result is not.

What a good answer looks like

Either the accounts appear within a day, or the limitations paragraph names the roles. Both are acceptable answers. Silence is not.

A configuration review arrives titled "penetration test"

§6(iv), §16.1(i)

Ask for the title corrected before signature, and for the methodology section to state that testing was read-only. §6(iv) defines penetration testing as active testing to identify and exploit potential vulnerabilities, to determine whether they can be exploited to compromise the application, access sensitive data or affect the underlying infrastructure and environment. §16.1(i) requires the report format to be mutually agreed and finalised before commencement, which is the hook for asking now rather than arguing later.

What a good answer looks like

The title changes and nobody loses anything, because the work was legitimate — it was the label that was wrong.

A staging-only report is about to be filed as production assurance

§16.3(v), §15.2.3(i)

The production follow-up is a contractual deliverable, not a favour. §16.3(v) requires the final audit report to be issued after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment, and requires the report to state explicitly where the scope was limited to staging. Ask which of the two documents you are being given, and check the environment line §15.2.3(i) requires.

What a good answer looks like

You get either a production follow-up in the plan, or an explicit staging statement in the report. Both are honest outcomes, but a silent staging report filed as production assurance is not.

The retest comes back as a variation quote

§13.1.1(g), §9.3(iv), §16.3(iv)

Point at the scope of work. §13.1.1(g) requires it to specify the requirement to conduct follow-up audits as part of the engagement, §9.3(iv) requires follow-up audits to be included within the scope or RFP proposal and conducted after closure, and §16.3(iv) requires them to verify closure of the vulnerabilities and non-conformities highlighted in the previous audit. If the scope of work genuinely omitted it, that is a scoping failure a month old rather than a commercial dispute today — pay it once and fix the template.

What a good answer looks like

The retest is delivered against the original scope, and the next scope of work carries the clause.

The findings look like scanner output with the severities untouched

§8(i), §18(iii), §16.2(ii), §15.2.5(iii)

Ask for the evidence appendix and the working notes. §18(iii) requires all observations to be supported by objective evidence, carefully and correctly compiled with the report and presented so that decision makers can use it to make credible risk-based decisions. §18(i) lets you seek working notes where the contract provides for it. Ask separately which findings were verified by hand, and who performed the maker-checker review §15.2.5(iii) requires. §16.2(ii) then gives you the shape a real finding has: a CVSS score, an EPSS input, and a CWE and CVE mapping per observation.

What a good answer looks like

Requests, responses and screenshots per finding, and a named reviewer who is not on the audit team.

Nothing above is answered

§13.2.6, §15.2.7, §11(iii)

Use the escalation matrix §13.2.6 requires both sides to define, and the regular review meetings with the single points of contact that §15.2.7 expects, rather than inventing a new escalation. Afterwards, whatever the outcome, give CERT-In the auditee feedback §11(iii) describes as both a right and a duty — feedback and complaints are kept confidential and acted upon promptly, and the form comes from empanelment@cert-in.org.in.

What a good answer looks like

A corrective action note with dates. This is also the step that costs nothing and has no deadline, which is why it is the one most often left undone.

Objections

What project teams argue about

What do project teams argue about when scoping VAPT?

These arrive in real scoping meetings, usually with a date attached. In each case the answer that settles it cites the clause rather than asserting the conclusion.

“Can we just buy one VAPT that covers everything?”	You can buy one engagement with several types inside it, which is normal and sensible. What you cannot do is buy one type and treat it as coverage of the others, because each has a structural blind spot the others fill. §6 itself frames the list as including, but not limited to, twenty-six classes, and §6 also states the expectation that auditee organisations ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, and may opt for additional assessments during the year. Read as a buyer: one comprehensive exercise a year, assembled from the types your inventory requires.
“Our scanner runs weekly. Why pay for a penetration test?”	They answer different questions and the instruments treat them as different classes. §6(iii) defines vulnerability assessment as examination to determine the adequacy of security measures and identify deficiencies. §6(iv) defines penetration testing as active testing to identify and exploit vulnerabilities and determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure. A scanner is a tool inside the first. §8(i) separately discourages solely tools-based testing, on the ground that it overlooks the non-automated components.
“The vendor says grey box, so we do not need to give credentials.”	Box colour is a market vocabulary, not a scope. What the instruments require you to fix is the environment (§15.2.3(i)), the assets (§13.1.1, §16.1(iii)) and the audit type (§13.2.3(i)(a)) — so write the credential and access position into the scope in those terms. The operational point stands whatever you call it: an engagement without authenticated access at every role cannot produce authorisation findings, and that is where the serious defects are.
“Can we test in production? Staging is nothing like it.”	For a website heading for an audit certificate the sequence is fixed the other way. §15.2.3(ii) requires testing on the staging server or testing environment provided by the hosting service provider before the certificate issues. §16.3(v) then requires the final report to issue after closure and the follow-up audit on production, and to state explicitly where the scope was limited to staging. Separately, §15.2.2(iv) says that in critical environments where availability is a top priority, testing should be conducted in a passive manner. So the answer is: staging first, production follow-up, and passive where availability governs.
“Our cloud provider is certified, so the cloud is covered.”	A provider’s certification covers the provider’s side of the boundary. §6(xviii) Cloud Security Testing is about evaluating the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures — your account, your identity model, your storage, your network. §13.1.1(f) additionally puts third-party, vendor and supply-chain risk assessment inside the audit scope, so the provider relationship is an item in your scope rather than a reason to shorten it.

Where we fit

We deliver CERT-In audits

What stays with the auditee in a CERT-In audit?

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us. The work this page is really about is the auditee-side work — the asset inventory the scope is derived from, the decision about which of the ten types each row of it needs, the environment and accounts and artefacts that have to exist before a tester can start, and the remediation cycle that lets the follow-up audit find closed findings.

For the testing itself, see penetration testing and VAPT. Where the engagement sits inside a wider assurance programme — ISO 27001, SOC 2 or the DPDP Act — the same asset inventory and the same evidence do a great deal of double duty once they are organised properly.

Two things this page deliberately does not cover. It does not state a sectoral audit cadence: §13.1.2(i) says sectoral regulators may decide to increase the frequency, and names no regulator and no sector, so if a banking, securities, insurance or critical-infrastructure instrument is what brought you here, the cadence that binds you is in that document and you should read it rather than a summary of it. And it does not price an engagement, for the reason given under reading the proposal — what it gives you instead is the set of clause-anchored tests that let you compare two quotes without either of them naming a number.

Frequently Asked Questions

What is VAPT?

VAPT stands for Vulnerability Assessment and Penetration Testing, and CERT-In writes the expansion out in its own instrument: §13.2.3(i)(a) of the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) lists "VAPT (Vulnerability Assessment Penetration Testing)" as one of the types of audit an auditor must communicate to the auditee before commencement. The two halves are separate classes of engagement with separate definitions at §6. A vulnerability assessment is "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" (§6(iii)). Penetration testing is "a security testing methodology in which individual components or the application as a whole are actively tested to identify and exploit potential vulnerabilities", with the objective of determining whether they can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment (§6(iv)). One measures breadth, the other measures reachable impact.

What are the types of VAPT?

In the market, ten are bought regularly: web application, external network, internal network, mobile application, API, cloud configuration review, wireless, endpoint, industrial control systems and operational technology, and Internet of Things and Industrial Internet of Things testing. In CERT-In’s own vocabulary there is no list of "types of VAPT" — §6 of the 2025 audit policy guidelines lists twenty-six classes of engagement, framed as "including, but not limited to", and §13.2.3(i)(a) separately names nine audit types a scope must identify: VAPT, EAPT (External Attack Penetration Testing), DLA (Device Level Audit), Configuration Audit, Process Audit, Mobile Application Security Audit, Web Application Security Audit, API Security Audit and Compliance audit — a list the guidelines themselves end with "etc.". The market ten map onto those two lists cleanly in some places and not at all in others, which is the subject of this page. Sixteen of the twenty-six classes are outside the ten, and this page names each of them with the trigger that makes it yours rather than pretending a VAPT covers them.

What is the difference between vulnerability assessment and penetration testing?

Scope of question and scope of evidence. A vulnerability assessment enumerates: it tells you what deficiencies exist across everything in scope, scored and mapped, and it is the right instrument when you need coverage. A penetration test demonstrates: it actively tests and, where authorised, exploits, to show whether a deficiency can be used to compromise the application, reach sensitive data or affect the underlying infrastructure. A vulnerability assessment will not tell you that two medium findings chain into full account takeover. A penetration test will not tell you that the same weakness exists on four hundred other hosts. Buying one and reporting it as the other is the most common misrepresentation in this field, and §16.1(ii) is the defence: the report must state sampling decisions, exemptions, limitations and other constraints.

What is the difference between black box, grey box and white box VAPT?

Box colour is market vocabulary, not a scope, and no CERT-In instrument uses any of the three words. What the guidelines require you to fix instead are three things that are actually decidable: the environment tested, under §15.2.3(i) — test, development, UAT, pre-production or production. The assets, under §13.1.1 and §16.1(iii), which requires every asset you provided in scope to be named in the report. The type of audit, under §13.2.3(i)(a), communicated before commencement. Write the credential and access position into the scope in those terms and the box colour stops mattering. There is one operational consequence worth stating plainly, because it is usually the real reason the word is being used: an engagement conducted without authenticated access at every role structurally cannot produce authorisation findings — horizontal access across peer records, vertical access across privilege levels, function-level access to endpoints the interface never renders. That is the defect class behind most breaches. “Grey box” used as a reason to withhold credentials does not make the test more realistic. It removes the finding class you were paying for.

Is there a VAPT for OT, ICS or IoT, and is it the same engagement?

Yes, and no. §6(xix) of the 2025 audit policy guidelines makes Industrial Control Systems/Operational Technology Security Testing a class of engagement in its own right, defined as evaluating the cyber security posture of ICS and OT networks, specifically designed to identify vulnerabilities and potential threats that could disrupt critical industrial processes, impacting safety, production and overall system availability within a facility. §6(xx) does the same for Internet of Things and Industrial Internet of Things security testing. §13.1.1(a) puts OT and ICS inside the audit scope alongside applications, networks, cloud, APIs and databases, so a scope that covers a plant’s corporate network and stops at the process boundary has departed from the clause. What makes the engagement different from IT testing is a single rule: §15.2.2(iv) states that in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid any potential downtime or service disruption. That is a deliberate trade of depth for safety, and it belongs in the scope as a decision rather than arriving as a disappointment. Note also that attacks on critical infrastructure, SCADA and operational technology systems are a mandatorily reportable incident class at Annexure I item (ix) of the CERT-In Directions of 28 April 2022, and attacks on IoT devices and associated systems at item (xiii).

How do we compare two VAPT quotes without a price to compare?

Eight clause-anchored tests do most of the work. Does the test plan carry both calendar time and man-hours, as §13.2.2(ii) requires and as item 10 of Annexure I to the empanelment terms repeats? Is the follow-up audit named as a deliverable, which §13.1.1(g) requires the scope of work to specify? Is any part of the fee contingent on the outcome, which §7 prohibits along with tying payment to the submission or approval of closure reports? Which standard is named — and is it one of the comprehensive frameworks at §8(ii), rather than the OWASP Top 10, which the same clause says should not be considered a standard or reference for audits? Which of the nine audit types at §13.2.3(i)(a) is named, per asset? Which environment, under §15.2.3(i)? Who does the work, given that §12.2(iii) says auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice? And what does the quote say it will not do? A quote that answers all eight is comparable to another that does. A quote that answers none is a number.

Does a web application VAPT cover the APIs behind it?

Only if the APIs are in the scope as their own assets. A browser-driven web application test exercises the endpoints the front end calls, with the identifiers the front end supplies — which is structurally the wrong shape for object-level authorisation findings, because the front end never asks for a record belonging to somebody else. §6(xii) names APIs expressly inside application security testing, §13.1.1(a) requires APIs to be inside the audit scope, and API Security Audit is a separate type at §13.2.3(i)(a). Enumerate base paths and operations in the asset inventory and scope them, or accept that the tier holding your data was tested through a client that was built not to misuse it.

Is a cloud configuration review the same as a cloud penetration test?

No, and this is the substitution that costs the most. A configuration review uses read-only, audit-scoped credentials to assess identity, network, storage, logging and encryption posture against a baseline. It is covered by §6(xviii) Cloud Security Testing, which is defined as evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications and infrastructures, and it corresponds to the Configuration Audit type at §13.2.3(i)(a). Penetration testing is defined at §6(iv) as active testing to identify and exploit potential vulnerabilities and to determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure. A read-only review does not do that. Both are worth buying for a material cloud estate. Neither substitutes for the other, and the document title should say which one was performed.

Do we need separate testing for Android and iOS?

Yes, in practice. They are two artefacts with two storage models, two sets of platform components and two runtime-protection stacks, and findings on one rarely transfer to the other. §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be explicitly stated in the audit scope and the report, so a scope that says "the mobile app" without naming platform, build and version has not identified the asset. Budget for iOS provisioning as a lead-time item, and decide in advance whether the tester may bypass your anti-tamper controls — if not, the engagement measures the wrapper rather than the application.

What is EAPT?

External Attack Penetration Testing. It is one of the nine audit types §13.2.3(i)(a) of the 2025 audit policy guidelines requires an auditor to communicate before commencement, alongside VAPT, DLA (Device Level Audit), Configuration Audit, Process Audit, and the web, mobile, API and compliance audits. EAPT is the instrument’s own label for testing the externally reachable estate, but §6 itself has no class of that name, reaching the work instead through (v) Network infrastructure Audits and (iv) Penetration Testing. If a scope of work uses the phrase, make sure the assets behind it are the ranges and hostnames in your inventory with an as-of date, which §13.2.3(ii)(b) requires to be reflected in the report.

How often should VAPT be done in India?

§13.1.2(i) of the 2025 audit policy guidelines states that a cyber security audit should be conducted at least once in a year, and adds that sectoral regulators may decide to increase the frequency based on the size of the organisation, the criticality of the assets being audited and the complexity of the adoption of digital infrastructure. Note carefully what that clause does and does not do: it names no regulator and no sector, and the only other verified link between CERT-In and sectoral regulators is §12.1(i), which says the published snapshot information should be utilised by organisations or sectoral regulators to identify and select auditing organisations. So if you arrived here from a banking, securities, insurance or critical-infrastructure instrument, the cadence that binds you is in that instrument and not in this one — read it directly. This page does not cover sectoral cadence and does not assert one. §13.1.2(ii) says the stated frequency may be treated as the minimum. On top of the annual floor sits a change rule: §13.1.2(iii) requires every change to go through formal change management classified as minor or major, with minor changes needing standard change management but not an audit, and major changes — system overhauls, technology migrations, or configuration adjustments affecting sensitive data or critical infrastructure — requiring an audit before implementation. §13.1.2(iv) requires an audit after every major change, and (v) requires periodic audits even where no major change has occurred.

Is VAPT mandatory in India?

It depends on the instrument that reaches you, and the honest answer is that there is no single national rule covering every organisation. For an Indian government website, web application, portal or mobile app, GIGW guideline 5.3.1 requires it to have been security audited with an audit clearance certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory before hosting in production. For an auditee inside the 2025 audit policy guidelines, §4(ii) describes the applicability as organisations in both public and private sectors "that are required to or are seeking to evaluate their cyber security posture" — the document’s own hedge, which should not be upgraded into a mandate. Beyond that, what usually makes it mandatory is a contract, a tender, a hosting policy or a sectoral requirement, and you should read your own instrument rather than a vendor’s summary of it.

What is the difference between VAPT and red teaming?

Objective. §6(xvi) defines 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". It measures whether your detection and response work against a goal-directed adversary. VAPT measures coverage and reachable weakness across a defined scope. A red team that finds one path and stops has succeeded. A penetration test that finds one path and stops has under-delivered. Note a separate and confusing use of the same phrase: the 2018 Guidelines for CERT-In Empanelled Information Security Auditing Organizations say auditors should deploy a verification team (Red Team) to verify the work performed by their audit team (White Team) — there, "red team" means the internal reviewer, not an adversary simulation.

How long does a VAPT take, and what actually drives the duration?

Not the size of the estate in the way buyers expect. For a web application it is authenticated roles times distinct workflows. For an API it is operations times roles, where an operation is a method on a path. For an external network it is live answering services rather than address-space size. For mobile it is platforms times build variants plus the time spent defeating anti-tamper before any finding exists. For cloud it is accounts times regions times distinct managed services. For wireless it is sites and travel. For endpoint it is distinct builds rather than device count. §13.2.2(ii) gives you the check: the test plan shared by the auditing organisation must include both calendar time and man-hours, and item 10 of Annexure I to the empanelment terms says the same. Ask for both numbers and ask what the multiplier was.

What standards does a VAPT test against?

§8(ii) of the 2025 audit policy guidelines names them: ISO/IEC standards, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix for cloud security, OSSTMM 3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, the OWASP Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model. The same clause is explicit that limited lists such as the OWASP Top 10, SANS Top 25 and similar should not be considered standards or references for audits. For critical applications, databases or platforms of Ministries, Departments, Secretariats and Offices where sensitive personally identifiable information is involved, §8(v) states that the auditing organisation shall verify compliance with the “Comprehensive Audit Program Checklist – Cyber and Information Security Audit” as outlined in the “Guidelines on Mandatory Features of Cybersecurity Architecture to be Ensured in all Ministries/Departments” issued by the Cyber Security Division, MeitY, and that this checklist, comprising 282 control points, shall form the default mandatory audit scope for such entities. One caution on that sentence: the audit policy guidelines give the MeitY document no version, no date and no link, and this page has not been able to retrieve it, so cite §8(v) as the authority and ask your auditor which edition of the checklist they hold. Where ASVS is named, name its version and verification level too: the OWASP project page gave 5.0.0 as the latest stable release when it was checked for this page, the level definitions were restructured from 4.0.3, and GIGW names ASVS without naming a level.

What should a VAPT report contain?

§16.1(ii) requires the report to be clear, precise and comprehensive, covering all details of the audit process, detailed scope, duration of audit, methodologies and standards used, tools, manual process, findings, prioritisation, sampling decisions, manpower involved, exemptions, limitations and other constraints. §16.1(iii) requires all assets provided in scope to be named in the report, and §16.1(iv) requires draft and final versions with their dates. §16.2(ii) requires CVSS scoring supplemented by EPSS and every observation mapped to a CWE and a CVE. Annexure II to the Terms and Conditions for Empanelment (v7.2, April 2024) sets the content format, and Annexure I adds two checks most reports fail: all unknowns clearly marked as unknowns, and all states of security found stated rather than only the failed measures.

Can one firm perform every type?

Some can, and the way to find out is published rather than asserted. The Snapshot Information CERT-In publishes for each empanelled organisation carries a field headed "Capability to audit, category wise", answered Yes or No against the categories that organisation itself lists — and the category lines differ between organisations, so there is no fixed national taxonomy to check against. §12.2(iv) puts the burden on you: check the domain of audits conducted, previous audits, methodology, tools and relevant-domain experience, and consider the available alternatives before selecting. §12.2(iii) adds that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice, and that the auditee should verify compliance.

Does VAPT include phishing and social engineering?

Only if you scope it, and it is heavily fenced. §6(x) Process Security Testing is the class. §15.2.2(iii) requires anonymised or statistical techniques with no individual identified or penalised, limits it 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 say the same at Annexure I items 14 and 15. §13.2.7 additionally requires written permission for process testing and social engineering among the remote and high-risk scenarios. Treat it as a separate engagement with its own authorisation, not as a line inside a network test.

Who can perform VAPT in India, and does it have to be a CERT-In empanelled auditor?

For the audit clearance certificate a government website, portal or app needs before production hosting, GIGW guideline 5.3.1 names the permitted issuers: NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory. For everything else, empanelment is a standing rather than a licence — clause 2.1 of the Terms and Conditions for Empanelment states that an auditor is contracted by a customer directly and that CERT-In is not a party to such contracts. Where a tender, contract or hosting policy names empanelment, check the exact legal entity against CERT-In’s published list rather than a bidder’s claim, and read the wording the bidder uses: clause 4.2 permits one sentence and no more.

Is a VAPT report the same as a safe-to-host certificate?

No. VAPT is testing. A safe-to-host certificate is an instrument that may be issued at the end of an audit by one of the four bodies GIGW names, and it is issued after closure and the follow-up audit rather than at the end of the first test pass. §16.3(v) requires the final report to issue after closure of vulnerabilities and completion of the follow-up audit on the production environment, with an explicit statement where the scope was limited to staging. A VAPT report from a firm that is not one of the four permitted issuers will not satisfy guideline 5.3.1, however good the testing was.

References

The instruments behind every clause

Every claim on this page about CERT-In, GIGW, STQC or NIC comes from one of the Government of India documents in the first list below, linked so you can read the clause rather than our paraphrase. The second list holds the non-government standards — OWASP, ISECOM, the Cloud Security Alliance, FIRST, MITRE and the CVE Program — which this page tests its argument against because §8(ii) and §16.2(ii) name them, not because any Indian authority publishes them. One entry in the first list is also not CERT-In’s own: the Cyber Security Audit Baseline Requirements is published by the National Security Council Secretariat and hosted on CERT-In’s website, and its row says so. Section numbers in the form §13.2.2(ii) refer to the Comprehensive Cyber Security Audit Policy Guidelines unless another document is named. Where these disagree with anything written here, they win.

Every §-locator on this page was checked against the instruments below on 22 September 2026. The 2025 guidelines are version 1.0 and will be superseded. This block is where that will show first. One document the guidelines name is deliberately absent because it cannot be retrieved: the “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022”, cited at §15.2.1(iv). As at 22 September 2026 the cert-in.org.in path printed in the guidelines served the CERT-In home page rather than a document, so it is named here as the guidelines name it and not linked. The descriptions of what each engagement type covers, misses and costs are our own operational reading. Only the clause-attributed statements are the instruments’.

Government of India instruments

Comprehensive Cyber Security Audit Policy Guidelines · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 1.0, 25 July 2025 · 69 pages, 20 sections · relied on for §4(ii), §6 and its definitions, §8(i), §8(ii), §8(v), §8(viii), §9.2, §9.3(iii)–(iv), §9.5(i), §10.1(i), §10.3, §12.1(i), §12.2(ii)–(iv), §13.1.1, §13.1.2, §13.1.3(iii), §13.1.4(ii), §13.1.5, §13.2.2(ii)–(v), §13.2.3, §13.2.6, §13.2.7, §13.2.4(ii), §14.1(ii), §14.2, §14.3, §15.1.1, §15.1.2, §15.1.3, §15.2.1(iii)–(iv), §15.2.2(i)–(iv), §15.2.3, §15.2.5(iii), §15.2.7, §16.1, §16.2(ii), §16.3, §16.4, §18(i), §18(iii) and §18(vi), with §7 on fees and §11(iii) on auditee feedback
Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment · CERT-In, MeitY · Version 7.2, April 2024 · 10 pages · relied on for clause 2.1, clause 4.2, Annexure I items 6, 10, 14, 15, 17, 18, 20, 21 and 22, and Annexure II (audit report content format)
Guidelines for CERT-In Empanelled Information Security Auditing Organizations · CERT-In, MeitY · Version 3.0, May 2018 · 6 pages · relied on for the discouragement of solely tools-based testing, the verification team (Red Team) verifying the audit team (White Team), the requirement to state the environment tested, the restriction on testing and exploiting high-risk vulnerabilities such as discovered breaches or anything that may put immediate lives at risk, the removal of tools after completion with the auditee’s acceptance in the presence of the auditee system administrator, and the two separate restrictions on DDoS testing over the Internet and on any form of flood testing where a person, network, system, or service is overwhelmed from a larger and stronger source
Policy Guidelines for Handling Audit related Data · CERT-In, MeitY · Version 1.0, June 2014 · 5 pages · relied on for §5.1 to §5.3 on storage, access, retention and the restriction on hosting reports on online file-sharing and cloud services
Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 · CERT-In, MeitY · No. 20(3)/2022-CERT-In · 28 April 2022 · 8 pages · relied on for direction (i) on time synchronisation, direction (ii) on six-hour reporting, direction (iv) on 180 days of logs maintained within the Indian jurisdiction, and Annexure I items (ix) on critical infrastructure, SCADA, operational technology systems and wireless networks, (xiii) on Internet of Things devices and associated systems, and (xx) on systems related to artificial intelligence and machine learning
FAQs on the Cyber Security Directions of 28.04.2022 · CERT-In, MeitY · May 2022 · 22 numbered pages plus an Annexure · relied on for the log-residency answer at Q35, the log types answer at Q37 and the NIC and NPL time-source hostnames at Q43 · the document states of itself that 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, and that it is an evolving document whose version may change. Where it is relied on above, it is CERT-In’s own gloss on a direction and not a substitute for the direction.
Guidelines for Indian Government Websites and Apps (GIGW 3.0) — security guidelines and attributes · National Informatics Centre with STQC and CERT-In, MeitY · clause numbers follow the GIGW 3.0 manual, because the live attributes page mis-numbers the third cybersecurity statement · relied on for guideline 5.3.1 (audit clearance before hosting in production, and the naming of OWASP Top 10, ASVS and MAVS in the government-organisation action), guideline 5.3.2 (securing the hosting environment, hosting within the geographical boundaries of India, hardening with the latest security patches plus periodic VA and PT, and 180 days of logs) and the preamble to chapter 5.3, which is where ISO 27001, OWASP ASVS, OWASP Top 10 and CIS benchmarks are named — guideline 5.3.2 itself names no benchmark, so this page cites the preamble for the baselines and 5.3.2 for the hardening duty
GIGW 3.0 — new features · National Informatics Centre with STQC and CERT-In, MeitY · the official provenance of the phrase this page uses as a term of art, quote-exact: “Government organisations must continue to obtain a ‘safe to host’ certificate issued by the cybersecurity auditors empanelled by CERT-In/STQC or the auditors of STQC or NIC.” The phrase does not appear on the attributes page, so it is attributed here.
Cyber Security Audit Baseline Requirements · National Security Council Secretariat, Government of India · publication NSCS-46-16 Rev 1.0, October 2020 · 19 pages · published on CERT-In’s website and named at §8(iii) and §13.1.8(i) of the audit policy guidelines
Empanelled Information Security Auditing Organisations by CERT-In — the published list and Snapshot Information · CERT-In, MeitY · the list §10.2(vi) and §12.3(iii) refer to · relied on for the anatomy of the Snapshot Information, including the field "Capability to audit, category wise" whose category lines are set by each organisation rather than by a fixed taxonomy
Guidelines for Secure Application Design, Development, Implementation & Operations · CERT-In, MeitY · updated January 2024 · 15 pages · the secure-design document named at §8(vii) of the audit policy guidelines, and the standard §8(viii) has in mind when it says an application developed without secure design and development practices should not be considered for assessment and audits
CERT-In SAMVAAD 2026 — Conference Proceedings · CERT-In, MeitY · 2nd edition · event 27–29 April 2026, BITS Pilani K. K. Birla Goa Campus · 666 pages · relied on only for the stated remit of the Working Group on Indian Standards for Cybersecurity Auditing, which names standardised audit reporting formats, RFP templates and scope templates for audit types including ICS and OT environments among its aims. That is an aim recorded in the proceedings, not a published template, and no template has been read for this page.
Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM · CERT-In, MeitY · Version 2.0, dated 09.07.2025 · §6(xxvi) names SBOM, QBOM and AIBOM auditing as a class of engagement without citing this document, so read them together rather than treating the link as stated

Standards named by the instruments above

None of these is published by the Government of India. They are here because §8(ii) of the audit policy guidelines names them as the comprehensive standards and frameworks an audit is to be built from, and because §16.2(ii) requires the two scoring systems and the two identifier schemes. Where this page describes what one of them contains, that is a statement about the standard and not about an Indian instrument.

OWASP Application Security Verification Standard (ASVS) · OWASP · named at §8(ii) and in GIGW guideline 5.3.1 · relied on for the three verification levels, for the note that the level definitions were restructured between 4.0.3 and 5.0.0, and for the project page giving 5.0.0 as the latest stable release when it was checked for this page. OWASP project paths move. If the link has moved again, search the project name rather than trusting a cached URL.
OWASP Web Security Testing Guide (WSTG) · OWASP · named at §8(ii) · relied on as the named testing methodology for the web application and API engagements on this page
OWASP Mobile Application Security Testing Guide (MASTG) · OWASP · §8(ii) names “the OWASP Mobile Security Testing Guide (MSTG)”, but the guide is published at mas.owasp.org under the Mobile Application Security project, where the current document is titled MASTG · relied on as the named methodology for the mobile engagement. Note the separate drafting difference this page flags: GIGW guideline 5.3.1 names OWASP MAVS where CERT-In names the MSTG, which is why a scope of work should name the document and its version rather than the initialism.
OWASP DevSecOps Maturity Model · OWASP · named at §8(ii) · relied on for the pipeline row of the inventory-routing table, but no assertion on this page is sourced to its content
OSSTMM 3 — The Open Source Security Testing Methodology Manual · ISECOM, created by Pete Herzog · Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs, 2010 · named at §8(ii) as OSSTMM3 · relied on as the named methodology for the external network, internal network and wireless engagements. The manual states that it covers a single testing methodology across five channels — human, physical, wireless, telecommunications and data networks — which is why this page names it for the radio estate as well as the wire
CSA Cloud Controls Matrix (CCM) · Cloud Security Alliance · named at §8(ii) for cloud security · relied on as the named control set for the cloud configuration review
Common Vulnerability Scoring System (CVSS) · FIRST · §16.2(ii) requires CVSS for severity · the bands used in the severity table on this page (9.0–10.0, 7.0–8.9, 4.0–6.9 and below 4.0) are CVSS’s own qualitative severity ratings, not CERT-In’s. The guidelines require the scoring system and do not print the bands
Exploit Prediction Scoring System (EPSS) · FIRST · §16.2(ii) requires EPSS for real-world exploitation likelihood alongside CVSS · relied on for what the second number adds at each band
Common Weakness Enumeration (CWE) · MITRE · §16.2(ii) requires every reported observation or vulnerability to be mapped with a CWE number · every CWE identifier on this page is a weakness class, lookup-able at this address, and is given so the finding-class descriptions are checkable rather than decorative
Common Vulnerabilities and Exposures (CVE) Program · The CVE Program · §16.2(ii) requires every reported observation or vulnerability to be mapped with a CVE number · a CWE says what kind of weakness it is, while a CVE says which specific published vulnerability in which specific product

One further document is named on this page and deliberately not linked, for a different reason. §8(v) requires verification against MeitY’s “Comprehensive Audit Program Checklist – Cyber and Information Security Audit”, as outlined in the “Guidelines on Mandatory Features of Cybersecurity Architecture to be Ensured in all Ministries/Departments”, and states that the checklist, comprising 282 control points, forms the default mandatory audit scope for the entities that clause covers. The audit policy guidelines give that document no version, no date and no URL, and none was located for this page, so it is cited as §8(v) names it and nothing is asserted about its contents beyond the count the clause itself states.

Written By Expert Auditors

Surendra Pal SinghChief Information Security Officer & Data Protection OfficerCISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi ChauhanLead AuditorISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Last reviewed: 22 September 2026 • Content verified by certified lead auditors

Keep Exploring