VAPT, Penetration Testing and Red Teaming Are Not the Same Engagement
Four activities get quoted against each other in India as though they were sizes of the same thing: a scan, a vulnerability assessment, a penetration test, and a red team engagement. They differ in objective, in how the scope is set, in how much the tester is told, in who knows the test is happening, in how long they run, and in what the deliverable proves. Buying the wrong one is not a pricing mistake. It is an assurance mistake that surfaces later, usually in front of somebody who matters.
Where the definitions come from: CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) list twenty-six classes of engagement at §6 and define three of these four separately — vulnerability assessments at (iii), penetration testing at (iv), and red team assessment at (xvi). The fourth, scanning, is not a class of engagement at all.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · Auditor Guidelines v3.0 (May 2018) · Empanelment terms v7.2 (April 2024) · Every clause locator checked 22 September 2026
What is VAPT, and how is it different from red teaming?
What is the difference between VAPT and penetration testing?
Penetration testing is not an alternative to VAPT. It is the second half of it. VAPT stands for Vulnerability Assessment and Penetration Testing, so a quote labelled “VAPT” and a quote labelled “penetration test” do not differ by depth of testing — they differ by whether a systematic assessment of the estate is bundled in. Almost everybody arriving at this comparison is holding two proposals and trying to work out which one is bigger, and that is the wrong axis. The question that settles it is which of §6(iii) and §6(iv) each proposal actually covers, across which assets. Get that answer in writing and the two documents become comparable. Leave it and you are comparing a bundle against one of its own halves.
VAPT stands for Vulnerability Assessment and Penetration Testing. It is an umbrella term for two distinct activities usually sold as one engagement: an assessment, which examines a defined estate to find and rank security deficiencies, and a penetration test, which actively tries to exploit what it finds in order to establish what an attacker could actually reach. A red team assessment is a third thing entirely — a simulated adversary pursuing an objective against your live organisation, measured by whether your people detected it and what they did next. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) treat them as three separate classes of engagement, at §6(iii), §6(iv) and §6(xvi) respectively.
The cleanest way to hold the difference is by the question each one answers. A vulnerability assessment answers what is wrong here, and how much of it is there. A penetration test answers what is actually exploitable here, and what does exploiting it reach. A red team assessment answers would we detect this, and would we respond well enough to stop it. A vulnerability scan answers none of those. It answers what a tool recognised. Four questions, four engagements, four prices — and a quote that says only “VAPT” has not yet told you which of them you are buying.
Key Takeaways
- Penetration testing is the PT inside VAPT, not an alternative to it. Two quotes labelled "VAPT" and "penetration test" differ by whether a systematic assessment of the estate is included, not by how deep the testing goes.
- VAPT is a category, not a specification. §13.2.3(i)(a) lists it as one of nine named audit types alongside EAPT, device level audit, configuration audit, process audit, mobile, web, API and compliance audits — and ends the list with "etc.".
- A vulnerability assessment aims at completeness, while a penetration test aims at proof. §6(iii) defines the first as examination to identify security deficiencies and confirm the adequacy of measures, and §6(iv) defines the second as active testing to identify and exploit, and to determine whether exploitation compromises the application, accesses sensitive data or affects the underlying infrastructure.
- A red team assessment is a separate class at §6(xvi) — an exercise reflecting real-world conditions, conducted as a simulated attempt by an adversary — and it measures your defence rather than your attack surface. It is not a bigger penetration test.
- CERT-In uses "Red Team" in a second, unrelated sense. The 2018 auditor guidelines require an auditing organisation to deploy a verification team (Red Team) to verify the work performed by its audit team (White Team). That is internal quality control on the auditor, not an engagement you buy.
- Who knows is an axis, not a detail. §15.1.1(i) limits notification of the test to key personnel — policy-making level, and managers responsible for security processes, incident response and security operations. Tell the SOC and you have stopped measuring the SOC.
- Scanning is a technique, not an engagement. §8(i) says solely tools-based testing should be discouraged, because it may overlook the non-automated and manual components and produce an incomplete view of the overall security.
- The fastest way to read a quote honestly is the test plan. §13.2.2(ii) requires it to state both calendar time and man-hours, which is what makes two bids comparable at all.
- Almost every rule on this page binds CERT-In empanelled auditing organisations. If your tester is not empanelled, none of it reaches them by default — and the remedy is to import the clauses into your engagement letter.
VAPT against a pentest is a bundle against half of itself
Because the acronym contains the thing it is being compared with, the label difference never tells you about depth. It does tell you something — but you have to know which of three things it is signalling, and only the scope annexure settles which.
One: the VAPT bundles breadth the pentest does not
The VAPT covers an asset inventory and the penetration test covers one application. This is the honest version of the difference, and the one worth paying for when you do not yet know the size of the estate. You can see it in the scope annexure: a list of assets on one side, a hostname and an API base path on the other. §13.1.1 expects the scope to be derived from the consolidated and updated asset inventory, so the broader document should also be able to tell you what its inventory was as at which date — §13.2.3(ii)(b) requires that date in the report.
Two: the pentest goes deeper on a narrower target
The penetration test is priced for authenticated testing at every role, business-logic work and chaining, against one application. The VAPT spreads the same money across forty hosts. Both are legitimate purchases and they answer different questions. The tell is the role count and the man-hours, not the word: a proposal that prices identically whether you have one application role or six is not testing roles, whichever label it carries.
Three: the two words are being used interchangeably
This is the common case, and it is not necessarily dishonest — the Indian market uses “VAPT” as the default name for security testing of any shape. It does mean the label carries no information at all, and that every question worth asking has to be asked of the scope instead. Ask which §6 class or classes the engagement falls into and which asset each one covers, and the answer arrives immediately or not at all.
None of this is an argument for the bigger document. It is an argument for making the seller name the class. §6 lists twenty-six of them and §13.2.3(i)(a) requires the type of audit to be communicated to the auditee before commencement — so a bidder who cannot say which class they are offering is failing a requirement, not being asked an unusual question.
Four activities, three of them defined
What is a vulnerability assessment, a penetration test and a red team assessment?
§6 of the 2025 audit policy guidelines lists twenty-six classes of cyber security audit and assessment, introduced with the phrase “including, but not limited to”, so the list is a floor rather than a boundary. Three of the four activities below appear in it with a definition attached. The fourth appears nowhere, and that absence is itself the finding.
Vulnerability scanning
A tool runs against a target and reports what it recognises.
The question it answers
What do the signatures match?
Not defined, and not named. It is not one of the twenty-six classes of engagement §6 lists, and a full-text search of the 2025 audit policy guidelines returns no occurrence of “scan”, “scanning” or “scanner” anywhere in the document. What the guidelines say instead is §8(i), and this page quotes it once, here, because four later sections rely on it: “Solely tools-based testing should be discouraged as tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure. This limitation can result in an incomplete view of the overall security.”
What you receive: A tool report, ranked by the tool.
Vulnerability assessment
A systematic examination of a defined estate to find and rank security deficiencies, tooling used but not trusted.
The question it answers
What is wrong here, and how much of it is there?
§5(xxi) and §6(iii): “Examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation.”
What you receive: A findings register with severity, evidence and remediation advice.
Penetration testing
Active testing of components or the whole application to identify and exploit vulnerabilities, and to see what the exploitation reaches.
The question it answers
What is actually exploitable here, and what does exploiting it get you?
§5(xxii) and §6(iv): “A security testing methodology in which individual components or the application as a whole are actively tested to identify and exploit potential vulnerabilities. The objective is to determine whether these vulnerabilities can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment.”
What you receive: Proven attack paths with reproduction steps, impact and business risk.
Red team assessment
A simulated adversary pursues an objective against the live organisation under real-world conditions.
The question it answers
Would we detect this, and would we respond well enough to stop it?
§5(xxiii) and §6(xvi): “An exercise, reflecting real-world conditions, that is conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems.”
What you receive: A narrative of the operation against a detection and response timeline, and the gaps that let it run.
Two of those definitions repay a second reading. §6(iii) ends with confirm the adequacy of such measures after implementation — the assessment has a closure role built into its own definition, which is why a retest is not an extra. And §6(iv) does not stop at “exploit”: its stated objective is to determine whether the vulnerabilities can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment. A penetration test that proves an injection point exists and never asks what the injection point reaches has completed half of its own definition.
A drafting detail worth knowing if you are quoting these in a scope of work: all three definitions appear twice in the same document. §5, the definitions section, carries them at (xxi), (xxii) and (xxiii), word for word identical to §6(iii), (iv) and (xvi). Either locator is correct. This page cites the §6 numbers throughout, because §6 is also where the class list lives and a scope of work is naming a class rather than reciting a definition.
Nine axes, and the differences that cost money
Vulnerability assessment vs penetration testing vs red teaming, compared
Most comparison tables on this subject vary one axis — depth — and present the four as a ladder. They are not a ladder. They differ on at least nine axes, and on three of them (knowledge of the target, who is told, and what counts as success) the differences run in opposite directions rather than in degrees.
| Axis | Vulnerability scanning | Vulnerability assessment | Penetration testing | Red team assessment |
|---|---|---|---|---|
| Objective | Coverage. Enumerate known conditions across as many hosts as possible. | Completeness. Know the security deficiencies across a defined estate and rank them. | Proof. Establish which weaknesses are exploitable and what exploitation reaches. | Effect. Reach a defined objective and learn whether the organisation noticed. |
| Scope, and who sets it | An address range or a URL. Set by whoever runs the tool. | An asset list. §13.1.1 requires the scope to be derived from the consolidated and updated asset inventory, and vetted by internal audit in consultation with the CISO. | An asset list plus a rules-of-engagement document. §17(i) requires written rules of engagement from auditee management. | An objective and a set of boundaries — not an asset list. The scope says what is off limits and what counts as success. |
| Knowledge of the target | Whatever the tool can reach unauthenticated. | Full. Credentials, architecture diagrams, configuration and, where in scope, source. §13.1.4(ii) requires the auditee to assign a technical team as point of contact to assist and monitor the auditing organisation. | Agreed per engagement, and it changes the finding set. Authenticated testing at every role is where authorisation defects live, and unauthenticated-only testing cannot see them. | Deliberately limited at the start. The operator works from what an outsider could discover, and the value of the exercise depends on not being handed the map. |
| Who is told it is happening | Everyone, usually. It is a scheduled job. | Everyone who has to provide access, credentials and environments. | The teams providing access, plus change management. §15.1.2 requires temporary privileged access to be revoked immediately on completion. | §15.1.1(i) is the clause: notification of the test is limited to key personnel — generally expected to include personnel at the policy-making level, as well as managers responsible for security processes, incident response, and security operations. If the SOC knows, you are not measuring the SOC. |
| How long it runs | Hours. It is bounded by the estate and the tool. | Bounded by the asset count and the depth agreed. Read the man-hours, not the calendar. | Bounded by the attack surface and the roles to be tested. A four-role application is not a one-role application with three extra logins. | Bounded by the objective, not by the estate. §15.1.1(ii) also constrains the auditee: no unusual or major network changes during the period, because a changed environment invalidates the result. |
| What counts as success | The scan completed and the report generated. | Every in-scope asset examined, every finding evidenced, nothing silently omitted. | The exploitable path is demonstrated and reproducible, and its blast radius is established. | The objective is reached — or the defence stops the operation, which is the better outcome and the one nobody budgets for. |
| What the deliverable proves | That a tool ran. Nothing about the findings has been confirmed by a person. | That the estate was examined against a stated method and these are the deficiencies as at a stated date. | That these specific paths work, against this build, in this environment. §10.1(i) limits the auditor to reviewing and reporting on the state of security at the point in time of the audit. | That the detection and response capability performed this way against this adversary behaviour on these dates. |
| What it cannot tell you | Whether any of it is exploitable, whether any of it matters, or what it missed. | Whether a finding is reachable in practice, or what an attacker would chain together. | Whether anyone would have noticed. A pentest is normally announced, and an announced test measures the surface, not the defence. | Whether the estate is clean. A red team that reaches its objective through one route says nothing about the assets it never touched. |
| Named in the instruments as | Nothing. The word does not appear in the 2025 guidelines at all. It is a technique inside an engagement, not an engagement. | §6(iii) Vulnerability Assessments, restated verbatim in the definitions at §5(xxi). In §13.2.3(i)(a) it is the VA half of “VAPT”. | §6(iv) Penetration Testing, restated verbatim at §5(xxii). §13.2.3(i)(a) additionally names EAPT — External Attack Penetration Testing — as its own audit type, and expands the acronym without defining it. | §6(xvi) Red Team Assessment, restated verbatim at §5(xxiii) — a separate class from (iii) and (iv), not a bigger version of either. |
The row that decides the most arguments is “knowledge of the target”. In an assessment you hand the tester everything, because withholding information only buys you a worse map of your own estate. In a red team you withhold deliberately, because an operator handed the architecture diagram is no longer simulating anything. Both positions are correct for their own engagement and wrong for the other, which is why a single scope of work cannot govern both.
Start from what is driving it, not from the menu
Which one do you need?
Nobody wakes up wanting a §6(iv) engagement. Something arrives — a questionnaire, a hosting gate, an audit, a board question, an incident — and the engagement is the answer to it. Find the row that describes why you are here. The fourth column matters as much as the second, because buying the wrong one is rarely a failure to buy. It is buying the adjacent thing.
| What is driving the request | What to buy | Why that one | What not to buy instead |
|---|---|---|---|
| An enterprise customer’s security questionnaire asks for a “penetration test report” | §6(iv) penetration testing of the named application and its API tier, at every authenticated role, with the scope annexure naming the product the customer buys. | The customer is asking for evidence that somebody tried, not for an inventory. The scope annexure is the part they will actually read. | An unauthenticated external sweep of your IP range. It will be delivered on time, and the first reviewer who opens the findings will see that no result required a login. |
| SOC 2 or ISO 27001 evidence | §6(iii) plus §6(iv) on the systems in the assurance scope, on a cadence you can show, with the retest and closure evidence retained. | The auditor is testing whether you run a process, not whether one report exists. Dates, scope stability and closure matter more than depth in any single cycle. | A one-off deep engagement with no retest. It proves a moment and leaves the period unevidenced. |
| A government hosting provider, or a safe-to-host clearance | Application-level testing by a CERT-In empanelled organisation against the build that will ship, on the staging environment the hosting provider supplies, under §15.2.3(ii), with §6(iii) and §6(iv) both named in the scope. | GIGW 5.3.1 requires an audit clearance certificate issued by NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory before hosting in production. Who signs is part of the requirement. | Testing by a firm that is not on the published list. The work may be excellent and the certificate will not be the one the gate asks for. |
| The board asked whether the organisation would detect a breach | §6(xvi) red team assessment, with an objective, a trusted-agent list under §15.1.1(i), and the four intervals defined before it starts. | That is a question about your people and your runbooks. No amount of §6(iv) depth answers it, because a penetration test is announced. | A larger penetration test. It will produce more findings and still say nothing about detection. |
| The first security test the organisation has ever commissioned | §6(iii) across the asset inventory first, then §6(iv) on whatever the assessment shows matters. | You cannot prioritise depth until you know the size of the estate. §13.1.1 has the scope derived from the consolidated and updated asset inventory for this reason. | §6(xvi). An adversary simulation against an unexamined estate measures the wrong thing at the highest day rate on the menu. |
| A major release, a migration or a configuration change affecting sensitive data | A scoped audit of the change and what it touches, before implementation. | §13.1.2(iii) classifies changes minor or major and requires a major change — system overhauls, technology migrations, or configuration adjustments affecting sensitive data or critical infrastructure — to undergo an audit before implementation, and §13.1.2(iv) requires an audit after every major change. | Waiting for the annual cycle. The change gate is separate from the calendar and it comes first. |
| The annual cadence, with nothing in particular having changed | The comprehensive audit §6 frames and §13.1.2(i) requires — all aspects of the ICT estate, at least once in the year. | §13.1.2(v) requires periodic audits even where no major change has occurred, because the vulnerabilities are new even when the system is not. | Re-running last year’s scope unexamined. §13.2.3(ii)(b) requires the as-of date of the asset inventory in the report, which is the line that exposes a stale scope. |
| Something has already happened — an incident, or a near miss | The investigation first, then §6(iii) and §6(iv) over the affected estate, then §6(xvi) once the gaps are closed, to test whether the fix to detection actually worked. | §14.3(iii) names security incidents or breaches occurring during the audit period as a legitimate trigger for revising scope, and §18(vi) sets what a forensic report must say where evidence or logs were inadequate. | A red team immediately. You already have the finding it would give you, and you have not fixed it yet. |
| Investor or acquirer diligence | §6(iii) for coverage and §6(ix) source code review where the code is the asset, with the findings register and the closure evidence together. | Diligence reads the remediation record more carefully than the finding list. An open critical with a dated plan reads better than a clean report nobody believes. | A report with the findings removed. Item 21 of Annexure I to the empanelment terms expects reports to state all states of security found, not only the failed measures — a redacted one answers neither question. |
| Weekly or daily release cadence | Continuous tooling in the pipeline as hygiene, plus a periodic §6(iii)/§6(iv) engagement, plus the change gate above for anything classified major. | §8(i) is explicit that solely tools-based testing should be discouraged, so the pipeline is the floor and never the whole answer. §13.1.2(ii) treats the stated frequency as a minimum. | Treating the pipeline scanner as the audit. That is the substitution §8(i) exists to prevent, and it is the easiest one to make at speed. |
Two rows deserve to be read together. The annual row and the change row are not alternatives: §13.1.2(i) sets the yearly minimum, §13.1.2(iii) requires an audit before a major change is implemented, and §13.1.2(iv) requires one after every major change. An organisation that ships a migration in March and audits in December has satisfied one of the three and missed the other two. More on turning any of these rows into a scope in how to scope a VAPT, and on the shapes each class takes in the types of VAPT.
“What is exploitable here” is not “would we detect and respond”
This is the distinction that survives every change of vocabulary, and the one worth carrying into a board paper. A penetration test measures the surface. A red team measures the organisation. An organisation can be strong on one and weak on the other, and the two results do not predict each other in either direction.
A penetration test asks: what is exploitable here?
The subject of the sentence is the system. Success is a demonstrated path with reproduction steps and a blast radius, and the answer is durable only for that build in that environment — §10.1(i) limits the auditor to reviewing and reporting on the state of security at the point in time of the audit.
Because the objective is proof, the test wants maximum access. Credentials at every role, the architecture, the API inventory, and often the source. Anything withheld shrinks the finding set rather than making the test more realistic.
It answers: which weaknesses are real, which are chainable, what each one reaches, and in what order to fix them. It cannot tell you whether anybody was watching, because your teams were told it was happening.
A red team asks: would we detect this, and respond?
The subject of the sentence is your organisation. §6(xvi) frames it as an exercise reflecting real-world conditions, conducted as a simulated attempt by an adversary. The route the operator takes is instrumental. The measurement is what your controls, your runbooks and your people did about it.
Because the objective is measurement, the exercise wants minimum disclosure. §15.1.1(i) limits notification of the test to key personnel, which the guidelines gloss as personnel at the policy-making level and managers responsible for security processes, incident response and security operations. §15.1.1(ii) adds the other half of the discipline: no unusual or major network changes during the period, because a changed environment invalidates the reading.
It answers: time to detect, time to triage, time to escalate, time to contain, and which of the four failed. It cannot tell you the estate is clean, because one successful route says nothing about the assets it never touched.
There is a sequencing consequence, and this is the page’s canonical statement of it. A red team run against an estate that has never had a systematic assessment is expensive theatre: the operator will enter through something an assessment would have found in an afternoon, and the exercise ends before it reaches the detection questions you paid for. Two clauses set the order between them. §6 frames it — auditee organisations are expected to ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, and may also opt for additional assessments and audits during the year. §13.1.2(i) is the operative requirement: the cyber security audit should be conducted at least once in a year, with sectoral regulators free to increase that frequency. So the comprehensive annual audit is the floor, and adversary simulation is one of the things you layer on top of it once the floor holds. Wherever the annual rule is cited later on this page, it is this pair: §6 frames it, §13.1.2(i) requires it.
The eight artefacts a red team runs on
“Do not tell the SOC” is easy to say and hard to run. What makes an exercise legal, safe and measurable is a small set of documents that mostly do not exist in a penetration test, and that an auditee who has never commissioned one has no reason to know about. Each is listed with the clause it hangs on where the auditing organisation is CERT-In empanelled — and each is worth writing into the engagement letter where it is not, because none of these are the auditor’s to invent on your behalf.
The trusted-agent list
The named few who know the exercise is running. §15.1.1(i) tells the auditee to limit notification about the testing to key personnel only, says it is the auditee organisation’s discretion to identify who those key individuals are, and adds that they are generally expected to include personnel at the policy-making level as well as managers responsible for security processes, incident response and security operations. Write the list as roles with names against them, date it, and keep it short enough that the population under test is genuinely unaware — a workable default is the accountable executive, the CISO and the head of incident response, with every further name argued for rather than assumed. The clause gives a reason as well as a rule: it exists to prevent a temporary increase in security measures solely for the duration of the audit.
The control cell and a single deconfliction channel
One channel, known to the trusted agents and to the operators, on which either side can ask “was that you?” and get an answer within minutes. It exists so that a real intrusion during the exercise window is not mistaken for the exercise, and so that a genuine outage is not left running while somebody guesses. §13.2.6 requires a well-defined escalation matrix for both the auditee and the auditing organisation for any problem encountered during the audit process, shared with the respective authorities. The clause does not use the word deconfliction, but read on a red team, a staffed channel is what satisfying it looks like. Name a person and a deputy on each side, with an out-of-hours number, because the exercise will not keep office hours.
Written authorisation carried by each operator
Two clauses set the floor. §13.2.7(i) requires that in the case of remote testing the identity of the auditor, with mobile number and/or IP addresses, be disclosed and formal written permission be obtained from the auditee organisation clearly outlining the tasks to be performed, and §13.2.2(v) requires written approvals before penetration tests. What practice adds on top — and this part is our recommendation rather than the instrument’s requirement — is that the permission travels with the operator as a signed letter held for the duration, naming the authorising officer and their office, the exercise dates and window, the systems and premises in scope, the activities authorised, and the trusted-agent contacts to call if the operator is challenged or detained. Where any part of the exercise is physical, that letter is the difference between an exercise and an incident involving your own security staff.
Specific written permissions for the four named techniques
Survivability-failure testing, denial-of-service testing, process testing and social engineering each need their own specific written permission under §13.2.7(ii) — the clause says “specific”, so a blanket authorisation to test does not carry them. §15.2.2(ii) adds explicit written permission before DoS, DDoS or flood testing over the Internet. Most red team scopes touch social engineering, which means most red team scopes need this and most engagement letters do not have it.
Third-party consent, started at scoping
Where the exercise would touch a managed service provider, a shared SOC, a payment partner or anyone else outside your own organisation, §15.2.2(iii) bars it unless specific written consent is obtained from the target organisation. That consent is yours to get, not the auditor’s, and it moves at the speed of somebody else’s legal team. Start it when you write the objective. A consent request that begins at kick-off rather than at scoping moves the start date by whatever the other organisation’s legal review takes, and that delay is entirely predictable in advance.
Stop conditions, and who holds stop authority
Write the conditions that halt the exercise before it starts: a production outage attributable to the operation, an action that would affect a real customer or a real payment, discovery of a genuine prior compromise, or an unplanned law-enforcement or regulator involvement. Name one person on the auditee side and one on the auditor side who can call stop unilaterally, with a deputy each, and give both the deconfliction channel. §15.2.2(iv) pushes the same way for critical environments where availability is a top priority: testing should be conducted in a passive manner to avoid any potential downtime or service disruption. A stop authority with no named holder is a stop authority nobody exercises.
The change freeze, which is the auditee’s to enforce
§15.1.1(ii) tells the auditee to refrain from implementing any unusual or major network changes during the testing period. On a red team that is a scheduling constraint with teeth: a firewall migration halfway through makes the detection result unreadable, because you can no longer say which control was in place when. Put the window on the change calendar before the engagement letter is signed, not after, and expect to move the exercise rather than the release.
The notification ledger
A dated record of who was told what, and when — including the trusted agents, any mid-exercise disclosure, and the moment the exercise was revealed at the end. It is what later proves the §15.1.1(i) discipline was respected, and it is what settles the debrief argument about whether a fast detection was real. It also feeds §16.1(ii), which requires the report to carry the audit process, duration, sampling decisions, manpower involved, exemptions, limitations and other constraints.
What does a red team actually measure?
Four intervals, and they are worthless until three things are fixed in writing before the exercise starts: what starts the clock, what each one means, and where the timestamp comes from. Most disputes at a red team debrief are definitional rather than factual — one side counts from engagement start and the other from first contact, or one side calls an alert that fired and was never read a detection and the other does not. Settle it in the engagement letter and the debrief argues about the gap instead of about the arithmetic.
| Interval | When the clock starts and stops | What it actually tells you | Where the timestamp comes from |
|---|---|---|---|
| Time to detect | Starts at the first operator action of consequence against a monitored asset — not at engagement start, and not at pretext delivery. Stops when an alert about that activity is generated by a control. | An alert exists somewhere. Nobody has necessarily seen it. This measures instrumentation and nothing else. | The SIEM or EDR record carrying the generation timestamp, read against the operator log for the same action. Both clocks stated in the same time zone, and reconciled if they differ. |
| Time to triage | Starts at alert generation. Stops when a human first works the alert — opens the ticket, acknowledges the page, or otherwise takes it out of the queue. | Somebody looked. This is the interval that separates a monitoring failure from a staffing or routing failure, and it is the one most often missing from a red team report. | The ticket or case record with its first-touch timestamp, plus the on-call or paging log where one exists. |
| Time to escalate | Starts at first triage. Stops when the alert is raised to the incident-response function as a suspected incident rather than handled as routine noise. | The alert was believed. An alert triaged, closed as benign, and later shown to be the operation is the most expensive finding in the exercise and the one the ledger exists to prove. | The escalation record, the IR channel message, or the call log — and the analyst’s own disposition note on the closed case where it was closed. |
| Time to contain | Starts at escalation. Stops when an action taken by the defence measurably impedes the operator — a credential revoked, a host isolated, a path blocked — as recorded on both sides. | The response worked. Containment is the only one of the four the operator can corroborate from their own side, which is what makes it the most reliable number in the report. | The defensive action record, paired with the operator log entry showing the access that stopped working and when. |
Notice that the common phrase “time to detect” hides the second row. An alert generated at hour nine and first read at hour sixty-one is not a nine-hour detection and it is not a sixty-one-hour failure — it is a nine-hour detection followed by a fifty-two-hour triage gap, and those two numbers belong to different teams with different budgets. A report that gives you one number has decided that argument for you without telling you which way. Recording the intervals is the auditee’s job as much as the auditor’s: §15.1.3(i) puts monitoring the execution of the agreed tests on the auditee organisation, through the scheduled progress meetings.
What a red team timeline looks like
The same imaginary estate as the worked illustration below, on one clock, with both tracks side by side. Hours run from the first operator action of consequence, per the definitions above. This is an illustration built to show the shape of the artefact — it is not a case study and it does not describe any client, and the hours exist to make the gaps legible.
| Clock | Operator track | Defensive track |
|---|---|---|
| H−21 d | Objective agreed and written: obtain and exfiltrate a sample of citizen records from the production database without being stopped. Trusted-agent list signed — Secretary, CISO, head of incident response. Stop authority named on both sides. | Nothing. The managed SOC is not told, and will not be told until the debrief. The change freeze goes on the calendar for the exercise window. |
| H−14 d | Specific written permission obtained for social engineering under §13.2.7(ii). Consent request sent to the managed SOC provider under §15.2.2(iii), because the operation may generate activity they will handle. | The provider’s legal team begins reviewing the consent request. This takes eleven days, which is why it was started first. |
| H−3 d | Reconnaissance against public sources only. No contact with the estate. | No signal, and none expected. Nothing here is instrumented, and nothing here starts the clock. |
| H+0 | Pretext delivered to the agreed group. One recipient authenticates to a lookalike portal. Clock starts here: this is the first operator action of consequence against a monitored asset. | The mail gateway scores the message and delivers it. No alert. |
| H+2 | Captured credential used against the identity endpoint from an unfamiliar network. Session established at a citizen-plus role. | The impossible-travel rule does not fire because the source is in-country. No alert. |
| H+9 | Enumeration of the undocumented API base path. First request patterns that do not resemble any legitimate client. | Alert generated by an API gateway rate rule nobody had reviewed in eighteen months. Time to detect: 9 hours. It routes to a shared queue. |
| H+31 | Internal header trust on the undocumented API yields administrative read across the tenant. The operator slows down deliberately. | The alert is still unworked in the shared queue. The queue has no named owner at the weekend, which is the finding rather than the alert. |
| H+52 | Staged extract assembled. Exfiltration begins over a channel chosen to resemble a legitimate integration. | The data-loss control logs the transfer and does not alert, because the destination matches an allowlist entry created for a decommissioned integration. |
| H+58 | Objective reached. Sample exfiltrated. The operator does not stop — the exercise now measures whether anyone arrives. | Still nothing worked. Two records exist that would have answered the question, and neither has been read by a person. |
| H+61 | Operator continues low-rate activity to give the defence a live target. | Monday shift picks up the H+9 alert. Time to triage: 52 hours. The analyst correlates it with the H+52 transfer log within twenty minutes. |
| H+62 | Access to the API base path begins failing. | Escalated to incident response. Time to escalate: 1 hour from triage. The credential is revoked and the allowlist entry removed. Time to contain: 1 hour from escalation. |
| H+62 → debrief | Exercise revealed. Operator log handed over in full, timestamped, to be read against the defensive record. | Four numbers, one story: detection worked at 9 hours, triage failed for 52, and once a human looked, escalation and containment took an hour each. The gap is not the SIEM. It is an unowned weekend queue. |
What the four numbers say, and to whom. Detection at nine hours is an engineering result and a good one. Triage at fifty-two hours is an operating-model result and a bad one, and it belongs to whoever owns the weekend rota rather than to whoever owns the SIEM. Escalation and containment at an hour each say that once a human believed the alert, the response worked — which is the finding that stops a board from buying a detection platform to fix a staffing problem. One exercise, four numbers, three different owners. That is the deliverable, and it is why the timeline and not the intrusion narrative is the part worth paying for.
CERT-In’s other Red Team, and the White Team it checks
If you read CERT-In’s instruments in order, you meet the words “Red Team” twice, and they mean two unrelated things. This trips up buyers, bidders and, in our experience, people writing tender language who have read one document and not the other.
“Auditors should deploy a verification team (Red Team) to verify the work performed by their audit team (White Team).”
Read it carefully. Nothing in that sentence is about attacking anybody. It is a maker-checker requirement on the auditing organisation: the audit team that did your work is the White Team, and a second team inside the same firm — the Red Team — verifies what they produced before it is issued to you. The 2025 guidelines carry the same requirement forward without the colour coding: §15.2.5(iii) requires a separate verification team to review and validate the work of the audit team.
| Which “Red Team” | Who they are | What it measures | Do you buy it? |
|---|---|---|---|
| Red Team, the internal verification team Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018, under Technical. “Auditors should deploy a verification team (Red Team) to verify the work performed by their audit team (White Team).” | Staff of the auditing organisation. The White Team is the auditors who did your engagement. The Red Team is a second group inside the same firm that checks their work before it leaves the building. | The quality of the audit. Did the audit team cover the agreed scope, reach sound conclusions, and support each observation with evidence? | You do not. It is a duty the auditing organisation owes as a condition of its empanelment. What you can do is ask who performed it and require the reviewer to be named. |
| Red Team Assessment, the engagement Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025, §6(xvi) — one of the twenty-six classes of engagement in scope of the document. “An exercise, reflecting real-world conditions, that is conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems.” | Operators playing an adversary against your live organisation, with your detection and response function on the other side of the exercise and mostly unaware of it. | Your defence. Detection, triage, escalation, containment — and the time each of those took. | Yes, as a scoped engagement in its own right, priced and planned separately from any VAPT. |
Two practical consequences. First, when a proposal from an empanelled organisation says its methodology includes “red team verification”, it may be describing its own internal review rather than offering you adversary simulation — and the honest version of that sentence is worth having, because §9.5(iii) requires the report to be reviewed and signed by a designated reviewer who is not part of the audit team and is from mid-management, before the head of the auditing organisation authorises it. Ask for the reviewer to be named.
Second, the colours do not travel. In wider exercise practice a white team usually means the exercise control group or referees, a blue team means the defenders, and a purple team means red and blue working together in the open. CERT-In’s instruments define none of those, and use White Team for the audit team itself. If a colour appears in an Indian scope of work, define it in the engagement letter rather than assuming a shared convention — §14.1(ii) requires the agreed terms to be documented in an audit engagement letter signed by authorised representatives of both organisations, and this is exactly the kind of ambiguity it exists to remove.
The engagement sense is where the national conversation is heading, for what it is worth. The Press Information Bureau release on CERT-In SAMVAAD 2026 (Release ID 2256581, 29 April 2026) records that the presentations selected for the conference covered, among other subjects, AI driven cyber risks and AI driven red teaming methodologies — alongside supply chain audits, cloud, APIs and operational technology. That is the Government of India’s own account of what the audit ecosystem is now working on, and it uses “red teaming” in the adversary-simulation sense.
When the quote says VAPT and scopes a scan
How to tell a scan from a penetration test in a quote
Nobody writes “this is a scan” on a proposal. The signals are structural, they are all visible before award, and most of them have a clause behind them. Each row is a thing you can look for in a document you already have, what it means, and the single question that settles it.
| What you see in the quote | What it usually means | The question that settles it |
|---|---|---|
| The deliverable is described as “a VAPT report” and nothing else | The quote has not committed to a method, a depth or a coverage claim. VAPT is a category, not a specification — §13.2.3(i)(a) lists it alongside eight other named audit types and ends the list with “etc.”. | Which of the §6 classes is this, and what is the method for each in-scope asset type? |
| The methodology line says “OWASP Top 10” | §8(ii) says in terms that limited lists such as OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits, and that audits should instead include discovery of all known vulnerabilities based on comprehensive standards and frameworks. A methodology line naming only a top-ten list has therefore named something the guidelines expressly exclude as a reference. | Which testing guide — WSTG, MSTG, OSSTMM 3 — and which control standard, at which version and level? |
| No man-hours anywhere in the document | You cannot compare two quotes on calendar time alone, because a five-day engagement can be one person or four. §13.2.2(ii) requires the test plan shared by the auditing organisation to include both calendar time and man-hours, and item 10 of Annexure I to the empanelment terms says the same. | Give me the test plan with man-hours per phase — planning, assessment, reporting, revalidation. |
| A named tool is the centre of the proposal | Tooling is expected, but tooling as the offer is not. §8(i) discourages solely tools-based testing, for the reason quoted in full above. The 2018 guidelines say the same in one line: auditors must utilise industry standard methodologies and best practices for security testing, and solely tools-based testing should be discouraged. | What proportion of the effort is manual, and which classes of finding does the manual work exist to catch? |
| The price is the same whether we have one application role or six | Almost certainly unauthenticated testing, or authenticated testing at one role. Authorisation defects only appear when a tester holds two accounts at different privilege levels and tries to cross the line between them. | How many authenticated roles are in scope, and how many test accounts do you need from us at each? |
| No retest, or the retest is a separate quote | Closure has not been priced. §9.3(iv) says follow-up audits should be included within the scope or RFP proposal and must be conducted after closure of the vulnerabilities identified, and §13.1.1(g) requires the scope of work to specify follow-up audits as part of the engagement. | How many retest rounds are included, and what triggers a chargeable one? |
| The word “red teaming” appears in a two-week web application quote | Either the word is decoration, or the quote is offering adversary simulation at the price of an application test. Both are problems, and the second is worse. | Is this §6(iv) or §6(xvi)? If it is (xvi), what is the objective, who will be told, and what is out of bounds? |
| The scope names a URL and stops | The admin console on a second hostname, the API tier, the mobile binary and the identity endpoint are all out of scope by omission. §13.2.3(ii)(c) requires version-specific details of web and mobile applications to be explicitly mentioned in the audit scope and report. | Reconcile the scope against our asset inventory line by line, and name what is excluded. |
| The environment is not stated | A finding set from staging and a finding set from production are different documents. §15.2.3(i) requires the environment — test, development, UAT, pre-production or production — to be specified. | Which environment, and who is providing it on the day you start? |
| The final milestone pays “on issue of the certificate” | The commercial structure is now arguing against the finding count. §7 requires payments not to be contingent upon the outcome of the audit, favourable or unfavourable, nor tied to the submission or approval of any closure reports. | Re-cut the milestones on delivery of the phases, not on the conclusion. |
If you only have time for one of these, take the roles. Ask how many authenticated roles are in scope and how many test accounts the auditor needs from you at each. A bidder offering a real application test will have an opinion about this before you ask, because the role matrix is what the effort estimate was built from. A bidder offering a scan will say they will confirm during kick-off, because the role count does not change what their tool is going to do. More on getting the scope right in how to scope a VAPT.
One system, four engagements, four answers
The abstract difference becomes obvious the moment you run all four against the same thing. The system below is imaginary and the numbers exist to make the shapes legible — this is an illustration, not a case study, and it does not describe any client. Everything in the failures and timeline tables on this page should be read the same way. It is also deliberately the same imaginary estate used in the walkthroughs on what a safe-to-host certificate is and the types of VAPT, so that the four engagements, the certificate route and the testing types can be read against one system rather than three. A second, shorter contrast follows it, for the private-sector buyer whose trigger is a customer questionnaire rather than a hosting gate.
The system
A citizen-facing services portal. Four hostnames — public portal, administrative console, file service, identity endpoint. Six application roles from anonymous visitor to super-administrator. Three API base paths, one of them undocumented and built for an internal integration two years ago. One database. A mobile app that talks to the same APIs. Hosted by a provider the department does not control, with a SOC on a shared managed service.
Quote A — the scan sold as VAPT
Unauthenticated tooling against the four hostnames over two days. It returns 140 items: TLS configuration, missing headers, an outdated library banner, a handful of medium CVEs on the web tier. Not one of them requires a login. The undocumented API is never found, because nothing links to it. The report is delivered in a fortnight and every finding is true. The organisation now knows less than it thinks, because a clean-looking authenticated surface was never opened.
Quote B — the vulnerability assessment
The same four hostnames plus the database and the mobile binary, with credentials at all six roles and a configuration review of the hosting tier. Tooling runs, and then a person checks every result and discards the ones the tool got wrong. The API inventory is reconciled against the code, which is how the undocumented base path is discovered. The output is a complete register with CVSS supplemented by EPSS, every observation mapped to a CWE and, where one exists, a CVE. What it does not answer: which of these an attacker would actually use.
Quote C — the penetration test
The same scope, and a mandate to chain. A role check enforced in the interface but not in the controller lets a citizen-role account read another citizen’s documents. That alone is a high. Chained with the undocumented API, which trusts an internal header, it becomes administrative read across the tenant. The report carries reproduction steps, the blast radius and the three independent fixes that each break the chain. The critical is notified the day it is found, under §16.3(ii), not held for the draft.
Quote D — the red team assessment
One objective: obtain and exfiltrate a sample of citizen records from the production database, without being stopped. No asset list. Notification limited to the Secretary, the CISO and the head of incident response under §15.1.1(i) — the managed SOC is not told. The operation starts with a phishing pretext against a group agreed in advance, reported later in aggregate under §15.2.2(iii). The result that matters is not the route taken. It is that the first alert fired at hour 9 on a control nobody expected, and that nobody triaged it until hour 61 because the runbook routed it to a queue with no owner at the weekend.
What the four buy you
A is an artefact. B tells you the size of the problem. C tells you which parts of the problem are real and what they cost you. D tells you whether any of it would be noticed. They are not stages of the same product and they do not substitute for one another. They do have an order, for the reason set out above under the two questions: D against an estate that has never had B measures the wrong thing, because the operator finishes before reaching the questions D was bought to answer.
Notice what happens to the undocumented API across the four. Quote A never finds it, because nothing links to it. Quote B finds it by reconciling the inventory against the code. Quote C turns it into the second half of a chain. Quote D might never touch it at all, because the operator took a faster route — and the exercise would still be a success, because it was never measuring the API. Four true reports, four different pictures of the same system, and only one of them is wrong about what it claims: the one that called itself VAPT.
The same four engagements, for a private SaaS buyer
The portal above is a government estate, and the clauses land cleanly on it. Most of the people searching this comparison in India are not buying for a government estate — they are a SaaS vendor with a customer questionnaire on the desk and no hosting gate anywhere in sight. Same four engagements, different question, and one part of the answer changes materially. Imaginary again, for the same reason.
The system, and the trigger
A B2B SaaS platform: one multi-tenant web application, a public API, an admin back-office used by the vendor’s own staff, and a data pipeline into a managed warehouse. Four customer-facing roles plus two internal ones. Nobody is asking for a safe-to-host certificate. What arrived is an enterprise customer’s security questionnaire with a line reading “provide your most recent penetration test report, dated within twelve months”.
What the questionnaire is actually asking for
Almost always §6(iv) work — evidence that somebody competent tried to break the application and wrote down what happened — with a date, a scope and a remediation status. It is rarely asking for §6(iii) coverage of the whole estate, and it is almost never asking for §6(xvi). A VAPT report satisfies it if the scope annexure names the application the customer cares about and the penetration-testing half is real. It does not satisfy it if the scope names an IP range and the findings are all unauthenticated.
Where the multi-tenant wrinkle lives
Tenant isolation is the finding class this buyer cannot afford to miss, and it is structurally unreachable without two tenants and two roles inside each. That is a scoping decision, not a testing decision: it means asking the tester for accounts across two customer tenants, and it is the single question that separates a real quote from a cheap one here, in the same way the role matrix does for the portal above.
What the CERT-In instruments do and do not do here
The clauses on this page bind CERT-In empanelled auditing organisations. A private SaaS vendor buying from a non-empanelled firm gets none of them by default — which is exactly why the shortlist below exists. The 2022 Directions are a different matter: they reach service providers, intermediaries, data centres, body corporate and Government organisations alike, so log retention, clock synchronisation and the point of contact are live obligations for this vendor whether or not it ever commissions an empanelled audit.
The difference worth carrying away is not technical. For the portal, who signs is part of the requirement, because GIGW 5.3.1 names the four bodies that may issue the clearance. For the SaaS vendor, nobody is checking the signature — the customer is checking the scope, the date and the remediation status. That changes what you optimise the procurement for, and it changes which of the clauses on this page you have to write into the contract yourself.
Three reports, three different burdens of proof
A report is the only part of a security engagement most stakeholders will ever see, so it is worth knowing what each kind has to carry. The floor is the same for all of them — §16.1(ii) and Annexure II of the empanelment terms set the content format — but what makes each one credible differs.
| Element | In a vulnerability assessment | In a penetration test | In a red team assessment |
|---|---|---|---|
| The findings register | Every in-scope asset, every observation, with objective evidence. §18(iii) requires observations to be well supported with objective evidence, compiled carefully with the report and presented so decision-makers can make credible risk-based decisions. | The same, plus reproduction steps and the demonstrated consequence of each exploited path. | Fewer findings, and a different kind. The register records the enabling conditions of the operation, not an inventory of the estate. |
| Severity | §16.2(ii) requires CVSS for severity, supplemented with EPSS for real-world exploitation likelihood, and every observation mapped to a CWE and a CVE number. | The same scoring, but the score is no longer the argument — the demonstrated impact is, and the report should say where the two disagree. | Severity by consequence to the objective. A medium that provided the pivot outranks a high that went nowhere. |
| The timeline | Audit dates, and the as-of date of the asset inventory. §13.2.3(ii)(b) requires that inventory date to be reflected in the audit reports. | The same, plus the dates critical and high findings were notified. §16.3(ii) requires those to be notified during the audit on an as-and-when-found basis, not held for the report. | The heart of the deliverable: every operator action against every defensive action, on one clock, with the clock-start conventions written down. Generated at, triaged at, escalated at, contained at — or not. There is a worked example of the shape above. |
| What was not covered | §16.1(ii) requires exemptions, limitations and other constraints in the report, and §16.1(iii) requires every asset given in scope by the auditee to be mentioned in it. | The same, plus anything the rules of engagement forbade. §10.1(ii) requires in-scope assets that could not be accessed to be named with reasons, and brought to CERT-In’s notice. | The boundaries that were respected, so nobody reads a clean result as coverage it never claimed. |
| Honesty about unknowns | Item 20 of Annexure I to the empanelment terms: reports include all unknowns clearly marked as unknowns. Item 21: reports state all states of security found, not only the failed measures. | The same two items, and they bite harder — an attack path that was plausible but unproven belongs in the report labelled as unproven. | Whether the alert was never generated, generated and never triaged, or triaged and not acted on. Those are three different findings with three different owners, and collapsing them into “we did not detect it” wastes the exercise. |
| Metrics | Item 22 of the same annexure: only qualitative metrics based on industry-accepted methods, based on a mathematical formula and not on feelings of the auditor. | Same rule. A risk rating that cannot be derived from a stated formula is an opinion wearing a number. | Time to detect, time to triage, time to escalate, time to contain — each one useless until the clock-start convention and the meaning of “detect” are fixed in writing. The four intervals are defined above, under how a red team is actually run. |
The two Annexure I rules in the “honesty about unknowns” row deserve to be quoted into your contract verbatim, because they are the crispest statement of what a report does with the things it could not establish. Reports include all unknowns clearly marked as unknowns. Reports state all states of security found, not only the failed measures. They do not stand alone: §16.1(ii) requires exemptions, limitations and other constraints in the report, §16.1(iii) requires every in-scope asset to be mentioned in it, §10.1(ii) requires in-scope assets that could not be accessed to be named with reasons, and §13.2.4(ii) requires the auditing organisation to communicate exemptions, limitations and constraints to the auditee in the first place. Annexure I is the version short enough to paste into a contract. A report that only lists failures is not a stricter report — it is an unreadable one, because you cannot tell a control that passed from a control nobody looked at. More on reading one in how to read a VAPT report.
Methodologies are named, and one popular answer is ruled out
Whichever of the four you buy, the methodology line in the scope decides how repeatable the result is. §8(ii) of the audit policy guidelines is unusually prescriptive here, and it begins by ruling out a widely used methodology line.
“The limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits.”
The comprehensive alternatives §8(ii) names are ISO/IEC standards, the Cyber Security Audit Baseline Requirements (National Security Council Secretariat, publication NSCS-46-16 Rev 1.0, October 2020, published on CERT-In’s website), the CSA Cloud Controls Matrix for cloud security, OSSTMM 3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, the OWASP Mobile Security Testing Guide and the OWASP DevSecOps Maturity Model. §8(iii) adds that the baseline requirements document should be used by auditees and auditing organisations to build their audit programme, so it belongs in your scope as well as theirs. Two of those are linked here because this page tells you to demand one by name, and a demand you cannot point at is an argument rather than a requirement. Note the drift in the mobile entry: §8(ii) names the Mobile Security Testing Guide (MSTG), and OWASP now publishes mobile testing guidance as the Mobile Application Security Testing Guide (MASTG), so name the document and its version in the scope rather than the acronym.
One detail is worth settling in the scope rather than discovering in the report. ASVS defines three verification levels: Level 1 is the lowest assurance level and is fully penetration-testable from outside, Level 2 is intended for applications handling sensitive data and is the level recommended for most applications, and Level 3 is the highest, for applications requiring significant verification. The level definitions were restructured between the 4.x and 5.x lines — at 22 September 2026 the 5.x line was the current stable release — so a scope of work should name the version as well as the level, and should expect that sentence to age. Neither the audit policy guidelines nor the GIGW manual picks a level for you — GIGW guideline 5.3.1 names OWASP ASVS, OWASP Top 10 and OWASP MAVS in its government organisation action without naming an ASVS level, so the choice is the buyer’s and belongs in the scope of work.
Severity, meanwhile, is not a matter of taste. §16.2(ii) requires CVSS to categorise the severity of vulnerabilities, supplemented with EPSS to reflect the likelihood of real-world exploitation, and requires every reported observation or vulnerability to be mapped with a CWE and a CVE number. That pairing does real work in a report: a medium by CVSS with a high EPSS is not a medium in practice, and a report that carries only one of the two numbers has given you half a prioritisation.
Three clauses that make two quotes comparable
Most of the difference in outcome is decided before anybody tests anything, by how the requirement was written. Many clauses help. Three change the result.
Name the class, not the acronym
Write the §6 class or classes the engagement falls into and, where more than one applies, say which asset each covers. §6 opens with “including, but not limited to”, so the list is not closed — but naming the class forces the bidder to state a method instead of a category. A scope that says VAPT and a scope that says “§6(iii) vulnerability assessment across the asset inventory at annexure A, plus §6(iv) penetration testing of the portal and API tier at all six authenticated roles” are different documents, and only one of them can be evaluated.
Require the test plan with man-hours before award, not after
§13.2.2(ii) requires the test plan shared by the auditing organisation to include both calendar time and man-hours, and §13.2.2(iv) requires the auditor to have a thorough understanding of the tools used, including their origin and functionality, to test them in a controlled test environment first, and to have those results formally reviewed and approved by an authorised representative of the auditee. Ask for both at bid stage. The firms that can produce them immediately are the ones that plan engagements rather than staff them.
Price the retest and fix the revision procedure
§13.1.1(g) requires the scope of work to specify follow-up audits as part of the engagement and §9.3(iv) requires them after closure. §16.3(v) then withholds the final report until closure and the follow-up audit on production are complete. Separately, §14.1(ii) requires the agreed terms to be documented in an audit engagement letter signed by authorised representatives of both sides, and §14.3 names the three things that legitimately reopen scope: discovery of previously unidentified systems or processes that present significant risk, changes in organisational structure, ownership or regulatory environment, and security incidents or breaches occurring during the audit period. Put the addendum procedure in the contract on day one and the mid-engagement argument disappears.
Two more belong in the file rather than the contract. Read the bidder against the published snapshot before award, not after: §12.1(i) says that information should be used to identify and select auditing organisations, and §12.2(iv) puts the burden on you to check the domain of audits conducted, previous audits, methodology, tools and relevant-domain experience, and to consider the available alternatives, before selecting. And for critical or high-user-reach applications, §12.4(i) recommends contracts of two to three years, which is the only realistic way to get the retest, the annual cycle and the change-driven audits from a team that already knows the system.
Eight ways the wrong engagement gets bought
Every one of these is recoverable if it is caught at scoping and expensive if it is caught at the report. The middle column is the point at which each one usually surfaces.
| The failure | Where it surfaces | How you know | What it costs |
|---|---|---|---|
| A scan was bought and a penetration test was assumed The quote said VAPT, the work was a credentialed scan with a cover page, and nothing was exploited or chained. The estate looks assessed and the exploitable path is still there. | The next real incident, or the customer’s security questionnaire | Every finding maps to a CVE and none has reproduction steps. No finding required two accounts. No finding required understanding the business logic. | A second engagement, and a period where the organisation believed it had been tested. |
| A red team was bought and the SOC was told Somebody sensible warned the operations centre so the alerts would not cause a panic. The exercise then measured a defence that was watching for it. | The debrief | Detection times are implausibly good, and the timeline shows the first alert before the first operator action of any consequence. | The entire budget. §15.1.1(i) limits notification to key personnel for exactly this reason. |
| A penetration test was bought to answer a detection question The board asked whether the organisation would notice an intrusion. A pentest was commissioned, came back with a findings register, and answered a different question well. | The board paper | The report has no timeline of defensive actions in it, because nobody was measuring any. | A year of believing detection was tested when only exposure was. |
| The roles were never enumerated Testing ran with one account. Every authorisation finding — horizontal, vertical, tenant-to-tenant — was structurally unreachable. | Scoping, discovered at the findings report | The scope annexure names hostnames and no roles, and the test accounts were requested on day one rather than agreed in the scope. | The most damaging class of web-application defect, unexamined and unremarked. |
| Nobody fixed what “done” meant The engagement had a start date and a report date and no success criterion. For a red team that is fatal, because the exercise has no objective to reach or fail to reach. | Week two | The status calls are about activity rather than progress toward anything. | A narrative with no verdict, which no board can act on. |
| The scope was revised verbally Assets appeared, a subsidiary was added, an environment moved. None of it went into writing, so the report describes an engagement nobody agreed to. | Report review | The scope annexure and the findings do not describe the same estate. §14.2 requires revisions to be documented in writing with justification, evaluated for impact on timelines, resources and deliverables, approved by authorised representatives and recorded as an addendum to the audit engagement letter — so the absence of an addendum is itself the signal. | A deliverable nobody can review against an agreed scope, and a dispute with no written baseline to settle it. |
| The red team result was used as an assurance certificate The operation failed to reach its objective, and the result was presented as evidence that the estate is secure. | The next audit | A one-page summary with a conclusion sentence and no coverage statement. | A large untested estate, and a document that implies otherwise to everyone who reads it. |
| The same firm built it, fixed it and tested it One team wrote the application, remediated the findings, and signed the assurance on its own work. | Whenever somebody independent reads the arrangement | The remediation owner and the testing owner have the same email domain. §5(xvii) defines conflict of interest to expressly cover the same entity implementing controls and auditing them, or auditing while responsible for remediation, as overlaps that inherently undermine the independence of the audit process. | Assurance that fails the first independent read, and a finding at the next audit. |
The second row is the one that hurts most, and it is normally done out of consideration rather than carelessness. Somebody tells the operations centre so the on-call engineer is not woken at 3am by an exercise, and in that moment the budget stops measuring anything. If the concern is real — and it often is — the answer is the trusted-agent list and the deconfliction channel described above: a named, silent holder of stop authority at policy-making level, which is exactly the population §15.1.1(i) contemplates, and not a broadcast to the team under test. §15.1.1(i) even gives the reason in its own words: the limit exists to prevent a temporary increase in security measures solely for the duration of the audit.
If you already bought it, this is the week to fix it
Most people reading a page like this are not planning a procurement. They are holding a report that does not look like what they expected, or a customer email asking a question the report cannot answer. The table above tells you which failure you are in. This is what to do about it. Work down in order and stop when the problem is solved — and note that the first three steps establish facts rather than fault, which is what makes the conversation recoverable.
- 01 Establish what you actually received, before anyone argues about what was promised. Read the delivered report against §16.1(ii): does it carry the audit process, the detailed scope, the duration, the methodologies and standards, the tools, the manual process, the findings, the prioritisation, the sampling decisions, the manpower involved, and the exemptions and limitations? Then apply this page’s own test: did any finding require a login, and did any finding require two accounts at different privilege levels? A document that fails both is a scan whatever its cover says.
- 02 Ask for the test plan with man-hours, even after the fact. §13.2.2(ii) requires the plan shared by the auditing organisation to include both calendar time and man-hours, and item 10 of Annexure I to the empanelment terms says the same. Man-hours per phase against the finding set is the fastest way to establish whether manual effort happened, and the answer arrives in one email.
- 03 Require the coverage statement the report should already carry. §16.1(iii) requires every asset provided in the scope by the auditee to be mentioned in the report, and §10.1(ii) requires in-scope assets that could not be accessed to be named with reasons. Ask which in-scope assets were not reached and why. Silence on that question is itself the answer.
- 04 Tell the customer or the regulator waiting on the report where you actually are, in writing, before they find out from the document. A dated note saying the current report covers X, that Y was not reached, and that a further engagement is scheduled, survives scrutiny. A report handed over in the hope that nobody reads the scope annexure does not, and it converts a procurement problem into a credibility one.
- 05 Use the revision route rather than inventing one. §14.2 requires scope revisions to be documented in writing with justification, evaluated for impact on timelines, resources and deliverables, approved by authorised representatives of both sides and recorded as an addendum to the audit engagement letter. If what you bought and what you need are genuinely different engagements, that is an addendum or a new engagement — not an argument about the existing one.
- 06 Keep the payment discipline while you do it. §7 requires fees to be based on predefined scopes, deliverables and timelines, and not to be contingent on the outcome of the audit, favourable or unfavourable, nor tied to the submission or approval of any closure reports. Decline to accept an undelivered phase if that is the position. Do not renegotiate the fee against the finding count, because that is the arrangement the clause exists to prevent.
- 07 Use the stop-and-replace clause if it is in the contract, and put it in the next one if it is not. §12.4(ii) contemplates a contractual right for the auditee to stop the audit and choose another auditing organisation within a reasonable time, to avoid financial loss on both sides.
- 08 Where the firm is CERT-In empanelled, give feedback afterwards whichever way it ends. §11(iii) describes auditee feedback as both a right and a duty, says it is kept confidential and acted on promptly, and points auditees at empanelment@cert-in.org.in for the form. It costs nothing, it has no deadline, and it is the step everybody skips.
One thing not on the list: do not commission the second engagement until step one is done. The commonest way a scan-sold-as-VAPT becomes two wasted engagements is that the buyer, having discovered the first was thin, writes the second scope in the same words. Establish what you actually received, write the scope from the asset inventory and the role matrix rather than from the last proposal, and name the §6 class. The second engagement is only worth buying if it is a different document from the first.
What buyers argue about
These arrive in real procurement reviews, usually with a date attached and a bidder in the room. In each case the answer that works cites the document rather than asserting the conclusion.
“Our auditor said their VAPT includes red teaming. Is that a problem?”
It depends entirely on which red team they mean, and asking is not pedantry. If they mean §6(xvi) — a simulated adversary against your live organisation, with your defenders unaware — that is a separate class of engagement with its own objective, its own notification rule at §15.1.1(i) and its own price, and it cannot be a line item inside an application test. If they mean the 2018 requirement that an auditing organisation deploy a verification team (Red Team) to verify the work performed by its audit team (White Team), then they are describing their own internal quality control, which is a duty they owe anyway and not something you are buying. Both answers are legitimate. Confusing them is how a department pays for adversary simulation and receives peer review.
“We already run a monthly scan. Do we still need an assessment?”
Yes, and the instrument says why rather than leaving it to argument. §8(i) states that solely tools-based testing should be discouraged, because tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure, and that this can result in an incomplete view of the overall security. The 2018 guidelines put the same point in one sentence: auditors must utilise industry standard methodologies and best practices for security testing, and solely tools-based testing should be discouraged. Continuous scanning is a good hygiene control and it is not an assessment. Keep both, and stop reporting the scan as though it were the audit.
“Can we skip the pentest and go straight to a red team? It is closer to reality.”
You can, and the sequencing argument against it is set out above under the two questions rather than repeated here. What the objection adds is the clause pair behind it. §6 frames the expectation — auditee organisations are expected to ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, and may also opt for additional assessments and audits during the year — and §13.1.2(i) is the operative requirement that the audit should be conducted at least once in a year. So the comprehensive annual audit is the floor and a red team is one of the additional exercises layered on top of it, which is a procurement answer as much as a technical one: an organisation that has not met the floor is being asked to fund the optional thing first.
“Our system integrator will do the testing as part of the build contract.”
That is the arrangement §5(xvii) defines as a conflict of interest: it expressly covers the same entity being involved in both the implementation of controls and their subsequent audit, or conducting audits while also being responsible for remediation, and says such overlaps create inherent conflicts that undermine the independence of the audit process. §7 adds that payments must not be contingent on the outcome of the audit nor tied to the submission or approval of closure reports. What the integrator should be doing is the other duty: §13.1.3 requires SAST by the developer or system integrator for critical applications, and says that requirement is to be clearly stated in RFPs and tenders. Build-side testing and independent assurance are both necessary and they are not interchangeable.
“The quote is half the price of the others. What are we actually losing?”
Check three things a price hides: authenticated coverage, manual effort and the retest. All three are invisible in a total and obvious in a test plan, which is why §13.2.2(ii) requires the plan to state calendar time and man-hours. Compare man-hours per phase across bids and the gap usually explains itself in about ten minutes — and if one bidder cannot produce the plan at all, that is the answer rather than a delay. The other thing worth checking is what the cheap bid is testing against: §8(ii) rules out limited lists such as the OWASP Top 10 or SANS Top 25 as standards or references for audits, and names the comprehensive alternatives — ISO/IEC standards, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM 3, the OWASP Web Security Testing Guide, ASVS, the Mobile Security Testing Guide and the DevSecOps Maturity Model.
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, SOC 2 and the DPDP Act.
Frequently Asked Questions
What is the difference between VAPT and penetration testing?
What is the full form of VAPT?
What is VAPT?
What is the difference between a vulnerability assessment and a penetration test?
What is the difference between a penetration test and a red team engagement?
Is vulnerability scanning the same as a vulnerability assessment?
Why does CERT-In use the term “Red Team” for an auditor’s own verification team?
What is a White Team in CERT-In’s terminology?
What does EAPT mean, and how is it different from VAPT?
How do I tell whether a quote is offering a scan or a real test?
Which one does a CERT-In empanelled audit or a safe-to-host certificate require?
How often does each of these need to happen?
Will a red team engagement disrupt production?
Can the red team phish our staff, and can we be told who clicked?
What should the report contain, whichever engagement we bought?
Does the auditor have to send our test results to CERT-In?
Is a red team assessment the same as a purple team exercise?
Does the CERT-In panel list tell me who can do red teaming?
Does our VAPT satisfy a customer’s request for a penetration test report?
Is VAPT mandatory in India?
Does a red team assessment have to be done by a CERT-In empanelled organisation?
Do these CERT-In rules apply if our tester is not CERT-In empanelled?
How much does a VAPT cost?
How long does a VAPT take?
The instruments behind every clause
Every definition and rule on this page is drawn from one of the following, and each is linked so you can read the clause rather than our paraphrase. Section numbers in the form §13.2.2(ii) refer to the Comprehensive Cyber Security Audit Policy Guidelines unless another document is named.
Every §-locator on this page was checked against the instruments below on 22 September 2026, and every URL below was fetched on the same date with its status code, content-type and byte size recorded. Both halves of that matter, and the second is the one usually skipped: cert-in.org.in answers 200 with a 938-byte HTML page for unknown paths under /PDF/, so a status code alone proves nothing about whether a document exists. The 2025 guidelines are version 1.0 and will be superseded. Where an instrument is revised, this block is where it changes first. Two documents those guidelines name are deliberately absent because they cannot be retrieved: the “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” cited at §15.2.1(iv), and the Deter and Punish Framework cited at §11(iv) and §19. As at 22 September 2026, both cert-in.org.in paths printed in the guidelines served the CERT-In home page rather than a document. They are named here as the guidelines name them, and not linked.
Four statements on this page are negative — that scanning is not named in the 2025 guidelines, that blue and purple teams are not defined anywhere in the instruments, that red teaming carries no stated cadence, and that EAPT is named without being defined. Each of those was established by full-text search of the 2025 audit policy guidelines, the 2018 auditor guidelines and the empanelment terms and conditions v7.2 on 22 September 2026, not by having failed to find them. Absence is a claim like any other, and it needs the same work.
- Comprehensive Cyber Security Audit Policy Guidelines · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 1.0, 25 July 2025 · 69 pages, 20 sections · relied on for §2, §4(ii), §5(xvii) and the definitions restated at §5(xxi)–(xxiii), §6 and its definitions at (iii), (iv), (ix) and (xvi), §7, §8(i)–(ii), §9.3(iv), §9.5(iii), §10.1, §10.3, §10.6, §11(iii), §12.1, §12.2(iv), §12.4(i)–(ii), §13.1.1, §13.1.2(i)–(v), §13.1.3, §13.1.4(ii), §13.2.1(iii), §13.2.2, §13.2.3, §13.2.6, §13.2.7(i)–(ii), §14.1(ii), §14.2, §14.3, §15.1.1, §15.1.2, §15.2.1(iv), §15.2.2, §15.2.3, §15.2.5(iii), §16.1–§16.6, §17(i), §18(iii) and §18(vi)
- Guidelines for CERT-In Empanelled Information Security Auditing Organizations · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 3.0, May 2018 · 6 pages · relied on, under Technical, for the verification team (Red Team) verifying the audit team (White Team), for industry standard methodologies rather than solely tools-based testing, and for the DDoS and flood-testing restrictions
- 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 · relied on for clauses 3.1.7 and 3.2.2, and for Annexure I items 10, 12, 14, 15, 17, 18 and 20 to 22, and Annexure II, the audit report content format
- Empanelled Information Security Auditing Organisations by CERT-In — the snapshot information · Indian Computer Emergency Response Team (CERT-In), MeitY · the published list §10.2(vi), §12.1(i) and §12.3(iii) refer to · 997 pages at the time of checking · relied on for the anatomy of the snapshot and the seven fields it carries
- Policy Guidelines for Handling Audit related Data · Indian Computer Emergency Response Team (CERT-In), MeitY · Version 1.0, June 2014 · 5 pages · required by §10.3(vii) by name · relied on for §5.3.3, the prohibition on hosting the report on public file or cloud services
- Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 · CERT-In, MeitY · No. 20(3)/2022-CERT-In · 28 April 2022 · the directions §15.2.1(iv) requires to be verified in every audit assignment
- 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(ii), §8(iii) and §13.1.8(i)
- Guidelines for Indian Government Websites and Apps (GIGW 3.0) — the manual · National Informatics Centre with STQC and CERT-In, MeitY · the PDF linked from guidelines.india.gov.in as “Download GIGW Manual 3.0” · 121 pages · relied on for guideline 5.3.1 (the audit clearance requirement, manual p.80) and guideline 5.3.2 (hosting environment, manual p.84 onwards, government organisation action item (f), which is the source of the periodic VA and PT obligation quoted here) · cite the manual for these numbers: the live attributes page prints “5.3.2” twice and mis-numbers the policies statement
- GIGW 3.0 — security guidelines and attributes (the live page) · guidelines.india.gov.in · relied on for the quote-exact text of 5.3.1 and the evaluator action requiring a valid certificate · note the numbering caveat above · the phrase “safe to host” does not appear on this page
- GIGW 3.0 — new features · guidelines.india.gov.in · the page that carries the phrase in official use: government organisations “must continue to obtain a ‘safe to host’ certificate issued by the cybersecurity auditors empanelled by CERT-In/STQC or the auditors of STQC or NIC”
- OWASP Application Security Verification Standard · Open Worldwide Application Security Project · not a government source · named at §8(ii) of the audit policy guidelines and in GIGW 5.3.1 · relied on for the existence of three verification levels, and for the 5.x line being the current stable release at 22 September 2026 — a scope of work should name the version it means, because that will change
- OWASP Web Security Testing Guide · Open Worldwide Application Security Project · not a government source · named at §8(ii) as one of the comprehensive alternatives to limited lists · listed here because this page tells buyers to demand a named testing guide, which means giving them the document
- OWASP Mobile Application Security Testing Guide · Open Worldwide Application Security Project · not a government source · §8(ii) names the “OWASP Mobile Security Testing Guide (MSTG)”, but at 22 September 2026 OWASP publishes mobile testing guidance at the URL below as the Mobile Application Security Testing Guide (MASTG), under the OWASP Mobile Application Security project. Name the document and its version in a scope of work rather than the acronym
- CERT-In SAMVAAD 2026 concludes — press release · Press Information Bureau, Ministry of Electronics & IT, Government of India · Release ID 2256581 · 29 April 2026 · relied on only for the statement that AI driven red teaming methodologies were among the topics presented
Related reading: what VAPT is, the types of VAPT, how to scope a VAPT, how to read a VAPT report, retesting and closure, what a CERT-In empanelled auditor may and may not do, how empanelment works, what CERT-In is, the CERT-In Directions of 2022, what a safe-to-host certificate is, how to verify a CERT-In audit certificate, 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 moreWhat AI Red Teaming Is
Adversarial testing of AI systems: what it targets, how it differs from a penetration test, and what it produces.
Read moreScoping a VAPT
Assets, environments, credentials, exclusions and the rules of engagement to agree before testing starts.
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 more