Scope is the one decision in a vulnerability assessment and penetration test that everything else depends on. Get it right and a short report is worth reading. Get it wrong and a thorough, well-written, technically excellent report describes a system you do not run. Scope, not testing depth, is what decides whether the report describes the system you have.
The instrument that settles most of it: the Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025), whose §13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory — the sentence the rest of this page unpacks.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · CERT-In Auditor Guidelines v3.0 (May 2018) · Every clause locator checked 22 September 2026
How do you scope a VAPT properly?
A VAPT scope is the written statement of which assets will be tested, in which environment, at which build, from which authenticated positions, under which rules and with which exclusions. Under §13.1.1(b) of CERT-In’s 2025 audit policy guidelines it is the auditee’s to define, in consultation with the auditor — not the auditor’s to propose.
Scoping one is six decisions, in this order.
- 01 Build the inventory, then cut the scope from it. A consolidated, dated asset inventory comes first and the scope is derived from it (§13.1.1(c)) — not a list of the systems somebody remembers.
- 02 Name the environment and fix the build. Say which environment each asset is tested in, and pin the exact build by hash, algorithm and version number (§15.2.3(i), §9.5(i)).
- 03 Decide the roles, and issue the accounts. Choose which authenticated positions the testing covers, and issue at least two accounts per in-scope role — and two tenants where the product is multi-tenant.
- 04 Add the interfaces. APIs, mobile back-ends, cloud configuration and third-party integrations are all named in the scope clauses and all silently absent from a web-application scope.
- 05 Write down every exclusion. Each one with what, why, who authorised it and on what date, and how it is covered instead (§13.2.4(ii), §9.2).
- 06 Agree the rules of engagement in writing before anyone touches a system. Ten separate gates, each with its own scope, its own signature and its own date.
That is not a methodology invented for this page. Section 13.1.1 of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) sets out in seven lettered sub-clauses what a scope has to cover and where it has to come from, and §13.2.3 sets out what must be communicated before the engagement begins. Between them they describe a scoping process that most VAPT purchases skip entirely. The rest of this page is those clauses, in the order a real scoping conversation hits them, with the operational detail each one requires.
If you are earlier in the process than scoping — still working out what VAPT is, or how it differs from a penetration test or a red team exercise — start with what VAPT is and VAPT versus penetration testing versus red teaming. If you are choosing between kinds of test rather than scoping one you have chosen, the types of VAPT is the page for that.
Key Takeaways
- Scope is derived from the consolidated and updated asset inventory (§13.1.1(c)), and the date that inventory was updated must reach the audit report (§13.2.3(ii)(b)).
- Scope is defined by you in consultation with the auditor (§13.1.1(b)) — not proposed to you inside a quotation.
- The environment tested must be stated (§15.2.3(i)), and a website is tested on the staging server or testing environment provided by the hosting service provider before the audit certificate is issued (§15.2.3(ii)).
- Fix the build: hash value, hash algorithm, version number and timestamp are captured by the auditee and featured in the certificate and report (§9.5(i), §16.1(v)). A staging test plus an unfrozen production release equals a certificate for a build nobody is running.
- Version-specific details of web and mobile applications must be explicitly mentioned in the audit scope and in the report (§13.2.3(ii)(c)).
- Testing, UAT, development and production assets are all in scope for complete coverage (§13.1.1(e)), and third-party, vendor and supply-chain risk is part of the scope too (§13.1.1(f)).
- APIs are named alongside web and mobile applications (§6 item xii), and API Security Audit is its own type of audit (§13.2.3(i)(a)) — a browser-driven test does not cover it.
- Every exclusion, limitation and constraint must be communicated (§13.2.4(ii)) and stated in the report (§16.1(ii)). An in-scope asset that could not be reached is named in the report with reasons and brought to CERT-In’s notice (§10.1(ii)).
- Written approvals come before penetration tests, tool installation, remote testing, disruptive tests and social engineering — and privileged access is temporary, revoked by you on completion (§15.1.2).
- Follow-up audits belong in the scope of work (§13.1.1(g), §9.3(iv)), and the final report issues after closure and the production follow-up (§16.3(v)).
A clean report on the wrong system is a true statement about nothing
A VAPT report is a statement about a defined set of assets, in a defined environment, at a defined point in time, tested from a defined position. Change any of those four and the same testing produces a different document. §10.1(i) of the 2025 guidelines puts the limitation in the auditor’s own terms: the auditor is not responsible for managing or maintaining your security measures directly or indirectly, and their responsibility is limited to reviewing and reporting on the state of security at the point in time of the audit. Everything outside that frame is outside the report, and the scope is what draws the frame.
This matters more in India than the market usually acknowledges, because the deliverable is often not the report. It is a certificate somebody else will rely on. A GIGW evaluator checking guideline 5.3.1 is checking that a website, web application, web portal or mobile app has been security audited and an audit clearance certificate issued before hosting in the production environment — and the evaluator’s own action, in the GIGW 3.0 manual’s words at page 84, is to check that the website, web application, web portal or mobile app under evaluation has a valid security audit certificate issued by NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory fulfilling CERT-In requirements. Validity is a question about the build, and the build is a question about the scope.
One caution if you go and check that sentence. The manual and the live attributes page on guidelines.india.gov.in do not word the evaluator action identically: the manual names four issuing bodies and says “website/ web application/ web portal/ mobile app under evaluation”, while the attributes page names three and says “the website”. The statement of 5.3.1 itself is the same on both. This page cites the manual, and both documents are linked in the sources block.
The second reason is structural. §9.6(i) of the 2025 guidelines states that the complete audit process of the information infrastructure must be undertaken by the auditee organisation itself — from defining the audit scope, selecting the auditing organisation and providing access to the information infrastructure, through to ensuring closure of all audit observations — and that this responsibility must not be delegated, though the organisation may seek external support for specialised expertise while retaining full ownership and accountability. Scoping is named first in that list. It is not something the auditor does to you. It is the part of the engagement the guidelines say is yours.
“The scope must be derived from the consolidated and updated asset inventory.”
What does CERT-In require a VAPT scope to cover?
§13.1.1 is titled “Defining and finalizing audit scope” and its sub-items run as letters, (a) to (g), not as roman numerals. §13.2.3 is titled “Planning Audit Scope and Objectives” and adds what has to be communicated before commencement. Read together they are the clearest published statement of what a scope of work should contain, and they are addressed as much to the buyer as to the auditor. Section numbers in the form §13.1.1(c) refer to the 2025 guidelines throughout this page unless another document is named.
| Clause | What it requires | What it means at the scoping table |
|---|---|---|
| §13.1.1(a) | The scope covers the entire cyber infrastructure — web and mobile applications, network, OT and ICS, cloud, APIs, database and hosting infrastructure, code review, application security, data security and incident-response testing. | The default is everything. Anything narrower is a decision somebody has to make on purpose and write down, which is what the exclusions section of this page is for. |
| §13.1.1(b) | The scope is defined by the auditee organisation in consultation with the auditing organisation. | Scope is yours to set, not the vendor’s to propose. A scope that arrives fully formed inside a quotation is a priced guess at your estate, and it will be wrong in the direction that makes the quotation smaller. |
| §13.1.1(c) | The scope must be derived from the consolidated and updated asset inventory. | This is the load-bearing sentence on the whole page. The inventory comes first and the scope is cut from it. Scoping from a list of URLs somebody remembers is how a report ends up certifying an estate the organisation does not run. |
| §13.1.1(d) | The scope is vetted by the internal audit team in consultation with the CISO. | Two internal sign-offs before the scope leaves the building. In practice this is the step that catches the system nobody in the project team owns. |
| §13.1.1(e) | Testing and UAT, development and production assets are included, to achieve complete audit coverage. | Non-production is in scope in its own right, not merely as a stand-in for production. The question to settle for each one is whether it holds production data or production credentials, because a development environment that does is a production asset wearing a different hostname. |
| §13.1.1(f) | Third-party, vendor and supply-chain risk assessment forms part of the scope. | The integrations, the SDKs, the payment gateway, the analytics beacon and the managed service that holds your database are inside the question even where they sit outside your account. |
| §13.1.1(g) | The scope of work should clearly specify the requirement to conduct follow-up audits as part of the engagement. | Retesting is a scope item, not a favour. If it is not in the scope of work it is not in the price, and §16.3(v) will not let the final report issue without it. |
| §13.2.3(ii)(a)–(c) | The scope is drawn from a centralised asset inventory, the date up to which that inventory was updated must be reflected in the audit reports, and version-specific details of web and mobile applications must be explicitly mentioned in the audit scope and report. | Three artefacts the scope has to carry into the report: where the asset list came from, how fresh it was, and exactly which version of each application was tested. |
| §8(iv) and §13.1.8(ii) | Guidelines and directions issued by CERT-In and regulators are to be included as part of the scope of audit by default. | Identical wording in both places — §8(iv) under Applicable standards and Frameworks, and §13.1.8(ii) under the heading “Reference Standards and Initial Guidelines”. It is not at §13.1.1, whose sub-items are letters. You do not add the CERT-In Directions of 28 April 2022 to the scope. They are in it unless somebody removes them, and §15.2.1(iv) requires their verification in every audit assignment anyway. |
| §16.1(iii) | All the assets provided in the scope by the auditee organisation must be mentioned in the report. | The report is checkable against the scope line by line. An asset that went in and did not come out is either a finding or an omission, and §10.1(ii) covers which. |
One sequence is worth noticing across that table. The inventory produces the scope (§13.1.1(c)), the scope produces the report’s asset list (§16.1(iii)), and the report’s asset list is what a reviewing authority compares against your estate later. Each step is checkable by somebody who was not in the room, which is the point of writing any of it down.
Build the inventory, then cut the scope
How do you build the asset inventory a VAPT scope is derived from?
Nobody has a complete asset inventory. The useful question is not whether yours is complete but whether it was assembled from more than one source, because a single source always agrees with itself. Reconciling four or five sources is what surfaces the assets that exist without an owner — and those are exactly the assets that turn up in a report as findings nobody expected, or worse, do not turn up at all.
A workable sequence, which takes a few days rather than a quarter:
- 01 Pull the authoritative lists you already have. Every DNS zone you control, every certificate issued to your domains, every cloud account, subscription and project, the load balancer and CDN configurations, the API gateway, the app store listings, the CMDB if there is one, and the asset register the finance team keeps for hardware. Export each one with a date on it.
- 02 Reconcile them against each other, and keep the disagreements. The hostname that has a certificate but no DNS record. The cloud account nobody in the platform team recognises. The subdomain pointing at a service that was decommissioned. These are not noise. They are the output of the exercise.
- 03 Add the interfaces, not just the hosts. Every API base URL and version, every webhook endpoint in both directions, every scheduled job that reaches outside the perimeter, every integration that authenticates as a machine identity. Interfaces are what a host-based inventory misses by construction.
- 04 Add non-production. §13.1.1(e) puts testing, UAT, development and production assets in scope to achieve complete audit coverage. List them with the same fields as production, because that is the only way to see which of them holds production data.
- 05 Assign an owner to every row, and record the rows you cannot. An unowned asset is a scoping decision waiting to be taken by default.
- 06 Classify by criticality, with the CISO. §13.1.3(iii) makes criticality operative: critical applications require both dynamic and static application security testing, and §13.1.2(i) contemplates sectoral regulators increasing audit frequency based on the criticality of the assets being audited.
- 07 Date it, freeze it, and have the internal audit team vet the scope drawn from it in consultation with the CISO, as §13.1.1(d) requires. The date is not an administrative detail: §13.2.3(ii)(b) requires the auditee to explicitly mention the date up to which the scope and asset inventory have been updated, and that date must be reflected in the audit reports.
What a usable inventory row looks like
The fields below are the ones that survive into the scope of work and then into the report. Anything you cannot fill in is a question for the scoping call rather than a reason to leave the row out.
| Field | Why the scope needs it |
|---|---|
| Asset identifier and type | Web application, API, mobile app, host, database, cloud account, network range. The type determines which of the twenty-six classes of engagement at §6 applies — the index further down this page gives all twenty-six with what each one needs in the scope. |
| Environment | The environment the application was tested in — Test, Development, UAT, Pre-Production or Production — which §15.2.3(i) requires the auditing organisation to specify, in a list the clause introduces with “such as”. |
| Version and build identifier | Version-specific details of web and mobile applications must appear in the scope and the report (§13.2.3(ii)(c)). |
| Owner, and the technical point of contact | §13.1.4(ii) requires a technical team to be assigned as point of contact for assisting and monitoring the auditing organisation during the audit. |
| Who operates the underlying server and OS | §13.1.5 places responsibility for auditing the web server, its OS, the hosting software and the backend database with whoever owns and operates the server. |
| Criticality, and the data it holds | Drives DAST and SAST decisions (§13.1.3(iii)) and the passive-technique constraint in critical environments (§15.2.2(iv)). |
| Internet-reachable, partner-reachable or internal only | Determines what an unauthenticated external test can see at all, and which exclusions are really network controls. |
| In scope / excluded, with the exclusion reference | Makes the scope and the exclusion list two views of one document rather than two documents that drift. |
There is a second reason to do this properly, and it arrives after the engagement rather than during it. §15.2.1(iii) requires the auditing organisation to revalidate observations from the previous audit cycle, with any unresolved issues recorded as repeat observations in the current cycle. Next year’s engagement will be compared against this year’s scope. An inventory assembled once and maintained is the difference between a comparison and an argument.
Staging first, and then say which build
Should a VAPT be done on staging or on production?
Both, in that order, and the report must say which. For a website heading towards a certificate the sequence is fixed by clause rather than by preference: staging first under §15.2.3(ii), production for the follow-up audit under §16.3(v). The table sets out each rule in the instrument’s own terms.
| Environment | What the guidelines say | What to settle at scoping |
|---|---|---|
| Staging or the testing environment provided by the hosting service provider | The auditing organisation is required to audit and test the website on the staging server or testing environment provided by the hosting service provider prior to issuing the Audit Certificate, and to obtain application hash values and version numbers from the auditee for inclusion in the report.§15.2.3(ii) · 2018 guidelines, Technical | This is a requirement, not a preference, and it is the reason a safe-to-host engagement starts on staging. Get the staging build stood up before the kickoff call rather than during week one. |
| Production | The final audit report should be issued after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment. Where the audit scope is limited to the staging platform, the report must explicitly state that the audit was not conducted on the production environment.§16.3(v) | Production is where the engagement ends, not where it starts. A report with no production follow-up is a staging report, and the guidelines require it to say so on its face. |
| Test, Development, UAT and Pre-Production | The environment in which the application was tested — Test, Development, UAT, Pre-Production or Production — must be specified. The 2018 guidelines put the same duty in one line: the auditor must clearly state the environment in which the application was tested.§15.2.3(i) · 2018 guidelines, Technical | Read the environment line before you read the findings. It is usually one sentence in the methodology section and it determines what every other page of the report is about. |
| A critical environment where availability is the priority | 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.§15.2.2(iv) | A constraint on technique, not a ban on testing. Name the systems this applies to in the scope, because after the fact it becomes an argument about what "critical" meant. |
Why testing staging and then shipping production invalidates the result
The mechanism is easy to describe. Testing runs against the staging build, as it is required to. Findings are remediated. The certificate is issued naming a hash value and a version. Meanwhile the release train keeps moving, and by the time the certificate is handed to whoever asked for it, production is running a build that was never tested, whose hash does not match the one on the document, and whose changes nobody assessed.
The instruments deal with this from three directions at once, and they are worth keeping apart because they say different things. §9.5(i) puts the artefacts on you: hash values, version numbers and timestamps of the audited application are captured by the auditee organisation, shared with the auditor, and prominently featured in the audit certificate and reports — and the developer should avoid making any code changes to the audited application or infrastructure after issuance of the audit certificate. §13.1.2(iii) defines the threshold: every change is classified as Minor or Major, and a Major Change — high-risk and impactful to security, expressly including system overhauls, technology migrations and configuration adjustments that affect sensitive data or critical infrastructure — must undergo a cyber security audit before implementation. And §16.3(v) closes the loop: the final report issues after the follow-up audit on production, so an engagement that stops at staging has not finished.
Note what “major” does and does not mean there. The 2025 guidelines define it by risk, not by size, and it governs when you must audit rather than how long a certificate lasts. Those are different questions, and how long a safe-to-host certificate is valid deals with the second one separately.
What is the application hash value on a CERT-In audit certificate, and who provides it?
Five artefacts fix the build, and they are agreed before testing starts rather than assembled afterwards. All five are the auditee’s to produce.
Application hash value
Captured by the auditee, shared with the auditor
Hash values, version numbers and timestamps of the audited application are to be captured by the auditee organisation and prominently featured in the audit certificate and reports (§9.5(i), restated at §16.1(v)). The hash is what makes "this build" a checkable statement rather than a claim.
Hash algorithm
Agreed with the auditor before capture
Published specimen certificates differ on this. The Web Security Audit Certificate published by the Indian Institute of Corporate Affairs (Ministry of Corporate Affairs), issued 11 July 2024, prints a 64-character hash value and names no algorithm at all. The Safe to Host Certificate published by CSIR Human Resource Development Group, dated 17 May 2025, prints both the hash and "Hash Algorithm: SHA-256 With RSA Encryption". Agree the algorithm, the exact artefact being hashed and the value together at the point of issue, not afterwards. The table below settles the middle term — which object is hashed, for each kind of asset.
Application version number
Auditee
Version-specific details of web and mobile applications must be explicitly mentioned in the audit scope and in the report (§13.2.3(ii)(c)). A semantic version with a build identifier beats a marketing version.
Site URL and test URL, stated separately
Both parties
The two are different and the certificate prints both. The Indian Institute of Corporate Affairs certificate makes the relationship explicit in its own conclusion: "Build of Site URL and Test URL need to be identical." That sentence is the whole staging-versus-production problem in nine words.
Code freeze window and change control
Auditee
The auditee’s developer should avoid making any code changes to the audited application or infrastructure after issuance of the audit certificate (§9.5(i)). Separately, §13.1.2(iii) classifies every change as Minor or Major and requires a Major Change — one that is high-risk and impactful to security — to undergo a cyber security audit before implementation.
What exactly gets hashed, for each kind of asset?
§9.5(i) and §16.1(v) put a hash on the certificate and in the report without saying which object it is taken over, and a team with a web application, an APK, an IPA and a container image has four different answers. Agree the answer per asset type at scoping, and record a source-repository commit alongside every hash — the hash identifies the artefact, the commit identifies what produced it, and you need both to investigate anything later.
| Asset type | What is hashed | Identifier recorded alongside it | Who captures it |
|---|---|---|---|
| Web application deployed on a server | The deployment artefact as shipped — the WAR, JAR, ZIP or tarball that was installed, or a manifest of file hashes over the deployed server-side source tree | Git commit SHA plus the build tag, and the deployment identifier from the release system | The build pipeline, captured by the auditee at the moment of promotion to the tested environment |
| Containerised service | The image digest (the content-addressable digest of the image manifest), not the mutable tag | Image tag, base-image digest, commit SHA of the source repository | The registry produces the digest, and the auditee records it against the environment it was deployed to |
| Android application | The exact APK or AAB submitted for testing, hashed as a file | versionCode and versionName, the signing certificate fingerprint, and the minimum supported version still in the field | The mobile build pipeline. The tested binary must be the one archived, not a rebuild |
| iOS application | The exact IPA supplied to the auditor, hashed as a file | CFBundleShortVersionString and CFBundleVersion, and the distribution profile used | As above. A rebuild from the same commit produces a different file hash, which is why the archived binary is the artefact |
| API deployment | The deployed service artefact or image digest per service, plus a hash of the published specification if one is relied on | API version in the path or header, the specification version, and the list of versions still answering | Platform team, per service. An API estate needs one row per deployed version, not one row |
| Infrastructure-as-code estate | The commit SHA of the configuration repository at the state that was applied, plus the plan or state identifier | Module versions, provider versions, and the account or subscription the state belongs to | Platform team. Configuration drift after capture is the same problem as a code change after issue |
And record the algorithm beside the value in every case. The two published specimen certificates cited on this page differ on exactly that point — one prints a 64-character hash and names no algorithm, the other prints the value and “SHA-256 With RSA Encryption” — so a value alone is not reproducible by whoever has to check it later.
Staging-versus-production parity: what to record as a known difference
A staging environment that does not match production in configuration is a subtler version of the same problem, and it is the one that produces false confidence rather than a visible mismatch. Debug endpoints enabled in staging and disabled in production produce findings you do not have. A web application firewall present only in production produces an absence of findings you also do not have. Walk this list at scoping and record each difference in the scope of work, so it reads as a limitation under §16.1(ii) rather than as a result.
| Parity item | What a difference does to the result |
|---|---|
| Debug endpoints, verbose stack traces, developer toolbars | Enabled in staging and disabled in production produces findings you do not have. Disabled in staging and enabled in production produces the opposite. |
| Security headers and TLS configuration | Headers and cipher suites are frequently terminated at a production-only edge. A staging test measures the origin. |
| Web application firewall and bot management | A WAF present only in production hides findings during the staging test and blocks the auditor during the production follow-up. |
| Rate limits and throttling | Different limits in the two environments change what is reachable. See the rate-limit note below — raise or exempt the declared source IPs, not the whole application. |
| Data volume and data shape | An empty or near-empty staging dataset makes authorisation, export and search behave differently, and makes a tenant-isolation test vacuous. |
| Third-party integrations: live, sandboxed or stubbed | A stubbed integration is untested by definition. A sandboxed one is tested against the sandbox. Name which each one is, per integration. |
| CDN, caching and edge rules | Cache poisoning, host-header handling and path normalisation live at the edge. No edge in staging means no result about the edge. |
| Feature flags and their default state | A flag on in staging and off in production tests code nobody runs. Record the flag state as part of the build identity. |
| Log verbosity and what reaches the logs | Sensitive-data-in-logs findings depend entirely on the environment’s log configuration. |
| Identity-provider configuration, MFA and session policy | Relaxed session timeouts, a different MFA policy or a separate IdP tenant in staging mean the authentication result measured there is a result about a different configuration. |
Credentialed or not, and as whom
What is the difference between credentialed and uncredentialed testing?
Uncredentialed testing works from the position of somebody who has no account: it sees what is reachable before authentication. Credentialed testing works from inside one or more authenticated roles, and sees the application as its users see it — the session, the object references, the workflow, the privilege boundaries. Both are legitimate. They answer different questions, and a scope that buys only the first is buying the cheaper question.
The published standard CERT-In names makes the distinction operative. §8(ii) of the 2025 guidelines lists the OWASP Application Security Verification Standard among the comprehensive standards audits should be built on — while expressly saying that limited lists such as the OWASP Top 10 and SANS Top 25 should not be considered standards or references for audits. ASVS defines three verification levels. In the current stable release, 5.0.0, Level 1 holds around 20 per cent of the requirements and is described as the minimum to consider when securing an application. Level 2 is what most applications should be striving for, taking the cumulative total to roughly 70 per cent of the standard. And Level 3 is the goal for applications demonstrating the highest levels of security, adding the final 30 per cent.
Two things about that are worth naming precisely, because both are commonly misstated. ASVS 5.0.0 does not say Level 1 is penetration-testable from outside — it says the opposite: “Level 1 is not necessarily penetration testable by an external tester without internal access to documentation or code”, although the smaller number of requirements should make it easier to verify. That wording is new. Earlier versions of the standard framed Level 1 as the black-box level. And 5.0.0 is a substantial break from 4.0.3, not a revision of it: of the 286 requirements in 4.0.3, only 11 remain unchanged, 109 are no longer separate requirements, and identifiers changed even where the substance did not. So a scope of work that names a level without naming the version is naming something that has moved.
The guidelines name ASVS but do not name a level, and ASVS declines to prescribe one — it says an organisation should analyse its risks and decide what level it believes it should be at, given the sensitivity of the application and the expectations of its users. That leaves you with a decision and no rule. The table below is a rule you can apply, read off the application profile, with the scope consequences each level carries.
| Application profile | ASVS level | What that forces into the scope | The clause it interacts with |
|---|---|---|---|
| Public marketing site or brochureware, no accounts, no personal data beyond a contact form | Level 1 | Unauthenticated testing only. No role matrix, no tenant provisioning. Configuration and hosting still in scope as their own assets. | Nothing special. If the site is on a GIGW hosting path, jump to Level 2 — the hosting gate is the real requirement, not the content. |
| Internal tool behind SSO, no regulated data, small known user population | Level 1, or Level 2 where it holds employee personal data | Two accounts per role at minimum. Source access not required. Threat-model review out of scope unless the tool is an access path to something larger. | §15.1.1(ii) — resist the temptation to harden the tool for the test window, because it is a network change during the test period. |
| Customer-facing product handling personal data under the DPDP Act | Level 2 | Two accounts per role and two tenants where multi-tenant. Authenticated and unauthenticated both in scope. Documented-security-decision requirements mean the scope has to name which design documents the auditor may read. | §13.1.3(iii) — if the application is classified critical, DAST and SAST both, with SAST placed on the developer’s or system integrator’s contract. |
| Payments, health data, or an application on a GIGW hosting path towards a safe-to-host certificate | Level 2 as a floor, Level 3 for the components that hold or move the sensitive data | Full role matrix including administrative and service identities. Source code review in scope for the sensitive components. Threat-model review in scope. Staging supplied by the hosting service provider (§15.2.3(ii)). | §13.1.3(iii) DAST and SAST, and §9.5(i) hash and version capture, because the certificate will name them. |
| Critical infrastructure, ICS or OT, or anything where a failure is a safety event | Level 3 | Everything above, plus the technique constraint written into the scope rather than negotiated during the window. | §15.2.2(iv) — passive technique in critical environments where availability is a top priority, agreed before the window opens, not during it. |
The line to paste into the scope of work
Verification standard: OWASP ASVS 5.0.0, Level 2, all chapters in scope. Mobile components additionally against the OWASP mobile control groups named at §8(ii). Deviations from the standard to be listed as limitations under §16.1(ii).
Read practically, that is the whole credentialed-versus-uncredentialed argument settled. Anything above the lowest level needs accounts, and accounts need to be issued before the test window rather than during it.
How many test accounts does a VAPT need?
At least two per in-scope role, and two tenants where the product is multi-tenant. The cheapest improvement available to almost any VAPT scope is issuing two accounts per in-scope role instead of one. Access-control failures are about one identity reaching another identity’s data, and a single account cannot express that test. The table below is the coverage question in the form it should appear in a scope of work — add up the third column and you have the number the credential request has to ask for.
| Role | What it covers | Accounts to issue | Tenant | What goes wrong |
|---|---|---|---|---|
| Unauthenticated / anonymous | Everything reachable before login: the marketing surface, registration, password reset, public APIs, error pages, file uploads that do not require a session. | None | n/a | Scoped alone, this is the cheapest engagement to sell and the least useful to receive. It tests the front door of a building whose rooms are the point. |
| Standard user | The authenticated application as your ordinary customer sees it — the session, the object references, the workflow state machine, the exports. | 2 accounts | Same tenant | One standard account is not enough. Horizontal access control needs two accounts in the same role so that one can try to reach the other’s objects. |
| Second standard user, separate tenant or organisation | Tenant isolation in a multi-tenant product: whether tenant A can reach tenant B’s records by identifier, by export, by search, by webhook or by a stale cache. | 2 accounts | Second tenant | This is the class of finding a single-tenant test cannot reach at all. With one tenant provisioned, cross-tenant access control is not tested and not reported as untested — it simply does not appear. |
| Elevated or administrative user | Privilege boundaries, user management, audit-log tampering, impersonation features, configuration that changes the security posture of every other role. | 2 accounts, time-boxed | Both tenants where the console is per-tenant | An administrative account issued against an empty sandbox tenant, so the privileged surface tests clean because there is nothing in it to reach. The other version is one shared admin login used by the whole test team, which destroys attribution in your own audit trail at the exact moment you most want it. |
| Service, machine and integration identities | API keys, OAuth clients, service accounts, webhook signing secrets, CI tokens, the credentials your integrations authenticate with. | 1 per integration class | As deployed | These are users. They are rarely listed in a scope because nobody thinks of them as people, and they usually hold broader permissions than any human role. |
| Support, back-office and internal-only roles | The internal console, the impersonation tool, the refund screen, the data-export job, the admin panel that is only reachable from the office network. | 2 accounts | Whichever the console operates on | “Internal” is the heading exclusions hide under. Internal reachability is a network control, not an exemption, and if it is the reason a surface is out of scope then it is an exclusion with a reason and an authoriser — which is what the exclusion register below is for. |
The credential matrix, filled in
§15.1.2 puts a revocation duty on you and nowhere to record it. This is the record: one row per role, with both ends of each credential’s life on the same line and a named person who closes it. Filled against the worked example further down the page so the shape is concrete rather than notional.
| Role | Count | Tenant or org | Account identifiers | MFA handling | Issued | Expires | Revoked | Revocation owner |
|---|---|---|---|---|---|---|---|---|
| Standard user | 2 | Tenant A (Northwind Foods) | vapt-std-a1@, vapt-std-a2@ | Test IdP group, static TOTP seed held by IT | 06-Mar | 27-Mar | 24-Mar | IT service desk |
| Standard user, second tenant | 2 | Tenant B (Calder Logistics — seeded, not empty) | vapt-std-b1@, vapt-std-b2@ | As above | 06-Mar | 27-Mar | 24-Mar | IT service desk |
| Approver / manager | 2 | Tenant A | vapt-apr-a1@, vapt-apr-a2@ | As above | 06-Mar | 27-Mar | 24-Mar | IT service desk |
| Tenant administrator | 2 | Tenant A and Tenant B | vapt-adm-a1@, vapt-adm-b1@ | As above, but device binding waived for these accounts only | 06-Mar | 20-Mar | 20-Mar | Head of Platform (named) |
| Internal support console | 2 | Cross-tenant by design | vapt-sup-1@, vapt-sup-2@ | As above, source-IP allowlist only | 09-Mar | 20-Mar | 20-Mar | Head of Platform (named) |
| Service / machine identity | 3 | Staging project | API key ×1, OAuth client ×1, webhook signing secret ×1 | n/a | 06-Mar | 27-Mar | 24-Mar | Platform team |
Two details in that table do work. The privileged rows expire four days before the window closes, because privileged testing finishes first and there is no reason to leave the access standing afterwards. And the second tenant is annotated “seeded, not empty”: an administrative or cross-tenant account issued against an empty sandbox tests clean because there is nothing in it to reach, which is the quietest way to buy a good-looking result.
How do testers get past MFA, device binding and rate limits?
Somebody has to decide this in advance, and the options are not equally good. In descending order of how little they change what was tested:
- 01 A dedicated test group in your identity provider whose members enrol a static TOTP seed held by IT and handed to the auditor with the credentials. The authentication factor is still enforced. Only the enrolment is arranged. This changes nothing about the application under test and is the answer to reach for first.
- 02 Source-IP allowlisting of the auditor’s declared addresses. §13.2.7(i) already requires those addresses to be disclosed to you for remote testing, so the list exists. Use it to exempt the test accounts from a step-up challenge rather than to remove the challenge.
- 03 Device binding waived for named test accounts only, with the waiver scoped to those accounts, dated, and reversed on the same date the credentials are revoked. Narrower than it looks if the accounts are named individually.
- 04 Disabling MFA for the test accounts — last, because it changes what was tested. If it is done, it is recorded as a limitation under §16.1(ii), which means the report says the authentication controls in the tested configuration were not the ones in production.
Rate limits follow the same logic and are settled the same way. Raise or exempt the declared source IPs, not the whole application, and record the exemption as a limitation. A blanket relaxation across the estate for the duration is itself the kind of change §15.1.1(ii) tells you not to make during the test period, and it produces a result about an application nobody is running.
One further constraint belongs in the scope alongside the role list: privileged access is temporary by rule. §15.1.2 is addressed to you, not to the auditor: where privileged testing is necessary the auditee organisation provides only temporary access — login credentials, access tokens, certificates or secure ID numbers — and must ensure that all such privileges are revoked immediately upon completion of the audit. Issue named, individually attributable accounts rather than a shared one, so the audit trail says who did what, and put revocation on somebody’s checklist with a date, because it is the obligation with no deadline attached once the team has left.
One more thing the guidelines ask of you during the window, which affects what credentials are worth. §15.1.1(i) says notification of the test is limited to key personnel — generally those at policy-making level and the managers responsible for security processes, incident response and security operations — and §15.1.1(ii) says no unusual or major network changes should be made during the test period. A scope that issues good credentials and then quietly hardens the environment for the fortnight has measured a system that will not exist the following month.
What a scope quietly leaves out
What does VAPT scoping usually miss?
None of these are exotic. They are missed because a scope tends to be written in the vocabulary of the thing people look at — the website — rather than in the vocabulary of the estate. §6 of the 2025 guidelines lists twenty-six classes of engagement and introduces them with its own hedge, “including, but not limited to”, and several of the omissions below are separate named classes in that list.
The API behind the web application
§6 item xii is "Application security testing (including web applications, mobile applications and APIs)", §13.2.3(i)(a) lists API Security Audit as a named type of audit, and §13.1.1(a) names APIs in the scope definition. Testing the browser client exercises the subset of the API the client happens to call, in the order the client happens to call it. The API is a larger surface with its own authorisation model, its own versioning and, frequently, its own older deployments still answering on a path nobody has retired.
The mobile back-end, as distinct from the mobile app
A mobile application security audit (§6 item xiii) that ends at the binary tests obfuscation, storage and pinning, and stops exactly where the interesting failures begin. The standard §8(ii) names for mobile work says the same in its own structure: OWASP publishes the mobile material as control groups, and MASVS-NETWORK and MASVS-AUTH are about what happens between the app and the remote endpoint, not inside the binary. The back-end that serves the app is a separate asset with separate endpoints, and the app’s own traffic is the map to it. Scope the app and the endpoints it calls as one engagement, and say so in the scope of work rather than assuming the auditor will infer it.
Second and third mobile platforms, and the versions still in the wild
iOS and Android are two builds with two code paths and often two sets of hardcoded values. Older versions of your app that users have not updated still talk to your current back-end. Name the platforms and the minimum supported version in the scope. §13.2.3(ii)(c) requires the version-specific details in the report anyway. Several of the OWASP mobile control groups §8(ii) points at — MASVS-STORAGE, MASVS-PLATFORM and MASVS-RESILIENCE — are platform-specific by construction, so a result on one platform is not a result on the other.
Cloud configuration, as opposed to the application running on it
§6 item xviii defines Cloud Security Testing as evaluating and assessing the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures. An application test does not look at the storage bucket policy, the identity and access management trust relationships, the security groups or the key management configuration, and those are the findings that turn one compromised component into an account-wide event.
The cloud provider’s own permission, as distinct from the account owner’s
Authority under §13.1.5 answers who may permit testing of the workload. It does not answer whether the platform underneath permits the test at all. The major cloud providers publish their own terms governing penetration testing of customer workloads: which services may be tested, which test classes are prohibited outright, and where advance notification or a submitted form is required. Read the provider’s current terms for each in-scope account at scoping rather than at the first block. Two things make this tractable. The prohibited classes usually overlap almost exactly with what §15.2.2(ii) already gates on your side — denial of service, flood testing, anything that reaches shared infrastructure — so the scope is often already compliant by construction. And where notification or a form is required, obtaining it is an auditee task with a lead time, which means it belongs on the schedule with an owner and a date, not in week one as a discovery.
Infrastructure you do not own but depend on
§13.1.5 splits it cleanly: where a website is hosted on a web server owned by another organisation, responsibility for auditing the web server, its operating system, the web hosting application software and the backend database software lies with the organisation that owns and operates the server. Your responsibility is that the website data and software are audited by a CERT-In empanelled auditing organisation. Get the hosting provider’s own audit position in writing at scoping, because you cannot scope in a system you have no authority to permit testing against.
Third parties, vendors and the supply chain
§13.1.1(f) makes third-party, vendor and supply-chain risk assessment part of the scope, and §13.1.4(i) requires that where any of the activities to be audited are outsourced, the auditee organisation must ensure that relevant personnel from the outsourced organisation are available at the time of audit. That is a scheduling commitment you have to obtain from somebody else’s company before the scope is signed.
Operational technology and industrial control systems
§6 item xix defines ICS and OT security testing as evaluating the cyber security posture of industrial control systems and operational technology networks to identify vulnerabilities and potential threats that could disrupt critical industrial processes, impacting safety, production and overall system availability within a facility. Where OT is in the estate, §15.2.2(iv) passive testing is usually the only responsible technique, and it belongs in the scope, not in an argument during the test window.
Source code, where the application is critical
§6 item ix is Source Code Review, and §13.1.3(iii) requires both dynamic and static application security testing for critical applications, with static testing to be carried out by the developer or system integrator and that requirement clearly stated in the RFPs and tenders. Two consequences at scoping: decide whether the engagement is black-box, grey-box or includes code, and put the static-testing obligation into the development contract rather than into the audit contract.
The things that only exist during the test
Temporary privileged credentials (§15.1.2), the auditor’s source IP addresses (§13.2.7(i)), the tools installed on your systems and the artefacts they leave behind (§13.2.2(iii)–(v)). None of these are assets in your inventory and all of them are your responsibility to close out. The revocation step is the one with no deadline attached once the team has gone.
A useful test when reading a draft scope: for every asset listed, ask what talks to it and what it talks to. The answers are interfaces, and interfaces are where scoping omissions live.
Which of the twenty-six CERT-In audit classes is your engagement?
Here is the list, so the test is one you can actually run. §6 of the 2025 guidelines enumerates twenty-six classes of engagement, in the document’s own order and wording. The two columns beside each are the scoping cut — what has to be named in the scope for that class, and what you have to supply for it to happen at all. Which gates attach to which class is a different question, answered on the rules-of-engagement page.
| §6 | Class | What has to be in the scope for it | What you have to provide |
|---|---|---|---|
| i | Compliance Audits | The instruments being audited against, named. The CERT-In and regulator directions that are in scope by default (§8(iv), §13.1.8(ii)) | Policies, prior reports, the compliance evidence set |
| ii | Risk Assessments | The asset inventory and its criticality classification | Risk register, treatment decisions and the head-of-organisation authorisations (§9.2) |
| iii | Vulnerability Assessments | Hosts, ranges and applications by identifier, and the authenticated positions, if any | Network access, credentials where credentialed, an asset list with owners |
| iv | Penetration Testing | The same list plus the technique boundary and the exploitation limit | Written approval before testing (§13.2.2(v)), and source IPs allowlisted |
| v | Network infrastructure Audits | Ranges, segments, devices and the management plane | Topology, device inventory, read access to configurations |
| vi | Operational Audits | The processes in scope, named, and the period covered | Runbooks, ticket history, on-call records, escalation matrix (§13.2.6) |
| vii | IT security policy review and assessment | Which policies, at which version and approval date | The approved policy set with version history |
| viii | Information Security Testing | Assets and environment per asset (§15.2.3(i)) | Access, and the environment statement |
| ix | Source Code Review | Repositories by name and branch or tag, and which components, not “the codebase” | Read access to the named repositories at the tested commit — and the §13.1.3(iii) split, which puts static testing on the developer or system integrator’s contract rather than this one |
| x | Process Security Testing | The processes and the employee group, both bounded | Specific written permission (§13.2.7(ii)), and the agreed group list |
| xi | Communications Security Testing | The channels, and who owns each one | Permission from the channel owner where it is not you |
| xii | Application security testing (web applications, mobile applications and APIs) | Hostnames, API base paths and versions, package identifiers, per environment, per version | Build artefacts and hashes (§9.5(i)), specifications, and accounts per role |
| xiii | Mobile Application Security Auditing | Per platform, per build, with the minimum supported version named | The archived APK and IPA actually tested, plus the back-end endpoints they call |
| xiv | Wireless Security Testing | Sites and SSIDs, and the physical premises they cover | Site access and the premises owner’s permission |
| xv | Physical Security Testing | Locations, and what may and may not be attempted at each | Written rules of engagement from management (§17(i)), and a named on-site escalation contact |
| xvi | Red Team Assessment | The objective, the crown jewels, and the out-of-bounds list | Per-technique written permissions, and the key-personnel notification list (§15.1.1(i)) |
| xvii | Digital Forensic Readiness Assessment | The systems whose evidential capability is being assessed | Log configuration, retention settings, and access to the log platform |
| xviii | Cloud Security Testing | Accounts, subscriptions or projects by identifier, and the services within each | Read access to the named accounts, the §13.1.5 answer on who owns and operates what, and the provider’s own testing authorisation where its terms require one |
| xix | Industrial Control Systems / Operational Technology Security Testing | Cells, lines, protocols and the safety boundary | The §15.2.2(iv) passive-technique agreement, in writing, before the window opens |
| xx | Internet of Things (IoT) / Industrial IoT Security Testing | Device models and firmware versions, plus the management back-end | Sample devices, firmware images, and the provisioning credentials |
| xxi | Log Management and Maintenance Audit | Which systems’ logs, and the retention position being tested | Log platform access, and the 180-day retention configuration evidence |
| xxii | Endpoint Security Assessment | Endpoint classes and build images, not a headcount | Sample endpoints, the standard build, and management-console read access |
| xxiii | Artificial Intelligence (AI) System Audits | The model, the serving surface and the data path, each named | Access to the serving endpoints, and the documented purpose and data flows |
| xxiv | Vendor Risk Management Audits | Which vendors, and which of their services touch your data | Contracts, the vendor register, and vendor personnel availability (§13.1.4(i)) |
| xxv | Blockchain Security Audit | Contracts by address, the network, and the off-chain components | Source at the deployed commit and the deployment record |
| xxvi | SBOM, QBOM and AIBOM Auditing | Which products, at which build, and the BOM format being produced | The component inventory, derived from the same asset inventory §13.1.1(c) requires |
Now run the test. Ask which of those twenty-six the engagement actually is. If the honest answer is three classes priced as one, the scope is not a scope, it is a summary — and the three classes will not be delivered to the same depth, because the price was set for one of them.
Write every exclusion down, or it did not happen
Why must VAPT exclusions be written down?
Because an exclusion is a risk acceptance, and an unwritten risk acceptance is indistinguishable afterwards from an oversight. Three clauses converge here. §13.2.4(ii) requires the auditing organisation to provide clear communication to the auditee regarding any exemptions, limitations and other constraints related to the audit. §16.1(ii) requires the report itself to include exemptions, limitations and other constraints alongside the scope, duration, methodologies, tools, manual process, findings, prioritisation, sampling decisions and manpower involved. And §9.2 puts authorisation of risk treatment and of exceptions with the head of the auditee organisation, who is the owner of the application.
There is a fourth case that is not an exclusion at all and gets confused with one: an asset that was in scope and could not be reached. §10.1(ii) handles that separately. The auditor must promptly inform you and request resolution, and where it remains unresolved the asset must be named in the report with the reasons, and the same must be brought to the notice of CERT-In. An inaccessible in-scope asset is a reported gap, not a silent one — which is a good reason to resolve access problems while the engagement is running rather than after it.
| Field | Why it is there | Example value |
|---|---|---|
| What is excluded, named as precisely as the inclusions | An exclusion written as "third-party systems" excludes nothing checkable. An exclusion written as a hostname, an application version, an API path prefix or a named environment can be verified against the report. | payments-legacy.example.in (all paths) · Android app versions below 4.2 |
| Why it is excluded | §13.2.4(ii) requires the auditing organisation to communicate clearly any exemptions, limitations and other constraints related to the audit. A reason is what lets a reviewer decide whether the exclusion was reasonable. | Hosted and operated by the payment provider. No authority to permit testing |
| Who decided, and on what date | Exclusions are risk acceptances. §9.2 requires risk treatment to be authorised and accepted by the head of the auditee organisation, and exceptions to be authorised by the head of the organisation, who is the owner of the application. | [Name], Head of IT · 14-Jan-2027 |
| How it will be covered instead, or an explicit acceptance that it will not | Most exclusions are really deferrals. Saying which they are at scoping stops the same system being excluded again next year on the strength of last year’s scope document. | Provider’s own current audit report obtained and reviewed. No independent test |
A filled exclusion register
The four fields above are a specification. This is the register, filled — one row for each of the four kinds of exclusion described below, plus the fifth case that is constantly mistaken for an exclusion and is not one. It is drawn from the worked example further down the page, and it is the annexure to copy.
| Kind | What is excluded | Why | Authorised by, date | Covered instead |
|---|---|---|---|---|
| Authority | pay.example-psp.in — the hosted payment page and the PSP-operated card vault, all paths | Operated by the payment provider. No authority to permit testing against infrastructure we do not own or operate (§13.1.5). | Head of Engineering · 04-Mar | Provider’s own current audit report and attestation obtained and reviewed. Integration boundary (redirect, callback, signature verification) remains in scope on our side. |
| Technique | Denial-of-service, distributed denial-of-service and any form of flood testing, against every in-scope asset | Not authorised. §15.2.2(ii) requires explicit written permission expressly to prevent disruption of services, and the 2018 guidelines tell auditors to refrain from DDoS testing over the Internet and from flood testing. | Head of Engineering · 04-Mar | Not covered instead. Resilience testing scheduled as a separate exercise with its own authorisation, outside this engagement. |
| Window | All testing against admin.example.in between 28-Mar and 02-Apr | Quarter-end close. Availability of the finance workflow is a business constraint for those five days. | CFO and Head of Engineering · 04-Mar | Test window set 09-Mar to 24-Mar so the constraint never binds. Recorded so the report’s duration does not read as a gap. |
| Budget | Android and iOS binaries below version 4.2, and the deprecated /v1 API surface except for its authentication and authorisation endpoints | Budget. The estate is larger than this engagement. Criticality classification put the current mobile builds and the /v2 API ahead of legacy surfaces, and the /v1 authentication and authorisation endpoints were pulled back in because they issue tokens the /v2 surface honours. | CISO, vetted by internal audit · 04-Mar | Deferred, not accepted. /v1 scheduled for the next cycle. Retirement date committed for 30-Sep. Recorded on the risk register with an owner. |
| Not an exclusion — a deferral to a named owner | analytics.partner.example — partner-operated analytics endpoint our application posts to | Third-party consent not obtained by scope freeze. The partner’s security team was asked on 26-Feb and has not responded. | Head of Engineering · 04-Mar | Chased weekly by the named owner. If consent arrives during the window it becomes a §14.3(i) scope revision, not an informal addition. |
Exclusions come in four recognisable kinds, and they are worth labelling because they have different consequences. Authority exclusions — you do not control the system and cannot permit testing against it — are the strongest, and the right response is usually to obtain the owner’s own audit position instead. Technique exclusions — no denial of service, no flood testing, passive only in this environment — are usually required rather than chosen. See the gates below. Window exclusions — not during month-end, not during the examination results week — are scheduling, and they belong in the test plan rather than in the scope. Budget exclusions are the ones to write most carefully, because they are the ones a reader six months later will most want the reason for.
One sentence to keep out of a scope document: “and any other systems agreed between the parties”. It reads like flexibility and functions as an erasure. If the scope can change, change it the way §14.2 says to — in writing, with justification, assessed for impact, approved by authorised representatives and recorded as an addendum to the audit engagement letter.
What a finished scope actually looks like
What does a VAPT scope of work look like?
A composite, built to show the shape rather than to describe any real engagement: a B2B SaaS product sold in India, eighteen assets, heading for a customer-driven security review rather than a hosting gate. Two decisions are in it on purpose, because they are the two that make a scope real. One asset nobody could get permission for, and one asset discovered during the engagement that triggered a §14.3 revision. The first table is the scope schedule itself — the annexure a reader can copy. The second is the same engagement as a dated sequence, so the elapsed time between the decisions is visible.
| Asset | Type and §6 class | Environment | Version and build identity | Roles and accounts issued | In scope or excluded, with reference |
|---|---|---|---|---|---|
| www.example.in | Web application · §6(xii) | Production | v11.4.0 · commit 8c41f2e · no server-side session | Unauthenticated only | In scope |
| app.example.in | Web application · §6(xii) | Staging (provider-supplied) then production follow-up | v11.4.0 · commit 8c41f2e · artefact SHA-256 recorded 06-Mar | 2 standard + 2 approver in Tenant A, 2 standard in Tenant B | In scope |
| admin.example.in | Web application, internal console · §6(xii) | Staging then production follow-up | v11.4.0 · same artefact | 2 tenant admin (A and B), and 2 internal support, cross-tenant | In scope · window exclusion 28-Mar to 02-Apr (quarter-end) |
| Android app, package in.example.app | Mobile application · §6(xiii) | Staging back-end | versionName 4.6.1 · versionCode 461 · APK hashed as supplied · minimum supported 4.2 | Standard and approver, Tenant A | In scope · builds below 4.2 excluded (budget) |
| iOS app, bundle in.example.app | Mobile application · §6(xiii) | Staging back-end | CFBundleShortVersionString 4.6.1 · CFBundleVersion 4610 · IPA hashed as supplied | Standard and approver, Tenant A | In scope · builds below 4.2 excluded (budget) |
| api.example.in/v2/core | API security audit · §13.2.3(i)(a) | Staging then production follow-up | OpenAPI 3.1 spec v2.18, verified against deployment 04-Mar | OAuth client × 1, and all six human roles via the same surface | In scope |
| api.example.in/v2/reporting | API security audit · §13.2.3(i)(a) | Staging then production follow-up | OpenAPI 3.1 spec v2.18 | As above | In scope |
| api.example.in/v2/webhooks | API security audit · §13.2.3(i)(a) | Staging | Spec v2.18 · signing secret issued for testing | Webhook signing secret × 1, inbound and outbound | In scope |
| api.example.in/v1 (deprecated, still answering) | API security audit · §13.2.3(i)(a) | Staging | No current spec · deployment identified from the gateway, not from documentation | OAuth client × 1 | Partially in scope · authentication and authorisation endpoints only. Remainder excluded (budget), retirement committed 30-Sep |
| Cloud account 4417… (production) | Cloud security testing · §6(xviii) | Production, configuration review only | IaC repo commit 2b9d07c as applied · state id recorded | Read-only audit role | In scope · provider testing authorisation confirmed not required for configuration review. Owner and date recorded |
| Cloud account 4418… (staging) | Cloud security testing · §6(xviii) | Staging | Same IaC repo, staging workspace | Read-only audit role | In scope |
| Managed database cluster, staging | Database configuration audit · §13.1.3 | Staging | Engine version and parameter group recorded | Read-only audit role | In scope · §13.1.5: cluster operated by the cloud provider, but the data and schema are ours to have audited |
| Staging environment supplied by the hosting service provider | Environment · §15.2.3(ii) | Staging | Handed over 06-Mar with the payment integration pointing at a sandbox, not stubbed | All of the above | In scope · parity differences recorded against the checklist above |
| pay.example-psp.in | Third-party payment surface · §13.1.1(f) | n/a | n/a | n/a | EXCLUDED — authority. Operated by the payment provider. No authority to permit testing. Provider’s own audit report obtained and reviewed. Our side of the integration boundary stays in scope. |
| analytics.partner.example | Third-party integration · §13.1.1(f) | n/a | n/a | n/a | EXCLUDED — third-party consent not obtained by scope freeze. Named owner chasing weekly. If consent arrives, it is a §14.3(i) revision, not an informal addition. |
| sso.example.in (identity provider tenant) | Configuration audit · §13.2.3(i)(a) | Staging | Policy export dated 05-Mar | Read-only | In scope |
| ci.example.in (build pipeline) | CI/CD configuration · §8(ii) DevSecOps Maturity Model | Production | Pipeline definition at commit 2b9d07c | Read-only + 1 CI token | In scope — a pipeline that can deploy into a tested environment is part of that environment |
| files.example.in (document service, discovered 12-Mar) | Web application · §6(xii) | Production | v2.1.0 · commit e70a1b4 | 2 standard, Tenant A | Added by addendum 1 to the engagement letter, 13-Mar — §14.3(i) previously unidentified system presenting significant risk. §14.2 impact on timelines and man-hours assessed and signed |
The same engagement, dated
Sixty-three days from scope freeze to final report, of which the test window is fifteen. Ten of the twelve steps fall outside the test window, which is where the outcome is decided.
| 20 Feb | Inventory reconciliation opened | DNS zones, certificate transparency, two cloud account exports, the API gateway route table, both app-store listings and the CMDB pulled and dated. Eleven disagreements recorded, of which four were live systems the CMDB did not hold. |
| 04 Mar | Scope frozen, exclusions authorised | Seventeen assets in scope, five exclusion register rows authorised by the Head of Engineering and the CISO. Internal audit vets the scope in consultation with the CISO (§13.1.1(d)). Inventory as-of date recorded as 03-Mar for the report (§13.2.3(ii)(b)). Elapsed from inventory: 12 days. |
| 05 Mar | NDA, then the audit engagement letter | NDA before any activity. The engagement letter fixes the audit criteria and standard (OWASP ASVS 5.0.0 Level 2, OWASP WSTG, the OWASP mobile control groups), the plan with calendar time and man-hours per phase, the deliverable structure, both escalation matrices and the revalidation clause. Milestones: mobilisation, draft report, retest — none contingent on outcome or certificate (§7). |
| 06 Mar | Staging handed over, build fixed, credentials issued | Provider-supplied staging stood up with the payment integration on a sandbox. Artefact hashes and versions captured for the web build, both mobile binaries and each API deployment, with the algorithm recorded alongside each value. Thirteen accounts issued against the credential matrix, each with an expiry date and a named revocation owner. Source IPs allowlisted and entered in the SOC runbook. |
| 09–24 Mar | Test window | Assessment across both tenants and all six roles. Critical and high findings notified on the day of discovery (§16.3(ii)) rather than held for the report. Weekly progress minute. One inaccessible asset logged and resolved within two days. |
| 12–13 Mar | Scope revision under §14.3(i) | A document service nobody had listed is found reachable from the application. Proposed in writing with justification on 12-Mar. Impact on timelines, man-hours and deliverables assessed by both parties. Approved by authorised representatives and recorded as addendum 1 to the engagement letter on 13-Mar (§14.2). Eighteen assets from this point. |
| 20 Mar | Privileged credentials revoked | The four administrative and support accounts expire and are revoked on the date set at issue, ahead of the window closing, because the privileged testing finished first (§15.1.2). |
| 24 Mar | Remaining test credentials revoked | The nine standard, approver and machine credentials are revoked on window close. Revocation owner signs the matrix closed. Elapsed from issue: 18 days. |
| 28 Mar | Draft report and exit conference | Draft report carrying the §16.1(ii) contents — scope, duration, methodologies and standards, tools, manual process, findings, prioritisation, sampling decisions, manpower, exemptions, limitations and constraints — with every parity difference and every exclusion reproduced as a limitation. Exit conference with senior management (§17(iii)). |
| 29 Mar – 24 Apr | Remediation | Remediation owned by the auditee (§9.3(iii)), against the closure timelines by severity the report sets (§16.3(iii)). Two mediums risk-accepted in writing, authorised by the head of the organisation as owner of the application (§9.2), each with a date. |
| 28–30 Apr | Follow-up audit on production | The revalidation phase priced into the original scope of work (§13.1.1(g), §9.3(iv)) verifies closure on the production environment. New build tag, new hash, recorded against the change register. |
| 06 May | Final report | Issued after closure and the production follow-up, as §16.3(v) requires, signed by the auditors who conducted the audit, a mid-management reviewer outside the team, and the head of the auditing organisation (§9.5(iii)). Scope freeze to final report: 63 days. |
Two rows are worth re-reading. The excluded payment surface never becomes a gap, because the exclusion carries an authoriser, a date and a replacement — the provider’s own audit position. And the document service discovered on 12 March does not get added by email: it is proposed in writing with a justification, its impact on timelines and man-hours is assessed by both parties, and it lands as a numbered addendum to the engagement letter the following day. That is the whole of §14.2 and §14.3(i) in two working days.
Putting the scope into a tender
What should a VAPT scope of work contain in an RFP or tender?
Most VAPT in India is bought by tender, and two clauses of the 2025 guidelines are addressed to procurement directly. §13.1.3(iii) requires the static-testing obligation on the developer or system integrator to be “clearly stated in the RFPs and tenders”. §9.3(iv) requires follow-up audits to be “included within the scope or RFP proposal”. Everything below is something one instrument or another already requires of one party. Putting it in the tender is what makes the bids comparable, because a bidder prices what it can see.
The asset schedule, enumerated
Every asset by identifier — hostnames, package identifiers, API base paths and versions, databases, cloud account identifiers, network ranges — as an annexure derived from the dated inventory. §13.1.1(c) requires the scope to come from the consolidated and updated asset inventory, and §13.2.3(ii)(a)–(b) require the inventory and its as-of date to reach the report. A bidder prices what it can see.
Versions and build identity
Application and platform versions per asset, because §13.2.3(ii)(c) requires version-specific details of web and mobile applications in the audit scope and in the report. State that hash values, versions and timestamps will be captured by the auditee and featured in the report (§9.5(i), §16.1(v)), and which artefact is hashed for each asset type.
The environment per asset, and who supplies it
§15.2.3(i) requires the environment to be specified. Where a website is heading for a certificate, §15.2.3(ii) puts the staging server or testing environment on the hosting service provider — so name the provider and the handover date in the tender, because they are on your critical path whether or not they are on your contract.
The audit classes being bought, named
Say which of the §6 classes the engagement is, and name the §13.2.3(i)(a) type for each — web application security audit, API security audit, mobile application security audit, configuration audit, cloud security testing, source code review. Three classes priced as one is the commonest way a tender produces bids that cannot be compared.
Standards and version, with the ASVS level stated
§13.1.7(i)(a) requires the audit criteria and standard in the contract and §8(ii) gives the framework list. Name the standard, the version and the level: “Verification standard: OWASP ASVS 5.0.0, Level 2, all chapters in scope.” §8(ii) also tells you what not to write — limited lists such as the OWASP Top 10 and SANS Top 25 are not standards or references for audits.
Role and account counts to be issued
State how many accounts you will issue, per role, per tenant, and that they will be issued before the window opens. This is a commitment by the buyer, and it is the single line that most changes what the bid can find.
The SAST obligation, placed on the right contract
§13.1.3(iii) requires both dynamic and static testing for critical applications, requires static testing of the developer or system integrator, and requires that obligation to be clearly stated in the RFPs and tenders. It belongs in the build contract, not in the audit contract — so the audit tender should say where it sits rather than silently buying it twice or not at all.
Follow-up audits inside the price
§13.1.1(g) requires the scope of work to specify follow-up audits, §9.3(iv) requires them to be included within the scope or RFP proposal and conducted after closure, and §16.3(v) will not let the final report issue without the production follow-up. Ask for the revalidation phase as a separately stated line, not as an allowance.
The test plan in calendar time and man-hours
§13.2.2(ii) requires the test plan to include both. Require man-hours per phase — planning, assessment, reporting, revalidation — in the bid, and you get the only unit that makes two prices comparable.
Data handling, retention and the deletion certificate
§10.3 requires auditee data to be stored in India, encrypted on auditor devices, and wiped beyond forensic recovery, with a certificate of deletion formally issued to the auditee (§10.3(iv)). §10.3(vi) sets a one-year default retention of the report where the agreement is silent, which means your agreement should not be silent.
Both escalation matrices
§13.2.6 requires a well-defined escalation matrix on both sides for problems encountered during the audit. §13.1.7(iii) requires a separate escalation matrix in the contract for repeated vulnerabilities. Different problems, different matrices, both named in the tender.
Milestones that do not depend on the outcome
§7 requires fees to rest on predefined scopes, deliverables and timelines, and expressly prohibits payment contingent on the audit outcome or tied to the submission or approval of closure reports. Mobilisation, draft report, retest — and nothing worded “on issuance of certificate”.
Two clauses to refuse
- “and any other systems agreed between the parties”. It reads like flexibility and functions as an erasure: it makes the scope unbounded in the bidder’s favour at pricing and unbounded in yours at delivery, so neither party can hold the other to it. If the scope can change, change it the way §14.2 says to.
- Any milestone worded “on issuance of certificate” or “on approval of the closure report”. §7 requires fees to rest on predefined scopes, deliverables and timelines and expressly prohibits payment contingent on the outcome of the audit or tied to the submission or approval of closure reports. A milestone of that shape pays the auditor to find less, and a finance reviewer will ask for it because it looks prudent.
What has to be agreed before anyone touches a system
What are the rules of engagement for a VAPT in India?
Where the testing is carried out by a CERT-In empanelled organisation, the rules of engagement are published rather than negotiated. §17(i) of the 2025 guidelines expects written rules of engagement from auditee management, and §14.1(ii) requires the agreed terms to be formally documented in an audit engagement letter, reviewed and signed by authorised representatives from both organisations, serving as a binding reference point throughout the engagement. The ten gates below are what that letter has to cover. Each is a separate decision with its own scope, its own signature and its own date. One blanket signature at kickoff is not the same thing. The “Who signs it” and “The artefact” fields on each card are the question a gate list usually raises and never answers — who on your side puts their name to it, and what the signed thing is called when somebody asks for it later.
The audit team
Information regarding the audit team selected for conducting the audit is shared with the auditee and documented approval obtained before the formal commencement of the audit. Only manpower declared to CERT-In in the Snapshot Information Form may be deployed.
Who signs it
The auditee’s authorised representative under §14.1(ii) — in practice the CISO or the contract owner
The artefact
Audit team note, listing each auditor by name and designation, countersigned and dated
§13.2.2(i), §10.2(vi) · 2018 guidelines, Process
The test plan
The test plan shared by the auditing organisation must include both calendar time and man-hours.
Who signs it
The technical point of contact §13.1.4(ii) requires you to assign, with the contract owner
The artefact
Accepted test plan, with the phase-by-phase man-hours it is accepted on
§13.2.2(ii) · T&C v7.2 Annexure I, item 10
The tools
A list of tools with written IPR and licence confirmation, a thorough understanding of the tools including their origin and functionality, testing of those tools in a controlled test environment before deployment on your systems, and formal review and approval of the results of that testing by an authorised representative of the auditee organisation.
Who signs it
An authorised representative of the auditee — the clause says so in terms
The artefact
Tool record: tool, version, origin, IPR/licence declaration, controlled-test result, approval date. The same record carries the removal line later.
§13.2.2(iii)–(iv) · T&C v7.2 Annexure I, item 12
Penetration testing and tool installation
Appropriate written approvals before conducting any penetration tests, with installation of tools carried out in the presence of the auditee’s system administrator. Tools are removed after completion, with the auditee’s acceptance of removal, again in the system administrator’s presence.
Who signs it
Authorised representative for the approval, and the named system administrator for the installation and the removal
The artefact
Penetration-testing permission, and the second half of the tool record — removed by, witnessed by, accepted by, date
§13.2.2(v) · 2018 guidelines, Technical
Remote testing
The identity of the auditor with mobile number and/or IP addresses disclosed, and formal written permission obtained from the auditee clearly outlining the tasks to be performed.
Who signs it
Authorised representative, with the security operations lead copied because the allowlist and the runbook entry are theirs
The artefact
Remote-testing permission naming the auditors, their mobile numbers and every source IP. SOC runbook entry referencing it
§13.2.7(i) · T&C v7.2 Annexure I, item 6
Disruptive and high-risk tests
Written permission for tests involving survivability failures, denial-of-service, process testing or social engineering. Explicit written permission before DoS, DDoS or flood testing over the Internet, to prevent disruption of services — and the 2018 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. Note what the flood-testing sentence names: a person as well as a network, system or service.
Who signs it
Head of the auditee organisation, or the authorised representative they delegate in writing — this is the gate where a refusal is also a decision
The artefact
A separate permission per technique, each naming the technique, the targets and the window. One blanket kickoff signature is not this.
§13.2.7(ii), §15.2.2(ii) · 2018 guidelines, Technical · T&C v7.2 Annexure I, items 17–18
Social engineering
Only the group of employees explicitly included in the agreed scope. Anonymised or statistical techniques where general staff are targeted, so no individual is personally identified or penalised. No customers, business partners, vendors or other third parties without specific written consent.
Who signs it
Authorised representative, with the head of HR on the record because the reporting constraint is an employment matter as much as a security one
The artefact
Social-engineering permission naming the employee group and stating that results are reported as rates, and separate written consent from any third party targeted
§15.2.2(iii) · T&C v7.2 Annexure I, items 14–15
Privileged access
Temporary access only — login credentials, access tokens, certificates or secure ID numbers — with all such privileges revoked immediately upon completion of the audit. This clause is addressed to the auditee.
Who signs it
The system owner who issues them, with a named revocation owner recorded at the same time
The artefact
The credential matrix below: role, count, tenant, identifiers, MFA handling, issued, expires, revoked, revocation owner
§15.1.2
A breach discovered during the test
Not a permission but a pre-agreed stop-and-report path, and the one gate most engagements have not written down. The 2018 guidelines tell auditors to refrain from testing and exploiting high-risk vulnerabilities such as discovered breaches, or anything that may put immediate lives at risk. §15.2.2(i) replaces exploitation with a positive duty: such vulnerabilities are assessed and reported immediately to the auditee organisation and to CERT-In. §16.4 requires immediate reporting to you with a recommended practical solution. Your own duty is separate and is not discharged by the auditor’s — under the CERT-In Directions of 28 April 2022 the incident types listed in Annexure I are to be reported to CERT-In within 6 hours of noticing them or being brought to notice of them.
Who signs it
Nobody signs it in advance. What you agree in advance is who takes the call, out of hours, and on which number
The artefact
A named stop-and-report contact on each side, with the six-hour clock and the incident@cert-in.org.in route written into the engagement letter before anyone needs it
§15.2.2(i), §16.4 · 2018 guidelines, Technical · Directions of 28 April 2022, direction (ii) and Annexure I
The engagement letter itself
The agreed terms must be formally documented in an audit engagement letter, reviewed and signed by authorised representatives of both organisations, serving as a binding reference point throughout the engagement.
Who signs it
Authorised representatives of both organisations — the clause requires it of both, not of one
The artefact
The audit engagement letter, and thereafter the numbered addenda §14.2 requires for every scope change
§14.1(ii)
One organising point about those cards. Six of the ten gates are signed by an “authorised representative”, which §14.1(ii) names and does not define. Decide at scoping who that person is, get it into the engagement letter by name and designation, and record a deputy — because two of the gates are ones you may need signed within the hour, and the discovered-breach gate is one nobody can be asked to sign in advance at all.
A fourth item is not a gate but changes how the engagement feels, and it should be said at scoping rather than discovered at delivery. Your audit report and audit metadata go to CERT-In. §10.6 makes it mandatory for the auditing organisation to provide information about the audits it carries out to CERT-In within 5 days of completion of audit, in the format CERT-In prescribes, and states that the data submitted will be kept confidential. Clause 3.2.2 of the empanelment terms (version 7.2, April 2024) repeats the five days and adds critical vulnerabilities pointed out during the audit but not fixed by the auditee even during follow-up audits, reported with auditee details on the same clock. §13.2.1(iii) requires the auditor to inform you of that requirement before the assignment starts.
The full set of conduct rules, including data handling, tooling records and who may sign the report, is set out in what a CERT-In empanelled auditor may and may not do. This page covers the subset that has to be settled while the scope is still being written.
A scoping questionnaire you can actually use
What questions should a VAPT scoping call answer?
Nine blocks, in the order they need answering, because several of the later ones cannot be answered until the earlier ones have been. Take it into the scoping call and record the answers against the questions. The completed document is most of your scope of work, and §13.2.4(i) — which requires the expectation gap between what the auditee expects and what the audit professionals understand the engagement to entail to be reduced or eliminated by explaining the process, artefacts and deliverables at the outset — is largely satisfied by having gone through it together.
1. The inventory the scope will be cut from
§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 reach the report. Answer these before you answer anything else.
- Where does the consolidated asset inventory live, and who owns it?
- What date was it last updated, and what is the evidence of that date?
- Which sources were reconciled into it — DNS zones, certificate transparency, cloud accounts, the load balancer, the CMDB, the app store listings, the API gateway?
- Which assets are in the inventory but out of this engagement, and under what heading?
- Which assets exist that nobody has an owner for? (Answer honestly: this is the list the audit will otherwise discover for you.)
- Has the internal audit team, in consultation with the CISO, vetted the scope drawn from it (§13.1.1(d))?
2. The applications and their versions
§13.2.3(ii)(c) requires version-specific details of web and mobile applications in the audit scope and in the report.
- Exact name and version of each web application, with the build identifier.
- Exact name and version of each mobile application, per platform, plus the minimum version still supported in the field.
- Which repositories and pipelines produce those builds?
- Which applications are classified as critical, and by whom? (§13.1.3(iii) requires both DAST and SAST for critical applications.)
- Is static application security testing being done by the developer or system integrator, and is that obligation written into their contract rather than this one?
3. Environments and the build under test
§15.2.3(i) requires the environment to be specified, and §15.2.3(ii) requires website testing on the staging server or testing environment provided by the hosting service provider before the audit certificate is issued.
- Which environment is each asset tested in — Test, Development, UAT, Pre-Production or Production?
- Does a staging environment exist that matches production in build, configuration and data shape? If not, when will it?
- Who provides it — your team, or the hosting service provider?
- What is the hash value, hash algorithm, version number and timestamp of the build under test, and who captures them (§9.5(i))?
- What is the site URL and what is the test URL, stated separately?
- What is the code-freeze window, and what is the change-control path if a release cannot wait?
- Which environments are classified as critical, requiring passive technique under §15.2.2(iv)?
4. Interfaces: APIs, integrations and machine clients
§6 item xii covers web applications, mobile applications and APIs, and §13.2.3(i)(a) names API Security Audit as its own type of audit.
- Which APIs are in scope, by base URL and by version, including deprecated versions still answering?
- Is there a current OpenAPI, GraphQL schema or equivalent specification, and does it match what is deployed?
- Which endpoints are public, which are partner-only, which are internal-only, and what enforces the difference?
- Which webhooks does the system send and receive, and how are they authenticated?
- Which machine identities exist — API keys, OAuth clients, service accounts, CI tokens — and will test credentials be issued for them?
- What are the rate limits, and what happens to them during the test window? (Raise or exempt the auditor’s declared source IPs, not the whole application — a blanket relaxation is itself the kind of change §15.1.1(ii) tells you not to make during the test period, and the exemption is recorded as a limitation under §16.1(ii).)
5. Credentials and role coverage
§15.1.2 requires privileged access to be temporary and revoked immediately on completion. Everything else here is scope design.
- Which roles exist in the application, and which are in scope?
- Will two accounts be provided in the same role, so that horizontal access control can be tested at all?
- For a multi-tenant product, will two tenants be provided?
- Will administrative access be provided, and on what temporary credential, expiring when?
- Who revokes those credentials on completion, and by what date?
- Does the engagement include unauthenticated testing as well as authenticated, or only one?
- Are multi-factor authentication and device binding going to block the test accounts, and who unblocks them?
6. Infrastructure, cloud and hosting
§13.1.5 divides responsibility where the server belongs to somebody else. Settle this before it becomes a permission problem in week two.
- Who owns and operates the web server, its operating system, the web hosting software and the backend database software?
- If that is not you, has the hosting provider confirmed its own audit position in writing?
- Which cloud accounts, subscriptions or projects are in scope, and will read access be provided for configuration review (§6 item xviii)?
- Which databases are in scope, and is a database configuration audit included (§13.1.3)?
- Does any in-scope cloud workload require the provider’s own testing authorisation or notification under its acceptable-use terms, who is obtaining it, and by when?
- Is any OT or ICS in the estate (§6 item xix), and is passive-only technique agreed for it?
- What network ranges are in scope, internal and external?
7. Exclusions and constraints
§13.2.4(ii) requires exemptions, limitations and constraints to be communicated clearly, and §16.1(ii) requires them in the report.
- What is excluded, named as precisely as the inclusions?
- Why is each exclusion excluded, and who authorised it (§9.2)?
- What blackout windows apply — month-end, payroll, exam results, festival trading, a regulatory filing date?
- What is out of bounds by technique rather than by asset — no DoS, no flood testing, no social engineering against customers?
- What happens if an in-scope asset turns out to be inaccessible? (§10.1(ii) requires the auditor to inform you, request resolution, and if unresolved name it in the report with reasons and bring it to CERT-In’s notice.)
- Is anything excluded because a third party has not given permission, and is somebody chasing that permission?
8. Rules of engagement and communications
The written-approval gates are set out in full above. These are the answers each of them needs.
- Who on your side signs each approval, and what is their designation (§14.1(ii) requires authorised representatives)?
- What are the auditor’s source IP addresses, and who puts them on the allowlist and into the SOC runbook (§13.2.7(i))?
- Which people inside your organisation know the test is happening (§15.1.1 limits notification to key personnel)?
- What is the escalation matrix, on both sides (§13.2.6)?
- What is the stop-and-report threshold, and who takes that call out of hours?
- What is the report distribution list of official email IDs, and the mobile number for password delivery (§13.2.5)?
- Have you been told, before commencement, that the report and audit metadata go to CERT-In within five days of completion (§13.2.1(iii), §10.6)?
9. Deliverables, evidence and what happens afterwards
§16.1(i) requires the report format to be mutually agreed and finalised before commencement. Agreeing it afterwards means accepting whatever arrives.
- What is the agreed report format, and has it been finalised before commencement?
- Are working notes and the audit evidence appendix contracted for (§18(i))?
- What is the agreed timeframe for the auditor to respond to clarification requests on evidence (§18(v))?
- Is the follow-up audit inside the scope of work and the price (§13.1.1(g), §9.3(iv))?
- What are the closure timelines by severity, and who owns remediation (§16.3(iii), §9.3(iii))?
- What standards and frameworks will the audit be conducted against, named in the contract (§13.1.7, §8(ii))?
- What happens to your data at the end — retention period, deletion, and the certificate of deletion (§10.3(iv)–(vi))?
What does a VAPT scoping checklist cover?
Those nine blocks are the checklist. Blocks 1 to 3 settle what is being tested and in which state. Blocks 4 to 6 settle what it talks to and who can reach it. Blocks 7 to 9 settle what is deliberately left out, what may be done to the rest, and what arrives at the end. If you are working to a deadline and can only complete three of them, complete 1, 3 and 5 — inventory, environment and build, credentials and roles — because everything in the other six is recoverable later and those three are not.
Two habits make the difference between a questionnaire and a completed questionnaire. Record “we do not know” as an answer rather than leaving a blank — a recorded unknown gets an owner, a blank does not. And date the document, because §13.2.3(ii)(b) is going to ask you for that date again when the report is written.
Reopening a scope is a procedure, not a favour
Can a VAPT scope be changed once testing has started?
Yes, and §14 of the 2025 guidelines — titled “Agreeing on the Terms of Engagement and Revisions to the Scope” — says how. Revisions must be proposed in writing with a justification. Both parties must evaluate the impact on timelines, resource allocation and deliverables. The change must be approved by authorised representatives and documented as an addendum to the audit engagement letter or through formal amendment procedures. And the revised scope must be communicated to all relevant stakeholders. §14.3 then names the three criteria for a revision.
Discovery of previously unidentified systems or processes that present significant risk
The trigger the asset inventory exists to make rare: a system nobody listed, found by the people you hired to look. Where it happens mid-engagement, it is a scope revision rather than a favour and it follows the §14.2 procedure.
Changes in organisational structure, ownership, or regulatory environment
An acquisition, a divestment, a new regulator’s instrument, a change in who owns the application. Any of these can move an asset into or out of the estate the scope was cut from.
Security incidents or breaches occurring during the audit period
Note what else follows. Where the auditor deals with high-risk vulnerabilities such as discovered breaches, §15.2.2(i) requires them to be assessed and reported immediately to the auditee organisation and to CERT-In, and §16.4 requires immediate reporting to you with a recommended practical solution. Your own duty is separate and survives whatever the auditor does: the CERT-In Directions of 28 April 2022 require cyber incidents listed in Annexure I to be reported to CERT-In within 6 hours of noticing them or being brought to notice of them.
Alongside the formal revision procedure there is a lighter-weight duty that keeps the scope honest day to day. §13.2.7(iii) requires the auditing organisation to notify you of any changes to the audit plan, a change in the source test venue, identification of high-risk findings, or before conducting new, high-risk or high-traffic tests — and to tell you if any testing issues arise, with progress updates at reasonable intervals. Item 19 of Annexure I to the empanelment terms carries the same expectation in the auditee’s own voice. Agree the cadence of those updates at scoping. Weekly is usually right and it costs nothing to ask for.
Two escalation paths should exist before they are needed. §13.2.6 requires a well-defined escalation matrix on both sides for problems encountered during the audit process, and §13.1.7(iii) requires an escalation matrix to be defined as part of the audit contract for the case of repeated vulnerabilities. Different problems, different matrices. Both belong in the scoping pack rather than in an email thread.
Twelve ways a scope wastes an engagement
Why do VAPT reports so often turn out to be useless?
Because the scope was wrong and nothing downstream can correct it. Each entry below carries a tell — the thing you can observe in your own draft scope before the money is spent — because a named failure mode you cannot detect is not useful. They are ordered by how early each one is detectable, not by how often it happens: the first is visible in the scope document itself, the last only after delivery.
The scope was a price, not an estate
Somebody asked for a quotation for "a VAPT", received a number for five applications, and the number became the scope. §13.1.1(b) puts scope definition on the auditee in consultation with the auditor, in that order.
The tell: The scope document carries no as-of date and there is no asset inventory behind it. Ask which export the asset list came from. If the answer is a person rather than a system, this is the failure.
Where it surfaces
Kickoff, if anyone asks. Otherwise the draft report.
What it costs by then
A second procurement for the estate the first one missed.
The fix: Build the inventory first, then cut the scope from it, then price the scope. If the budget will not cover the estate, exclude deliberately and record the exclusion — which is a defensible position — rather than excluding by omission, which is not.
The scope was inherited
The annexure was reused from last year, or lifted from another department’s tender. It describes an estate that existed once. §13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory, which a reused annexure by definition is not.
The tell: The asset names do not reconcile against today’s DNS zone export and cloud inventory. Two or three rows name systems that have been decommissioned, and the systems built in the last year are absent.
Where it surfaces
Kickoff, in the first reconciliation — or never, if nobody reconciles.
What it costs by then
A report that certifies last year’s estate, and a §14.2 addendum mid-engagement if you are lucky enough to notice.
The fix: Reconcile the inherited annexure against fresh exports before it is signed, and date the result. An inherited scope is a starting point for a reconciliation, never an output of one.
Nobody with authority signed it
The scope was agreed between two engineering leads and a purchase order was raised against it. §14.1(ii) requires the agreed terms to be documented in an audit engagement letter reviewed and signed by authorised representatives of both organisations, and §13.1.1(d) requires the scope itself to be vetted by internal audit in consultation with the CISO.
The tell: The signature block on the scope names nobody, or names somebody whose designation does not appear in the delegation of authority. There is a purchase order and no engagement letter.
Where it surfaces
At the first scope change, when §14.2 has no baseline to amend.
What it costs by then
Every subsequent change is renegotiated from nothing, and the exclusions have no authoriser under §9.2 — which means they are not risk acceptances, they are gaps.
The fix: Name the authorised representative on both sides before the scope is signed, and make the engagement letter the instrument rather than the purchase order.
The API was assumed to be inside the web application
The browser client was tested, but the API was reached only through it. Endpoints the client never calls, older API versions still deployed, and the authorisation model as the API enforces it were all outside what was actually exercised.
The tell: The scope names hostnames and no base paths, and no API version appears anywhere in it. Ask the auditor which API versions are in scope. If the answer is "whatever the app uses", this is the failure.
Where it surfaces
Draft report — the findings are all client-side.
What it costs by then
A second engagement and a second procurement, on a surface that was always in the estate.
The fix: Name the API as a separate asset with its own base URLs and versions. §13.2.3(i)(a) already treats an API security audit as its own type.
Only one account was issued
One standard user account means the engagement can test vertical privilege escalation by guesswork and horizontal access control not at all. The report comes back short and reads as a good result.
The tell: The credential request lists one username per role. For a multi-tenant product, one tenant.
Where it surfaces
Credential handover, three days before the window — which is also the last cheap moment to fix it.
What it costs by then
The authenticated half of an engagement you have already paid for.
The fix: Issue two accounts per in-scope role, and two tenants where the product is multi-tenant. This costs nothing and changes what the engagement can find.
The accounts arrived in week two
The roles were scoped correctly and the credentials were issued on day eight of a ten-day window. The authenticated testing that the whole role matrix was designed for got two days.
The tell: The credential request has no date on it. Nobody owns issuance, and the plan treats it as an administrative step rather than as a milestone.
Where it surfaces
The draft report, as a thin authenticated findings section beside a thorough unauthenticated one.
What it costs by then
The same as issuing one account, arrived at more expensively.
The fix: Make credential issue a dated milestone that closes before the test window opens, and set the §15.1.2 revocation date at the same time so both ends of the credential’s life are on one record.
The exclusions were verbal
Everyone in the kickoff call agreed that the legacy system was out of scope. Nothing was written. The report does not mention it, the reviewing authority reads the report as covering the estate, and nobody can now say when the decision was taken or who took it.
The tell: The scope has an inclusions list and no exclusions list. Ask for the exclusion register. If the answer is an email thread, it is verbal.
Where it surfaces
When somebody outside the project reads the report — a customer, a regulator, an acquirer.
What it costs by then
Not recoverable by re-reading anything. Either the asset is tested late, or the report is represented as covering more than it does.
The fix: Write every exclusion down with the four fields above. §13.2.4(ii) and §16.1(ii) both expect exemptions, limitations and constraints to be stated, and a verbal exclusion satisfies neither.
The permission did not belong to you
An asset was scoped in that a third party owns and operates — a hosted payment component, a managed database, a partner-run portal. Testing it would require their authorisation, which nobody obtained, so it was quietly skipped.
The tell: The scope includes a hostname on somebody else’s domain, or a service whose operator you would have to email to reboot. No consent document exists for it.
Where it surfaces
First test pass, when the auditor stops at the boundary.
What it costs by then
A §14.2 variation order, or a silent gap that §10.1(ii) should have turned into a reported one.
The fix: §13.1.5 puts the server, OS, hosting software and backend database with whoever owns and operates them. Either obtain written permission at scoping or exclude the asset explicitly and obtain the owner’s own audit position instead.
The cloud provider’s authorisation was never sought
The account owner authorised the test, which is the §13.1.5 question, and nobody read the platform’s own terms on testing customer workloads. The test pauses mid-window while somebody works out who submits what.
The tell: The scoping pack answers who owns the account and says nothing about the provider’s terms. No owner and no date are recorded against obtaining them.
Where it surfaces
Mid-window, at the first test the platform notices.
What it costs by then
Days lost inside a fixed window, which come out of testing rather than out of the calendar.
The fix: Add it to the scoping questionnaire as an auditee task with an owner and a lead time. The prohibited classes usually match what §15.2.2(ii) already gates, so the scope is often compliant already — the failure is procedural, not technical.
The staging build was not the production build
Testing happened on staging, as §15.2.3(ii) requires, and then production shipped a different build. The certificate names a hash that no longer corresponds to anything running. A certificate published by the Indian Institute of Corporate Affairs states the condition plainly in its own conclusion: the build of the site URL and the test URL need to be identical.
The tell: No code freeze is recorded against the test window, and no hash was captured at the start of testing. The release calendar runs through the window untouched.
Where it surfaces
Hosting gate, or the first time anyone compares the deployed hash against the certificate.
What it costs by then
A delta re-audit if a change record exists for what moved, a full re-audit if one does not.
The fix: Fix the build at the start of testing, capture the hash and version, agree a code freeze and a change-control path, and run the production follow-up audit §16.3(v) requires before the final report issues.
Retesting was not in the scope of work
Findings were remediated and there was no budget, no contract line and no auditor availability to verify closure. §16.3(v) requires the final report to issue after closure of vulnerabilities and completion of the follow-up audit on production, so the engagement cannot finish.
The tell: The auditor quotes for the retest. That quote is the tell, and it should have been inside the original price.
Where it surfaces
Retest, which is the worst moment to discover it.
What it costs by then
A variation order, a finance approval cycle, and a quarter of slip on whatever date depended on the certificate.
The fix: §13.1.1(g) and §9.3(iv) both put follow-up audits inside the scope. Price the revalidation phase from the start and diarise it against your remediation plan.
The scope never changed, but the estate did
A new system went live during the engagement, or an acquisition arrived, or a breach occurred mid-test. The scope document was three weeks old and nobody reopened it.
The tell: Nothing in the engagement has a review point. The scope was signed and then not looked at again.
Where it surfaces
After delivery, when somebody asks whether the new system was covered.
What it costs by then
A delta engagement, or an untested system carrying the reputation of a tested one.
The fix: §14.3 names the three criteria for revising scope, and §14.2 sets the procedure. Both are below. The mechanism exists precisely so that the answer is not "we will catch it next year".
Two of those have a reading consequence rather than a scoping one, and they are worth carrying into the report review: reading a VAPT report starts with the scope and environment statement rather than with the findings, and retesting and closure is where the follow-up audit §16.3(v) requires actually gets done.
Scoping for safe-to-host is a narrower problem
How is a VAPT scoped when a safe-to-host certificate is the deliverable?
Where the engagement ends in a certificate somebody else will rely on, the scope has a second audience. GIGW 3.0 guideline 5.3.1 requires that the website, web application, web portal or mobile app has been security audited and an audit clearance certificate issued by NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory before hosting in the production environment. The evaluator’s own action under that guideline is to check that the application has a valid security audit certificate issued by one of those bodies, fulfilling CERT-In requirements.
Three scoping consequences follow, and they are the ones teams learn the hard way.
- The application under test has to be the application the certificate will name. That means one build, one hash, one version, one pair of URLs, and a change-control regime that holds between testing and issue. §9.5(i) captures the artefacts, and §13.1.2(iii) requires a Major Change to be audited before implementation, not after.
- The staging environment is a prerequisite, not a preference. §15.2.3(ii) requires testing on the staging server or testing environment provided by the hosting service provider before the audit certificate issues, so the hosting provider is a party to your schedule whether or not they are a party to your contract.
- The certificate is the auditor’s to sign, and the audit is the empanelled organisation’s to perform. §9.5(iii) requires the audit report to be signed by the auditors who conducted the audit, reviewed and signed by a designated reviewer who is not part of the audit team and is from mid-management, and finally authorised and signed by the head of the auditing organisation — with the audit certificate signed by both the Lead Auditor and the Head of the Auditing Organization. Only manpower declared to CERT-In may sign (§9.5(iii), restated at §10.3(ix) and §16.1(vi)), and only declared manpower may be deployed on the audit at all, which is the separate rule at §10.2(vi).
The certificate route has its own pages: what a safe-to-host certificate is, how to get one, why applications fail and how to verify a certificate you have been handed. For who CERT-In is and how empanelment works at all, see what CERT-In is and CERT-In empanelment explained.
Who scopes it, and who signs it
Who scopes a VAPT, and who signs the report?
Scoping and signing are two different jobs, and they sit with two different parties. The audit report and any safe-to-host certificate are signed and issued by the CERT-In empanelled organisation on the engagement, using the manpower it has declared to CERT-In.
Scoping is the part of the engagement the guidelines put squarely on the auditee, for the reasons set out at why scope is the whole decision — §9.6(i), which reserves the whole process to the owner of the infrastructure and then permits external support for specialised expertise.
What that split means in a contract is worth saying plainly, because it is where the arrangement is easy to get wrong. The audit assignment itself cannot be passed on: §10.5(vii) tells empanelled organisations not to engage in sub-letting or outsourcing of audit assignments. So the engagement letter §14.1(ii) requires is between you and the empanelled organisation.
§5(xvii) defines conflict of interest to include the same entity implementing controls and auditing them, or auditing while also being responsible for remediation, and §7 rules out fees contingent on the outcome of the audit or tied to the approval of closure reports. The party that helps you remediate should not be the party attesting that the remediation worked.
Sentences you will hear in a scoping call, and the move
What do you say when a vendor pushes back on scope?
The rule behind each of these is stated in full further up the page and again in the questions at the end, so none of it is re-argued here. What follows is the move: the reply, the thing to ask for in writing, what goes in the minutes, and what to do if the answer is still no. Most of these sentences are said in good faith by somebody on your own side.
“We will just scope the public-facing site — that is where the risk is.”
Say: “Agreed that it is the priority. It is not the estate, so let us record the rest as exclusions rather than pretend they are not there.”
Ask for, in writing
The exclusion register, with the four fields filled for every system not being tested — what, why, who authorised it and when, and how it is covered instead.
Minute
That the narrowing is a budget exclusion, not a description of the estate, and that internal audit and the CISO vetted the scope on that basis (§13.1.1(d)).
If the answer is no
Escalate it as a risk acceptance rather than as a scoping disagreement. §9.2 puts exceptions with the head of the organisation, so the decision has an owner whether or not anyone writes it down — and you would rather they wrote it down.
“Can you test production? Staging is not ready.”
Say: “Then the date moves, not the environment. Staging is a prerequisite for the certificate, so testing production first does not save the schedule, it just spends it twice.”
Ask for, in writing
A date from the hosting service provider for staging handover, and a parity statement listing the differences between staging and production, using the checklist below.
Minute
The staging handover date, who owns it, and every known parity difference — so they read as limitations under §16.1(ii) rather than as findings.
If the answer is no
If staging genuinely cannot exist, the engagement is a production engagement and the report says so. What you must not accept is a staging-shaped certificate for a production-only test, or the reverse.
“We do not want to give the testers admin access — it is too risky.”
Say: “Understood. The alternative is not permanent access, it is two named accounts that expire on a date we set. If we still say no, the privileged surface goes untested and the report has to say so.”
Ask for, in writing
Two named, individually attributable administrative accounts, issued against a tenant with real data in it, with an expiry date and a named revocation owner recorded at issue.
Minute
The issue date, the expiry date, the revocation owner and the tenant each account operates on. If access is refused, minute the refusal and the consequence in the same line.
If the answer is no
Write it as a technique exclusion with an authoriser, and tell the auditor to state the untested privileged surface as a limitation. An untested admin console is a known gap. An admin console tested against an empty sandbox is a false clean result, which is worse.
“The API is the same as the website, so testing the website covers it.”
Say: “The website exercises the endpoints the client calls, in the order it calls them. Everything else on the API is untested — including the versions we have not retired.”
Ask for, in writing
The API base paths and versions in writing, including deprecated versions still answering, plus the current specification if one exists and a statement of whether it matches what is deployed.
Minute
Each API version named as its own scope line, with the type of audit recorded as an API security audit in its own right.
If the answer is no
Ask for the deprecated versions to be turned off instead. If an API version is not worth testing it is not worth serving, and that is a cheaper conversation than the second engagement.
“Include a DDoS test so we know the site holds up.”
Say: “Not in this engagement. Resilience testing is a separate, scheduled, separately authorised exercise — and a proposal that offers it as a routine line item has not read the instrument it is bound by.”
Ask for, in writing
That the technique exclusion is written into the scope explicitly, covering denial of service, distributed denial of service and any form of flood testing, against every in-scope asset.
Minute
The exclusion, and the separate decision about whether resilience testing happens at all, on what date, under whose written permission.
If the answer is no
If somebody genuinely wants it, it needs explicit written permission from the head of the organisation, its own window, and the hosting and cloud providers notified. That is a project, not a line item.
“Let us get the test done now and sort the asset list out afterwards.”
Say: “The inventory is not paperwork that follows the test. It is the thing the scope is cut from. Two or three days now, or a report whose coverage nobody can state afterwards — including us.”
Ask for, in writing
The reconciled inventory with an as-of date, from at least three sources: DNS zones, cloud account exports and the app-store or API-gateway listings.
Minute
The as-of date. §13.2.3(ii)(b) will ask for it again when the report is written, and the report has to carry it.
If the answer is no
Start the inventory in parallel with the engagement and treat everything it surfaces as a §14.3(i) revision trigger. It is the expensive way round, but it is a great deal better than discovering the estate at the next audit.
“Retesting can be a separate purchase order later.”
Say: “It can, but the engagement does not conclude without it, so we are choosing between buying it now and buying it later at whatever the auditor’s calendar costs in month four.”
Ask for, in writing
The revalidation phase priced as a named line in the same scope of work, with its man-hours stated separately (§13.2.2(ii)).
Minute
That follow-up audits are inside the scope of work and inside the price, and the indicative window they are expected to fall in.
If the answer is no
Get the auditor’s availability commitment in writing even if the money comes later, and diarise the retest against the remediation plan rather than against the finance calendar.
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.
For the testing itself, see penetration testing and VAPT. For the assurance programmes these engagements usually sit inside, see ISO 27001 and the DPDP Act.
Frequently Asked Questions
What is VAPT scoping?
What should be included in a VAPT scope of work?
Should a VAPT be done on staging or production?
What is the difference between credentialed and uncredentialed VAPT?
How many test accounts should we give the testers?
Do we need to include our APIs in the VAPT scope separately?
Is the mobile back-end included when we scope a mobile app VAPT?
Why do VAPT exclusions have to be written down?
What happens if an in-scope asset cannot be tested?
Can a VAPT include a DDoS or load test?
Can the auditor phish our staff as part of a VAPT?
Who owns the scope — us or the vendor?
How long should a VAPT take, and how do we compare quotes?
Does retesting need to be in the original scope?
How often does a VAPT have to be repeated?
Do the CERT-In Directions of 2022 have to be in the audit scope?
How much does a VAPT cost in India, and what drives the price?
What does a VAPT scope of work look like?
We have more applications than budget. How do we scope a defensible subset?
Who signs the VAPT scope on our side?
Do we need the cloud provider’s permission to test our own workloads?
What is the difference between a VAPT scope and an audit engagement letter?
The instruments behind every clause
Every rule on this page is drawn from one of the following, each published by the Government of India except where another publisher is named, and linked here so you can read the clause rather than our paraphrase. Section numbers in the form §13.1.1(c) refer to the Comprehensive Cyber Security Audit Policy Guidelines unless another document is named.
Every §-locator on this page was checked against the instruments named below on 22 September 2026. Every link was checked on the same date for HTTP status, content type and byte size rather than status alone, because cert-in.org.in answers an unknown path under /PDF/ with a 200 and a small HTML page — so a status code on its own proves nothing about whether the document is there. The 2025 guidelines are version 1.0 and will be superseded. Where an instrument is revised, this block is where it will change first. One document the guidelines name is deliberately absent because it cannot be retrieved: “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.
- Comprehensive Cyber Security Audit Policy Guidelines · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 1.0, 25 July 2025 · 69 pages, 20 sections · §6, §8, §9.2, §9.3, §9.5, §9.6, §10.1, §10.3, §10.6, §13.1, §13.2, §14, §15.1, §15.2, §16.1, §16.3, §18
- Guidelines for CERT-In Empanelled Information Security Auditing Organizations · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 3.0, May 2018 · 6 pages · the Technical heading, for the staging-environment rule, the DDoS and flood-testing prohibitions, written approvals before penetration tests and tool installation, and removal of tools afterwards
- Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 7.2, April 2024 · 10 pages · Annexure I, “Expectations of an Auditee organisation from an Auditor”, items 6, 10, 12, 14, 15, 17 and 18 · Annexure II, audit report content format
- Policy Guidelines for Handling Audit related Data · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 1.0, June 2014 · 5 pages · §5.1 handling, storage, access, retention and destruction · §5.2 disclosure and sharing
- 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 · direction (ii), the six-hour reporting duty, and Annexure I, the twenty mandatorily reportable incident types
- 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 2025 guidelines
- Empanelled Information Security Auditing Organisations by CERT-In — the snapshot information · Indian Computer Emergency Response Team (CERT-In), MeitY · the list §10.2(vi), §12.1(i) and §12.3(iii) refer to · 997 pages at the time of checking
- Guidelines for Indian Government Websites and Apps (GIGW 3.0) — the manual · National Informatics Centre with STQC and CERT-In, MeitY · linked from guidelines.india.gov.in as “Download GIGW Manual 3.0” · statement 5.3.1 at page 80 and its evaluator action at page 84, which names four issuing bodies — NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory — and requires the certificate to be valid
- GIGW 3.0 — security guidelines and attributes (the live page) · National Informatics Centre with STQC and CERT-In, MeitY · guideline 5.3.1, the audit clearance certificate required before hosting in the production environment · carried separately because its evaluator action names three issuing bodies and “the website” where the manual names four and “the website/ web application/ web portal/ mobile app under evaluation”. Both read 22 September 2026, and the statement of 5.3.1 is identical on each.
- OWASP Application Security Verification Standard (ASVS) · Open Worldwide Application Security Project · project page, which names 5.0.0 as the latest stable version · ASVS is named at §8(ii) of the 2025 guidelines, which does not name a verification level
- OWASP ASVS 5.0.0 — the tagged release · Open Worldwide Application Security Project · the versioned artefact behind every ASVS claim on this page: the level definitions in “What is the ASVS?” (including that Level 1 is not necessarily penetration testable by an external tester without internal access to documentation or code), and “Changes Compared to v4.x”, which records that of the 286 requirements in 4.0.3 only 11 remain unchanged
- OWASP Mobile Application Security (MAS) — MASVS and MASTG · Open Worldwide Application Security Project · §8(ii) of the 2025 guidelines names “the OWASP Mobile Security Testing Guide (MSTG) for mobile app audits”. OWASP now publishes that material under the Mobile Application Security project as the MASVS, the MASTG and the MASWE. The control groups relied on for the mobile scoping advice on this page — MASVS-STORAGE, -CRYPTO, -AUTH, -NETWORK, -PLATFORM, -CODE, -RESILIENCE and -PRIVACY — were read from the MASVS page on 22 September 2026. The page states no version number on its face, so none is asserted here.
- Web Security Audit Certificate — Indian Institute of Corporate Affairs, Ministry of Corporate Affairs · Published on iica.nic.in · issue date 11 July 2024 · cited on this page for its hash field and for the conclusion that the build of the site URL and the test URL need to be identical
- Safe to Host Certificate — CSIR Human Resource Development Group · Published on csirhrdg.res.in · dated 17 May 2025 · cited on this page for its hash value and named hash algorithm, application version and audit methodology fields
Related reading: what VAPT is, VAPT versus penetration testing versus red teaming, the types of VAPT, reading a VAPT report, retesting and closure, what a CERT-In empanelled auditor may and may not do, the CERT-In Directions of 2022, the safe-to-host certificate, why applications fail safe-to-host, and penetration testing and SOC 2.
Related Reading
What VAPT Actually Is
Vulnerability assessment and penetration testing are two activities. Why India bundles them, and what a real one covers.
Read moreThe Types of VAPT
Web, network, mobile, API, cloud configuration and wireless — what each can and cannot find.
Read moreAPI Security Testing
The surface behind every mobile app and single-page frontend, and why testing the UI misses it.
Read moreRules of Engagement for an Empanelled Auditor
What the auditor must do, must not do, and needs your written permission for.
Read moreHow to Read a VAPT Report
Scope, severity, evidence and the parts that reveal a weak test.
Read moreRetesting and Closure
Severity-based closure timelines, what counts as evidence of a fix, and the traps in partial closure.
Read more