Most organisations plan the testing half of a VAPT engagement and improvise the other half. Retesting — the follow-up audit — is where a list of findings becomes a defensible statement about a system: each observation verified against a build you can identify, each remaining item disposed of by a named office with a date. It is also the half that decides your go-live date.
The operative clause: §16.3(iv) of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines — “After remediation actions, follow-up audits should be performed by auditing organizations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit.” §16.3(iii) says the report should state closure timelines by severity, and §16.3(v) puts the final report after closure and the follow-up audit.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · Empanelment terms v7.2 (April 2024) · Auditor Guidelines v3.0 (May 2018) · Every clause locator read against the primary instrument on 22 September 2026
What is VAPT retesting, and what is closure?
VAPT retesting is the verification pass an auditing organisation runs after you have remediated, to establish that each reported finding no longer exists in the deployed build. Closure is the outcome of that pass: a weakness that is gone, verified by somebody who did not fix it, against an artefact you can identify by version and hash. CERT-In calls the pass a follow-up audit. §16.3(iv) of the Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) states it in terms — after remediation actions, follow-up audits should be performed by auditing organisations to verify closure. §9.3(iv) then adds the limb that is not optional: follow-up audits should be included within the scope or RFP proposal, and must be conducted by the auditing organisation after the closure of vulnerabilities or issues identified during the initial audit. That distinction runs through this page: where an instrument says must or shall, so do we. Where it says should, we say so.
The same instrument names the document the pass produces. §5(viii) defines a Closure Report as a comprehensive report generated at the conclusion of the audit, indicating that all audit observations, findings and issues have been addressed, remediated or closed, and confirming that the audit engagement has met its objectives and that all necessary corrective actions have been taken. Read that definition carefully and you will notice the word that does most of the work: addressed. Not every finding gets fixed. Some are closed with a compensating control, some are risk-accepted, some are partially closed with a dated residual — and each of those is a legitimate outcome with a named authorising office behind it. What is not legitimate is an open finding with no disposition at all. That is not a residual risk. It is an unfinished audit.
“After remediation actions, follow-up audits should be performed by auditing organizations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit.”
“The Final audit report should be issued after the closure of vulnerabilities & completion of follow-up audit of the application hosted on production environment. If the audit scope is limited to the staging platform, the report must explicitly state that the audit was not conducted on production environment.”
Those two clauses explain why closure planning belongs in the tender rather than in a status call. A first pass on an application that was never threat-modelled produces a finding count nobody budgeted for, and the report cannot issue until the findings are closed and re-verified on production. The testing is rarely the long pole. Remediation is your own development cycle, the retest cannot start until remediation is deployed, and the report cannot issue until the retest is done. Everything upstream of that — scope, staging readiness, the retest rounds you bought — determines how long the downstream half takes. If you are earlier in the process than this, start with what VAPT is and how a VAPT scope is written.
Key Takeaways
- Retesting is CERT-In’s follow-up audit. §16.3(iv) puts it with the auditing organisation — after remediation actions, follow-up audits should be performed to verify closure of the vulnerabilities and non-conformities highlighted in the previous audit. It is not a courtesy and it is not the developer’s confirmation.
- Closure timelines by severity belong in the report — §16.3(iii) says the audit report should mention appropriate timelines for closure of vulnerabilities according to severity — but no CERT-In instrument fixes the number of days per band. Agree them in the engagement letter and write them into the report.
- Closure evidence has to demonstrate the behaviour of the deployed system and reconcile to a build — §15.2.3(ii) makes the application hash and version mandatory report content, which is what a closure reconciles against.
- Retest scope is a decision, not a default: the finding, the class of finding by CWE, or the whole system. Critical and high findings deserve a class sweep, because a defect that appeared once usually appeared wherever the same habit appeared.
- A finding ends in exactly one of seven states. Partial closure, compensating controls and risk acceptance are legitimate — each needs a residual statement, a named authorising office and a review date.
- The auditor never waives. §9.2(i) puts risk treatment with the head of the auditee organisation and §9.2(ii) puts an application exception with the head of the organisation that owns the application.
- A reopened finding is a process defect, not a code defect. §13.1.7(iii) says an escalation matrix should be defined in the audit contract for repeated vulnerabilities, and §15.2.1(iii) turns unresolved items into repeat observations next cycle.
- The retest belongs in the price. §13.1.1(g) and §9.3(iv) put follow-up audits in the scope of work — and §9.3(iv)’s second limb is a must. §7 requires the commercial arrangement to be structured to maintain independence, and says payments should not be tied to the submission or approval of any closure report.
- A critical left unfixed even at follow-up reaches CERT-In within five days, with your organisation named — clause 3.2.2 of the empanelment terms, without your explicit permission under clause 3.1.7.
Retest, follow-up audit, revalidation: four names, three different things
These get used interchangeably and they are not interchangeable. They have different triggers, different payers and different outputs, and the difference decides whether the work is already inside your price. Everything below this block uses them in the sense defined here.
Retest
The colloquial name for the verification pass, and the word every project plan uses. It has no clause behind it, which is why an engagement letter that says only “retest included” has not actually specified anything. Triggered by a remediation build. Paid for inside the engagement, if it was bought. Produces a disposition per observation.
Follow-up audit
CERT-In’s own name for the pass. §16.3(iv): after remediation actions, follow-up audits should be performed by auditing organisations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit. Triggered by remediation, inside the same engagement. §9.3(iv) puts it in the scope or the RFP proposal and makes conducting it after closure a must. Produces the verification the final report under §16.3(v) depends on.
Revalidation clause
A contractual return visit, and a different animal. It fires after the compliance window mentioned in the auditee’s own information security audit policy — not after a build. It therefore presupposes that you have an audit policy and that the policy states a window. Paid for as part of the contract it sits in. This is the clause almost nobody includes.
Repeat-observation revalidation
Next cycle’s duty, not this cycle’s. The auditing organisation must revalidate observations from the previous audit cycle, and any unresolved issues should be recorded as repeat observations in the current audit cycle. Triggered by the next audit starting. Paid for as part of that audit. Produces a repeat flag, which is a governance signal rather than a technical one.
VAPT closure timelines, severity by severity
Two things get confused here and they should not be. Stating the timelines is the report’s job: §16.3(iii) says the audit report should mention appropriate timelines for closure of vulnerabilities according to severity, and the 2018 Auditor Guidelines carry the same sentence. Setting the numbers is yours: no CERT-In instrument prescribes a number of days for any severity band, so any page that tells you CERT-In requires criticals to be fixed in exactly seven days is inventing a rule. Recommending a band is a different act, and the windows below are ours, labelled as ours. What the instruments do fix is the notification timing, which is the column most engagements get wrong. The windows below are defensible starting points for an engagement letter, not quotations.
| Severity | When you must be told | A defensible closure window | Retest scope | Who authorises a deviation |
|---|---|---|---|---|
| Critical CVSS 9.0 – 10.0 | During the audit, on an as-and-when-found basis, and again in the Final Outcome Report — §16.3(ii). Where the finding is a discovered breach, a vulnerability with a known high exploitation rate, unmonitored or untraceable access, or anything posing an immediate risk to life, §16.4 requires immediate notification with a recommended practical solution, and §15.2.2(i) adds CERT-In to the list of recipients. | Days, not sprints. TCSA’s recommended target, offered as ours rather than as a rule from any instrument: deployed within 7 days of notification, retested within 7 days of deployment. No CERT-In document sets this or any other number. | Targeted retest of the finding plus a class sweep. A critical rarely has only one instance, and the sweep is what establishes that rather than assuming it. | The auditing organisation never waives — §9.2 puts the decision with the auditee, and it is not severity-scoped: §9.2(i) covers retain, avoid, transfer and reduce for any reported vulnerability or observation, so a critical can be formally retained by the head of the auditee organisation like anything else, or by the head of the owning organisation under §9.2(ii). Two consequences bite here that do not bite lower down. Clause 3.2.2 of the empanelment terms sends an unfixed critical to CERT-In with auditee details inside five days, and clause 3.1.7 means your permission is not sought for it. And §16.3(v) holds the final report — and with it the certificate — behind closure and the production follow-up audit. The route exists, but it is expensive and visible, which is a different thing from it not existing. |
| High CVSS 7.0 – 8.9 | Same as critical: as and when found during the audit, and in the Final Outcome Report — §16.3(ii). | A defensible band to write into an engagement letter: 14 to 30 days, measured from notification rather than from the draft report. Ours, not an instrument’s. | Targeted retest, plus the same class across every in-scope asset. A high on one endpoint is a question about the other endpoints, not an answer about them. | In principle §9.2(ii) permits an exception authorised by the head of the organisation that owns the application. In practice this is the band where a department should expect to be told no, and where a compensating control has to be evidenced rather than described. |
| Medium CVSS 4.0 – 6.9 | In the report. §16.2(ii) requires the severity to be supplemented with EPSS, and a medium carrying a high exploitation probability is not a medium in operational terms — that is precisely what EPSS is in the instrument for. | A defensible band: 30 to 90 days, with a date against each item rather than a blanket quarter. | Sampled. Agree the sample rule in writing before the retest, because a sample nobody defined is a sample nobody can defend. | Risk treatment, authorised under §9.2(i) by the head of the auditee organisation, with the accepted item still carrying a closure timeline in the report. |
| Low CVSS 0.1 – 3.9 | In the report, with the evidence. §18(iii) has every observation well supported with objective evidence, compiled carefully and correctly with the report, and that applies to a low as much as to a critical. | Next planned release, or the next audit cycle. State which. | Usually verified from evidence rather than by re-execution, unless the fix touched shared code. | The auditee’s own risk register, under the same §9.2(i) authorisation. The cost of skipping this is §15.2.1(iii): unresolved items return next cycle as repeat observations. |
| Informational No CVSS score | In the report, distinguished from scored findings so the counts stay honest. Annexure I of the empanelment terms — a list of what an auditee should expect from an auditor — puts it at items 20 and 21: reports include all unknowns clearly marked as unknowns, and state clearly all states of security found and not only failed security measures. | Tracked, not timed. An informational item with no owner is a finding that will be rediscovered. | Not retested as a rule. Closed on evidence or carried forward with a decision recorded. | None needed — but record the decision anyway. In our experience the arguments in cycle two start with an informational item somebody silently dropped in cycle one. |
The CVSS ranges in the first column are the qualitative severity rating scale published with the Common Vulnerability Scoring System by FIRST, not a CERT-In classification. What CERT-In requires is the pairing: §16.2(ii) obliges auditors to implement both CVSS and the Exploit Prediction Scoring System, categorising observations on CVSS for severity and supplementing that with EPSS to assess the likelihood of real-world exploitation, with every reported observation mapped to a CWE and a CVE number. That pairing is what makes a closure timeline arguable in the right direction — a CVSS 5.8 with a high EPSS value has no business sitting in a ninety-day queue behind a CVSS 6.4 that nobody has ever exploited.
Start the clock at notification, not at the report. §16.3(ii) requires critical and high findings to be notified to the auditee during the course of the audit on an as-and-when-found basis, and to be reported again in the Final Outcome Report. On a three-week testing pass that is routinely two or three weeks of remediation time available before the draft report exists. Teams that measure their closure window from the report date give that time away, and it is the cheapest time in the engagement.
What counts as VAPT closure evidence, class by class
§18(iii) sets the standard and it is a high one: all observations well supported with objective evidence, compiled carefully and correctly with the report, and presented in a manner that decision makers are able to use effectively in making credible risk-based decisions. The practical translation is that closure evidence has to demonstrate the behaviour of the deployed system and reconcile to a build you can name. The third column is the one worth reading twice — it is what actually arrives in most evidence packs.
| Finding class | What proves it is closed | What gets submitted and proves nothing | Retest technique |
|---|---|---|---|
| Injection — SQL, command, template, LDAP | The original payload re-executed against the fixed build and returning the application’s ordinary error or validation response, captured as a full request and response pair with the build identifier. Plus the code-level change: parameterised query or prepared statement, shown in the diff. | A screenshot of a web application firewall rule. A WAF rule blocks a payload, but it does not fix a query. The retest has to distinguish “the fix worked” from “something in front of the fix worked”, which usually means testing from inside the WAF or with the rule disabled for the test window. | Re-execute the recorded payload, then three mutations of it. Encoding variants are a common way an injection fix closes only partially: one encoding handled, another still reaching the sink. |
| Broken access control — IDOR, horizontal and vertical privilege escalation | The same request, with the same object identifier, replayed with each of the other roles’ session tokens, and the authorisation denial returned by the server rather than by the interface. Evidence is the response, per role, per endpoint. | A screenshot of the admin menu no longer appearing for a standard user. Hiding a control is not enforcing one, which is why an interface capture proves nothing here — the server’s response does. | Authenticated testing at every privilege level in the role matrix, not at two of them. Ask for the role matrix before the retest and test the cells, not the roles. |
| Broken authentication and session management | A replayed session identifier that is rejected after logout, a session identifier that changes on privilege elevation, an expiry that actually expires, and a password-reset token that is single-use. Each demonstrated as a request and response, with timestamps. | A configuration page showing a session timeout value. The value is the intention. The server’s behaviour is the control. | Time-based tests need a documented clock. Record the timestamps in the working notes so the evidence is reconstructable months later. |
| Transport and cryptographic configuration | A fresh protocol and cipher enumeration against the host, showing weak protocols and suites refused, captured with the tool name, version and timestamp, and repeated against every host and port in scope rather than the marketing hostname. | A vendor dashboard screenshot, or a scan of the load balancer when the finding was on the origin. This class closes cleanly on evidence — but only if the evidence covers the same endpoint the finding named. | Enumerate, do not assert. And recheck after the next infrastructure change: a proxy or load-balancer configuration rollback reopens this class silently, without touching the application at all. |
| Known vulnerable component — a CVE in a dependency or platform | The dependency manifest or package inventory from the deployed build showing the fixed version, reconciled against the artefact hash that was retested. §16.2(ii) requires every observation to carry a CWE and a CVE, so closure is checked against the CVE that was reported. | “Patched in the next release.” A fix that exists in a branch is not a fix in the environment. Closure attaches to the deployed artefact, which is why §15.2.3(ii) requires application hash values and version numbers to be obtained from the auditee and included in the audit report. | Re-run discovery against the running instance, not against the repository. Backported vendor patches keep the old version string, so record the vendor advisory reference where the version number will not move. |
| Security misconfiguration and hardening gaps | The effective configuration read back from the running system — headers observed on a live response, a directory-listing request returning the correct status, a default account authenticating unsuccessfully — plus the configuration baseline the change was made against. | A screenshot of the console where somebody toggled the setting. This is the archetype of the useless artefact: it shows an intent, at one moment, on one node, by one person, with nothing tying it to the build that is serving traffic. | Observe from outside the system. Where there is a fleet, sample nodes rather than testing the one the engineer was logged into. |
| Secrets in source, configuration or logs | Two things, and closure needs both: the secret removed from the artefact and from history where the history is reachable, and the secret rotated at the issuer. Evidence is the rotation record with its timestamp, not only the diff. | A commit that deletes the line. A credential that has been published and not rotated is still a live credential, so a diff-only closure leaves the finding open while the register says otherwise. | Retest by attempting the old credential against the issuing service and recording the refusal. Nothing else demonstrates rotation. |
| Insecure file upload and file handling | The original malicious artefact rejected, a renamed and re-encoded variant also rejected, and the storage location shown to be non-executable and outside the web root, evidenced by request and response. | An extension whitelist in the code. The control is what the server does with the file, including what the content-type sniffing does behind the whitelist. | Retest the storage as well as the upload. These findings often turn on where the file lands rather than on whether it was accepted. |
| Business logic flaws | The abuse sequence re-executed step by step and failing at a named step, with the server-side state shown afterwards. These findings cannot be closed by inspecting code, because the flaw is in the permitted sequence rather than in any one call. | A developer’s explanation of why the sequence is no longer possible. Ask for the sequence to be run. | Keep the original reproduction steps in the register verbatim. A logic finding whose reproduction was summarised is a logic finding nobody can retest. |
| Database configuration and access | Connection attempts from outside the permitted source refused, the application account demonstrated to hold least privilege by a denied operation, and the encryption state read from the instance. §13.1.3 makes a configuration audit the instrument for critical databases. | A policy document saying access is restricted, or an architecture diagram. The diagram is the design. The retest is about the deployment. | Test from a network position that represents the threat, and record the source address used, so the result can be interpreted a year later. |
| Cloud identity and configuration | The effective permission evaluated for the principal, the public-access state of the storage read back, and the change reconciled to the infrastructure-as-code commit that will survive the next deployment. | A console screenshot. Cloud consoles are the most screenshot-friendly and least durable evidence surface there is: the next pipeline run can revert the change without anyone touching the console again. | Close in code, retest in the account. If the fix exists only in the console, record it as a partial closure with a date for the code change. |
| Mobile application findings | A rebuilt binary at a stated version and hash, with the local storage, transport pinning and exported component behaviour re-examined on the rebuilt binary — plus the API-tier retest, because a mobile finding is frequently a server-side finding observed through a client. | A store listing showing a new version number. The version increments for many reasons, but the hash is what the certificate and the register can reconcile. | Retest the binary and the tier behind it as one closure. Splitting them across two engagements is how a closed mobile finding stays exploitable. |
| Logging, monitoring and detection gaps | The event generated deliberately and then located in the retained log, with the retention window demonstrated. For anything in scope of the CERT-In Directions of 28 April 2022, that means a rolling 180 days maintained within Indian jurisdiction. | A screenshot of a logging configuration, or a dashboard with a green tile. Closure here is an end-to-end demonstration: generate, detect, retain, retrieve. | Agree the synthetic event with the auditee in advance so a detection test does not become an incident. |
What one closure evidence bundle contains
The table above says what proves a fix. This is the same standard expressed as a folder, so the reader who accepts the argument can check the pack they were handed against it. Ten items, each with the reason it is there.
The observation ID and the original reproduction steps, verbatim
A retest verifies what was reported. A summarised reproduction is a different test, and a logic finding whose reproduction was paraphrased cannot be retested at all.
The request and response pair, or the tool output, in full
Cropping is where the interesting part goes. §18(iii) asks for evidence presented so decision makers can use it to make credible risk-based decisions — a cropped response is not that.
The tool name and version
A negative result from a scanner is only interpretable against the version that produced it. §16.1(ii) already puts tools among the report contents, and the bundle is where the version lives.
The build identifier and hash, with the algorithm named
§15.2.3(ii) requires application hash values and version numbers to be obtained from the auditee and included in the audit report. A hash with no algorithm reconciles to nothing a year later.
Timestamp with timezone
Session-expiry, token-lifetime and log-retention findings are all time-based, and a bare local timestamp makes the evidence unreadable across a team split between offices.
The environment
§15.2.3(i) requires the environment to be stated — test, development, UAT, pre-production or production — and §5(xiv) and §5(xv) define staging and production as distinct things. A closure in the wrong one is not a closure.
The network position or source address the test ran from
Segmentation, database-access and WAF-related closures are all claims about where the traffic came from. Without the source, the result is uninterpretable.
The tester
§9.5(iii) puts a name on the report and §15.2.5(iii) puts a second pair of eyes behind it. A verification with no name is an assertion.
A sanitisation note: what was redacted and why
Evidence packs contain live payloads and sometimes real data. Recording the redaction is what lets a later reader tell a redaction from a gap.
A naming convention keyed on observation ID plus retest round
OBS-014-R1, OBS-014-R2. Without the round in the name, the second round overwrites the first and the reopening evidence disappears — which is precisely the chain a reopened finding needs.
Two cross-references finish the bundle rather than sit inside it. §18(i) says auditee organisations must seek the working notes upon completion of the audit, with provisions for the same included in the audit contract — those notes are what let a reader who was not present judge a closure. And §18(iv) requires audit evidence to be stored securely, with access restricted to authorised personnel and proper measures including encryption and access controls maintaining confidentiality, integrity and availability throughout the audit lifecycle. The bundle lives there, and the register only points at it.
Why a screenshot of a configuration screen is usually not closure evidence
Screenshots are not worthless. They are context, and in a few classes — a policy value, a console state that no pipeline manages — they are most of what exists. The problem is that they are offered as the evidence, and there are four questions a screenshot cannot answer.
Is the change in the artefact, or only in the environment?
A console edit satisfies a screenshot and not a pipeline. §9.5(ii) asks for version control and change management to be effectively implemented so that the assets which were part of the audit scope can be backtracked — a requirement a screenshot is structurally unable to meet.
Does it apply everywhere, or on the node somebody was logged into?
Fleets drift. A setting corrected on two of five nodes is a partial closure, and the screenshot looks identical either way.
Does the system behave differently, or does the interface just look different?
This is the fatal case for access-control findings. Removing the admin menu changes the screenshot and changes nothing about the controller — the server still answers the request when it is replayed directly.
Which build does it belong to?
§15.2.3(ii) is the mandatory clause: application hash values and version numbers must be obtained from the auditee and included in the audit report. §9.5(i) and §16.1(v) add the recommendation that those artefacts — hash values, versions, timestamps — be captured by the auditee, shared with the auditing organisation and prominently featured in the certificate and reports. A screenshot reconciles to none of them, so the closure it claims cannot be tied to the software that is running.
The fix is cheap and mostly procedural: ask for behaviour, and ask for it against a named build. Where evidence is the right closure route rather than re-execution — a dependency version, a rotation record, an enumeration output — keep it in the evidence store rather than in the register. §18(iv) requires audit evidence to be stored securely with access restricted to authorised personnel and with encryption and access controls maintaining confidentiality, integrity and availability throughout the audit lifecycle. A closure record points at evidence. It does not contain it. What to expect the report itself to carry is set out in reading a VAPT report.
What if the retest finds we were already breached?
Then the item leaves the closure register and enters incident handling, and three duties fire that have nothing to do with the closure clock.
- The auditor reports immediately, not at the exit conference. §15.2.2(i) says high-risk vulnerabilities such as discovered breaches should be assessed and reported immediately to the auditee organisation and to CERT-In. §16.4 separately requires high-risk vulnerabilities — discovered breaches, vulnerabilities with known high exploitation rates, unmonitored or untraceable access, or anything posing an immediate risk to life — to be reported to the auditee immediately upon discovery with a recommendation for a practical solution. Two clauses, two recipients, one timing.
- The auditor stops rather than develops it. The 2018 Auditor Guidelines direct auditors to refrain from testing and exploiting high-risk vulnerabilities such as discovered breaches or anything that may put immediate lives at risk. Expect the finding reported, not proven further.
- Your own six hours run in parallel and are not discharged by any of that. Direction (ii) of the CERT-In Directions of 28 April 2022 requires the entity to mandatorily report the cyber incidents listed in Annexure I to CERT-In within six hours of noticing them or being brought to notice about them — and being told by your auditor is being brought to notice.
Practically: move the item out of the register into the incident record, let the closure cycle continue around it, and do not let the two processes share a status field. The six-hour duty is set out in the CERT-In Directions of 2022.
What a VAPT retest should cover: the finding, the class, or the whole system
“Retest” is three different pieces of work with three different prices, and most disputes about retest cost are really disputes about which one was bought. Assign a scope to each severity band in the engagement letter and the argument never happens. §16.2(ii)’s mandatory CWE mapping is what makes the middle option specifiable rather than a matter of opinion.
| Retest scope | What it is | When it is the right answer | What it costs | What it still misses |
|---|---|---|---|---|
| The finding | Re-execute the recorded reproduction steps for that one observation against the remediated build, and record the result. | The finding is genuinely isolated: a single misconfigured header, one outdated component, one endpoint that existed once. It is also the only honest scope where remediation was a configuration change with no code movement. | Hours. This is what most people mean when they say retest, and it is the cheapest thing in the engagement. | Every other instance of the same defect. A retest at this scope answers “is this instance fixed” and is routinely reported as though it answered “is this class fixed”. Those are different sentences and the register should carry both. |
| The class of finding | Re-execute the finding, then sweep every in-scope asset for the same weakness — the same CWE, across endpoints, roles, services and hosts. | Always, for critical and high. A defect that appeared once in an application usually appeared wherever the same developer, framework habit or copied controller appeared. §16.2(ii) makes this practical by requiring every observation to be mapped to a CWE, which gives the sweep a definition. | A meaningful fraction of the original test for that asset class — plan for it rather than discovering it. | Regressions elsewhere. A class sweep confirms the class, but it says nothing about what the remediation build broke somewhere else. |
| The whole system | A fresh assessment pass over the full scope, treating the remediated build as a new build. | Where remediation was large enough to be a major change in its own right — §13.1.2(iii) classifies a change by risk, not by size, and expressly includes configuration adjustments that affect sensitive data or critical infrastructure. A remediation release that rewrites the authorisation layer is a major change, and §13.1.2(iv) says an audit should be performed after every major change. | A second engagement, in effort if not in procurement. Say so at the point the remediation plan is agreed, not at the point the retest is booked. | Nothing structural — but it resets the clock. The build that gets the certificate is the build that was fully tested, and a full retest late in the cycle is the classic cause of a slipped go-live. |
One boundary is worth marking, because crossing it silently is how a retest turns into an unpriced second engagement. Where remediation is large — an authorisation layer rewritten, a framework upgraded, a data store migrated — the remediation is itself a change that §13.1.2(iii) would classify as major. The guideline defines major by risk rather than by size, expressly including system overhauls, technology migrations and configuration adjustments that affect sensitive data or critical infrastructure, and requires the audit before implementation. §13.1.2(iv) adds that an audit should be performed after every major change in infrastructure and application, based on the criticality involved. So a remediation release that rewrites the thing the findings were about is not retested. It is audited. Say that at the point the remediation plan is agreed, not at the point the retest is booked.
A second boundary belongs in the same conversation: regression. A class sweep confirms the class and says nothing about what the remediation build broke elsewhere. Where a remediation touches shared code — an authentication filter, a common validation library, a base image — the honest scope is wider than the findings, and it is cheaper to say so in week one than to discover it in the follow-up audit on production that §16.3(v) puts ahead of the final report. Which classes of testing belong in which pass is covered in the types of VAPT.
Seven states a VAPT finding can end in, and only one is closed
This is the controlled vocabulary the closure register needs. Free text in the status column is how “partially closed” becomes “closed” between two meetings, and how an item that nobody decided about ends up in a report as though somebody had. Every state below carries two obligations: what must be recorded, and who signs.
| State | What it means | What must be recorded | Who signs | What happens next |
|---|---|---|---|---|
| Closed | The weakness no longer exists in the deployed build, and the auditing organisation has verified that by re-execution or by evidence it accepts. §16.3(iv) is the operative clause: after remediation actions, follow-up audits should be performed by auditing organisations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit. | Retest date, retest method, the evidence reference, the build identifier and hash the retest ran against, and the auditor who verified it. | The auditing organisation, under §16.3(iv). §5(xvii) is why the verifying party cannot also be the remediating party — it names conducting audits while also being responsible for remediation activities as a conflict, which cuts against an auditor who helped design the fix just as it does against a developer marking their own work. | Nothing, until the next cycle — where §15.2.1(iii) will revalidate it anyway. |
| Partially closed | The remediation reduced the finding without eliminating it: one of three injection points fixed, the class fixed on the web tier and not the API tier, the setting corrected on two nodes of five. It is a real state and it is the one most often written up as “closed”. | What was fixed, what was not, with the residual expressed as its own observation carrying its own severity and its own closure timeline under §16.3(iii). If the residual has no date, the item is open and undated, not partially closed. | The auditing organisation records the residual, and the auditee accepts the residual timeline. Both entries, or neither. | A second retest against the residual. Partial closure that is never re-dated becomes a repeat observation next cycle under §15.2.1(iii). |
| Closed with a compensating control | The underlying weakness remains, and a different control now makes it materially harder to exploit — network segmentation in front of an unpatchable appliance, a virtual patch in front of a legacy component, monitoring plus an alert where prevention is not available. | The weakness, the compensating control, what the control does and does not stop, the evidence that it is operating, an owner, and a review date. A compensating control with no review date is an undeclared risk acceptance. | This is risk treatment, so it is authorised under §9.2(i) by the head of the auditee organisation. | Retest the control, not the weakness. And re-open the item when the control changes, because the compensation was the whole basis of the closure. |
| Risk accepted | The organisation has decided to live with the finding. It is a legitimate outcome and it is not the auditor’s to grant: the authorisation sits with the auditee under §9.2(i), or with the owner of the application under §9.2(ii). | The finding, the residual risk in business terms, the reason, the compensating measures if any, the named authorising office, the date, and the review date. §16.2(i) asks the executive summary to translate technical findings into business risk — an acceptance written in CVSS terms has not been explained to the person signing it. | A named office, not a committee and not a mailbox. “Approved by the project team” is not an authorisation under §9.2. | Review on the stated date. An acceptance with no expiry is how a finding survives three audit cycles without ever being argued about again. |
| Deferred | Agreed to be fixed, not yet fixed, with a date. Distinct from acceptance: nobody has decided to live with it. Most open items at the point a draft report is issued are properly in this state. | The target date, the owner, the dependency that makes it a deferral rather than a fix, and the retest slot it will be verified in. | The remediation owner, with the authorising office informed. If the deferral crosses the severity band’s closure timeline, it becomes an acceptance decision and moves up the ladder. | One of the other states. Deferral is a waypoint, and a register where items sit deferred for two cycles is a register that has stopped working. |
| Withdrawn as a false positive | On examination the observation does not hold — the control existed, the path was unreachable, the scanner matched a version string the vendor backported a patch into. | Why, with the evidence that establishes it, and the auditor who agreed. A withdrawal is a change to the report, so it belongs in the version history §16.1(iv) puts in the report — draft and final versions, each with its date of issuance, maintained and captured. | The auditing organisation, after the maker-checker review §15.2.5(iii) calls for. A finding withdrawn on the auditee’s say-so is a finding the auditor has stopped auditing. | Nothing — but count them. A report with many withdrawals is telling you something about the first pass. |
| Reopened | Verified closed, then found again — in the same cycle after another release, or in the next cycle. | The original observation reference, the date it was closed, the date it was found again, the build in between, and the change that reintroduced it. That chain is the finding. | The auditing organisation, and it should be escalated. §13.1.7(iii) says an escalation matrix should be defined as part of the audit contract in case of repeated vulnerabilities — this is the clause it exists for. | Root cause analysis, which §5(vii) defines as a systematic investigative process to identify the fundamental causes, addressing the source rather than the symptoms. A reopened finding is a process defect, not a code defect. |
The rule that removes most of the argument
The auditor does not waive findings. §9.2(i) requires risk treatment techniques — retain, avoid, transfer and reduce — for any reported vulnerability or observation to be authorised and accepted by the head of the auditee organisation. §9.2(ii) requires any exception to a reported vulnerability or observation in the application to be authorised by the head of the organisation who is the owner of the application. The auditing organisation records the disposition and verifies what it can verify. It has no clause under which it makes a finding go away, and an auditor who offers to is telling you something about the next engagement.
Why the auditee cannot close its own findings
§5(xvii) defines conflict of interest to include the situation where the same entity is involved in both the implementation of controls and their subsequent audit, or in conducting audits while also being responsible for remediation activities — overlaps the guideline says create inherent conflicts that undermine the independence of the audit process, and which must be disclosed and managed. That is the principle behind §16.3(iv) putting verification with the auditing organisation. It also cuts the other way: an auditing organisation that helped design the fix has acquired the same conflict, which is worth remembering before accepting an offer of remediation support from the firm that will retest.
One more piece of vocabulary, because it appears in the instrument and confuses people. §5(vi) defines Non-Conformity / Non-Compliance as one term: a condition where a process, control or practice fails to meet prescribed standards, regulatory requirements or internal policies. §16.3(iv) puts the follow-up audit on closure of vulnerabilities and non-conformities, so a compliance gap — a missing policy, an unimplemented procedure, an absent review record — is closed and re-verified by the same machinery as a technical finding. The evidence differs. The discipline does not.
A reopened VAPT finding is a process defect, not a code defect
A finding verified closed and then found again is the most diagnostic event in the whole cycle, and it is almost always treated as an embarrassment instead. The guidelines expect repetition and build for it in two places: §13.1.7(iii) requires an escalation matrix to be defined as part of the audit contract in case of repeated vulnerabilities, and §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. Six patterns account for nearly all of them, and each has a different fix.
The retest found something that was not in the report. What is it?
Four answers, and on retest day they look identical to a project manager. They are recorded differently, they escalate to different people, and they say different things about the first pass. Getting this wrong in the register is how a reopening gets written up as a new finding — which quietly removes the only signal that the closure process failed.
| What it is | What happened | How you tell it apart | How it is recorded | Who it escalates to | What it says about the process |
|---|---|---|---|---|---|
| New observation | A weakness that was in scope and was not reported in the first pass. Usually a second instance of a reported class, found because the retest swept by CWE rather than re-executing one reproduction. | Was it in scope, and was it never verified closed? Then it is new. The register distinguishes the instance from the class, so finding the class somewhere else is not a reopening of the instance. | A fresh observation ID, its own CVSS vector, CWE and severity-derived closure timeline. Cross-reference the sibling observation so the pair reads as one class. | The remediation owner, on the ordinary closure clock for its band. | Something about first-pass coverage — which is a scoping conversation, not a blame one. §13.1.1 derives scope from the consolidated and updated asset inventory, and a missed endpoint is usually a missing inventory row. |
| Reopened | An observation that was verified closed by the auditing organisation, and is found again — in this cycle, after a later build. | Was there a recorded verification with a date, a method and a build hash? If yes, and the weakness is back, it is a reopening. If there was never a verification, it was never closed. | The original observation reference, the date it was closed, the date it was found again, the build in between, and the change that reintroduced it. That chain is the finding. | Up the §13.1.7(iii) matrix. A reopening is what that clause was written for. | A process defect. Run the root cause analysis §5(vii) describes and expect one of the six patterns below. |
| Repeat observation | An observation carried over from the previous audit cycle, still unresolved when the next cycle starts. | Did it appear in a prior cycle’s report? §15.2.1(iii) makes the auditing organisation revalidate previous-cycle observations, so this is found by the auditor rather than declared by you. | The repeat flag and the prior observation ID — the two register fields that make this a query instead of an archaeology exercise. | The head of the auditee organisation, because an item surviving a cycle is a risk decision by default whether or not anybody made it. | That the disposition never happened. §19 also reads it from the other side: inadequate closure of non-compliances is the first indicative parameter on CERT-In’s watch-list grade. |
| Regression from the remediation build | A weakness that did not exist before the fix and exists after it. Shared code is the usual route — an authentication filter, a validation library, a base image. | Does it trace to a change made for remediation? The build diff answers this, which is why the fix reference and the build identifier belong in the register rather than in a ticket. | A new observation, flagged as introduced by remediation, referencing the observation whose fix caused it. Both rows matter. Either alone misleads. | The remediation owner and the change board, because the answer is usually about test coverage on the fix rather than about the fix. | That the retest scope was too narrow. A class sweep confirms the class and says nothing about what the build broke elsewhere — which is the argument for treating a large remediation as a major change under §13.1.2(iii) rather than as a retest. |
Six patterns behind a reopening, and what each one changes
| Pattern | What it usually means | What to change |
|---|---|---|
| Closed on a hotfix, reopened on the next release | The fix went into a running environment and not into the source of truth — a console change, a manual configuration edit, a patch applied to one node. The deployment pipeline then overwrote it. | Close in the artefact the pipeline builds from, and retest after a deployment rather than before one. §9.5(ii) is the clause underneath this: version control and change management to be effectively implemented so that the assets which were part of the audit scope can be backtracked. |
| Closed on one instance, reopened on another | The retest scope was the finding when it should have been the class. The defect was never singular. The evidence was. | Sweep by CWE. §16.2(ii) makes the CWE mapping mandatory, which makes the sweep specifiable in the engagement letter instead of negotiable on the day. |
| Closed, reopened with a different payload | The fix handled the reported input rather than the underlying weakness — an encoding, a content type or a code path was left out. This is a partial closure that was recorded as a closure. | Require the retest to include mutations of the original payload, and record in the register which mutations were tried. That single field prevents most of these. |
| Closed in the application, reopened in a dependency | The application code moved and the component underneath did not, or moved backwards. Lockfile drift and container base-image drift produce this quietly. | Reconcile the closure to a build hash, not to a release name, and keep the component inventory with the closure record. |
| Reopened across the audit cycle boundary | It was never closed. It was reported as closed. §15.2.1(iii) is designed to catch exactly this — the auditing organisation must revalidate observations from the previous audit cycle, and unresolved issues are recorded as repeat observations in the current cycle. | Treat a repeat observation as a finding about the closure process and escalate it under the matrix §13.1.7(iii) says should be in the contract. Then look at how the first closure was evidenced, because the answer is usually a screenshot. |
| Reopened after a third-party or subservice change | The control lived on somebody else’s side of the boundary — a hosting provider, an identity component, a shared platform — and changed without notice. | Record the owner of the control in the register, not only the owner of the finding. Where the application sits on infrastructure the auditee does not own, §13.1.5 already splits the audit responsibility, so split the closure the same way. |
The instrument has a name for the response. §5(vii) defines Root Cause Analysis as a systematic investigative process used to identify the fundamental causes or underlying factors contributing to an incident, audit finding or failure, seeking to address the source of the issue rather than merely its symptoms to ensure effective corrective actions. Applied to a reopening, that means the question is not “who forgot” but which of the six rows above you are in — and the answer changes the register, the pipeline or the contract, not the ticket.
Repeat observations are also read from the other side. §19 of the 2025 guidelines sets out a graded ladder of consequences for empanelled auditing organisations, and the first grade — move to watch list with warning and written commitment — lists “inadequate closure of Non Compliances (NCs)” as its first indicative parameter, alongside inadequacy of sample details and improper conclusions. The second grade, suspension, lists issues appearing soon after the conduct of an audit. So a pattern of findings that were reported closed and were not is a quality signal about the audit as well as about the remediation, and CERT-In is watching for it.
What to do when the auditor and the team disagree about a closure
Four disputes account for most of them: the auditor will not close an item the team believes is fixed, the auditor closed something that has come back, the retest report has not arrived and the certificate is blocked, or the auditee disagrees with a severity that drives a closure window. Every clause that answers them is already cited above. What nobody assembles is the order to use them in. Work down and stop when the problem is solved.
- 01 Put the disagreement in writing the same day, and name the clause. An email saying the retest result feels wrong gets a different answer from an email saying the closure evidence for OBS-014 does not meet §18(iii) and asking what would. The clause is the vocabulary that makes this a compliance conversation rather than a complaint.
- 02 Invoke §18(v) and ask for the justification. The auditee organisation may request clarifications or justifications for any evidence presented, and the auditing organisation must respond within a mutually agreed timeframe. Note what the clause actually leaves to you: the timeframe is the one you agreed. Agreeing it at signing is the real fix, because agreeing it during a dispute is another dispute.
- 03 Take it to the meeting the contract already provides. §15.2.7 expects regular review meetings with the points of contact, and §15.1.3(i) puts monitoring of execution and timelines through the scheduled progress meetings. Use one, with minutes, rather than inventing an escalation nobody agreed to.
- 04 Walk the §13.1.7(iii) escalation matrix by name, one rung at a time: the remediation owner and the audit point of contact. Then the head of the auditee organisation, who is the office §9.2(i) puts the authorisation with. Then the exit conference §17(iii) already expects senior management to attend.
- 05 If the dispute is about severity rather than closure, argue it on the pairing rather than on the number. §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. A severity argument that never mentions the vector or the EPSS value is an argument about a feeling.
- 06 Withhold only the phase that has not been delivered, and never a fee tied to findings. Phase-based fees exist so you can decline to accept an undelivered phase without recreating the conflict §7 is about. Do not renegotiate the fee against the closure state.
- 07 If the retest report has not arrived and the certificate is blocked, escalate to the head of the auditing organisation. That is the person who has to authorise and sign the report under §9.5(iii), and who therefore has a direct interest in it existing.
- 08 Give feedback to CERT-In afterwards, whatever the outcome. §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 and has no deadline, which is why it is the step most often skipped.
One thing worth noticing about that ladder: five of the eight rungs are clauses you either agreed at signing or did not. The §18(v) timeframe, the §13.1.7(iii) matrix, the review meetings, the phase-based fee structure and the exit conference are all decided before there is anything to argue about. A dispute process invented during a dispute is a negotiation, which is a different and much worse thing.
How to run a VAPT retest: eight steps in the order the guidelines put them
None of this is complicated and most of it is upstream of the retest itself. Two steps — freezing the register before remediation starts, and deciding the retest scope per severity band in writing — account for most of the difference between a closure cycle that takes three weeks and one that takes three months.
Freeze the register before remediation starts
Export the observations from the draft report into the register with the identifiers, CVSS vectors, CWE and CVE mappings, notification dates and severity-derived closure timelines already populated. §16.3(iii) puts the timelines in the report, and the register is where they become dates against owners. Do this before anyone starts fixing, because a register assembled after remediation records what was done rather than what was found.
Decide the retest scope per severity band, in writing
Critical and high get a class sweep by CWE, medium gets a defined sample with the sample rule stated, and low and informational close on evidence. Where the remediation plan amounts to a system overhaul, technology migration or configuration adjustment affecting sensitive data or critical infrastructure, §13.1.2(iii) makes it a major change and §13.1.2(iv) says an audit should be performed after it — which is a full pass, not a retest. Decide that now, not when the developer says the refactor grew.
Remediate against the source of truth, not against the environment
§9.3(iii) puts patching and correction of vulnerabilities on the auditee organisation. The operative discipline is that the fix goes into the artefact the pipeline builds from and the configuration the pipeline applies. §9.5(ii) asks for version control and change management to be effectively implemented so that the audited assets can be backtracked. A console edit satisfies neither, and in our experience that is where most reopened findings come from.
Deploy, then pin the build
Capture the version, the artefact hash and the algorithm, and the deployment timestamp. §15.2.3(ii) is where the obligation bites: application hash values and version numbers must be obtained from the auditee and included in the audit report. §9.5(i) and §16.1(v) recommend that the artefacts be captured by the auditee, shared with the auditing organisation and prominently featured in the certificate and reports. This is the step that converts “we fixed it” into a statement somebody can check next year.
Hand over a retest package, not a status update
Per finding: the observation ID, what changed, the change reference, the build the change is in, the environment it is deployed to, and the evidence the auditee already holds. A retest that begins with the auditor working out what was done consumes the round on discovery. The full readiness list — six items per engagement, six per finding — is set out below this sequence. Put it in the engagement letter §14.1(ii) requires.
Retest, and record the method as well as the result
§16.3(iv) is the operative clause: after remediation actions, follow-up audits should be performed by the auditing organisation to verify closure of vulnerabilities and non-conformities highlighted in the previous audit. The result is a disposition per observation with the retest method, the scope, the evidence reference and the verifying auditor. §15.2.5(iii) applies here too — the verification team reviews the retest, not only the first pass.
Dispose of what did not close, with a named authorisation
Everything still open lands in one of four states: partially closed with a residual that has its own severity and date, closed with a compensating control that has an owner and a review date, risk accepted under §9.2(i) by the head of the auditee organisation, or deferred with a target date. §9.2(ii) adds that an exception on an application is authorised by the head of the organisation that owns the application. The auditor records. The auditee authorises. There is no state in which the auditor waives.
Issue the final report, then stop changing the build
§16.3(v) puts the final audit report after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment, and requires the report to state explicitly where the scope was limited to the staging platform that the audit was not conducted on production. §9.5(i) then asks the developer to avoid code changes to the audited application or infrastructure after the certificate issues. The next change goes through the change classification, not around it.
Two supporting duties sit alongside the sequence and are worth putting on the project plan explicitly. §15.1.3(ii) makes tracking the auditee’s job — the auditee organisation should actively track the closure of the assessment phase, the re-validation phase and overall audit completion — which is the clause that says a closure register is your artefact rather than a document you wait for. And §17(iii) says entry and exit conferences should be organised and attended by senior management, with an exit presentation covering observations, posture, risks, remediation review and next steps. Put the closure state of every observation into that exit presentation, and the people who authorise risk acceptances see them before they are asked to sign.
Retest readiness criteria, written out
Step 05 is the one that decides whether a round is a verification or a discovery exercise, and “readiness criteria” is usually asserted and never enumerated. Here it is as a list, split into what the engagement needs once and what each finding needs every time. Lift it into the engagement letter §14.1(ii) requires and the argument about a consumed round does not happen.
Per engagement, before the slot opens
- The build identifier and hash the retest will run against, stated at least twenty-four hours before the slot. If nobody can name it, the build is not ready and the slot should move.
- The environment named and reachable from the auditor’s test position — and named as one of the environments §15.2.3(i) recognises: test, development, UAT, pre-production or production.
- Test accounts at every role in the matrix, re-provisioned and unexpired. Expired retest credentials are the single most avoidable way to lose a morning.
- The evidence store path agreed, so closure evidence lands somewhere §18(iv) would recognise rather than in an email thread.
- The named auditee point of contact available for the window, with the escalation path for the day written down.
- Every third-party, subservice or hosting component owner confirmed deployed — not scheduled, deployed.
Per finding, every time
- Observation ID, exactly as the report states it.
- What changed, in one sentence a tester can act on.
- The commit or change-request reference.
- The build the change is in, and whether that build is the one in the named environment.
- Whether the fix is in the artefact the pipeline builds from, or only in the environment — say so honestly, because the retest will establish it either way and the honest answer saves the round.
- The auditee-side evidence already held, referenced rather than pasted.
The rule the whole list exists to state: a retest slot is consumed when the retest starts, not when it succeeds. That is why readiness is a contractual condition rather than a courtesy, and why the honest answer to “is the fix in the build or only in the environment?” saves the round even when the answer is the embarrassing one.
The retest is what the certificate is actually about
On a government or PSU engagement the closure cycle ends in an instrument, and the instrument is not really a statement about the testing. 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 before hosting in the production environment — what MeitY’s own note calls a safe-to-host certificate. The sequencing clause is about the report rather than the certificate: §16.3(v) puts the final audit report after the closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment. The certificate is issued off the back of that report. So a certificate that pre-dates a closed register is describing a report that should not yet exist — which is the practical reason the closure half sits on the critical path, and not a sentence any instrument writes about certificates directly.
Three consequences follow, and each of them surprises somebody on every project.
A clean first pass is not the goal, a closed second pass is
A report with thirty findings and a complete closure record is a stronger document than a report with four findings and a vague one. The certificate rests on the closure, not on the finding count — and a first pass that found almost nothing is a question about the scope, which §13.1.1 requires to be derived from the consolidated and updated asset inventory and vetted by internal audit in consultation with the CISO.
The build gets frozen, and the freeze is the point
§9.5(i) says the application developer should avoid making any code changes to the audited application or infrastructure after issuance of the audit certificate. What pins the build is §15.2.3(ii), under which application hash values and version numbers must be obtained from the auditee and included in the audit report — with §9.5(i) and §16.1(v) recommending the same artefacts be prominently featured in the certificate. The certificate describes a build. A hotfix after issuance describes a different one, and the change then runs through the classification §13.1.2 requires rather than around it.
Staging tested, production verified
§15.2.3(ii) requires the auditing organisation 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. §16.3(v) then puts the follow-up audit on production. Those are not in tension: the assessment happens where it cannot break a live service, and the verification happens where the software will actually run. Where the scope never reached production, §16.3(v) requires the report to say so explicitly — and a reader who skips that sentence has misread the certificate.
There is also a reporting line that runs past you. Clause 3.2.2 of CERT-In’s Terms and Conditions for Empanelment (version 7.2, April 2024) makes it mandatory for the empanelled auditing organisation to share the audit report and audit metadata with CERT-In within five days of completion of the audit, and to report all critical vulnerabilities along with auditee details inside the same five days where those vulnerabilities were pointed out during the audit but not fixed by the auditee organisation even during follow-up audits. Clause 3.2.1 lists the same two items as mandatory data. Clause 3.1.7 settles the consent question, since empanelled organisations provide audit reports and data to CERT-In without the auditee’s explicit permission. And §10.6 of the 2025 guidelines restates the five-day duty. Read together, those clauses say something straightforward: an unfixed critical does not quietly stay inside the engagement. How to check the resulting instrument is covered in how to verify a CERT-In audit certificate, and the rules the auditor works under in what a CERT-In empanelled auditor may and may not do.
Does closing findings extend the certificate? No. Closure is what lets the certificate issue, but it does nothing to how long the certificate stays true afterwards. That is set by the issuing body’s own validity line and by the audit cadence rules — and the two are not the same instrument, so they are handled separately in how long a safe-to-host certificate lasts. A second closure cycle on the same certificate does not buy you another year.
Who pays for the retest: six clauses that belong in the engagement letter
The answer to the question in the heading is: you do, and it should already be in the price. The reason it so often is not is that the retest was never written down as a deliverable, so it arrives as a quotation at the worst possible moment. §14.1(ii) names the instrument this belongs in — the agreed terms must be formally documented in an audit engagement letter, reviewed and signed by authorised representatives from both the auditing and the auditee organisation, and serving as a binding reference point throughout the engagement.
| Clause | What the instrument says | How to draft it |
|---|---|---|
| Follow-up audits are in the scope of work | §13.1.1(g) directs that the scope of work should clearly specify the requirement to conduct follow-up audits as part of the engagement. §9.3(iv) splits into two limbs with different force: follow-up audits should be included within the scope or RFP proposal, and must be conducted by the auditing organisation after the closure of vulnerabilities or issues identified during the initial audit. The second limb is the one an auditor can be held to. | Name the number of retest rounds included, the retest scope per severity band, and the response time between remediation notice and retest. A scope that says “retest included” without those three is a scope that will be argued about. |
| A revalidation clause, tied to your own compliance window | §13.1.7(i) lists what the contract should include, and (g) is the clause to revalidate the audit observations after the compliance window mentioned in the IS audit policy of the respective auditee organisation. | This is the clause almost nobody includes, and it is the one that brings the auditor back after your own deadline has passed rather than after a fixed number of days. It presupposes you have an audit policy with a compliance window in it — write the window before you write the clause. |
| Commercial arrangements structured to maintain independence | §7 (Independence) requires the commercial arrangements between auditee and auditing organisation to be structured to maintain independence. On payments its own modality is softer and worth quoting accurately: payments should not be contingent upon the outcome of the audit — whether favourable or unfavourable — nor should they be tied to the submission or approval of any closure reports, because linking payments to audit outcomes or closure status could compromise the impartiality of the assessment and create a conflict of interest. It then recommends that fees be based on predefined scopes, deliverables and timelines. | So a milestone worded “on closure report approval” is the exact structure §7 tells you not to use, named in the clause. Pay for the retest as a deliverable with an effort estimate, never as a bonus for a clean result. §13.2.2(ii) requires the test plan to carry both calendar time and man-hours, which is what makes a retest priceable honestly. |
| An escalation matrix for repeated vulnerabilities | §13.1.7(iii) states that an escalation matrix should be defined as part of the audit contract in case of repeated vulnerabilities. | Write it as a ladder with names: first repeat to the remediation owner and the audit point of contact, second to the head of the auditee organisation who authorises risk treatment under §9.2(i), third to the exit conference §17(iii) already expects senior management to attend. |
| A contract long enough to have a second cycle | §12.4(i) says contracts for critical or high-user-reach applications should be awarded for a period of two to three years, and §12.4(ii) requires the contract to let the auditee stop and switch auditor. | A multi-year contract makes revalidation cheap and repeat observations visible. The switch clause is what stops that turning into dependence. |
| Who pays when a retest fails | No CERT-In instrument addresses this, and any page that tells you it does is inventing a rule. It is a commercial term, and it belongs in the audit engagement letter §14.1(ii) requires to be signed by authorised representatives of both organisations. | The defensible position: included retest rounds cover verification. A round consumed because remediation was not deployed, or was deployed to the wrong environment, is a rescheduling cost the auditee carries. Write the readiness criteria for a retest slot into the letter — they are enumerated in full under the retest sequence — and the argument disappears. |
“Payments to the auditing organization should not be contingent upon the outcome of the audit—whether favorable or unfavorable—nor should they be tied to the submission or approval of any closure reports.”
That clause is the one a finance reviewer will try to remove, because a milestone that pays on a clean closure report looks like sensible outcome-based contracting. It is the opposite. Under that structure every finding the auditor writes down costs the auditor money, and every finding the auditor declines to reopen at retest earns it some. There is no technical requirement in a tender that does more damage than this one, and it is invisible in the deliverable — you get a clean closure report and buy none of the assurance.
How many retest rounds should be in the contract?
Three places above tell you to name the number of rounds and none of them says how to choose it. What drives it is the expected finding count, the release cadence and the number of owners — in that order, and the third one surprises people. These are our recommendations rather than anything an instrument sets.
| Engagement shape | Rounds | What drives it | What the round is bought as |
|---|---|---|---|
| One application, mature release pipeline, prior audit history | Two rounds | A small expected finding count, a release cadence that can absorb two builds inside the closure window, and one owner for everything in scope. The second round exists for the residual and for anything the first round finds while sweeping the class. | Two follow-up audits named as deliverables, each with its own man-hour estimate. §13.2.2(ii) already requires the test plan to carry both calendar time and man-hours, so ask for the retest rounds to be expressed the same way rather than as a line item with no shape. |
| First-ever audit on an application that was never threat-modelled | Three rounds | A high expected finding count and, more importantly, class instances: the first sweep by CWE routinely surfaces siblings of reported findings, and those siblings need a round of their own. Budget for the second round being a real round rather than a formality. | Three rounds, with the class-sweep scope written into rounds one and two explicitly. If the remediation turns into an authorisation-layer or framework rewrite, §13.1.2(iii) makes that a major change and §13.1.2(iv) calls for an audit after it — which is a fresh pass and should be priced as one, not absorbed into a round. |
| A portfolio, or a scope crossing a subservice or hosting boundary | Rounds per asset group, not per engagement | The number of owners, not the number of findings. Round scheduling is gated by somebody else’s deploy calendar, and a single shared round means one late third party consumes it for everyone. §13.1.5 already splits audit responsibility where the server is owned by another organisation, so split the rounds the same way. | A round per asset group with independent scheduling, plus a named window inside which a group can be re-slotted without a variation order. Say in the letter what happens to an unused round. |
Six questions about the retest that procurement asks and nobody answers
Everything above assumes the clean case: one empanelled organisation, one application, one owner, a cycle that finishes. These are the situations where that assumption breaks — and in each of them the guidelines have an answer most people on both sides of the table have not read.
Can a different empanelled organisation do the retest?
Yes — nothing ties the follow-up audit to the organisation that ran the first pass, and §12.4(ii) contemplates a contract that lets the auditee stop the audit and choose another empanelled organisation. What it costs you is context. The incoming team has to re-derive the reproduction steps, the source positions and the role matrix from the report alone, which is the argument for §18(i): auditee organisations must seek the working notes upon completion of the audit, with provisions for the same included in the audit contract, and should ask for the evidence collected during the assessment as an appendix to the final report. Those notes are the handover artefact. Contract for them before you need them, not when you are switching.
Does the same lead auditor have to sign the retest?
Not the same individual — the same class of individual. §9.5(iii) requires audit reports to be signed only by the manpower declared to CERT-In in the organisation’s snapshot information, signed by the auditors who conducted the audit, then 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. The audit certificate is signed by both the Lead Auditor and the head of the organisation. So a retest performed by a different declared auditor is fine, but a retest verified by somebody who is not on the declared list is not, and the list is the published one.
Does the verification team have to review the retest too?
The clause does not carve the retest out. §15.2.5(iii) says the auditing organisation should implement the maker-checker concept, with a separate verification team deployed to review and validate the work performed by the audit team. A closure decision is audit work with a higher consequence than a finding — a wrong finding gets argued about, a wrong closure gets believed. Ask at signing whether the checker reviews retest dispositions as well as first-pass observations, because the honest answers differ between firms and neither is a breach.
The auditor is suspended or de-empanelled mid-cycle
Plan for the half-closed register rather than for the event. §19 sets a graded ladder — watch list, suspension, debarment as per GFR and de-empanelment, penal and legal actions — and the empanelment terms allow CERT-In to hold or temporarily withdraw empanelment status, with a terminated auditor required to refrain from making claims about its status. The register is your artefact under §15.1.3(ii), which is the point: a successor can verify remaining items against it, but only if the closure evidence is in your evidence store rather than in theirs, and only if the working notes were contracted for under §18(i). Both of those are decisions you make at signing.
The finding belongs to a hosting or subservice provider who will not deploy
Split the closure the way the instrument already splits the audit. Where a website is hosted on a server owned by another organisation, §13.1.5 puts responsibility for auditing the server, its operating system, the hosting software and the backend database with the organisation that owns and operates it, while the content owner remains responsible for the application being audited by an empanelled organisation. Apply the same line to closure: record the owner of the control as well as the owner of the finding, and where the activity is outsourced, §13.1.4(i) requires the auditee to ensure relevant personnel from the outsourced organisation are available at the time of the audit. Availability is a contract term, so it belongs in their contract, not in an email sent the week the retest is booked.
You are a private company, not a government department
The closure machinery still applies, and §4(ii) is the reason: the guidelines cover auditee organisations in both the public and private sectors that are required to or are seeking to evaluate their cyber security posture. The document’s own hedge is “required to or are seeking to”, so do not read it as a universal mandate. What changes in practice is the vocabulary rather than the discipline: there is usually no safe-to-host certificate at the end, the authorising office under §9.2(i) is a named executive rather than a departmental head, and the customer asking to see the closure record is a procurement team rather than a hosting provider. The register is identical.
A VAPT closure register: sixteen fields and why each one is there
Most organisations track findings in the ticket system that happens to be open, and lose the audit-specific fields that make a closure defensible eighteen months later. This is the minimum register. It fits in a spreadsheet, it maps onto a work-tracking tool without much effort, and every field earns its place from an instrument rather than from habit. §15.1.3(ii) makes the tracking the auditee’s own duty, so this is your artefact to keep.
| Field | What it holds | Why it is there |
|---|---|---|
| Observation ID | A stable identifier that survives report versions. Not a row number. | Report versions change — §16.1(iv) has draft and final versions, with the date of issuance of each, maintained and captured in the report. A row number does not survive that, but an ID does. |
| Title and description | The finding as the report states it, not a paraphrase. | §5(v) defines an observation as a documented finding supported by objective, verifiable evidence. Rewriting it in the register quietly changes what was found. |
| Asset and environment | Hostname, package identifier or API base path, plus the environment — staging, UAT, pre-production or production. | §15.2.3(i) requires the environment to be stated, and §5(xiv) and §5(xv) define staging and production as distinct things. A closure in the wrong environment is not a closure. |
| Severity, CVSS vector and EPSS | The band, the full vector string rather than the number alone, and the EPSS value at the date of assessment. | §16.2(ii) requires CVSS for severity supplemented with EPSS for real-world exploitation likelihood. The vector is what makes a severity arguable. The bare number is not. |
| CWE and CVE | The mapped CWE, and the CVE where one exists. | §16.2(ii) requires every reported observation to be mapped to a CWE and a CVE number. The CWE is also what defines a class sweep at retest. |
| Date notified | When the auditee was told, not when the report was issued. | §16.3(ii) requires critical and high findings to be notified during the audit on an as-and-when-found basis. The closure clock starts here, and this field is what proves the remediation window was real. |
| Closure timeline | The due date, derived from the severity band. | §16.3(iii) says the audit report should mention appropriate timelines for closure of vulnerabilities according to severity. A register without this column cannot show whether anything is late. |
| Remediation owner | A named individual with a team, not a queue. | §9.3(iii) puts patching and correction on the auditee organisation. Somebody inside it has to hold each item. |
| Fix description and change reference | What was changed, with the commit, change request or configuration baseline reference. | §9.5(ii) asks for version control and change management to be effectively implemented so that assets in the audit scope can be backtracked. This field is that requirement in a spreadsheet. |
| Build identifier and hash | The version and the cryptographic hash of the artefact the fix landed in, with the algorithm named. | §15.2.3(ii) is the mandatory limb: application hash values and version numbers must be obtained from the auditee and included in the audit report. §9.5(i) and §16.1(v) add the recommendation that those artefacts — hash values, versions and timestamps — be captured by the auditee, shared with the auditing organisation and prominently featured in the certificate and reports. Closure that is not tied to an artefact is tied to nothing. |
| Closure evidence reference | A pointer to the artefact — request and response capture, enumeration output, rotation record — held in the evidence store, not pasted into the row. | §18(iii) has observations well supported with objective evidence compiled with the report, and §18(iv) requires evidence to be stored securely with access restricted to authorised personnel. |
| Retest date, method and scope | When it was retested, how, and at which of the three scopes — the finding, the class or the system. | §16.3(iv) puts the follow-up audit after remediation, to verify closure. The method and scope are what make a later reader able to judge the verification. |
| Verified by | The auditor who performed the retest. | §9.5(iii) permits only manpower declared to CERT-In to sign audit reports, and §15.2.5(iii) says a separate verification team should be deployed to review and validate the audit team’s work. Closure verification carries a name for the same reason the report does. |
| Disposition | One of: closed, partially closed, closed with a compensating control, risk accepted, deferred, withdrawn, reopened. | One field, one controlled vocabulary. Free text here is how “partially closed” becomes “closed” between two meetings. |
| Residual risk and authorisation | For anything not closed: the residual in business terms, the named authorising office, the authorisation date and the review date. | Authorisation under §9.2(i), or §9.2(ii) where the exception is on an application. A residual with no named office is an undecided finding recorded as a decided one. |
| Repeat flag and prior reference | Whether this appeared in a previous cycle, and the earlier observation ID. | §15.2.1(iii) requires the auditing organisation to revalidate previous-cycle observations and record unresolved issues as repeat observations. This field is what makes that mechanical rather than archaeological. |
Three rules for using it
- One row per observation, never per ticket. A finding that spawns four tickets is still one observation with one disposition, and a register keyed on tickets cannot produce a closure statement.
- The disposition column is a controlled list. Seven values, no free text. If a value does not fit, the finding has not been decided yet — which is itself the answer.
- Evidence is referenced, not embedded. §18(iv) requires evidence to be stored securely with restricted access. A register that carries the payloads is a register you cannot circulate.
The three fields that make it a portfolio instrument
Across more than one application, three columns do the heavy lifting. The CWE, because it turns four unrelated findings into one defect class appearing in four places — and because §16.2(ii) makes the mapping mandatory, you already have it. The repeat flag with a prior reference, which converts §15.2.1(iii)’s repeat-observation rule from archaeology into a query. And the build hash, which is the only field that reconciles a closure claim to a thing that is running. Everything else is useful, but these three are what let you answer a question about the estate rather than about a project.
One addition worth making at contract stage rather than at closure stage: §18(i) says auditee organisations must seek the working notes upon completion of the audit, with provisions for the same included in the audit contract, and should ask for the audit evidence collected during the assessment to be submitted as an appendix along with the final audit report. §5(iv) defines working notes as the auditors’ internal documentation of activities, methodologies, evidence gathered and preliminary findings. Those notes are what let a future reader — a new CISO, a customer’s due-diligence team, the next auditor — judge a closure they were not present for. Ask for them in the contract, because §18(i) assumes you did.
What a closed VAPT finding actually looks like on paper
Sixteen field definitions are an instruction. One filled-in row is a specimen. Below is a single observation carried through every field, twice — once as it stood after the first retest round, and once after the second. The hostname, hashes, commit and evidence paths are synthetic and the values are illustrative, in the same sense as the worked cycle further down. The clause locators are not.
After retest round one — disposition: partially closed
| Observation ID | OBS-014 |
| Title and description | Broken access control — insecure direct object reference. An authenticated user of the Customer role can retrieve another tenant’s records by substituting the identifier in GET /api/v2/orders/{id} and GET /api/v2/invoices/{id}. Both endpoints are named in the observation. |
| Asset and environment | api.example-portal.invalid · /api/v2/orders, /api/v2/invoices · pre-production |
| Severity, CVSS vector and EPSS | High · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (8.1) · EPSS 0.004 as at the date of assessment |
| CWE and CVE | CWE-639, Authorization Bypass Through User-Controlled Key · no CVE — this is an application defect, not a known component vulnerability, and the register says so rather than leaving the cell blank |
| Date notified | Day −6, during testing, under §16.3(ii). Not the report date. |
| Closure timeline | Day 14 — twenty days from notification, per the High band agreed in the engagement letter |
| Remediation owner | Named engineer, Orders service team. An individual with a team, not a queue. |
| Fix description and change reference | Tenant ownership check moved into the repository layer · commit 9f3c1ab · change request CR-2291 |
| Build identifier and hash | v3.4.1 · SHA-256 · 4b9d…e07a — the algorithm is named, because §15.2.3(ii) makes the hash and version mandatory report content and a digest with no algorithm reconciles to nothing |
| Closure evidence reference | evidence-store://vapt-2026-q3/OBS-014-R1/ — a path, not a paste. §18(iv) puts the evidence behind access control, and the register only points at it. |
| Retest date, method and scope | Day 13 · method: replayed the recorded request with each of four role tokens and compared the server response, not the interface · scope: class sweep by CWE-639 across all 11 tenant-scoped endpoints |
| Verified by | Named auditor from the declared manpower of the empanelled auditing organisation (§9.5(iii)) |
| Disposition | Partially closed — fixed on /api/v2/orders, still reproducible on /api/v2/invoices. Part of the reported observation remains, so the item is not closed. |
| Residual risk and authorisation | Residual raised as OBS-031, High, with its own Day 27 closure date. No authorisation needed: it is a deferral with a date, not an acceptance. The sweep separately found the same class on a reporting endpoint that was never in OBS-014 — that is OBS-032, a new observation on its own clock, not a reopening of this one. |
| Repeat flag and prior reference | No — first cycle |
Three things in that row are worth pausing on. The notification date is Day −6, during testing, because §16.3(ii) puts critical and high findings in front of the auditee as they are found — so the closure clock started six days before the pass ended. The disposition is not closed, because part of what the observation reported still reproduces. The residual becomes its own row with its own date rather than a note in a comment field. And the sweep turned up the same class on an endpoint the observation never named — which is a new observation rather than a reopening, on the distinction the table above draws.
After retest round two — the fields that changed
| Retest date, method and scope | Day 24 · same method, against build v3.4.3 · scope: the CWE-639 sweep re-run across all 11 endpoints, not only the two that failed |
| Build identifier and hash | v3.4.3 · SHA-256 · c1a7…9d52 |
| Closure evidence reference | evidence-store://vapt-2026-q3/OBS-014-R2/ — a new folder, because the round is in the name and round one is not overwritten |
| Disposition | Closed |
| Residual risk and authorisation | None. OBS-031 and OBS-032 both closed against the same build, each with its own evidence bundle. |
Everything else on the row is unchanged, and that is the point: the observation ID, the vector, the CWE, the notification date and the original closure timeline all survive into the closed record. A register that overwrites them cannot answer the only two questions anybody asks eighteen months later — how long did this take, and against which build was it verified.
Working back from a go-live date: thirty-one days to a certificate
An illustrative composite, not a client engagement. The counts exist to show the shape of the arithmetic — how many findings survive a first remediation build, where the second round goes, what the residual looks like. The rules behind each step are not illustrative, and each one carries its locator.
Working backwards from your go-live date
A forward narrative answers what happened to somebody else. The question you actually hold is when you have to start. Every constraint below is already on this page, scattered across six sections, but nobody assembles them into a calendar. Read it from the top. The ranges are ours, the sequence is the instrument’s, and the column that matters most is the third — because the steps marked yours are the only ones you can move.
| Counting back | Step | Typical span | Whose | What governs it |
|---|---|---|---|---|
| T-0 | Go-live | — | The date somebody has already committed to a minister, a customer or a board. | |
| T-2 to T-7 days | Certificate issued | 2–7 days | Auditor | Issued off the back of the final report and signed by the Lead Auditor and the head of the auditing organisation under §9.5(iii). |
| T-5 to T-14 days | Final report, after the production follow-up audit | 3–7 days | Auditor | §16.3(v) puts the final audit report after closure of vulnerabilities and completion of the follow-up audit of the application hosted on production. This step cannot be compressed by agreement. It is a sequence, not a service level. |
| T-10 to T-20 days | Disposition sign-offs | 3–10 days | Yours | Every item not closed needs a named authorisation under §9.2(i), or §9.2(ii) where it is an application exception. This is the step that slips, because it depends on one senior person’s calendar rather than on anyone’s effort. Book it before you need it. |
| T-14 to T-24 days | Retest round two | 2–5 days | Auditor | The residual round. If round one was finding-scoped rather than class-scoped, this round is where the class instances arrive — too late to get a third round. |
| T-18 to T-30 days | Remediation build two, deployed and pinned | 3–10 days | Yours | Your release cycle, not the auditor’s. Capture the version, hash and deployment timestamp at deploy time rather than reconstructing them later. |
| T-22 to T-36 days | Retest round one | 2–5 days | Auditor | Class sweep by CWE for critical and high. A slot is consumed when the retest starts, so the readiness list decides whether this is a round or a rehearsal. |
| T-28 to T-50 days | Remediation build one, deployed | 5–20 days | Yours | Usually the long pole, and the reason the assertion that testing is rarely the long pole holds: the auditor’s steps above are days, and this one is your development cycle. |
| T-32 to T-55 days | Draft report | 3–7 days | Auditor | The register is exported from this the same day it arrives — §16.3(iii) means the closure timelines are already in it. |
| T-40 to T-70 days | Testing window | 5–20 days | Auditor | Criticals and highs are notified during this window under §16.3(ii), on an as-and-when-found basis, which is the first of the two levers. |
| T-45 to T-80 days | Criticals notified as found | Inside the window | Auditor | Lever one, and it costs nothing: remediation on the criticals can start here rather than at the draft report, buying back a week or more before the report exists. |
| T-55 to T-100 days | Scoping and the engagement letter | 5–15 days | Both | Where the retest rounds, the per-band retest scope and the readiness criteria are written down. Lever two lives here: a class sweep on round one finds the second instance while a round remains. |
The long pole is your remediation build, not the testing. Add the auditor-side spans and they come to somewhere between two and four working weeks across the whole cycle. The two remediation builds are your development cycle, and they are the only rows on the table whose length is not bounded by somebody else’s process. Two levers shorten the whole thing and both are decided before testing starts: taking critical notifications as they are found under §16.3(ii), which buys remediation time before the report exists, and buying a class sweep on round one, which finds the second instance while a round remains to verify the fix. Neither costs money at the point you use it.
The same cycle, forwards
| Day 0 First pass ends | 34 observations on a citizen-facing portal, an admin console and three API base paths: 2 critical, 6 high, 12 medium, 9 low, 5 informational. Every observation carries a CVSS vector, an EPSS value and a CWE, and 11 carry a CVE. The register is exported from the draft report the same day, with owners and severity-derived due dates attached before anyone opens an editor. |
| Day −12 The criticals were already out | Both criticals — a controller missing a role check, and a stored credential in a configuration file committed to the repository — were notified the day they were found, twelve days before the pass ended, under §16.3(ii) and §16.4. Twelve days of remediation therefore happened before the draft report existed. This is the single largest lever on the calendar and it costs nothing. |
| Day 9 Remediation build one | One release closes both criticals, 4 of the 6 highs and 7 mediums. The credential is rotated at the issuer as well as removed from the file, and the rotation record is filed as the closure evidence — the diff alone would have been a partial closure. New build tag, new artefact hash with the algorithm recorded, deployment timestamp captured. |
| Day 12 – 14 Retest round one | Class sweep by CWE for both criticals and all highs, defined sample for mediums. The authorisation defect closes on the reported endpoint and is found on a second controller nobody had listed — reported as a new observation, not as a reopening, because the register distinguishes the instance from the class. One high, a session-fixation issue in a shared identity component the department does not own, cannot be retested because the component owner has not deployed. |
| Day 21 Remediation build two | The second controller and the remaining high are fixed. The identity component owner deploys on day 19 and confirms the build. Two mediums prove to be in a vendor appliance with no patch available. The department proposes segmentation plus alerting as a compensating control. |
| Day 24 – 25 Retest round two, and the dispositions | All criticals and highs verified closed against the day-21 build hash. The two vendor-appliance mediums are closed with a compensating control: the segmentation is evidenced by a refused connection attempt from the previously permitted network position, the alert by a generated event located in the retained log, with an owner and a 90-day review date. Three further mediums are risk-accepted in writing, authorised by the head of the department as the owner of the application, each with a residual statement in business terms and a review date. The lows go to the risk register with dates. |
| Day 31 Final report, then the certificate | The final report issues after closure and the follow-up audit on production, signed by the auditors who did the work, a mid-management reviewer outside the audit team, and the head of the auditing organisation. It carries both report versions with their dates, the closure state of every one of the 34 observations, the authorisations for the five items not closed, and the build hash the retest ran against. The certificate follows, signed by the Lead Auditor and the head of the organisation. |
| Day 46 The hotfix that tests the process | A hotfix changes the password-reset flow. The change board classifies it major — it touches authentication — so it does not ship on the weekly release. It goes back as a delta assessment of that flow with a fresh build hash, and the register gains three rows rather than losing its meaning. Everything the closure cycle built is still true because the build it described is still the build that is running. |
What made it thirty-one days. Four things, and none of them was speed. The criticals were notified as found, so twelve days of remediation happened before the report existed. The retest rounds were priced in the original work order, so nothing waited on a variation. The class sweep on round one found the second controller while there was still a round left to verify the fix — a finding-scoped retest would have found it in the next audit cycle instead. And the two items that could not be fixed were disposed of properly rather than argued about: a compensating control with evidence, an owner and a review date, and three risk acceptances signed by the office §9.2 names.
Where VAPT closure goes wrong
Eight patterns, ordered so the first four are the ones that most often move a committed date. Each has a written rule behind it that somebody did not apply. Read them as a pre-mortem before the work order goes out rather than as a post-mortem afterwards.
| Failure mode | Surfaces at | How you know | Cost of catching it later |
|---|---|---|---|
| Nobody bought the retest The work order covers one assessment, so when the findings arrive there is no contractual basis for the follow-up. §13.1.1(g) directs that the scope of work should clearly specify the requirement to conduct follow-up audits as part of the engagement, and §9.3(iv) makes conducting them after closure of the identified vulnerabilities a must — both were written to prevent exactly this. | The day remediation finishes | The auditor sends a quotation for the retest. That quotation is the signal: the retest should have been in the original price with its rounds and scope named. | A variation order, a finance approval cycle, and weeks of slip on a date that was already committed. |
| The closure evidence is a screenshot of a settings screen A configuration screen shows an intention at one moment on one node by one person. It does not show the behaviour of the deployed system, and it reconciles to no build. §18(iii) sets the standard: observations well supported with objective evidence, compiled carefully and correctly with the report, and presented so decision makers can use them effectively in making credible risk-based decisions. | Retest — or a year later, when somebody asks what closed it | The evidence pack is a folder of PNGs with no request or response captures, no tool output, no timestamps and no build identifier. | A retest round consumed on re-verification, and a closure record that cannot answer a question in the next cycle. |
| Partial closure recorded as closure One of three injection points fixed, or the class fixed on the web tier and not on the API tier. The status column says closed because the ticket said fixed, and the residual was never given its own severity or its own date. | Next release, or next cycle as a repeat observation under §15.2.1(iii) | The retest note says “verified on the reported endpoint”. That sentence is a partial closure wearing a closed label. | A live weakness carried as closed, and an audit trail that actively misleads the next reader. |
| The fix went into the environment, not into the build A console change, a manual configuration edit, a patch on one node of a fleet. The next pipeline run reverts it and nobody is watching the thing that reverted. | The deployment after the retest | The change reference is a person’s name and a date rather than a commit or a change request, and the deployed hash does not move. | A reopened finding, and an escalation under the §13.1.7(iii) matrix that lands on a team who genuinely believed it was fixed. |
| The retest ran against the wrong environment Remediation is deployed to staging, the retest confirms it, and production is a release behind. §15.2.3(i) requires the environment to be stated. §16.3(v) says the final report should be issued after the follow-up audit of the application hosted on the production environment — and then, in its one mandatory limb, that where the scope was limited to staging the report must explicitly state that the audit was not conducted on production. | Go-live, or the first production incident after it | The retest note has no environment field, or the build hash it names is not the hash in production. | A production-side pass at minimum, and a certificate the department cannot honestly represent. |
| A risk acceptance with no name and no expiry “Accepted by the project team” against a high severity item with no residual statement and no review date. The authorisation §9.2(i) requires is a named office, and §9.2(ii) puts an application exception with the owner of the application. | Invisible until an incident or a customer due-diligence request | The authorising office field holds a team, a mailbox or a job title nobody currently holds. | An acceptance that is not an acceptance, and a finding that survives three cycles without ever being decided. |
| Payment tied to the closure report The final milestone pays on submission or approval of the closure report, so every unclosed finding costs the auditing organisation money. §7 requires commercial arrangements to be structured to maintain independence, and says payments should not be contingent on the audit outcome nor tied to the submission or approval of any closure reports, because linking them could compromise impartiality and create a conflict of interest. | Scoping, and it never surfaces at all | A milestone line reading “on closure report approval” or “on issuance of certificate”. | Nothing visible, which is the problem. The closure record comes back clean and the assurance was never bought. |
| The retest is booked before remediation is deployable A slot is held on the calendar, the build is not ready, and the round is consumed on an environment that has not changed. | The retest slot itself | Nobody can state the build hash the retest will run against, twenty-four hours before it starts. | A round wasted, and an argument about who pays for the next one that the engagement letter could have prevented. |
The application-level version of the same question — which technical findings tend to block a clearance in the first place — is on why applications fail safe-to-host. The scoping-level version, which is where most of these are actually created, is on VAPT scoping.
What project teams argue about once the findings exist
These arrive in real project reviews, late, with a date attached. In every case the answer that ends the argument cites the clause rather than asserting the conclusion.
“Can we get the certificate now and close the remaining findings next month?”
Not on the guidelines’ own sequence. §16.3(v) puts the final audit report after the closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment, and the certificate summarises that report. What is available instead is the honest version: close the criticals and highs, dispose of the rest with named authorisations under §9.2, and let the report carry the residual items with their closure timelines. A certificate issued over an undisposed critical is not an early certificate — it is a different document from the one the hosting provider thinks it is reading.
“Our developers have confirmed the fix. Why are we paying for a retest?”
Because a fix confirmed by the person who wrote it is not a verification. §5(xvii) defines conflict of interest to include conducting audits while also being responsible for remediation activities, and says such overlaps create inherent conflicts that undermine the independence of the audit process. §16.3(iv) puts the verification with the auditing organisation: after remediation actions, follow-up audits should be performed by auditing organisations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit. The developer’s confirmation is useful — it is the retest package, not the retest.
“The scanner still flags it, but we have patched it. Can the auditor just accept our word?”
It can be closed, but on evidence rather than on assertion. Backported vendor patches leave the version string unchanged, so the register needs the vendor advisory reference in place of a version bump, and the retest needs a behavioural check — the exploit path attempted and failing — rather than a banner read. §18(v) is the clause that makes this a conversation instead of a dispute: the auditee may request clarifications or justifications for any evidence presented, and the auditing organisation must respond within a mutually agreed timeframe. Agree that timeframe when you sign, not when you disagree.
“The finding is in a vendor product we cannot patch. Does that block everything?”
No, and this is what compensating controls are for — but the control has to be evidenced, not described. Record the weakness, the control, what it stops and what it does not, the evidence that it is operating, an owner and a review date. Then treat it as risk treatment and get it authorised under §9.2(i). Where the product sits on infrastructure somebody else owns, §13.1.5 already splits the audit responsibility between the server owner and the content owner, so split the closure ownership the same way rather than leaving it in the gap.
“We fixed it once and it came back. Is that the auditor’s problem or ours?”
It is a process finding, and the contract anticipated it. §13.1.7(iii) states that an escalation matrix should be defined as part of the audit contract in case of repeated vulnerabilities, and §15.2.1(iii) requires the auditing organisation to revalidate previous-cycle observations, with unresolved issues recorded as repeat observations. Run the root cause analysis §5(vii) describes — the fundamental causes rather than the symptoms — and expect the answer to be one of four things: the fix went into an environment rather than a build, the retest scope was the instance rather than the class, the closure evidence never demonstrated behaviour, or a control on somebody else’s side of a boundary changed.
“Our system integrator says they will manage the closure process for us.”
Part of that is fine and part of it is the one thing the guidelines say cannot be delegated. §9.6(i) states that the entire process — from defining the audit scope, selecting the auditing organisation, providing access to the information infrastructure, to ensuring closure of all audit observations — must be carried out by the owner of the information infrastructure and must not be delegated, while adding that the organisation may seek external support for specialised expertise while retaining full ownership and accountability. So external hands on the remediation and the evidence, yes. The disposition decisions, the authorisations and the register stay with you — and the builder should not be the party deciding whether its own build is closed.
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. On the closure half, the work that actually moves the date is auditee-side work: the register and its controlled vocabulary, the evidence pack that demonstrates behaviour rather than intention, the build identity that makes a closure reconcilable, the retest package that stops a round being consumed on discovery, and the disposition paperwork that puts each residual item in front of the office §9.2 says must authorise it.
For the testing itself, see penetration testing and VAPT. For the assurance programmes these engagements usually sit inside — ISO 27001 and the DPDP Act — a closure register organised this way does a great deal of double duty, because it is already the evidence that corrective action happened and was verified.
Frequently Asked Questions
What is VAPT retesting?
What does closure mean in a VAPT engagement?
How long do we have to fix a VAPT finding?
What counts as proof that a vulnerability is fixed?
Why is a screenshot of the settings page not enough?
Should a retest cover just the finding, or the whole system?
Can a certificate be issued while findings are still open?
Can we go live with an open critical vulnerability?
What is the difference between a retest and revalidation?
What if the retest finds evidence we were already breached?
How many retest rounds should be in the contract?
Who can accept the risk on a finding we are not going to fix?
What is a compensating control, and how is it recorded?
What does a reopened finding mean?
Who pays for the retest?
Is a follow-up audit the same thing as an annual audit?
What should a closure report contain?
Does the retest have to run on production?
What happens to a critical vulnerability we do not fix?
How do we track closure across a portfolio rather than one application?
Sources, named and linked
Every rule on this page comes from one of the documents below, each published by the Government of India and linked so you can read the clause rather than our paraphrase. Section numbers written as §16.3(iv) refer to the Comprehensive Cyber Security Audit Policy Guidelines unless another document is named.
Every §-locator on this page was read against the primary instrument on 22 September 2026. The 2025 guidelines are version 1.0 and will be superseded. When they are, this block changes first. Two documents those guidelines name are deliberately absent from the list because they cannot be retrieved: the “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” named at §15.2.1(iv), and the Deter and Punish Framework named at §11(iv) and §19. As at 22 September 2026, both cert-in.org.in paths printed in the guidelines returned the CERT-In home page rather than a document. They are named here as the guidelines name them and are not linked. Two things this page does not claim, because no instrument says them: that CERT-In prescribes a number of days for any severity band, and that any CERT-In document allocates the cost of a failed retest.
- 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 §5(v), §5(vii), §5(viii), §5(xiv), §5(xv), §5(xvii), §6, §7, §9.2, §9.3, §9.5, §9.6(i), §10.6, §12.4, §13.1.1(g), §13.1.2, §13.1.3, §13.1.5, §13.1.7, §14.1(ii), §15.1.3(ii), §15.2.1(iii), §15.2.2, §15.2.3, §15.2.5(iii), §16.1, §16.2, §16.3, §16.4, §17(iii), §18 - Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment
CERT-In, MeitY · Version 7.2, April 2024 · 10 pages · relied on for clauses 3.1.7, 3.1.12, 3.2.1 and 3.2.2, and Annexure I items 20 and 21 and Annexure II, the audit report content format that names recommendations for action and follow-up audits - Guidelines for CERT-In Empanelled Information Security Auditing Organizations
CERT-In, MeitY · Version 3.0, May 2018 · 6 pages · relied on for the rule that the audit report should mention appropriate timelines for closure of vulnerabilities according to severity, for the requirement that observations be supported by objective evidence compiled with the report, and for the verification team that checks the audit team - Policy Guidelines for Handling Audit related Data
CERT-In, MeitY · Version 1.0, June 2014 · 5 pages · named by §10.3(vii) of the 2025 guidelines · relied on here for the handling, storage, access, retention and destruction of the evidence a closure record points at - 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 · relied on for direction (ii), the six-hour incident reporting duty that runs independently of anything the auditor does, and direction (iv), the rolling 180 days of logs maintained within Indian jurisdiction that a monitoring-gap closure has to demonstrate - 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) as the document auditees and auditing organisations should use to build their audit programme - Empanelled Information Security Auditing Organisations by CERT-In — the snapshot information
CERT-In, MeitY · the published list §9.5(iii), §10.2(vi) and §12.1(i) refer to, and the list against which a retest signatory is checked - Guidelines for Indian Government Websites and Apps (GIGW 3.0) — security guidelines and attributes
National Informatics Centre with STQC and CERT-In, MeitY · guideline 5.3.1, the audit clearance requirement before hosting in production, and its developer action requiring periodic auditing of the web application at least once in a year or as and when any changes are done in the source code, whichever is earlier - Common Vulnerability Scoring System v3.1: Specification Document
Forum of Incident Response and Security Teams (FIRST) · relied on for the qualitative severity rating scale that supplies the CVSS bands in the closure-timeline table, and for the vector string the register records rather than the bare number. Not a CERT-In instrument — but §16.2(ii) requires observations to be categorised on CVSS, which makes it one this page depends on. - Exploit Prediction Scoring System (EPSS)
Forum of Incident Response and Security Teams (FIRST) · the model §16.2(ii) requires auditors to implement alongside CVSS, to assess the likelihood of real-world exploitation. Relied on here for the EPSS value the register carries at the date of assessment, and for the argument that a medium with a high exploitation probability does not belong in a ninety-day queue.
The CVSS severity ranges quoted in the closure-timeline table are the qualitative severity rating scale published with the Common Vulnerability Scoring System by FIRST, and the Exploit Prediction Scoring System is likewise a FIRST publication. Neither is a CERT-In classification, but §16.2(ii) requires both to be used and maps every observation to a CWE and a CVE. Both are listed and linked above so the scale can be checked rather than taken on trust.
Where this page states a number that no instrument sets — the closure windows in the severity table, the retest-round counts, the spans in the backwards calendar — it says so in the same sentence and attributes it to us. The one filled-in register row and the worked cycle are illustrative composites with synthetic hostnames, hashes and identifiers. They are not a client engagement and no count on this page describes work TCSA delivered.
Related reading: what VAPT is, VAPT versus penetration testing versus red teaming, VAPT scoping, the types of VAPT, reading a VAPT report, what a safe-to-host certificate is, how to get one, how long it lasts, who can issue one, GIGW compliance before go-live, what a CERT-In empanelled auditor may and may not do, how to verify a CERT-In audit certificate, the CERT-In Directions of 2022, and what CERT-In is.
Related Reading
How to Read a VAPT Report
Scope, severity, evidence and the parts that reveal a weak test.
Read moreWhat VAPT Actually Is
Vulnerability assessment and penetration testing are two activities. Why India bundles them, and what a real one covers.
Read moreWhy Applications Fail Safe-to-Host
The finding classes that recur, and the ones that cost a second retest cycle.
Read moreHow Long a Safe-to-Host Certificate Lasts
One year, or the next source-code change — whichever comes first, and how to classify the change.
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 more