One year from the date of issue, or the moment the audited build changes — whichever comes first. Two clocks run at once, and in an actively developed application the change clock almost always fires first. This page reads the wording as it is actually printed on certificates published on government domains, and works out what it does to a release calendar.
Read your own certificate first. The wording is not uniform. On one certificate published on a Government of India domain, validity is tied to the build’s hash value and to dynamic contents, and on another, to changes in the source of the tested application. The widely repeated word “major” appears on neither, nor in the GIGW 3.0 attribute behind them.
Plain-English explainer · GIGW 3.0 · CERT-In empanelment terms v7.2 (April 2024) · CERT-In Directions 28.04.2022 · Last reviewed September 2026
A safe-to-host certificate is valid until the audited build changes, or one year from the date of issue, whichever is earlier. On the wording published on Government of India domains, “the audited build changes” is an objective test rather than a judgement. One certificate makes it valid “till no additional changes in the Hash value or dynamic contents carried out or one year from the date of issue, whichever is earlier”. Another states that the maximum validity is one year from issue, and that the auditor’s opinion holds only “for the period during which the changes are not made in the source of tested application”. Certificates issued in the softer formulation in general circulation say “a major change to the server-side application code” instead. Where yours does, that threshold is the issuing auditor’s to define — and you want the definition in writing.
Our own reading of that, offered as a reading rather than as something the documents say: there is no grace period, no renewal window built into the certificate, and no partial validity. The document is current or it is not, and “whichever is earlier” is the half of the sentence that most often gets dropped in the retelling.
The certificate is the audit clearance certificate that the Guidelines for Indian Government Websites and apps require before a site goes live. GIGW 3.0 states the requirement at guideline 5.3.1: “Website, web application, web portal or mobile app have been Security Audited and an Audit Clearance certificate has been issued by NIC/ STQC/ STQC empanelled laboratory/CERT-In empanelled laboratory before hosting in production environment.” The guidelines use the phrase this page is named after, noting that government organisations “must continue to obtain a ‘safe to host’ certificate issued by the cybersecurity auditors empanelled by CERT-In/STQC or the auditors of STQC or NIC”, and record that a chapter on cybersecurity formulated by CERT-In has been incorporated, based on practices including ISO 27001, the OWASP Application Security Verification Standard, the OWASP Top 10 and the CIS benchmarks. For what the certificate is and who may issue one, start with the safe-to-host certificate explained and who can issue one. This page is about what happens after it is issued. Every instrument quoted here is listed, with a link, in the sources section at the foot of the page.
Key Takeaways
- Two clocks run simultaneously. The calendar clock starts on the date of issue and runs one year. The change clock ends the moment the audited build stops being the build in production. The certificate expires on whichever fires first, and for an actively developed application that is the change clock.
- The year runs from the issue date, not from the end of testing. On a certificate published by the Indian Institute of Corporate Affairs the audit date is a range of nearly three months and the issue date is the single day at the end of it — remediation time comes out of your year, not the auditor’s.
- “Major change” is a real defined term, but not a validity threshold. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) §13.1.2 define Minor and Major changes and require a major change to be audited before implementation — defining “major” by risk, not size, and expressly including configuration adjustments affecting sensitive data. The word appears in neither government-published certificate quoted here, nor in the GIGW attribute, which says “as and when any changes are done in the source code”.
- A certificate identifies a build. One published certificate prints a hash value on its face and conditions the conclusion on the tested and live builds being identical. Another prints the digest with its algorithm, SHA-256. That is why the practical control is a promotion process rather than a rebuild, and a digest comparison rather than an argument.
- Continuous deployment and this rule are genuinely incompatible without a design decision. Teams that ship weekly either separate the certified artefact from the change stream, run a slower release train for it, or agree a standing delta-assessment arrangement with the issuing auditor.
- A lapse rarely causes a takedown. It blocks the next hosting change, the next tender submission and the next conformity assessment, and it is written up against the lapse period — so the renewal trigger belongs at whatever date the auditor’s stated turnaround plus your own remediation time puts before the anniversary.
- A valid certificate is not CERT-In compliance. The CERT-In Directions of 28 April 2022 impose separate continuing duties — 6-hour incident reporting, 180-day log retention within Indian jurisdiction, NTP synchronisation, a maintained point of contact — that the certificate says nothing about.
- Confirm the exact wording against the current GIGW text and with the issuing auditor before you build a release calendar on it. Certificates differ between issuers, and between years from the same issuer.
What the documents actually say
There is no single instrument that says “a safe-to-host certificate is valid for X”. The rule is assembled from the certificate document itself, the GIGW attributes that oblige the organisation to hold one and to re-audit, and the empanelment terms that govern what the auditor does afterwards. Every row links to the document it quotes, so you can check this page against its sources rather than trusting it.
| Instrument | What it says | What it binds | What to notice |
|---|---|---|---|
| GIGW 3.0 — Security guideline 5.3.1 | “Website, web application, web portal or mobile app have been Security Audited and an Audit Clearance certificate has been issued by NIC/ STQC/ STQC empanelled laboratory/CERT-In empanelled laboratory before hosting in production environment.” | The gate. No production hosting without a clearance certificate. It sets the precondition rather than the duration. | This is the clause that makes expiry consequential. If a valid certificate is the condition of being hosted, an expired one is a hosting problem, not a paperwork problem. |
| GIGW 3.0 — periodic auditing attribute | “Conduct periodic auditing of Web Application – at least once in a year or as and when any changes are done in the source code, whichever is earlier.” | The organisation’s audit cadence, not the certificate document. It is an obligation to re-audit, expressed with the same two-clock shape. | Note what is absent: the word “major”. The attribute says “any changes are done in the source code”. Read literally it is stricter than most teams assume, which is precisely why the wording on your own certificate matters. |
| A certificate published on iica.nic.in, issued 11 July 2024 | “The certificate is valid till no additional changes in the Hash value or dynamic contents carried out or one year from the date of issue, whichever is earlier. The audit is performed on Test URL. In case any threat is observed in production environment, the operation shall be stalled and intimation to be sent.” | The specific build that was tested, identified by a hash value printed on the face of the certificate, plus a calendar limit measured from the issue date. | No materiality threshold at all. This wording binds validity to the hash and to dynamic contents, not to a judgement about how large a change was. |
| A “Safe to Host Certificate” published on csirhrdg.res.in, dated 17 May 2025 | “Certificate Validity: The maximum validity of the certificate is One Year from the date of issue.” And, separately: “Our opinion is valid for the period during which the changes are not made in the source of tested application thus any changes in the system will require re-audit of application’s new version.” | The same two clocks, worded differently again — a one-year outer limit, plus an opinion that holds only while the source of the tested application is unchanged. | A second government-published certificate, a different issuer, a third form of words, and still no “major”. This document also prints the hash algorithm — SHA-256 — alongside the value, which the first one does not. |
| CERT-In Comprehensive Cyber Security Audit Policy Guidelines, v1.0 (25 July 2025), §13.1.2 | “The cyber security audit should be conducted at least once in a year.” And: “All changes to the system or application must undergo a formal change management process. Each change should be classified as either a ‘Minor Change’ or a ‘Major Change’. Minor change (low-risk, non-critical) require standard change management processes but do not need a cyber security audit. Major change (high-risk, impactful to security) such as system overhauls, technology migrations, or configuration adjustments that affect sensitive data or critical infrastructure must undergo a cyber security audit … before implementation.” | When you must audit, and the change-classification process you must run to decide. It is the instrument that gives “major change” an actual definition — and the definition is risk-based, not size-based. | Read the examples: system overhauls, technology migrations and configuration adjustments affecting sensitive data or critical infrastructure. Configuration is expressly capable of being a major change, which is the opposite of the common assumption. Note also “before implementation” — the audit precedes the change rather than following it. |
| CERT-In empanelment terms and conditions, Version 7.2 (April 2024) | Clause 3.2.2: “it is mandatory for the auditor to share the audit report and audit metadata related to information Security audits within 5 days of completion of audit with CERT-In as per format provided by CERT-In.” The same clause makes it mandatory to report critical vulnerabilities, with auditee details, within 5 days where they were raised during the audit and not fixed by the auditee even during follow-up audits. | The auditor, not you — but it determines what CERT-In sees about your application, and when. | This is why an unresolved critical finding is not a private matter between you and your auditor. It also means every re-audit you commission leaves a dated trail at CERT-In. |
The GIGW attributes also tell the evaluator what to look for, which is the reason a stale date is a conformity finding rather than administrative untidiness: an evaluator is directed to confirm that the site holds “a valid security audit certificate issued by NIC/STQC/Cert-IN empaneled laboratory fulfilling Cert-IN requirements.” Valid, not merely present.
Where “major change” actually comes from
The formulation in general circulation — valid until a major change is made to the server-side application code, or one year, whichever is earlier — is usually repeated without a source, so it is worth saying plainly where “major change” is and is not defined. It is a defined term, in CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, 25 July 2025). Paragraph 13.1.2 requires every change to be classified as a Minor Change or a Major Change, exempts minor changes — “low-risk, non-critical” — from a cyber security audit, and requires a major change — “high-risk, impactful to security”, such as system overhauls, technology migrations, or configuration adjustments affecting sensitive data or critical infrastructure — to undergo an audit before implementation.
Two things follow, and both cut against the way the phrase is normally used. The definition is about risk, not size — a one-line configuration adjustment touching sensitive data is expressly capable of being a major change, while a large refactor that alters nothing security-relevant may not be. And the classification governs when you must audit, not how long your certificate lasts. Validity is a statement made by the issuer on the face of the document, and the issuers do not use the word.
Take the texts side by side. The GIGW 3.0 attribute obliges an organisation to “Conduct periodic auditing of Web Application – at least once in a year or as and when any changes are done in the source code, whichever is earlier.” That is the two-clock shape, but the trigger is “any changes” to source code, with no threshold. The certificate published by the Indian Institute of Corporate Affairs reaches the same destination by a different road, and the certificate published by CSIR’s Human Resource Development Group by a third.
“The certificate is valid till no additional changes in the Hash value or dynamic contents carried out or one year from the date of issue, whichever is earlier. The audit is performed on Test URL. In case any threat is observed in production environment, the operation shall be stalled and intimation to be sent.”
“Certificate Validity: The maximum validity of the certificate is One Year from the date of issue.” — and, in the note beneath it: “Our opinion is valid for the period during which the changes are not made in the source of tested application thus any changes in the system will require re-audit of application’s new version.”
Three documents that speak to validity and cadence, three forms of words, and “major” in none of them. Certificates do exist whose notes are worded in terms of major or significant changes to server-side code, and where yours is one of them, that is the wording you are governed by — and you can at least point the issuer at paragraph 13.1.2 for a definition rather than negotiating one from scratch. What none of this supports is treating “major” as a default that lets small changes through. Two of the four instruments set no threshold at all, and the one that defines the word defines it by risk rather than by size.
There is a second reason the distinction matters, and it is about who decides. If validity turns on a hash, “is the certificate still live?” is a fact your build system can answer. If it turns on whether a change was major, it is a judgement — and it is the issuing auditor’s judgement, not yours. A team that assumes it holds the pen on that judgement discovers otherwise at the least convenient moment, usually when an evaluator asks how a particular release was classified. The last block of the annexe further down this page is the paragraph to send an auditor whose certificate says “major”.
Two clocks, one certificate
“Whichever is earlier” is doing all the work in the rule, and it is the half most often dropped in the retelling. Both clocks start at issue. Neither pauses. The certificate ends when the first one fires, and nothing about the second clock extends it.
| Clock | Starts | Ends | How it is misread | The control that fixes it |
|---|---|---|---|---|
| The calendar clock | The date of issue printed on the certificate — not the date testing started, and not the date you deployed. | One year later. Both published certificates read this way, and one states it as a maximum. | Teams date the year from the audit window. On the certificate published by IICA the audit date is a range — 18 April 2024 to 11 July 2024 — and the issue date is a single day at the end of it. Where remediation and retest stretch the audit window, those weeks come out of your validity, not out of the auditor’s. | Compute the calendar expiry at issue, write it into the same system that holds your renewal reminders, and set the reminder against the auditor’s stated turnaround rather than against the expiry date itself. |
| The change clock | The moment the audited build stops being the build in production. | Immediately, on both published wordings — “till no additional changes in the Hash value or dynamic contents carried out”, and “valid for the period during which the changes are not made in the source of tested application”. | Teams read “major change” and conclude that small changes are free. Neither published certificate nor the GIGW attribute contains a materiality threshold at all — and where “major” is defined, in the 2025 audit policy guidelines §13.1.2, it is defined by risk rather than size, so a one-line configuration change can qualify. Where your certificate says “major”, the threshold is the issuing auditor’s to define, and you want that definition in writing before you rely on it. | Tie the certificate to a build identifier in your release records, so that “has the audited build changed?” is a query rather than an argument. |
What the hash on the certificate is, and how to check it
The hash is the hinge of the whole subject. It is what turns “is the certificate still live?” from an argument into a comparison. It is also the field most readers skim past, so it is worth being concrete about what it is, who computes it, and how you check it.
What is hashed is the artefact handed to the auditor, not your repository.
The auditor tests a deployable build on a staging or test environment and records a digest of what was tested. That is normally the build package — the archive, image or bundle that gets promoted — and not the source tree, which contains files that never ship and produces a different digest on every checkout. If your certificate prints a value and you cannot say which bytes produced it, you do not yet have a build identity. You have a number.
Certificates often print the value without the algorithm. Get all three in writing.
The IICA certificate prints a 64-character hexadecimal hash value under the heading “Hash Value” and names no algorithm at all. The CSIR-HRDG certificate prints “Current Version Hash” and, on the line beneath it, “Hash Algorithm: SHA-256 With RSA Encryption”. A digest you cannot reproduce is not a control, so at issue obtain three things together and record them in one place: the algorithm, the exact artefact path or filename it was computed over, and the value. Ask for them while the engagement is live. It is a one-line answer then and an archaeology project a year later.
Reproduce the digest in the pipeline, and compare it on every deploy.
This is the instrument that step eight of the re-audit sequence asks for, named plainly: a step in the deployment pipeline that computes the digest of the artefact about to be promoted, using the algorithm the certificate names, and compares it to the recorded audited value. Equal means the running application is still the audited build. Unequal means the change clock has fired, on that day, with a timestamp — which is exactly the evidence an evaluator asks for and almost nobody can produce. Make it fail loudly or flag loudly, because a silent check is a check nobody reads.
A pipeline that rebuilds from source silently breaks the test.
Rebuilding the same commit can produce a different artefact — timestamps, build metadata, dependency resolution and toolchain versions all leak into the output — so the digest moves with no code change at all. Every deploy then reports a change that is not a change, and the check gets switched off, which is worse than never having it. The fix is the architectural move this page keeps returning to: build once, hash it, have that hash tested, and promote that artefact rather than rebuilding it on the way to production. It is also what makes the certificate’s build-parity condition true rather than merely asserted.
When the certificate identifies no build at all.
Some certificates carry only a date and a URL. You are then in a judgement regime whether you like it or not, and the recovery is the same three steps. Ask the issuing auditor, in writing, what artefact the certificate covers. Record the answer beside the certificate, and treat that answer as the build identity from that day forward. Do it at issue rather than at renewal, because the person who can answer it is on the engagement now and may not be later.
What to record about your certificate
One row per certificate, kept wherever your organisation keeps things that outlive their author. The example column is drawn from the two certificates published on government domains that this page quotes, so the fields are not hypothetical — they are the fields real certificates carry. The last four are not printed on any certificate and are the ones that actually prevent lapses.
| Field | Why it matters | Example value |
|---|---|---|
| Certificate number | The reference a tender committee, hosting provider or evaluator quotes back at you. Without it a certificate is hard to cite and easy to confuse with last year’s. | <issuer prefix>/2024-25/150 |
| Issuer, and its empanelment status at issue | The attribute is satisfied by the issuer set, not by the quality of the testing. Record what the issuer asserted about its own empanelment, in the issuer’s own words. | A CERT-In empanelled organisation, empanelment letter number and date as printed |
| Site URL | The certificate names the live site on its face. A different hostname is, on the face of the document, a different fact. | https://iica.nic.in/ |
| Test URL | Where the audit actually ran. Published certificates name a staging host or an internal address here, which is the point at which most readers discover the audit was not run against production. | http://localhost/ · http://192.168.250.190:84/ |
| Audited artefact, digest and algorithm | The build identity the change clock is measured against. Record all three together — some certificates print the value with no algorithm named. | 7dc07d43…d96cf6, SHA-256, build package supplied to the auditor |
| Application version | A human-readable handle for the same artefact, and the one your release notes will actually use. | V1.0 |
| Audit date range | Shows how much of the elapsed time was testing and how much was remediation. The gap between its start and the issue date is time you have already spent. | 18th April 2024 to 11th July 2024 |
| Issue date | The date the calendar clock starts. Not the date testing finished, and not the date you deployed. | 11-July-2024 |
| Calendar expiry | Derived, not printed. Compute it once at issue and write it down, because nobody recomputes it under pressure. | 10-July-2025 |
| The validity note, verbatim | The operative sentence. Transcribe it rather than summarising it — the summary is where the error enters. | “…valid till no additional changes in the Hash value or dynamic contents carried out…” |
| Conditions and recommendations | Published certificates attach conditions to the conclusion — build parity between test and live, write permissions, server and OS hardening. They are terms, not suggestions. | “Build of Site URL and Test URL need to be identical.” |
| Tested standard and methodology | Defines the boundary of the assurance. What was not tested against is not covered by the conclusion. | OWASP 2021 Top 10, OWASP Web Security Testing Guide |
| Delta-rule reference | Points to the clause of the engagement terms that says which changes need what. A certificate without one leaves every release to be argued individually. | Engagement terms, Annexe C |
| Renewal trigger date | The date the re-audit starts, not the date the certificate dies. Set it far enough ahead to absorb a remediation cycle. | Calendar expiry minus the auditor’s stated retest and re-issue turnaround |
| Named owner and deputy | In a government department this is the Web Information Manager’s file. The deputy is what makes it survive a transfer. | Web Information Manager. Deputy named by role, not by person |
Handle the report that sits behind the certificate carefully. Clause 3.1.9 of the CERT-In empanelment terms provides that “The audit outcome & related matters should only be communicated to the specified Point of Contact (POC) of the auditee organization. The audit report should only be shared using secure methods such as use of passwords, encryption etc”. Nominate that point of contact deliberately rather than letting it default to whoever raised the purchase order, and keep the report out of general distribution lists.
Does this change invalidate the certificate?
A change just landed and somebody has to make a call. Run these five questions in order. The first one that gives you a definite answer is the answer. The table in the next section is the lookup this sequence sends you to.
Does your certificate name a hash, a digest, a version or any other build identity?
If it does, validity is a fact your build system can answer and the rest of this sequence is mechanical. If it does not, you are in a judgement regime: ask the issuing auditor in writing what artefact the certificate covers, record the answer, and treat that answer as the build identity from that day forward.
Did the artefact digest move?
Compare the digest of the artefact now running against the digest recorded at issue. If it moved, the audited build is no longer the build in production on the hash wording, whatever the size of the change. If it did not move, the change lives outside the artefact and steps four and five decide it.
Does the change add or alter an entry point, or touch identity, authorisation, session handling, cryptography or a data store?
If yes, stop classifying and notify the auditor. New or altered attack surface was never tested and the certificate does not reach it. This is the class no auditor waves through, and the diff size is irrelevant to it — it is also the shape of the “high-risk, impactful to security” test the 2025 audit policy guidelines apply at §13.1.2, which expects the audit before implementation rather than after.
Does it change only content or configuration held outside the build artefact?
Content published through a CMS is data rather than code, and configuration often lives outside the artefact. But one published certificate reaches “dynamic contents” explicitly, and a feature flag that exposes a previously dark code path changes what an attacker can reach without moving the digest. Classify and log these. Do not assume they are free.
What does your written delta rule say about this class?
If you have one, apply it: no assessment, log only, scoped retest, or full re-audit. If you do not have one — and most organisations do not — the default is not silence. Treat it as a change, log it, and notify the issuing auditor. An unnotified change that later turns out to have needed a retest is a lapse you chose, while a notified one that did not is a short email.
The default, stated plainly
With no written delta rule on file, treat the change as a change: log it, classify it, and notify the issuing auditor. That is the position most organisations are actually in, and the cost of being unnecessarily strict is one email and possibly one retest. The cost of being wrongly relaxed is a lapse somebody else discovers, dated from the release you did not report.
What counts as a change to the audited build
This is the table the question actually resolves to, and it is the one no public page in India sets out properly. Read it with your own certificate open. If it binds to a hash, the third column decides. If it binds to major server-side code changes, the second column decides. And where the two disagree — the front-end-only row is the clearest case — two organisations reach opposite answers from the same change. The final column is a starting position for the conversation with the issuing auditor, not a substitute for it.
| Change | Server-side code? | Build digest | How it is normally treated |
|---|---|---|---|
| Content edit through the CMS — a press release, a new PDF, a changed page title | No — data, not executable server-side code | Does not change the application build digest, but may change what one published certificate calls dynamic contents | Ordinarily inside the certificate, because the audited artefact is the application, not its content. Get this confirmed in writing: the IICA certificate names “dynamic contents” alongside the hash, and a certificate that treated every content change as invalidating would be unusable for a news-publishing department. |
| Configuration change in the application — a feature flag flipped, a timeout raised | Yes, in effect — server behaviour changes without the code changing | Usually unchanged if configuration lives outside the build artefact | The grey zone that causes the most disputes, and the one where the common assumption is expressly wrong: CERT-In’s 2025 audit policy guidelines §13.1.2 give “configuration adjustments that affect sensitive data or critical infrastructure” as an example of a major change requiring an audit before implementation. A flag that exposes a previously dark code path is a functional change to what an attacker can reach, whether or not the digest moved. Treat flag-gated releases of new functionality as changes requiring assessment, and say so in your change record. |
| Dependency or library upgrade, including a security patch | Yes | Changes | Changes the audited artefact on any reading. Ask your issuing auditor how they treat a patch that closes a known vulnerability against a version bump that alters behaviour — in the CERT-In audits we deliver with our CERT-In empanelled partners the two are not always treated alike, and the answer differs by auditor. Ask before you need to. |
| Bug fix in server-side code | Yes | Changes | A change on every reading of the wording. Whether it needs a full re-audit or a scoped retest of the affected area is the auditor’s call, and the answer belongs in the engagement terms rather than being negotiated per release. |
| New endpoint, new API route, new form, new file upload | Yes | Changes | Unambiguously a re-audit trigger under any of the formulations. New attack surface was never tested, so the certificate does not reach it. This is the category no auditor will wave through. |
| Authentication, authorisation, session or cryptography change | Yes | Changes | The highest-risk class. Expect a full retest of the affected flows at minimum, and expect the auditor to want the change walked through rather than described in a ticket. |
| Front-end-only change — CSS, a client-side script, an image | No, but it ships inside the same build | Changes if the asset is part of the audited artefact | The formulation matters here more than anywhere. On a “server-side application code” reading this is outside. On a hash reading it is inside, because the digest moved. Two teams with differently worded certificates reach opposite, equally defensible conclusions. |
| Domain, hostname or URL change — a new domain, a subdomain move, a path restructure | Often no code change at all | Unchanged | Raise it before you make it. Published certificates name a Site URL on their face, and one conditions its conclusion on the build behind that URL matching the build that was tested. A certificate that names the old hostname is weak evidence about the new one even where the artefact is byte-identical, and an evaluator reading the document will see the mismatch before they read anything else. |
| Infrastructure change — web server version, OS patch, TLS configuration, WAF rule | Not application code, but inside the hosting environment | Unchanged | Outside the application digest and inside the environment the certificate assumed. Both published certificates carry a recommendation that web server and OS hardening be in place for the production server, which is a condition of the conclusion rather than a suggestion. A hardening regression undermines the certificate without touching the code. |
| Migration to a new host, new region or new cloud account | No code change, wholesale environment change | Unchanged | Raise it with the auditor before the migration, not after. GIGW frames the certificate as a precondition of hosting in the production environment. A different production environment is a different fact from the one the certificate was issued against. |
| Mobile app release — a new build submitted to a store | App binary changes, but backend may not | Changes for the app artefact | GIGW names mobile apps expressly in the same attribute. A store release is a new artefact and is treated as one. Where the backend is separately certified, its certificate is unaffected by the app release and vice versa. |
| Rollback to the previously audited build | Returns the artefact to a tested state | Returns to the audited value | The one change that can restore rather than break the position, and the reason it is worth recording the audited digest in your release system. A rollback to the audited build is defensible in a way that a rollback to “the last thing that worked” is not. |
Two structural observations come out of this table. The first is that the certificate is attached to an artefact, and everything that does not change the artefact sits in a grey zone — configuration, infrastructure, content, hostnames and hosting all change what an attacker faces without necessarily changing what the auditor hashed. The second is that the grey zone is where the disputes live, which is why a written agreement with the issuing auditor pays for itself. If a change turns out to have introduced a defect rather than merely a difference, that is a different subject with a different remedy — see why applications fail safe-to-host for the findings that actually stop a certificate being issued.
Continuous deployment meets a certificate
The rule was written for applications that change a few times a year. Most government digital services are now built by teams that would like to ship far more often than that, and the two facts do not reconcile themselves. What follows is where the engineering decision has to be made at each cadence — not a recommendation to ship less.
| Release cadence | Degree of collision | The pattern that works |
|---|---|---|
| Weekly or continuous deployment | Total. Any reading of the wording invalidates the certificate at the first deploy after issue, and that can be the same week. | Separate the certified artefact from the deployment stream. The arrangement that works, in the estates we have worked on, is a distinct and slower release train for the audited application, with everything else — content, configuration, non-code assets — held outside the build. Where that is impossible, the honest answer is that the certificate has to be re-issued at the cadence of the release train, and the engagement has to be scoped and scheduled that way from the start. |
| Monthly release train | High, but tractable. Twelve builds a year against a certificate that expires on the first change. | Agree a standing delta-assessment arrangement with the issuing auditor covering scoped retest of changed areas, with a full re-audit at the annual mark. Bundle changes into the train deliberately: a release that carries one authentication change and nine cosmetic ones is priced and scheduled by the authentication change. |
| Quarterly release | Manageable. Four change events and one calendar event a year. | The cadence the rule was written for. Schedule the audit window to land immediately before the release rather than after it, so the artefact tested is the artefact shipped — the IICA certificate says as much in its conclusion: “Build of Site URL and Test URL need to be identical.” |
| Annual or event-driven release | Low. The calendar clock usually expires first. | The risk inverts: the failure mode is nobody noticing the anniversary. Set the reminder against the issue date and treat the annual re-audit as a fixed line in the budget cycle, not a project to be raised each year. |
| Static or near-static site | Minimal for code. Content changes are the live question. | Get the treatment of content updates in writing at engagement time. If the certificate wording reaches “dynamic contents”, a department publishing daily needs to know what its auditor means by that before it publishes, not after an evaluator asks. |
The four architectural moves that buy you room
Move content out of the build.
If pages, notices, documents and images are data served by the application rather than files baked into it, publishing does not touch the artefact and the digest does not move. This is the single largest win available, and it is why content-managed government sites can sustain a certificate while hand-built ones cannot. The caveat is real: where the certificate wording reaches “dynamic contents”, content may not be as free as the architecture suggests, so confirm the treatment in writing before you rely on it.
Promote the audited artefact. Do not rebuild it.
The IICA certificate conditions its conclusion on the tested and live builds being identical, and CERT-In’s auditor guidelines have the audit performed on the staging or testing environment before the certificate is issued. A pipeline that rebuilds from source on the way to production can produce a different artefact from the one that was tested, even with no code change, which quietly breaks both the premise and your digest check. Build once, hash it, test that hash, promote that hash.
Give the certified application its own release train.
Where an estate contains one certified citizen-facing application and several internal services, coupling their release schedules is a choice, not a necessity. Decouple them and the certified artefact can move quarterly while everything else moves weekly. The cost is release-management discipline, and the benefit is a certificate that survives the year.
Batch changes into audited windows, and size the window by its riskiest item.
A release carrying one authentication change and nine cosmetic ones is an authentication release. Plan the audit effort against the riskiest change in the batch and schedule the batch so the audit window closes before the go-live date, not on it. The corollary is that holding a risky change back to join a later batch is a legitimate and often correct scheduling decision.
None of these four removes the obligation, but they change how often it bites. And none of them should be read as licence to ship a security fix slowly. Where a fix closes an active risk, it ships — the certificate question is handled on the same day by recording the change and notifying the auditor, and the incident question, if there is one, runs on the 6-hour clock the 2022 Directions set.
Twenty-three days of a one-year certificate
An illustrative composite department, with both clocks tracked as dates. The audit-window shape — an audit opening on 18 April and a certificate issued on 11 July — is taken from the certificate published on iica.nic.in, and everything after the issue date is constructed to show what the two clocks do to an ordinary release calendar. No real organisation is described.
| 18 April | The audit opens on a frozen staging build. | The department freezes a release candidate, deploys it to the staging environment the hosting provider supplies, and hands the auditor the build package. The digest of that package is recorded on the department’s side on the same day — which is the single step most organisations skip, and the one that makes everything after 11 July answerable. |
| 2 May | Findings are raised. | A mix of severities, with closure timelines stated by severity in the draft report. The department now owns the clock: nothing further happens until the fixes land. |
| 3 May – 28 June | Remediation, on the department’s side. | Eight weeks, almost all of it waiting on a development vendor with other commitments. This is the part of the elapsed time that belongs to the auditee and is routinely budgeted as though it belongs to the auditor. |
| 1 – 9 July | Retest, and review of the fixes. | The auditor reviews the fixes and records that they are compliant with the requirements relating to security as per CERT-In guidelines. The staging build is rebuilt once more with the fixes in it. The department records the new digest and discards the April one. |
| 11 July | The certificate is issued. Both clocks start. | Calendar clock: expires 10 July the following year. Change clock: open, and running against the digest recorded on 9 July. The department writes both into the register, along with the validity note verbatim. Elapsed from audit open to issue: 84 days, of which 57 were remediation the department controlled. |
| 3 August | A release ships. The change clock fires on day 23. | The release carries a dependency bump and one new endpoint. The digest moves — so on a hash wording the certificate no longer describes what is running, and the new endpoint is surface that was never tested, so on a “major change” wording it fails too. Both readings agree, which is what makes this release the easy case rather than the hard one. |
| 5 August | The delta call, which has to be made without a written rule. | There is no delta annexe in the engagement terms, so the classification is a conversation rather than a lookup. The new endpoint decides it: a scoped audit of the new surface plus regression of adjacent areas, not a documented assessment. Had the release carried only the dependency bump, the same conversation would have been shorter and cheaper — and with a written rule it would not have been a conversation at all. |
| 14 November | A tender asks for a current security audit certificate. | The scoped retest was never commissioned — August became September, the development vendor’s contract was being renegotiated, and the certificate in the file still reads 11 July with a year to run. Somebody notices that the document and the running application describe different builds. The honest position is stated in the submission, which is uncomfortable, and is still better than the alternative. |
| December – January | Re-audit, re-issue, and the year restarts. | A full re-audit rather than a scoped retest, because four months of unclassified releases have accumulated on top of the August one. The new certificate carries a new issue date and a new digest, and the calendar clock starts again from that date — the unused months of the old certificate are simply lost. |
The certificate was current for 23 of the 365 days the organisation believed it held it. Nothing in that sequence involved negligence. The audit was real, the remediation was real, the release was ordinary, and everybody involved would have said in October that the department held a valid safe-to-host certificate with eight months to run. What was missing was a single comparison on 3 August between the digest of the artefact being promoted and the digest recorded on 9 July — and a written rule saying what to do when they differed.
Planning the re-audit window
Eight steps, in order, because each one constrains the next. Steps one and two cost an afternoon and prevent most of what goes wrong later. Step seven is the one organisations skip and then regret.
Read your own certificate
The operative wording is the sentence printed on your document, not the paraphrase in a vendor blog or on this page. Copy that sentence into your compliance record verbatim, with the certificate number and the issue date beside it.
Record the audited build identity
Whatever your certificate binds to — a digest, a build number, a tag, a release name — write it into the release system, together with the algorithm and the exact artefact it was computed over, so that “is production still the audited build?” has an answer a machine can give.
Establish the two dates that matter
The issue date, and the date of the next planned change to the audited artefact. Your effective expiry is the earlier of issue date plus one year and that change date. Plan against the earlier one.
Agree the delta rule in writing, at engagement time
What counts as a change requiring re-audit, what qualifies for a scoped retest instead, how long a retest takes, and what evidence you must supply. An auditor who will not put this in the engagement terms is telling you something.
Book the audit window against the release calendar
Not against the expiry date. CERT-In’s guidelines for empanelled auditing organisations require the auditor to audit and test the website on the staging server or testing environment provided by the hosting service provider before issuing the audit certificate — so the staging build must be frozen and identical to what will ship.
Budget remediation time inside the window
On the IICA certificate the audit date spans nearly three months while the issue date is a single day at the end of it, because findings were raised, fixed and reviewed before issue. If you schedule backwards from a go-live date without a remediation buffer, the buffer comes out of the go-live.
Set the renewal trigger against a number you asked for
Not against a rule of thumb. Ask the issuing auditor what their current re-audit, remediation-review and re-issue turnaround is, add the remediation time your own team realistically needs, and set the trigger that far before the calendar expiry. In a government department the trigger belongs to the Web Information Manager, with a named deputy, because the commonest cause of a lapse is a reminder that lived in one person’s calendar.
Instrument the lapse
Recompute the digest of the artefact being promoted on every deploy and compare it to the digest recorded at issue, failing or flagging the pipeline when they diverge. Add a calendar alert on the issue-date anniversary owned by the same role. Together these turn both clocks into alerts instead of discoveries.
For the end-to-end process the first time round — scoping, environment preparation, the test itself, remediation and issue — see how to get a safe-to-host certificate. A renewal follows the same path with one difference that matters: you already know where the findings were last time, which makes the remediation buffer estimable rather than guessed.
Delta assessment or full re-audit
“The certificate expired, so we need another audit” is true but not useful — the difference between a scoped retest and a full re-audit is large, and which one applies is decided by the nature of the change. The second column is what to ask for and confirm in writing, not a verdict this page can give you. The fourth names what sets the elapsed time and who is on the critical path, which is usually your side rather than the auditor’s.
| What changed | Scope to settle in writing | What you have to supply | What sets the elapsed time | What widens it |
|---|---|---|---|---|
| A single bug fix in a module that was tested and found clean | Ask for: a scoped retest of the affected functionality | The diff, the affected endpoints or screens, the build identity before and after, and a statement of what behaviour changed. | Shortest of the three paths. Driven by the auditor’s retest queue and by how quickly you can produce a frozen environment. The verification-team step still applies. | Scope creep in the diff. A “single bug fix” branch that also carries a dependency bump and a config change is three changes, and the auditor will treat it as three. |
| A dependency security patch with no functional change | Ask for: a scoped retest, or a documented assessment with no testing | The advisory, the version delta, the build digest before and after, and evidence that no application behaviour changed. | Can be the shortest path of all where the auditor accepts a documented assessment. You are on the critical path: the evidence that behaviour did not change is yours to produce. | Transitive upgrades. A patch to one library that pulls in six others is a larger change than the ticket title suggests. |
| A new feature with new endpoints | Expect: a full re-audit, or a substantial scoped audit of the new surface plus regression of adjacent areas | A frozen staging build identical to the intended production build, the design or threat-model notes, and access for the test team. | Weeks rather than days, and the range is set by remediation on your side rather than by testing on theirs. Methodology-led testing plus the verification-team step means this cannot be compressed into a scan. | Testing the feature in isolation. New surface changes the reachability of old surface, and that is where the findings actually land. |
| An authentication, authorisation or session change | Expect: a full retest of identity and access flows regardless of diff size | Walkthroughs rather than documents, plus test accounts across every role, including the roles nobody uses. | Set by role coverage, not by diff size. Provisioning test accounts for every role is routinely the longest single item, and it is entirely on your side of the engagement. | Treating it as a small change because the diff is small. The diff size and the blast radius are unrelated here. |
| Infrastructure or hosting migration | Ask for: a configuration review of the new environment, often without a full application retest | The new environment’s hardening baseline, the TLS and WAF configuration, and evidence the application build is unchanged. | Usually short once the new environment is actually ready, which is the step that slips. Your infrastructure team, not the auditor, is on the critical path. | The assumption that the certificate travels. Raise it before the migration, because a certificate issued against one production environment is weaker evidence about another. |
| The annual anniversary with no code change at all | Expect: a full re-audit | The same package as a first audit — the year of quiet is not a discount. | The longest path, and the most predictable, which is why it is the one to schedule rather than react to. Plan it as you would a first audit and start from the renewal trigger date. | The belief that an unchanged application is a risk-free application. The application did not change, but the vulnerability landscape did. That is the reason the calendar clock exists alongside the change clock. |
The delta-rule annexe, as written
| Change classes and their treatment | Changes to the Audited Application shall be classified by the Auditee as: (a) Content — material published through the content management system and not forming part of the build artefact: no assessment, recorded in the change log. (b) Configuration — settings held outside the build artefact that do not enable previously unreachable functionality: recorded in the change log and notified in the quarterly reconciliation. (c) Minor code change — a change to the build artefact that adds no entry point and does not touch authentication, authorisation, session management, cryptography or data storage: notified to the Auditor and subject to a Scoped Retest of the affected functionality. (d) Material change — any change adding or altering an entry point, or touching authentication, authorisation, session management, cryptography or data storage, or any change to the deployment platform: subject to a Full Re-audit or a Scoped Audit of the new surface with regression of adjacent areas, at the Auditor’s determination. |
| Retest turnaround and what the auditee supplies | The Auditor shall confirm classification within [n] working days of notification, and shall commence a Scoped Retest within [n] working days of the Auditee making available: a staging environment identical in build and configuration to the intended production deployment, the build artefact and its digest (before and after the change), the change record and the affected endpoints or screens, and test accounts covering every application role. The Auditor shall state the expected elapsed time for the Scoped Retest and for re-issue at the point of classification. |
| Content and configuration where the certificate reaches dynamic contents | Where the validity note on the Certificate refers to dynamic contents, the Parties record that the expression is not intended to capture routine publication of content through the content management system, and that it captures: changes to content that is rendered as executable code, changes to file-upload handling, and changes to templates or components that alter the application’s output encoding. The Auditee shall record all such changes in the change log and notify the Auditor of any change in the second or third category. |
| The one-paragraph request where your certificate says “major” | Our certificate states that it is valid until a major change is made to the server-side application code, or one year from the date of issue, whichever is earlier. So that we can classify releases consistently and evidence that classification to an evaluator, please confirm in writing: (1) what your organisation treats as a major change for the purposes of that note, (2) whether the note is measured against a build artefact, and if so which artefact and by what digest and algorithm, (3) how content and configuration changes held outside the build artefact are treated, and (4) the process and expected turnaround by which we notify you of a change and you determine whether a retest is required. |
Illustrative wording, not a template. The delta rule has to describe your application, your release process and your auditor’s method, and an annexe borrowed from another engagement is the fastest route to a clause neither party can apply. Use it as a checklist of what the annexe has to settle, and let the issuing auditor draft the operative words.
Whichever scope applies, CERT-In’s guidelines for empanelled auditing organisations constrain how the work is done, and each constraint is a line in your project plan rather than a footnote in someone else’s. Auditors are directed to use industry-standard methodologies, with solely tools-based testing to be discouraged — which is why a credible re-audit is not a scan and cannot be delivered overnight — and to deploy a verification team to check the work of the audit team. They must obtain written approvals before penetration tests and before installing tools, install those tools in the presence of the auditee system administrator and remove them afterwards with the auditee’s acceptance, refrain from distributed denial-of-service and flood testing and from exploiting high-risk vulnerabilities, and state timelines for closure of vulnerabilities according to severity. The data-handling rules bind the plan too: auditee data stored only on systems located in India, encrypted on auditor laptops and wiped after completion, with no mirroring outside the country and no sharing with an overseas partner unless the auditee specifically authorises it. Where your application holds citizen data, confirm these arrangements in the engagement rather than assuming them.
What happens when it lapses and how you find out
The honest answer is that nothing dramatic happens on the day. No alarm sounds, the site does not go dark, and in most organisations the lapse is discovered weeks later by someone assembling a document pack. The consequences are real but deferred, and they land on six different surfaces — each with its own detection route and its own horizon, which is exactly why lapses persist.
| Surface | What sits behind it | How it surfaces first | When it bites | The consequence |
|---|---|---|---|---|
| The hosting gate | GIGW states the requirement as an audit clearance certificate issued before hosting in the production environment. A government department hosting through NIC, a State data centre or a managed provider is generally asked for the certificate at onboarding and at renewal of the hosting arrangement. | A hosting request, firewall change or DNS entry comes back with a document query attached rather than a refusal. | At the next hosting interaction — which may be next week or next year, and is the reason lapses persist. | The practical consequence is rarely an immediate takedown. It is a blocked change: the next hosting request, the next firewall change, the next go-live of a dependent service sits in a queue until the certificate is current. |
| The evaluator | Where conformity is assessed, the evaluator checks for validity, not existence. The GIGW attributes direct evaluators to confirm the site holds “a valid security audit certificate issued by NIC/STQC/Cert-IN empaneled laboratory fulfilling Cert-IN requirements.” | A conformity assessment, departmental audit or a question routed through the department’s IT security officer. | On the assessment cycle — so the lapse is often months old by the time it is written down. | An expired certificate reads worse than none at all in one specific way: it establishes that the organisation knew the obligation and let it slip. The finding is written against the lapse period, which is why the dates on the certificate matter more than its contents at this moment. |
| The tender and empanelment process | Departmental tenders, integration requests with other government systems and API-consumer onboarding routinely ask for a current security audit certificate as a submission document. | A bid checklist. Nobody reads the report, but someone reads the date. | On the tender’s own timetable, with no notice and no remedy — the submission window closes. | Bids are rejected on document validity dates alone. This is the most common commercial cost of a lapse and the easiest to avoid. |
| The certificate’s own conditions | The IICA certificate carries an operational instruction beyond expiry — “In case any threat is observed in production environment, the operation shall be stalled and intimation to be sent” — and conditions its conclusion on the tested and live builds being identical, with recommendations about write permissions and web server and OS hardening. | Usually not at all, until someone reads the document closely for the first time in a year. | Silently, and from the day the condition stops being met rather than from the expiry date. | A certificate whose conditions are not being met is not doing the work you think it is doing, even inside its validity window. Read the conditions with the same care as the date. |
| CERT-In’s own visibility | Under clause 3.2.2 of the empanelment terms (Version 7.2, April 2024) the auditor must share the audit report and audit metadata with CERT-In within 5 days of completing the audit, and report critical vulnerabilities with auditee details within 5 days where they were raised and left unfixed even during follow-up audits. Clause 3.1.7 adds that empanelled organisations “shall provide the audit reports and data to CERT-In without explicit permission of auditee organization” — while barring them from sharing client data with anyone else without the auditee’s written permission. | Upstream, and invisibly to you. You will not be told that it happened. | Within days of each audit completing — including audits that raised findings you did not close. | Your audit history is not a private matter. An unclosed critical finding carried from one audit into the next is visible upstream with your organisation named. The management consequence is that remediation deadlines are real deadlines. |
| Incident reporting, which is a separate obligation entirely | The CERT-In Directions of 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000, require covered entities to report the Annexure I incident types within 6 hours of noticing them, to retain logs of all ICT systems for a rolling 180 days within Indian jurisdiction, to synchronise clocks to NIC or NPL NTP servers, and to maintain a point of contact. | Not through the certificate at all. These duties are examined on their own terms, usually after an incident. | On the day an incident occurs — six hours from noticing it, regardless of certificate status. | These duties do not lapse with the certificate and do not arrive with it. An organisation with a current safe-to-host certificate and no 6-hour reporting path is non-compliant in a way the certificate says nothing about. Conflating the two is the single most common misunderstanding in this area, and it is the one this page most wants to leave corrected. |
How you find out you have lapsed
Four signals, in the order they fire. The goal of everything above is that the first two reach you before the last one does.
A build-digest comparison on every deploy.
Fires first, within minutes, and is the only signal that catches the change clock rather than the calendar clock. It is also the only one you fully control.
A calendar alert at the renewal trigger date.
Fires months before the calendar expiry, if it was set against the auditor’s stated turnaround rather than against the expiry date. Owned by a named role with a named deputy, because this is the signal that dies with a transfer.
A quarterly reconciliation of the change log against the written delta rule.
Catches the accumulation case — the estate where no single release looked like a trigger and eleven of them together plainly were. It is also the cheapest evidence to produce when an evaluator asks how releases were classified.
The external triggers, which fire last and worst.
The hosting provider’s renewal cycle, a tender document request, an evaluator’s conformity check. By the time one of these tells you, the lapse is established, dated and being written up by someone else. Every control above exists so that these are never the first to know.
What to do on discovering a lapse is short and unglamorous. Record the date you discovered it and the date it began, because a finding written against a documented, self-discovered lapse with a remediation plan reads very differently from one written against a lapse the evaluator found. Commission the re-audit immediately and put a date on it. Assess whether anything changed since the audited build that would have failed testing — if the answer is yes, that is a risk to manage now rather than at re-audit. Tell the hosting provider and the departmental IT security officer before they ask. And fix the mechanism: give the renewal trigger and the digest comparison to a named role with a named deputy, so the next lapse has to get past two people and a pipeline rather than one calendar.
The file that proves it is still live
A certificate on its own answers “did we ever get audited?”. It does not answer “is that audit still describing the thing we are running?”, and that second question is what a careful evaluator, a hosting provider or a tender committee is really asking. Seven artefacts answer it. Every one is cheap to maintain and expensive to reconstruct.
| Artefact | What it holds | Why it is in the file |
|---|---|---|
| The certificate PDF itself | Certificate number, site URL, the test URL the audit ran against, the build digest or equivalent build identity, the audit date range, the issue date, the conclusion, the conditions and recommendations, and the validity note. | This is the document an evaluator, a hosting provider or a tender committee asks for. Everything else on this list exists to prove that what it says is still true. |
| The audited build record | The commit, tag or artefact identifier that produced the tested build, the digest that identifies it and the algorithm used, recorded in the release system rather than in an email. | Without it, “has the audited build changed?” is answered from memory. With it, the answer is a comparison, and the comparison can be automated and alerted on. |
| The change log for the period since issue | Every change to the application since the issue date, each classified against your written delta rule: no assessment needed, log only, scoped retest, full re-audit. | The classification is the evidence that the certificate is still live. An unclassified change log is an admission that nobody has been tracking the change clock. |
| The engagement terms with the issuing auditor | Scope, environment tested, the written definition of a change requiring re-audit, retest turnaround, what you must supply, and the remediation timelines the report carries by severity — CERT-In’s auditor guidelines require the audit report to mention appropriate timelines for closure of vulnerabilities according to severity. | It converts “the auditor said it was fine” into a documented position that survives a change of staff on either side. |
| The remediation and retest trail | Each finding, its severity, the fix, the date, and the auditor’s confirmation. The IICA certificate records that the issuer “reviewed the fixes and observed to be compliant with requirements relating to security as per Cert-IN (Indian Computer Emergency Response Team) guidelines.” | The certificate is the output of that trail. If an evaluator asks how a high-severity finding was closed, the answer lives here, not in the certificate. |
| The hosting environment baseline | Web server and OS hardening state, the write-permission configuration on production folders, TLS configuration, and the date each was last verified. | Both published certificates make hardening a recommendation attached to the conclusion. A certificate issued on the assumption of a hardened environment that has since drifted is a weaker document than its date suggests. |
| The renewal calendar entry | The renewal trigger date, owned by a named role — in a government department, the Web Information Manager — with a named deputy, in a system that survives either of them leaving. | Most lapses are not decisions. They are a reminder that lived in one person’s calendar and left with that person. |
How to check a safe-to-host certificate is genuine
Whether the certificate is yours, a vendor’s, or attached to a tender response you are evaluating, the issuer question comes before every other question on the document. Six checks, in order. The register table above is the field-by-field companion to them.
Confirm the issuer is in the set GIGW names.
The attribute names NIC, STQC, an STQC empanelled laboratory and a CERT-In empanelled laboratory, and GIGW 3.0 restates it as “the cybersecurity auditors empanelled by CERT-In/STQC or the auditors of STQC or NIC”. This is a set membership question, not a quality question. A thorough test by an organisation outside the set produces a document that does not satisfy the requirement.
Check the name against CERT-In’s published list.
CERT-In publishes the list of empanelled information security auditing organisations as a document on its own site, reachable from the empanelment page at cert-in.org.in. Read the name on the certificate against the name on that list, not against the auditor’s marketing. Trading names, group companies and regional subsidiaries are exactly where this check earns its keep.
Treat empanelment as dated, not permanent.
Empanelment runs in blocks with annual review based on auditee feedback and review of the auditor’s performance, and CERT-In may temporarily withdraw or put empanelment on hold, or terminate it. So there are two questions, not one: was the issuer empanelled when the certificate was issued, and is it empanelled now? A certificate issued during a valid empanelment does not become void because the issuer was later de-empanelled, but you should know which situation you are in before you rely on the document in a submission.
Read how the issuer describes its own relationship with CERT-In.
This is the most useful and least used signal on the page. CERT-In’s rules are unusually strict about description: an auditor may state that it “is empanelled by CERT-In for providing information Security Auditing Service”, and no other words may be used without prior written permission, and the CERT-In logo may not be used on publicity or promotional material without that permission. A supplier whose marketing describes its CERT-In relationship in language richer than that single permitted sentence has told you something about how it reads rules — before you have read a line of its testing.
Then read what the document actually covers.
Two checks the issuer question does not answer. Confirm what was in scope — the whole application, a module, the web tier only, the mobile app — because a certificate covering less than the reader assumes is the commonest defect in this document class. And compare the certificate against your change log: if the log shows twenty releases since the issue date and nobody classified any of them, the certificate is the least reliable document in the file.
Know what to do with a certificate you cannot place.
If the issuer is not in the set and not on the list, the document does not meet the attribute, and saying so early is kinder than saying so at assessment. Ask the supplier which empanelment they are relying on and for the reference.
CERT-In publishes the list of empanelled information security auditing organisations from its own empanelment page. For the full set of bodies entitled to issue, and how NIC and STQC differ from an empanelled private auditor, see who can issue safe-to-host certificates.
What the certificate does not say
Published certificates state their methodology on their face — OWASP 2021 Top 10 on one, the OWASP Top 10 and the OWASP Web Security Testing Guide on the other. Everything outside that methodology is outside the conclusion, and knowing where the edge is matters as much as knowing when it expires. A reader who treats the certificate as a general statement of security is making a larger error than a reader who misjudges the date.
| Outside the conclusion | Why it falls outside | What does cover it |
|---|---|---|
| Business-logic abuse | A workflow that can be driven to an unintended outcome using only valid requests is not an OWASP Top 10 category and is not necessarily reached by a time-boxed application test. | A scoped business-logic review, or threat modelling of the transaction flows, commissioned separately. |
| Availability, resilience and disaster recovery | CERT-In’s auditor guidelines direct auditors to refrain from distributed denial-of-service testing over the internet and from flood testing of any kind. Availability is therefore outside what the testing could have established. | Capacity and failover testing, and a business continuity programme — see ISO 22301 for the management-system form of it. |
| Privacy and data-protection obligations | The certificate speaks to whether the application is safe to host, not to whether the processing inside it is lawful. Notice, consent, purpose limitation and retention are a different instrument entirely. | A DPDP Act readiness assessment and a data-processing inventory. |
| Depth of source-code review | Published certificates record the methodology — OWASP Top 10, the OWASP Web Security Testing Guide — and the tools used. None of that is a line-by-line review of the codebase, and the certificate does not claim it is. | A dedicated secure code review, scoped by module and stated as such. |
| The hosting provider’s own infrastructure | The audit runs against your application on a test environment. The data centre, hypervisor and managed platform underneath it are the provider’s scope, not yours. | The provider’s own certifications and the shared-responsibility boundary in your hosting agreement. |
| Embedded third-party components and services | Analytics scripts, payment widgets, CDN-delivered libraries and federated identity providers execute in your users’ context but are not your artefact and may not have been in scope. | A stated third-party inventory in the audit scope, and contractual assurance from each provider. |
| Everything that happened after the issue date | This is the whole subject of this page. The certificate is a considered opinion about one build, in one environment, on one date. | The change log, the digest comparison and the renewal trigger — the three controls this page keeps returning to. |
The distinction between this document and a general security audit report is confused routinely in procurement wording — see safe-to-host versus a security audit certificate for which one a given requirement is actually asking for, and GIGW compliance before go-live for the wider set of obligations a government application carries.
Confirm the wording — and why
Everything on this page is a reading of published documents, all of them linked in the sources section below. Before you build a release calendar, a budget line or a board assurance on it, confirm the precise wording against the current GIGW text and with the auditor who issued — or will issue — your certificate. Two reasons, neither of them a disclaimer for its own sake.
The certificate wording is the auditor’s, not the government’s.
GIGW sets the obligation to hold an audit clearance certificate and to re-audit at least annually or when source code changes. It does not prescribe the sentence printed on the certificate. That sentence is drafted by the issuing organisation — which is why the two certificates quoted on this page, both published on government domains, word validity differently, and why a third form of words is in general circulation. Your obligations are defined by the intersection of the guideline and your document, and the only person who can tell you what your document means is the organisation that signed it. Guidelines are revised, too: a page written in September 2026 is a starting point for reading the current text, never a substitute for it.
The cost of being wrong is asymmetric.
Being unnecessarily strict costs an extra retest. Being wrongly relaxed costs a lapse discovered by an evaluator, a blocked go-live, a rejected tender submission, and a finding written against a period during which a public service was running on an application whose audited state nobody could evidence. Those are not comparable outcomes, and the asymmetry should decide every close call — including the close call about whether to ask the question at all.
Six things teams believe that are not so
Each of these has cost somebody a go-live date. They are listed in roughly descending order of how often we meet them.
“It is valid for one year, full stop.”
One year is the outer limit, not the term — one published certificate calls it the maximum validity in as many words. Both clocks run at once and the certificate ends on whichever fires first. In an actively developed application that is almost always the change clock.
“Only major changes matter.”
“Major” is defined — by risk, not by size. CERT-In’s 2025 audit policy guidelines §13.1.2 classify a major change as “high-risk, impactful to security”, giving system overhauls, technology migrations and configuration adjustments affecting sensitive data or critical infrastructure as examples, and require the audit before implementation. A one-line config change can qualify. Separately, the word appears on neither certificate quoted here and not in the GIGW attribute, which says “as and when any changes are done in the source code”. So it neither means “big” nor governs your certificate’s validity.
“The year runs from when testing finished.”
It runs from the date of issue on both published wordings. Testing, remediation and review all happen before that date, which is why the audit date can be a range and the issue date a single day at its end.
“A certificate means the application has no vulnerabilities.”
It means the application was tested against a stated standard — the certificates quoted here name OWASP 2021 Top 10 and the OWASP Web Security Testing Guide — findings were raised, fixes were reviewed, and the auditor concluded it was safe for hosting on a particular build in a particular environment. That is a considered professional opinion about a point in time, not a guarantee. What it does not reach is set out in the section above.
“Certification is a compliance formality with no operational consequences.”
Under clause 3.2.2 of the empanelment terms the auditor must send the report and audit metadata to CERT-In within 5 days of completing the audit, and must report critical vulnerabilities together with auditee details where they were raised and not fixed even during follow-up audits. The audit has an audience beyond your organisation.
“We can rely on the certificate for our whole estate.”
The certificate names a site URL and a tested build on its face. Sibling applications, subdomains running different code, and the mobile app are separate artefacts requiring their own audits and carrying their own expiry dates.
What engineering leads push back on
Every one of these is raised in real planning meetings, usually by the person who will have to live with the answer. In each case the answer that works describes the mechanism rather than restating the rule.
“We deploy every week. Are you telling us we need fifty-two audits a year?”
No — we are telling you that the certificate covers a build, and that the answer is an engineering decision about which build carries the certificate rather than an audit-volume decision. Three patterns work. Separate the certified application from the change stream, so that content and configuration move freely while the build moves rarely. Run a slower release train for the certified artefact and let everything else ride a faster one. Or agree a standing delta-assessment arrangement with the issuing auditor so that most releases are a scoped retest rather than a full audit. What does not work is shipping weekly and assuming a certificate issued in April still describes what is running in November.
“Our certificate says one year. Why are you telling us about hashes?”
Because certificates differ. If yours says one year and nothing else, that is the wording you are governed by and you should be able to show it. If it carries a change condition — and both certificates quoted above do, in different words — the shape of that condition determines your release calendar. Either way the answer takes thirty seconds against a document you already hold, and the two readings produce release calendars that differ by months.
“Our auditor said a small change is fine.”
Then get it in the engagement terms, with the definition of “small” written out — and you do not have to invent the definition, because CERT-In’s 2025 audit policy guidelines §13.1.2 already require every change to be classified Minor or Major and define the terms by risk. Point at that and ask how your auditor applies it. A verbal assurance from an individual auditor does not survive that person changing employer, and under the empanelment guidelines a move between empanelled organisations is itself a controlled event requiring a no-objection or relieving letter as part of the background check. The position you want is a written delta rule the auditing organisation stands behind, not a person who remembers saying yes.
“Can we get a certificate that lasts longer than a year?”
Not on any wording we have seen — one published certificate states flatly that “the maximum validity of the certificate is One Year from the date of issue”, and the outer limit is the least ambiguous part of the rule. The useful question is a different one: how short can the audit-to-issue cycle be made, so the year you get is a full year rather than a year minus a remediation window. That is solvable. Extending the validity period is not.
“We are hosted on NIC infrastructure, so surely this is handled for us.”
Hosting and certification are different things, and CERT-In’s 2025 audit policy guidelines draw the line explicitly. Under §13.1.5, where a website sits on a web server owned by another organisation, responsibility for auditing the web server, its operating system, the hosting software and the backend database software “lies with the organization that owns and operates the server” — while the website’s owner remains responsible for ensuring the website data and software are audited by a CERT-In empanelled auditing organisation. So the provider covers the platform, but your application is still yours. GIGW naming NIC among the bodies whose auditors may issue is not the same as NIC holding a certificate on your behalf. Ask your hosting contact whether a certificate exists for your application, what its issue date is, and who holds the report — those three answers settle it.
“Does a valid certificate mean we are compliant with CERT-In?”
No, and the conflation is everywhere. The safe-to-host certificate evidences that an application was audited and found fit to host. The CERT-In Directions of 28 April 2022 impose continuing operational duties that a certificate says nothing about, and an organisation can hold a current certificate and be materially non-compliant with every one of them. The four duties and how they interact with a lapse are set out in the expiry section above. The point to carry away is that they are separate obligations with separate evidence, and neither substitutes for the other.
Where this gets contested
The rules above settle most questions. These are the ones that produce the arguments — between the delivery team and the security officer, and between the organisation and its auditor.
Your certificate says “major change” and the GIGW attribute says “any changes”
This is the live ambiguity in the whole subject, and it is not resolved by choosing the reading you prefer. Three instruments are speaking at once and they are not speaking about the same thing. The certificate governs what the auditor has attested. The GIGW attribute governs the organisation’s audit cadence. The 2025 audit policy guidelines §13.1.2 govern how changes are classified and when an audit must happen. A certificate can remain valid on its own terms while the organisation is out of step with its audit-cadence obligation, and an evaluator assessing conformity is reading the attribute. The safe construction is to satisfy both: hold a certificate whose wording you have confirmed with the issuer, and run an audit cadence that meets the attribute. Where a genuine conflict exists, the question belongs with the issuing auditor and, for a government body, with the department’s own IT security officer — not with a consultant’s interpretation.
The audit ran on the test URL and production has since diverged
Both published certificates name a testing URL distinct from the live site — one a local address, one an internal IP — and the IICA certificate states plainly that “The audit is performed on Test URL” and that “Build of Site URL and Test URL need to be identical.” Divergence between the tested build and the live build therefore does not merely risk expiry. It undermines the premise on which the conclusion was written. The control is the promotion process described in the build-identity section above.
A hotfix has to ship inside an hour
Security incidents do not wait for re-audits, and no reading of the validity rule requires an organisation to leave an exploited vulnerability in production. Ship the fix, record it as a change against the certificate on the day, notify the issuing auditor, and book the retest. Separately, check whether the event itself is a reportable cyber incident under the 2022 Directions, which run on a 6-hour clock from noticing. The certificate question and the incident question are different questions with very different deadlines.
You have two certificates — one for the web application, one for the mobile app
Normal, and they expire independently. GIGW names websites, web applications, web portals and mobile apps in the same attribute, but the artefacts are separate and so are the audits. The common error is a shared backend: a backend change can invalidate the web certificate, the app certificate, both or neither depending on what each audit scoped. Write the scope boundary of each certificate down at issue, in the same place you record the build identity.
The application is a portal assembled from several independently maintained components
Decide before the audit whether you are certifying the portal as one artefact or each component separately, because that decision determines what a change to one component does to the whole. A single certificate over an assembled portal means any component release is a change to the certified artefact. Several certificates mean more renewals but smaller blast radii. Neither is wrong. Drifting into the first while behaving as though you had the second is.
The certificate is valid but a critical finding was never closed
Validity and cleanliness are different properties. A certificate is issued after fixes are reviewed, but findings can be accepted, deferred or closed with compensating controls. Where a critical vulnerability was raised and not fixed even during follow-up audits, clause 3.2.2 of the empanelment terms obliges the auditor to report it — with your organisation’s details — to CERT-In within 5 days of completion of the audit. Treat an open critical finding as a live obligation with an external audience, not as a backlog item.
You changed auditors between renewals
Entirely permissible, and sometimes sensible. Expect the new auditor to test from scratch rather than accept the previous report, and expect the wording of the new certificate to differ from the old one — including, possibly, the validity note and whether it names a hash at all. The two certificates quoted on this page were issued by different organisations and word validity differently. Re-read the note on every re-issue. The assumption that this year’s certificate says what last year’s said is exactly the assumption that produces an unnoticed lapse.
The organisation is not a government body at all
The safe-to-host requirement sits in GIGW, which governs Indian government websites and apps. Private organisations meet CERT-In-adjacent obligations through other routes — regulator mandates, contractual requirements from a government customer, or the 2022 Directions, which apply to service providers, intermediaries, data centres, body corporate and Government organisations alike. If a private company is being asked for a safe-to-host certificate, the question worth asking first is which instrument the asker is relying on, because the answer changes what document actually satisfies them.
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. A safe-to-host audit is one of them, and so is its renewal, timed against the earlier of your two clocks. See how a CERT-In audit runs with us.
For our security testing practice, see VAPT and security testing.
Frequently Asked Questions
How long is a safe-to-host certificate valid?
Does the one year run from the audit date or the issue date?
What counts as a change to the audited build?
What happens if a safe-to-host certificate expires while the application is live?
Is there a grace period after a safe-to-host certificate expires?
Do we need a new certificate after every deployment?
Can we renew a safe-to-host certificate without a full re-audit?
Who can issue a safe-to-host certificate in India?
How do I check the auditor who issued our certificate is CERT-In empanelled?
What information is printed on a safe-to-host certificate?
Do we need a new certificate if our domain or URL changes?
Who in the department owns the safe-to-host certificate?
Is a valid safe-to-host certificate the same as CERT-In compliance?
Does a content update invalidate a safe-to-host certificate?
What should we do first if we cannot find our certificate or do not know its status?
Does an expired certificate mean the website must be taken down?
How far in advance should we start the re-audit?
The instruments this page is built on
Every quotation on this page comes from one of these documents, each of which is public. Where any of them disagrees with a vendor page, including this one, the document wins.
- GIGW 3.0 — Security: Guidelines and Attributes Guideline 5.3.1 (audit clearance certificate before hosting in production), the periodic-auditing attribute, and the evaluator’s verification requirement. Published by the National Informatics Centre.
- GIGW 3.0 — New features The “safe to host” formulation, and the statement that a chapter on cybersecurity formulated by CERT-In has been incorporated, based on practices including ISO 27001, OWASP ASVS, the OWASP Top 10 and the CIS benchmarks.
- Web Security Audit Certificate — Indian Institute of Corporate Affairs, issued 11 July 2024 Published on iica.nic.in. The source of the hash-and-dynamic-contents validity note, the 18 April to 11 July audit range, the build-parity condition and the hardening recommendation quoted on this page.
- Safe to Host Certificate — CSIR Human Resource Development Group, dated 17 May 2025 Published on csirhrdg.res.in. The source of the one-year maximum-validity wording, the source-of-tested-application condition, and the only stated hash algorithm quoted here.
- CERT-In — Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, 25 July 2025 §13.1.2, the annual audit requirement and the Minor Change / Major Change classification, including the requirement that a major change be audited before implementation. §13.1.5, which splits audit responsibility where a website is hosted on a server owned by another organisation.
- CERT-In — Terms and Conditions for Empanelment, Version 7.2, April 2024 Clause 2.1 (CERT-In is not a party to auditor–customer contracts), 3.1.7 (client data and reporting to CERT-In), 3.1.9 (point of contact and secure transmission), 3.2.1 and 3.2.2 (the 5-day reporting duties), and clause 4 (advertising and the permitted description).
- CERT-In — Guidelines for Empanelled Information Security Auditing Organizations, Version 3.0, May 2018 Staging-environment testing before issue, methodology-led rather than tools-only testing, the verification team, written approvals and tool removal, the prohibition on DDoS and flood testing, severity-based closure timelines, and India-only data handling.
- CERT-In — List of Empanelled Information Security Auditing Organisations The list to check an issuer’s name against, published from CERT-In’s empanelment page.
- CERT-In Directions under sub-section (6) of section 70B, 28 April 2022 The separate continuing duties: 6-hour reporting of the Annexure I incident types, 180-day log retention within Indian jurisdiction, NTP synchronisation to NIC or NPL, and a maintained point of contact.
Related Reading
How to Get a Safe-to-Host Certificate
Eleven stages end to end — eligible auditor, staging, first pass, remediation, retest, issue — plus what drives duration and cost.
Read moreWhat a Safe-to-Host Certificate Is
The audit clearance certificate GIGW 5.3.1 requires before a government application is hosted in production.
Read moreWhy Applications Fail Safe-to-Host
The finding classes that recur, and the ones that cost a second retest cycle.
Read moreHow to Verify a CERT-In Audit Certificate
Check the issuer, the signatures, the environment and the hash — before you accept the document.
Read moreGIGW Compliance Before Go-Live
The wider conformity picture — quality, accessibility, cybersecurity and lifecycle — of which safe-to-host is one part.
Read moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read more