The Guidelines for Indian Government Websites and apps are read as a style guide and enforced as a gate. One statement in the cybersecurity chapter decides whether a government site or application may be hosted in a production environment at all — and it is written in the past tense, which means the work has to be finished before the launch date, not scheduled around it.
The statement that gates everything: the site, app or portal has been security audited and an audit clearance certificate has been issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In-empanelled laboratory, before hosting in a production environment.
Plain-English explainer · Written from the GIGW 3.0 manual and guidelines.india.gov.in · CERT-In Directions, 28 April 2022 · Sources read 18 September 2026
GIGW is the Guidelines for Indian Government Websites and Apps — the standard that governs Indian government websites, web portals, web applications and mobile apps across four focus areas: quality, accessibility, cybersecurity and lifecycle management. GIGW compliance means conformity with those guidelines, which in the current edition, GIGW 3.0, run to 88 numbered guideline statements.
Before go-live, GIGW compliance means one thing above all others: the website, web application, web portal or mobile app has been security audited and an audit clearance certificate has been issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In-empanelled laboratory, before it is hosted in a production environment. That is statement 5.3.1, the first of three statements in the cybersecurity chapter, and it is the reason a hosting provider asks for a certificate before it will accept a deployment. Three of the eighty-eight statements gate production hosting. The other eighty-five do not.
GIGW was formulated by the National Informatics Centre in 2009 and made part of the Central Secretariat Manual of Office Procedure by the Department of Administrative Reforms and Public Grievances. GIGW 2.0 followed in 2019. The current edition was formulated jointly with the Standardisation Testing and Quality Certification (STQC) Directorate of MeitY and the Indian Computer Emergency Response Team (CERT-In), and its cybersecurity chapter was formulated by CERT-In — as the guidelines’ own introduction records. The certificate that satisfies statement 5.3.1 is the artefact most people call a safe-to-host certificate. GIGW uses both names, calling it an audit clearance certificate in the statement and a “safe to host” certificate in its summary of what is new in 3.0.
Key Takeaways
- GIGW is a gate, not a style guide. Three statements in its cybersecurity chapter decide whether a government site or app may be hosted in production at all, and the first is written in the past tense — so the audit, the remediation and the retest all precede the launch date.
- It binds Central and State governments, district administrations and local governments, at any organisational level, and every website or app a government organisation owns — including ones a vendor built and runs.
- Four bodies may issue the clearance: NIC, STQC, an STQC-empanelled laboratory, or a CERT-In-empanelled laboratory.
- GIGW names ISO 27001, OWASP ASVS, OWASP Top 10 and CIS benchmarks — and names no ASVS level. A citizen-facing transactional government application should be scoped at ASVS Level 2. A scope of work that leaves the level blank transfers the choice to the tester.
- The gate has a second half most departments miss. Statement 5.3.2 puts obligations on the government organisation itself: hosting inside India, DC/BCP/DR in high availability, annual DR drills, hardening with VA and PT, a deployed WAF, and 180-day log retention.
- Accessibility runs in parallel, not afterwards: fifty statements at WCAG 2.1 Level AA, of which 49 evaluator actions name manual testing.
- The certificate expires by event as well as by date — at least once in a year, or as and when any changes are done in the source code, whichever is earlier.
- We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. The safe-to-host audit behind a GIGW go-live is one of them.
A note on clause numbering and sources
Every statement number on this page — 5.1.1 to 5.1.25 for quality, 5.2.1 to 5.2.50 for accessibility, 5.3.1 to 5.3.3 for cybersecurity, 5.4.1 to 5.4.10 for lifecycle management — was read from chapter 5 of the GIGW 3.0 manual, which prints the number beside each statement, and the per-chapter counts were confirmed a second time by counting the statements published on the official guidelines index. One caveat worth carrying: the live cybersecurity chapter web page mis-numbers the third security statement as 5.3.2, so 5.3.2 appears twice there. The manual numbers it 5.3.3, and this page follows the manual. GIGW is a living document and its numbering has changed between editions, so before you cite a number in a tender response or an audit submission, open the current published text and confirm it. Quote the statement and treat the number as a pointer.
Who GIGW applies to — ministries, states, PSUs and vendor-built sites
Most writing on this subject says “government organisation” and leaves it there, which is why state departments and public sector undertakings routinely assume the page is not about them. GIGW is explicit. Its scope and objective recommends the guidelines for Indian government websites and applications “at any organisational level and belonging to both Central Government as well as State Governments (including district administrations and local governments)”, says that all websites and apps owned by government organisations must comply, and recommends that browser-based intranet applications follow them too. The guidelines are circulated to all Indian government organisations at all levels.
| Body | In scope | Who plays the WIM role | Typical issuer route |
|---|---|---|---|
| Union ministry, department, attached or subordinate office | Yes, at any organisational level — GIGW is circulated to all Indian government organisations, and DARPG made it part of the Central Secretariat Manual of Office Procedure. | An officer not below the rank of Joint Secretary, which is the rank GIGW names. For an attached or subordinate office the parent ministry often nominates, or an officer of equivalent seniority is designated. | Usually NIC, where the site is built or hosted inside the NIC estate. |
| State government department | Yes. The scope covers Central Government and State Governments expressly. | Joint Secretary is a Union rank. In a state the equivalent is normally a Secretary, Special Secretary or Additional Secretary to the State Government, or a Director heading the department. GIGW does not resolve the equivalence, so the nominating authority does — settle it in writing. | NIC state centre, or a CERT-In-empanelled laboratory the department procures. |
| District administration or local government | Yes. The scope names district administrations and local governments, including urban local bodies. | Usually the District Magistrate or Collector, or a municipal Commissioner. The rank equivalence is a local determination and should be minuted. | State NIC centre most often, because district sites commonly sit on state infrastructure. |
| PSU, CPSE or statutory body | Yes, as a government organisation. STQC also accepts private websites into its certification scheme, so a PSU has no ambiguity to shelter behind. | A whole-time director or functional head of equivalent seniority. GIGW contemplates public sector organisations expressly, directing them to display their official logo where a Central ministry displays the State Emblem. | Open-market procurement from a CERT-In-empanelled laboratory, because a PSU has its own procurement machinery. |
| Autonomous body, university or research institute | Yes where the body is a government organisation. GIGW contemplates educational and research institutions by allowing edu.in, res.in or ac.in domains where they are eligible for gov.in. | The Registrar, or a Dean or Director of equivalent standing. | Open-market procurement, or the parent ministry route where the institute sits under one. |
| A site built and run by a vendor | Yes — the obligation follows ownership, not operation. All websites and apps owned by government organisations must comply, and the government organisation action sits on the department. | The department nominates. A vendor cannot be the WIM. A vendor is the developer, and GIGW separates the two roles deliberately. | Whatever the contract provides — but the organisation that built the application is not the ideal one to clear it. |
| An internal or intranet application | Recommended rather than mandated: GIGW says browser-based intranet applications should also follow the guidelines. Statement 5.3.1, though, is written about hosting in a production environment, not about public reachability. | The same WIM, because the policy set and the conformity file are departmental. | Take the determination with the WIM and the hosting provider in writing — the provider is the party that will ask for a certificate. |
One row is the source of more confusion than the rest. Statement 5.4.1 says the department must appoint a Web Information Manager who is a senior official not below the rank of a Joint Secretary. That is a Union rank. It does not exist in a state department, a municipal corporation or a PSU. GIGW publishes no equivalence table, so the nominating authority decides what “not below that rank” means in its own structure and minutes the decision — the evaluator interviews the WIM during the backend audit, and “we were not sure” does not survive that conversation.
The four GIGW focus areas — one of them blocking
Every GIGW requirement has the same shape: a Statement of what must be true, the Benefit, and then separate actions for the government organisation, the developer and the evaluator — GIGW says so expressly, noting that government organisation actions are undertaken by the WIM. That structure tells you who owns each requirement before you start arguing about it. Read the statement to know what is required, and read the evaluator action to know how it will be checked.
| Focus area | Where it sits | What it covers | How it behaves at go-live |
|---|---|---|---|
| Quality | 5.1 — statements 5.1.1 to 5.1.25 | Association to government, ownership information, content currency, downloadable-material metadata, archival, contact and feedback, search, mobile responsiveness, the gov.in or nic.in domain requirement, and API integration with India Portal, DigiLocker, Aadhaar, single sign-on, MyGov and the data platform. | Assessed against the Website Quality Manual and the live site. Quality defects rarely block hosting on their own, but they block the CQW certification the department is usually chasing next. |
| Accessibility | 5.2 — statements 5.2.1 to 5.2.50 | Fifty statements, each mapped one-to-one in the conformity matrix to a WCAG 2.1 success criterion from 1.1.1 through 4.1.3. GIGW 3.0 moved the baseline from WCAG 2.0 to Level AA of WCAG 2.1, adding seventeen new success criteria. | Forty-nine of the fifty evaluator actions name manual testing. Tooling appears in eighteen and assistive technology in thirteen, always alongside manual testing and never instead of it. |
| Cybersecurity | 5.3 — statements 5.3.1 to 5.3.3 | Three statements, formulated by CERT-In. The first is the go-live gate: the security audit and the audit clearance certificate. The second covers the hosting environment. The third covers the Security Policy, Privacy Policy and Contingency Management Plan behind both. | Three of the eighty-eight statements, and the only three a hosting provider enforces before it will accept a deployment. Everything else on this page is downstream of that arithmetic. |
| Lifecycle management | 5.4 — statements 5.4.1 to 5.4.10 | Nomination of a Web Information Manager, the ten-document policy set the WIM approves, hyperlink accuracy, content moderation, simultaneous multilingual updates, broken links, accessible document formats and bilingual delivery. | Nothing here blocks a first deployment by itself, but 5.4.1 decides who is accountable for everything that does. A department without a nominated WIM has nobody empowered to approve the policies 5.3.3 and 5.4.3 require. |
Eighty-eight statements, and three of them decide whether you can deploy. That imbalance is why a department reading GIGW cover to cover comes away with an impression of a design and content standard: eighty-five statements are about quality, accessibility and governance. The three in the cybersecurity chapter are the ones a hosting provider enforces. The manual also publishes Annexure II, a matrix to check conformity, running across all four chapters and mapping each guideline to the risk factors it addresses — which is the closest thing the document has to a submission format, and is worked through further down this page.
GIGW and safe-to-host terminology — five terms that get confused
Most of the confusion in this area is vocabulary rather than substance. A procurement pack will use three names for one document and one name for three different obligations. These are the five terms worth fixing before a scope of work is written, because every one of them changes what somebody is expected to deliver.
| Term | What it means in the guidelines | What it means in practice |
|---|---|---|
| Audit clearance certificate | GIGW’s own name for the artefact inside statement 5.3.1. The evaluator action for the same statement calls it a “valid security audit certificate”, so the guideline uses two names in two consecutive paragraphs. | The document the hosting provider files. It certifies the tested build, not the organisation, and not the next build. |
| Safe-to-host certificate | The operational name for the same artefact. GIGW’s summary of what is new in 3.0 says 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. | Both names are live. Hosting forms tend to say safe-to-host, while the statement says audit clearance certificate. Expect both in one procurement pack. |
| CERT-In empanelment | An issuer qualification, not a testing method. Statement 5.3.1 names a CERT-In-empanelled laboratory as one of four bodies, and the evaluator action repeats the same four. | Empanelment is a status CERT-In grants an organisation, and the certificate is issued by that organisation. For Government and critical-sector audits the CERT-In auditor guidelines require manpower declared to CERT-In in the snapshot information form, which CERT-In may verify independently. |
| CQW / Website Quality Certification | A separate STQC scheme. The award of the mark “Certified Quality Website (CQW)” is a recognition that the website complies with the requirements of GIGW and that the organisation has adequate procedures and processes in place. | Different artefact, different body, different validity. GIGW says the certification of cybersecurity aspects by STQC may be done on the basis of the safe-to-host certificate — so the clearance feeds CQW rather than replacing it. |
| Web Information Manager (WIM) | Statement 5.4.1: the government organisation has nominated a WIM as defined in the guidelines. The government organisation action is explicit — a senior official not below the rank of a Joint Secretary. | The WIM approves the ten-document set under 5.4.3 and is the signature that makes go-live a departmental decision rather than a vendor’s. GIGW also expects the evaluator to interview the WIM to assess awareness and competence. |
The distinction that costs the most money is the last-but-one: a safe-to-host certificate and a CQW certificate are not the same document, do not come from the same body, and do not expire on the same schedule. The three-year certification sits on a security clearance that lapses after twelve months. For the boundary between the two, see safe-to-host versus a security audit certificate.
Reading GIGW statement 5.3.1 — one sentence, read slowly
Everything a department needs to plan is contained in the first statement of the cybersecurity chapter. It is worth reading as a lawyer would, one clause at a time, because each clause carries a scheduling consequence.
“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.”
“Website, web application, web portal or mobile app”
Four kinds of thing, listed so that no one can argue a mobile app or a headless application sits outside. The scope question at go-live is never whether your artefact is one of these. It is which instances of them you are deploying. A portal with two sub-applications, a mobile app on two platforms, a partner API and an admin console is seven things to scope, not one, and every one of them is in production the moment it is reachable.
“have been Security Audited”
Past tense, and note what it does not say: not scanned, not reviewed, and no methodology named. The methodology comes from the chapter preamble — ISO 27001, OWASP ASVS, OWASP Top 10 and CIS benchmarks — and from the CERT-In auditor guidelines, which require industry-standard methodologies and state that solely tools-based testing should be discouraged. A scanner report is not an audit, and the people who read these certificates know the difference.
“and an Audit Clearance certificate has been issued”
Clearance, not assessment. Testing that ends with findings has not produced clearance. A certificate follows remediation and retest. This single word is why a realistic plan budgets three phases — test, fix, retest — and why the arithmetic that sinks go-live dates is a missing remediation window rather than a missing test window.
“by NIC/ STQC/ STQC empanelled laboratory/CERT-In empanelled laboratory”
A closed list of four, and the evaluator action for the same statement repeats it: the evaluator shall check that the website, web application, web portal or mobile app under evaluation has a valid security audit certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In-empanelled laboratory, fulfilling CERT-In requirements. Anyone outside that list — an internal security team, a development partner, a general IT services firm, a consultancy without empanelment — can do excellent work and cannot issue the artefact. It is covered in more detail on who can issue safe-to-host certificates.
“before hosting in production environment”
The trigger is hosting in production, not public launch. A soft launch, a pilot with three districts, a demonstration to a minister or a “quiet” period before announcement is still hosted in a production environment. Departments that read this as “before we announce it” give themselves weeks of grace the statement does not offer.
“We will get the certificate after launch.”
Who can issue the certificate — four routes, four lead times
The four are equivalent for satisfying statement 5.3.1 and not equivalent for planning. No clearance timeline is published for any of them, so the useful comparison is not how long each takes but what drives the elapsed time and how much of it you control. On that test they rank in a stable order: a CERT-In-empanelled laboratory procured on the open market gives the department the most control, an STQC-empanelled laboratory under a rate contract slightly less, STQC itself less again because the security date depends on the assessment date, and NIC least, because allocation is not a departmental variable. Choose the route when the project plan is written. This is covered end to end on who can issue safe-to-host certificates, including how to check that an organisation’s empanelment is current.
| Issuer | What it is | When departments use it | What drives the elapsed time |
|---|---|---|---|
| NIC | The National Informatics Centre’s own auditors. | Sites built or hosted inside the NIC estate, where audit and hosting sit under one roof. | Internal allocation. NIC serves government organisations across the country, so the variable the department controls least is when a slot opens — and the one it controls most is how early it asks. |
| STQC | The Standardisation Testing and Quality Certification Directorate of MeitY, in its own laboratories. | Departments already inside the STQC certification path, where CQW is the destination. | Certification sequencing. STQC’s CQW process places the security audit after a satisfactory website assessment, so the security date depends on the assessment date. |
| STQC-empanelled laboratory (SETL) | A laboratory empanelled by STQC with scope for GIGW evaluation. | Capacity relief where STQC’s own labs are committed, or procurement through a rate contract. | Contract lead time — a purchase order where a rate contract exists, a full procurement where it does not. Confirm the empanelment is current and covers the work. STQC notes SETLs perform evaluation and do not issue the certificate. |
| CERT-In-empanelled laboratory | An organisation empanelled by CERT-In for providing information security auditing services. | Departments procuring on the open market with their own procurement machinery. | Procurement plus the empanelment check. The department controls the most variables here — timing, scope and vendor — provided the empanelment is verified against CERT-In’s published list rather than a letterhead. |
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. The safe-to-host audit a department needs before a GIGW go-live is one of them. See how a CERT-In audit runs with us.
One further constraint shapes how empanelled organisations may talk about themselves. The CERT-In auditor guidelines state that an auditor shall not use the CERT-In logo, nor make any reference to its association with CERT-In on any publicity or promotional material without CERT-In’s prior written permission — and that an auditor may use the words “This Organization is empanelled by CERT-In for providing information Security Auditing Service”, with no other words used without that permission. A vendor site carrying a CERT-In logo and a paragraph of creative phrasing about its association with CERT-In has told you how carefully it reads the guidelines it wants you to trust it with. The current list is published by CERT-In itself, and that is what to check against.
The security standards GIGW names — four standards, four jobs
The cybersecurity chapter does not leave “security audited” undefined. Its preamble says the government organisation will ensure and monitor that the host service provider and the developer adhere to industry best security practices and guidelines such as ISO 27001, OWASP ASVS, OWASP Top 10 vulnerabilities and CIS benchmarks. They are not alternatives. Each answers a different question, and a test plan that uses only one of them has a visible hole.
| Standard | The job it does | Where it shows up in the work | How a tester treats it |
|---|---|---|---|
| ISO 27001 | Management-system reference for the organisation running and hosting the site. | Controls around the hosting environment and the department’s own operations — access control, logging and monitoring, change control, backup, supplier management, incident handling. It is the frame statements 5.3.2 and 5.3.3 sit inside. | Not a pass/fail item on the application test plan. It shows up as evidence about how the environment is run, and is where a hosting provider’s own certification is usually cited. |
| OWASP ASVS | Verification-requirement catalogue for the application itself. | The structure of a competent test plan: authentication, session management, access control, input validation, cryptography, error handling, data protection, communications, business logic, files, API and configuration. ASVS requirements are levelled, and GIGW names ASVS without naming a level. | The most useful of the four, because it converts “security audited” into an enumerable list a non-specialist can review before testing starts. GIGW’s government organisation action also names OWASP MAVS for mobile. |
| OWASP Top 10 | Awareness list of the most critical web application security risks. | The coverage statement in the report, and the categories findings map to. GIGW’s government organisation action says the site should not have any security risks as identified by the latest OWASP Top 10 list. | A floor, not a ceiling. A report that maps only to the Top 10 has demonstrated it looked for ten categories of risk. ASVS is what shows it worked through a requirement set. |
| CIS Benchmarks | Configuration baselines for the operating systems, web servers, databases and container platforms underneath. | The hardening half of the work, mapping closely onto GIGW’s own system-administration attributes: ports closed by default, default and guest accounts removed, service banners suppressed, weak ciphers disabled, obsolete libraries replaced. | The part departments most often leave out of scope, because it belongs to whoever administers the server. A configuration review benchmark by benchmark is the difference between a hardening claim and hardening evidence. |
Alongside those four, statement 5.3.1 spells out its own developer actions — a secure-build checklist in two parts, worth reading in the original rather than in summary. The code half covers CMS, plugin and library currency. It covers salted-hash encryption of passwords, connection strings, tokens and keys, with nothing in plain text anywhere. And it covers custom error pages that never leak source, obscured HTTP response headers, secure HTTP-only cookies, captcha on login pages, directory traversal disabled, renamed default usernames and admin URLs, web-server processes running as a dedicated limited-privilege account, MFA, role-based access control, and input sanitised at both client and server, syntactically and semantically. The database half covers encryption at rest and in transit, salted hashing of stored passwords, default administrative passwords changed, TLS between web servers and databases, least privilege, surface-area reduction, audit trail logs, and backups kept off the website server. The item most often found open is stated plainly: access to the database only from the web server, on a whitelisted port, never assigned a publicly accessible IP. Every one of these is a configuration a tester can verify in an afternoon and a department can fix in a morning, which is why finding them in a clearance report is avoidable.
Choosing an OWASP ASVS level — the most cost-driving line in the scope
GIGW names OWASP ASVS and does not name a level. ASVS itself is levelled — three verification levels, each a different depth of assurance — as OWASP publishes them. That means the level is a decision the department makes, and it is the single largest determinant of what the engagement costs and how long it takes. A scope of work that leaves it blank does not avoid the decision. It transfers it to whoever is quoting, and the department finds out which level it bought when it reads the report.
| Level | What it means | Typical fit in government work | What it adds to test effort |
|---|---|---|---|
| Level 1 | The lowest assurance level, and the one fully testable from outside — Level 1 controls can be checked by tools or by hand without access to source code. | An informational site with no login, no personal data and no transaction. | The baseline. It establishes that the obvious classes of defect are absent. It does not establish that access control between two citizens’ records holds. |
| Level 2 | The level ASVS describes as appropriate for applications containing sensitive data, and recommends for most applications. | Any citizen-facing transactional government application: grievance redressal, scheme application and status, licensing, recruitment, land records — anything with a login, personal data or a payment path. This is the default a government scope of work should name. | Adds authorisation testing across roles and across records, session and token handling, cryptographic storage and business-logic abuse — work that needs more than one test account and a defined role matrix from the department. |
| Level 3 | The highest level, reserved for applications needing significant verification — ASVS names health and safety, military and critical infrastructure. | An application whose compromise carries national-security, life-safety or critical-infrastructure consequence. | Adds design review and source-code-level verification to the dynamic testing, changing both the duration and the access the department must grant. |
The rule, stated plainly
A citizen-facing transactional government application — anything with a login, anything holding personal data, anything with a payment path — should be scoped at ASVS Level 2. An informational site that only publishes, with no authentication and no personal data, can reasonably sit at Level 1. Level 3 is for the narrow set where compromise carries national-security, life-safety or critical-infrastructure consequence, and it changes the engagement shape because it brings design review and source-code-level verification with it. Name the ASVS version as well as the level: the level definitions were restructured between ASVS 4.0.3 and ASVS 5.0.0, so “Level 2” on its own is ambiguous across versions in a way “ASVS 5.0.0 Level 2” is not.
GIGW hosting-environment requirements — your obligation, not the provider’s
Statement 5.3.2 says the hosting environment has been secured for confidentiality, integrity and availability — and the attributes below are filed under it as a government organisation action, introduced as “certain mandatory aspects to check for when choosing a hosting service provider”. That placement is the point: the department is answerable whoever operates the infrastructure. Most of these are configuration items, cheap to fix before testing and expensive to explain afterwards. The middle column reproduces the guideline’s own wording from the published cybersecurity chapter.
| Attribute | The guideline’s own words | What the evidence looks like | Where it goes wrong |
|---|---|---|---|
| Hosting inside India | Ensure the hosting of the web infrastructure within geographical boundaries of India. | A written statement naming the data-centre locations, plus the region and availability-zone configuration from the console rather than the contract. | A managed service inside an Indian region that fails over to a foreign region, or a CDN, log-analytics or email-delivery dependency that lands data outside India while the application servers sit inside it. |
| DC, BCP and DR in high availability | Department to ensure the HSP is providing DC, BCP and DR environments with state-of-the-art secure infrastructure configured in high availability (HA) mode. | Architecture documentation showing the three environments, the replication between them, and what is configured for automatic failover rather than described as capable of it. | A DR environment that exists as a contract line and an empty subscription. An environment nobody has ever cut over to is a plan, not an environment. |
| Annual DR drill | Conduct periodic drills of disaster recovery environment – at least once in a year. | The drill record: date, scope, who ran it, what failed over, how long it took, what broke, what changed. A drill with no defect list tested the runbook, not the environment. | For a first go-live there is no prior drill. Say so and state the scheduled date — a commitment with a date survives review, but silence does not. |
| Data-centre and physical controls | HSP to ensure that the servers are protected against environmental, physical and cyber threats, and that all security controls of the Data Center including physical security and appropriate access control mechanisms are implemented. | The provider’s data-centre control documentation and any independent assurance it holds, plus the access arrangements for anyone who can reach the racks or the console. | Accepting a provider certification as evidence about your own tenancy. Their certification covers their controls, but the configuration of your tenancy is still yours. |
| Hardening, VA and PT | Servers, Network devices used to host the website should be hardened with latest security patches and periodic Vulnerability Assessment (VA) and Penetration Testing (PT) followed by corrective actions. | The hardening baseline, the configuration review against it, the VA scan with a run date and visible scope, the penetration-test report, and the closing retest. | Findings without closure. The attribute says corrective actions — a VA report with forty open highs and no retest evidences that testing happened and remediation did not. |
| Web Application Firewall | Ensure the HSP has deployed and configured a Web Application Firewall (WAF), which is hardened with latest security patches and is available for use by the department on demand. | The rule set, the mode it runs in, the tuning for this application, the patch level, and — because the guideline says so — that it is available to the department on demand. | A WAF in detection-only mode described as deployed. Also: a WAF treated as remediation. An input-validation defect mitigated by a WAF rule is still an input-validation defect. |
| 180-day log retention | Enable and maintain logs of the ICT infrastructure for a rolling period of 180 days as per CERT-In directions. | The retention configuration, the log sources feeding it, and the storage location — the Directions require these logs to be kept within Indian jurisdiction. | The default retention of the managed log service, frequently 30 or 90 days. A configuration change rather than a project, which is why it is worth checking before testing starts. |
| Alert and log review | Regularly monitor and conduct review of alerts and logs. | Who reviews, how often, against what, and where the record lives. A named reviewer and a dated record beat any description of a capability. | Collection mistaken for review. Shipping logs to a platform nobody opens satisfies the retention attribute and fails this one. |
| Transfer and host hygiene | Web host offer a Secure File Transfer Protocol (SFTP); FTP use by unknown users are disabled; It uses a rootkit scanner. | Configuration showing SFTP on and plain FTP off, the file-transfer account list, and the rootkit scanner with its last run. | A legacy content-upload workflow still using FTP because a content team has used it for years — usually discovered by the tester rather than declared by the department. |
| Container security | HSP should ensure to secure the containerized environments, if applicable. | Base-image provenance and signing, registry access control, image scanning, orchestration RBAC, network policies, private subnets, a firewalled etcd cluster, key rotation and secret management — all of which GIGW spells out underneath this one line. | Treating “if applicable” as optional. If the application runs in containers it is applicable, and a container estate assessed only through the application’s front door has not been assessed. |
Underneath those, statement 5.3.2 carries its own developer action addressed to the system administrator or DevOps engineer rather than to the application developer, and it is essentially a CIS-shaped hardening list: least privilege on admin access, ports closed with deny-all by default, default and guest accounts removed, unused modules disabled, SFTP for file transfer, HTTP disabled in favour of HTTPS with HSTS, service banners configured so web server and OS type and version are not disclosed, the web-server configuration files protected — GIGW names .htaccess, nginx.conf and web.config by name — obsolete libraries and outdated protocols replaced, network segmentation, development environments isolated from production, a software change control system, and periodic secure configuration review. Two items are specific enough to quote: a valid SSL certificate is mandatory on all websites and must use at least 2048-bit SHA-256 encryption or higher, with expiry tracked, and the weak ciphers to disable are named — SSLv2, SSLv3, 3DES, RC4, TLS 1.0 and TLS 1.1.
The planning implication is obvious: a substantial part of what a safe-to-host engagement examines belongs to whoever administers the infrastructure, not to whoever wrote the application. In government work those are usually two organisations, so both need to be in the room when the scope is agreed and both need a named person who can make changes during remediation. The evaluator action for 5.3.2 is blunt: the evaluator shall check that the government organisation actions are being complied with. That check lands on the department.
The GIGW policy pack — ten documents and one approver
Statement 5.3.3 asks that the website has the Security Policy, Privacy Policy and Contingency Management Plan clearly defined and approved by the government organisation. Statement 5.4.3 asks for a further set approved by the Web Information Manager — and the published list under 5.4.3 is ten documents, not seven, with the three security documents appearing in both places. The requirement in every case is approval, not authorship, and approval needs an approver: statement 5.4.1 asks the government organisation to appoint a WIM who must be a senior official not below the rank of a Joint Secretary.
| Document | Where the requirement comes from | Minimum contents | Who approves, and what record proves it |
|---|---|---|---|
| Security Policy | Statement 5.3.3, approved by the government organisation. Also item 10 of the 5.4.3 set, approved by the WIM. | Scope. Roles. Access control and privilege management. Password and MFA rules. Patching and change control. Logging, retention and review. Backup and restore. Vulnerability management including the audit cadence. Incident handling and the reporting route to CERT-In and NIC-CERT. Supplier obligations. The review cycle. | The government organisation, with the WIM responsible for implementation across the lifecycle. The approval minute, plus the records the policy generates — access reviews, patch logs, change tickets, scan reports. |
| Privacy Policy | Statement 5.3.3 and 5.4.3 item 8. The 5.3.3 developer action requires citizen-facing policies — copyright, privacy, terms and conditions — to be published on the website. | What personal data the application collects and where. The purpose for each. Who it is shared with. Retention. Cookies and analytics. The rights available and how to exercise them. The contact point for privacy queries. | The government organisation, approved and then published. The published page, reconciled against a data inventory built from the application’s actual forms and integrations. |
| Contingency Management Plan | Statement 5.3.3 and 5.4.3 item 9. | Scenarios. Trigger and severity definitions. Roles and escalation path with names and out-of-hours contacts. Technical response per scenario. Reporting to CERT-In within six hours and to NIC-CERT for the NIC estate. Citizen communications. Recovery and DR invocation criteria. The review and drill cycle. | The government organisation. The approved plan, the drill records, and the incident log — including a nil return, which is itself a record. |
| The 5.4.3 set — ten documents | Statement 5.4.3, approved by the WIM. The published list is ten documents, three of which are the same three 5.3.3 asks the government organisation to approve. | Copyright Policy. Content Contribution, Moderation and Approval (CMAP) policy. Content Archival (CAP) policy. Content Review (CRP) policy. Hyperlinking Policy. Terms and Conditions. Website Monitoring Plan. Privacy Policy. Contingency Management Plan. Security Policy. | The Web Information Manager. For each: the WIM’s approval, publication where citizen-facing, and the operational record the policy produces. |
The 5.4.3 set, one row per document
Departments meet this set as a single table cell in a checklist and then discover it is ten separate approvals. The evaluator does not test whether the documents exist: it compares the policies in the Website Quality Manual against the website for consistency, then checks implementation by examining the records the implementation generates. Each document therefore needs an approval and an operational trace.
| Document | Published or internal | The record that proves implementation |
|---|---|---|
| Copyright Policy | Published — citizen-facing. | Permission records for third-party content reproduced on the site. |
| Content Contribution, Moderation and Approval (CMAP) | Internal. | The CMS workflow history: who created, moderated and approved, and when. The evaluator checks randomly picked content against the policy. |
| Content Archival (CAP) | Internal. | Expiry dates on time-sensitive content, and the archive holding outdated tenders, notices and press releases. |
| Content Review (CRP) | Internal. | The review log behind the last-reviewed date the homepage displays. |
| Hyperlinking Policy | Usually published. | Link-validation output and the external-link alert mechanism working on the live site. |
| Terms and Conditions | Published — citizen-facing. | The published page, consistent with what the application actually does. |
| Website Monitoring Plan | Internal. | Monitoring output: uptime, performance, broken-link runs, security alerts. A plan with no output has not been implemented. |
| Privacy Policy | Published. | Also required under 5.3.3. The data inventory behind it. |
| Contingency Management Plan | Internal. | Also required under 5.3.3. Drill records and the incident log. |
| Security Policy | Internal. | Also required under 5.3.3. The audit cadence, patch and access records. |
An illustrative Contingency Management Plan outline
- 1. Scope and activation — which sites, apps, APIs and environments the plan covers, and what event activates it.
- 2. Severity definitions — mapped against the reportable categories under the CERT-In Directions, so the six-hour clock is not a judgement call at 2 a.m.
- 3. Roles and contacts — the WIM, the technical team, the hosting provider, the issuing organisation, communications. Names, numbers and an out-of-hours route for each.
- 4. Reporting — CERT-In at incident@cert-in.org.in and 1800-11-4949, and NIC-CERT at incident@nic-cert.nic.in for the NIC estate, both named in GIGW’s own developer action under 5.3.1.
- 5. Technical response per scenario — defacement, unauthorised access, data breach or leak, denial of service, provider outage, compromise of the CMS or a plugin.
- 6. Recovery — DR invocation criteria, who authorises a cutover, the restore procedure, and the acceptance test that says recovery finished.
- 7. Citizen communications — who speaks, through which channel, and what is said while the facts are incomplete.
- 8. Review and drill cycle — including the annual DR drill the hosting attributes require, and the record each drill produces.
Illustrative, not a template. GIGW publishes no required structure for this document — only the requirement that the plan is clearly defined and approved and that the WIM ensures implementation across the lifecycle. The value is in the questions the outline forces before an incident, not the headings.
A policy is tested through the records it produces. A content approval policy is evidenced by approval records, and a monitoring plan by monitoring output. A policy that has never produced a record has never been implemented, and the evaluator action is written to notice.
GIGW accessibility requirements — WCAG 2.1 Level AA, fifty statements
The accessibility duty on an Indian government website does not begin with GIGW. GIGW says its own basis includes ISO 23026, the W3C Web Content Accessibility Guidelines 2.1, the Rights of Persons with Disabilities Act, 2016 and the Information Technology Act, 2000 — so the accessibility chapter is the operational expression of a statutory expectation, not a design preference. GIGW 2.0 conformed to WCAG 2.0. GIGW 3.0 ensures conformity with Level AA of WCAG 2.1, and adds seventeen new success criteria aimed at users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Chapter 5.2 runs to fifty statements, 5.2.1 to 5.2.50, and Annexure II maps each one to a WCAG 2.1 success criterion from 1.1.1 through 4.1.3.
| How it is evaluated | How many | Examples | Why |
|---|---|---|---|
| Manual testing alone | 29 of 50 | Whether instructions rely solely on sensory characteristics such as shape, colour, size or position (5.2.9, WCAG 1.3.3). Whether a reading sequence preserves meaning (5.2.8, WCAG 1.3.2). Whether link text describes its purpose (5.2.30, WCAG 2.4.4). Whether headings and labels describe topic or purpose (5.2.32, WCAG 2.4.6). Whether captions and audio description are genuinely equivalent (5.2.3–5.2.6, WCAG 1.2.2–1.2.5). | These are judgements about meaning. No tool can decide whether alternative text serves the equivalent purpose. |
| Manual testing plus accessibility tooling | 18 of 50 name a tool | Contrast ratios of 4.5:1 for text and 3:1 for non-text content (5.2.14 and 5.2.18, WCAG 1.4.3 and 1.4.11). Markup validity with complete tags, correct nesting and unique IDs (5.2.48, WCAG 4.1.1). Programmatically determinable name, role and value (5.2.49, WCAG 4.1.2). Status messages exposed to assistive technology (5.2.50, WCAG 4.1.3). Resize and reflow (5.2.15, WCAG 1.4.4). | A browser extension, plug-in or web accessibility tool finds the mechanical failures fast. GIGW names the tool alongside manual testing in every one of these, never instead of it. |
| Manual testing plus assistive technology | 13 of 50 name assistive technology | Text alternatives for non-text content (5.2.1, WCAG 1.1.1). Information, structure and relationships conveyed by presentation (5.2.7, WCAG 1.3.1). Keyboard operation without a trap (WCAG 2.1.1 and 2.1.2). Focus visibility and focus order. Name, role and value exposure. | A screen reader is the only way to observe what is actually announced — and this bucket often needs someone who uses assistive technology daily, not a tester who has installed one. |
| Tooling without an explicit manual step | 1 of 50 | The high-contrast-mode statement, where the evaluator action is written as checking whether high contrast mode is available, using an accessibility extension, plug-in or web accessibility tool. | One statement out of fifty. The planning conclusion is the opposite of the one departments usually reach: an automated accessibility score covers almost none of the chapter. |
Counts taken by reading all fifty evaluator actions as published on the official guidelines page. The buckets overlap where a statement names both a tool and assistive technology, which is why the tool and assistive-technology figures are given as “of 50” rather than summed.
What the evaluation report must contain
Four things, for the conformity file to hold: a result for every one of the fifty statements rather than a score, the method used for each (because GIGW specifies the method statement by statement), a defect list grouped to the templates and components that produce the defects rather than to the pages where they appear, and a retest result. GIGW names tooling by category rather than by product — an accessibility extension to the browser, an accessibility plug-in, a web accessibility tool, and assistive technology — and a department can run all four categories itself in an afternoon before commissioning anything. That will not clear the chapter, but it will tell you the size of the problem, which is what you need to decide when to start. If CQW is the destination, check STQC’s prerequisite for an IAAP-certified auditor review report before commissioning, because it constrains who may do the work.
Three consequences follow. Accessibility defects are usually template-level: one heading-structure error or one unlabelled control pattern repeats across every page built from the same component, so the defect count reads as enormous and the fix count is small — provided the fix lands in the component. Those fixes are code changes, and code changes made after a security audit has closed hit the on-change re-audit trigger under 5.3.1. And both workstreams end up in the same conformity matrix and the same certification file.
The sequencing rule worth carrying into the plan
Finish accessibility remediation before the security audit closes. Both sets of fixes are then inside one tested build, one retest clears both, and the certificate describes the code you are actually deploying. Run them sequentially and you pay for a second round of testing — in elapsed weeks, at the point in the project where weeks are most expensive.
A worked GIGW go-live — thirteen weeks, counted backwards
A state department has a launch date it cannot move: a scheme portal announced for a fixed event. It thinks it is launching one website. “Start early” is advice. A calendar is a plan. The department, the scheme and the dates below are illustrative and composite — not a client engagement, and no figure here is drawn from one.
Step one: what is actually in scope
The project document lists four things. The DNS export and load-balancer configuration list six, and the app stores add a seventh. That gap is the most consequential thing on this page: the certificate names a scope, and everything outside it is live and uncertified.
| Item | In the project document | How it was found | Why it matters |
|---|---|---|---|
| www.<dept>.gov.in | Yes — “the portal”. | Declared. | The public portal. One of seven things, not the only thing. |
| seva.<dept>.gov.in | Yes — a “module”. | Declared. | The citizen application and status sub-application: separate codebase, its own login, its own personal-data store. |
| grievance.<dept>.gov.in | Yes — a “module”. | Declared. | The second sub-application. Shares a session provider with seva, which is itself a thing to test. |
| admin.<dept>.gov.in | No. | Found in the DNS export and confirmed on the load balancer. | The administrative console. Nobody thought of it as part of “the website” because nobody outside the department uses it. It is reachable from the internet, which is the only test that matters. |
| api.<dept>.gov.in/partner/v2 | No — in a separate integration document. | Found from the load-balancer rules. | The partner API, published for another department. No user interface, still a web application in production. |
| cms-preview.<dept>.gov.in | No. | Found in the DNS export. | A preview endpoint left reachable after a content migration — not built to be exposed, never decommissioned. |
| Android and iOS builds | Yes — as “the app”, singular. | Two binaries, two store listings. | Two platforms is two scope lines. |
Three of the seven were undeclared, and one — the CMS preview endpoint — should not have existed at all. It is decommissioned rather than tested, which is cheaper and better. The scope statement names six items and records the seventh as removed before testing, with a date. That sentence is what stops a reviewer asking about it in month eleven.
Step two: the calendar, counted backwards from the launch
Thirteen weeks, with accessibility starting in week two rather than after security closes. Run it sequentially and the accessibility remediation lands after the certificate, hits the on-change re-audit trigger, and buys a second round of testing.
| Phase | When | Owner | What it produces |
|---|---|---|---|
| Scope freeze and issuer decision | Weeks 1–2 | WIM and project manager | The signed scope statement, and the purchase order or NIC request raised. |
| Staging environment stood up to match production | Weeks 2–4 | Infrastructure administrator | Same build, OS, web server, database, TLS configuration and WAF policy as the intended production environment — which the auditor guidelines require the auditor to test on. |
| Accessibility evaluation, in parallel from week 2 | Weeks 2–7 | Developer and accessibility evaluator | A per-statement result across all fifty statements, defects grouped to the templates that produce them. |
| Security testing | Weeks 5–7 | The issuing organisation | The findings report with severities and closure timelines by severity. |
| Remediation — the window that is always short | Weeks 7–11 | Developer and infrastructure administrator, both named | Every finding mapped to a fix, an owner, a date and a retest reference. |
| Retest | Weeks 11–12 | The issuing organisation | The retest report covering every finding raised. |
| Certificate issued, read, and filed | Week 13 | WIM | The certificate, checked against the scope inventory before it is filed with the hosting provider. |
Step three: what the findings actually looked like
Two findings were configuration, not engineering. The managed log service was on its default retention, well short of the 180 days the hosting attributes require. The WAF was in detection-only mode, which reads as “deployed” on a procurement form and “not enforcing” in a report. Both closed inside the remediation window in days, at no development cost — and both would have closed for nothing if checked in week three. That is why the configuration items sit at step seven of the checklist below rather than after testing.
The application findings were where the weeks went. The two sub-applications share a session provider, and the authorisation testing ASVS Level 2 brings — not Level 1 — is what examines whether a citizen authenticated to one can reach another citizen’s record in the other. A Level 1 scope would not have looked, and it is not a class of defect a department can explain away after launch.
The accessibility defect count collapsed once it was grouped properly. Reported page by page it looked like hundreds of defects and an impossible schedule. Grouped to the templates that produced them it was a handful of shared fixes — a heading structure in the page template, an unlabelled control pattern in the form component, a contrast value in the design tokens, alternative text on a set of scheme icons — each fixing every instance at once. A defect count on its own tells a department nothing about how long the work will take.
What the certificate named, and what nobody assumed. The certificate named six items, the build tested, the staging environment with a statement tying it to production, the issue date and the validity condition. What it did not cover is the next release. Four months later the scheme added a payment path — new scope and a source-code change at once — which is a re-audit under both limbs of the rule regardless of the eight months still showing on the certificate. The department that planned for this has the trigger in its release process. The one that did not hears it from its hosting provider.
The GIGW go-live checklist — twelve steps a department can run
In the order that keeps the launch date. The first four are decisions, the middle five are work, and the last three are the handover. Nothing here is unusual. What is unusual is doing steps one to four at the start of the project rather than in the week the hosting provider asks for a certificate.
Name the WIM
Head of department
The nomination order, and the WIM’s contact details ready to publish on the site.
Statement 5.4.1 requires a WIM not below the rank of a Joint Secretary, and the policies under 5.3.3 and 5.4.3 need an approver with authority. Leave this to the end and the person who must sign has never seen the site — and GIGW expects the evaluator to interview the WIM about their awareness and competence.
Freeze the scope
Project manager
A written inventory: every hostname, mobile app identifier, API base path, admin interface and environment.
Build it from the DNS export and the load-balancer configuration, not from the project documentation. The certificate will name a scope, and an undeclared admin panel or an unlisted API is the commonest reason a cleared application is still exposed.
Choose the issuer route
Procurement, with the WIM
A purchase order, an NIC request or an STQC application — dated.
The four routes are equivalent for satisfying statement 5.3.1 and not equivalent for planning: they differ in what drives the elapsed time and how much of it the department controls. This decision belongs in the project plan.
Agree the ASVS level and the test plan
Project manager and the issuing organisation
A scope of work naming the ASVS version and level, the Top 10 coverage statement, and the CIS benchmarks in play.
GIGW names ISO 27001, OWASP ASVS, OWASP Top 10 and CIS benchmarks, and names no ASVS level. If the scope leaves the level blank, the tester picks one and the department pays for whichever it was.
Stand up a production-like staging environment
Infrastructure administrator
A staging environment plus a written statement of how it differs from production, if it does.
The CERT-In auditor guidelines require the auditor to test on the staging or testing environment provided by the hosting service provider before issuing the certificate. A staging environment with a different build, configuration or stub integrations produces a certificate for a system that does not exist.
Harden in parallel, not afterwards
Infrastructure administrator
A configuration-review result against the CIS benchmarks in use.
GIGW’s system-administration attributes are the checklist: ports closed by default, default and guest accounts removed, service banners suppressed, HTTPS with HSTS, weak ciphers off, development environments isolated from production, change control in place.
Close the configuration items before testing
Infrastructure administrator
Screenshots or console exports of each setting, dated.
The cheap ones, done now rather than explained later: 180-day log retention within Indian jurisdiction, a WAF deployed, tuned and available on demand, SFTP on and plain FTP off, a valid SSL certificate at 2048-bit SHA-256 or higher with expiry tracked, and the database reachable only from the web server on a whitelisted port.
Run accessibility as its own workstream
Developer and accessibility evaluator
A per-statement result across all fifty statements, with defects grouped to templates.
Forty-nine of the fifty evaluator actions name manual testing, so the schedule is driven by people rather than tooling. Accessibility defects are template-level and fix slowly, which is why starting alongside the security audit is the largest schedule saving available.
Approve the policy pack
WIM and the government organisation
Ten approved documents, the citizen-facing ones published.
Statement 5.3.3 wants three documents approved by the government organisation, and 5.4.3 wants ten approved by the WIM. Approval is the requirement, not authorship, and the evaluator tests implementation by examining the records it generates.
Test, remediate, retest
The issuing organisation, then the department, then the issuing organisation
The findings report, the remediation tracker, and the retest report.
The certificate follows the retest, not the first report. The CERT-In auditor guidelines expect the report to state closure timelines by severity — so an open high-severity finding is the reason clearance has not been issued.
Assemble the conformity file
Project manager
The Website Quality Manual and a completed conformity matrix, guideline by guideline.
Annexure II of the GIGW manual runs across all four chapters, mapping each guideline to the risks it addresses. Filling in a conformity position while the testing is fresh turns the submission into an assembly job rather than an archaeology project.
Read the certificate, then go live
WIM
The filed certificate, and the next audit trigger in the release process.
Check the scope, the URLs and app identifiers, the build tested, the issue date, the issuing organisation and the validity condition. Then open the post-launch clock: GIGW asks for periodic auditing at least once in a year or on any source-code change, whichever is earlier.
The step most often compressed is the fifth, and it is the one that cannot be. A staging environment that genuinely matches production — same build, configuration, integrations, TLS and WAF posture — is the precondition for a certificate that describes a real system. The CERT-In auditor guidelines require the auditor to test on the environment the hosting service provider supplies before issuing the certificate, and to state clearly which environment that was. A department that cannot provide it has not reached the point where testing is useful. For what happens when these steps are skipped, see why applications fail safe-to-host, and for the procurement view, how to get a safe-to-host certificate.
Other gates that run alongside this one — and who governs each
A launch plan that only tracks the security audit will still miss a date, because several other things have to be true before a government site is live — and they are governed by different documents and different bodies. Knowing which is which is what stops a department asking its security auditor about a domain allotment.
A gov.in or nic.in domain
GIGW governs it. Statement 5.1.21 requires the website to be in the nic.in or gov.in domain. Educational, research and academic institutions eligible for gov.in may use edu.in, res.in or ac.in.
The government organisation action points at the .IN Registration policy and at registry.gov.in for the procedure. Allotment has its own lead time and it is not part of the security audit.
Where the site is hosted
GIGW governs the security of it — statement 5.3.2 — but not the choice of provider.
The choice itself runs through the department’s own procurement and, for cloud, through MeitY’s empanelment of cloud service providers. Confirm the current position with MeitY and your state IT department rather than from a vendor claim. What GIGW requires of you either way is that the infrastructure sits within the geographical boundaries of India.
Procuring the audit itself
Neither GIGW nor CERT-In governs this. Your own procurement rules do.
For the STQC route, charges are deposited in advance through the Bharatkosh portal, and STQC states that the security audit is charged separately from the website evaluation. For the CERT-In route it is an ordinary procurement against the empanelled list.
Two STQC prerequisites, if CQW is the destination
STQC governs both, separately from GIGW.
STQC’s scheme page publishes a notice making an IAAP-certified auditor review report a prerequisite for organisations applying for GIGW evaluation under the Website Quality Certification Scheme — read it before commissioning the accessibility work, because it constrains who may do it. STQC also notes that CERT-In-empanelled vendors need to register with STQC, so confirm your chosen organisation has done so.
The CERT-In Directions
Law, not a gate. They apply whether or not anyone asks for a certificate.
Clock synchronisation to NIC or NPL, six-hour incident reporting, a designated point of contact, and 180-day logs within Indian jurisdiction. One of them — the 180-day rule — is quoted inside GIGW’s hosting attributes, so it is a conformity item and a legal obligation at the same time.
The GIGW conformity matrix — what a row actually holds
Annexure II of the GIGW 3.0 manual is titled “Matrix for checking conformity” and is published as a web page too. As published it is four tables — one per chapter — with three columns: a serial number, the guideline in shortened form, and “Risks Addressed”, carrying codes such as S1–S15 for the security chapter. That is the skeleton. A matrix that only restates the guidelines proves nothing: the row has to say what the position is and where the evidence lives.
A naming caution. GIGW’s Annexure II is the conformity matrix. Its Annexure I is the committee composition, Annexure III important terms, Annexure IV the role of the WIM. The CERT-In Directions have their own Annexure I — the twenty reportable incident categories — and their own Annexure II, the point-of-contact format. The two Annexure IIs are unrelated, and a conformity file citing “Annexure II” without naming the document invites exactly the question you do not want.
| Field | Why it is there | Example, filled from the worked example above |
|---|---|---|
| Guideline reference | Identifies the statement precisely, so a reviewer is not matching on prose. | 5.3.1 |
| Guideline statement | The statement as published, not a paraphrase. A paraphrase is where a conformity claim quietly narrows. | 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. |
| Applicable (Y/N) with reason | Not-applicable rows are where submissions get queried, so the reason has to stand on its own without a conversation. | Y — the portal, two sub-applications, the partner API, the admin console and both mobile builds are all hosted in a production environment. |
| Conformance status | Conformant, partially conformant or not conformant. Partial with a dated plan is a defensible answer. Silence is not. | Conformant. |
| Evidence reference | A pointer into the file, so the reviewer can go straight to the artefact. | EV-07: audit clearance certificate, EV-05: findings report, EV-06: retest report. |
| Responsible role | GIGW splits every statement between the government organisation, the developer and the evaluator. The matrix should carry the same split. | Government organisation (WIM), with testing by the issuing organisation. |
| Risks addressed | Annexure II carries a risk-factor code against each guideline — S1–S15 for the security chapter — which is how the matrix ties conformity back to the risk it exists to mitigate. | S1–S15. |
| Remarks | Where a scope boundary, a dated commitment or a known difference between staging and production gets recorded before anyone has to ask. | Certificate scope covers all seven items in the inventory, and cms-preview was decommissioned before testing and is not in scope. |
The rows that get queried: not-applicable
5.2.4 — audio description or media alternative for pre-recorded video in synchronised media
Applicable: N — the portal publishes no synchronised media. No audio or video content exists on any of the seven in-scope items at the date of assessment.
Remarks: Becomes applicable the moment a scheme explainer video is published. Flagged in the Content Contribution, Moderation and Approval policy so the check happens at publication rather than at the next audit.
Not-applicable rows are where submissions get queried, because a reviewer cannot see what is absent without being told. A reason plus a trigger for when it stops being absent is a complete answer. “N/A” alone is an invitation to a meeting.
The GIGW evidence pack — claim by claim
A conformity file is a set of claims, and every claim needs something behind it that a stranger can check. This is the pack as a hosting provider, an STQC assessor or an internal audit team will read it — what satisfies each claim, and what gets handed back.
| The claim | What satisfies it | What gets handed back |
|---|---|---|
| “The application has been security audited.” | The audit report: scope as tested, environment tested, methodology, the finding list with severities, and the retest confirming closure. The CERT-In auditor guidelines expect observations to be supported by objective evidence compiled with the report. | An automated scanner export with a cover page. The auditor guidelines say solely tools-based testing should be discouraged, and a report with no manual findings announces what it was. |
| “The certificate covers this system.” | The certificate with the scope on its face, reconciled against your inventory of hostnames, app identifiers, APIs and admin interfaces — and a note explaining any difference between tested and production hostnames. | A certificate naming a parent portal while you are hosting a new sub-application, or naming a staging hostname with nothing tying it to the production deployment. |
| “The hosting environment is secured.” | Region and data-centre locations, the DC/BCP/DR architecture, the hardening baseline and configuration review, the VA and PT reports with retests, the WAF configuration, and log retention showing 180 days within Indian jurisdiction. | The hosting provider’s marketing page, or a certification held by the provider offered as evidence about your configuration. |
| “Policies are in place.” | The three 5.3.3 documents with approval visible, the full ten-document 5.4.3 set signed by the WIM, the citizen-facing ones published, and for each a sample of the records its implementation generates. | Drafts, or a template with another department’s name in the header. The evaluator compares the policies in the Website Quality Manual against the website and checks implementation through the records it generates. |
| “The site meets WCAG 2.1 Level AA.” | An evaluation covering all fifty statements with a per-statement result, the method used for each, the defect list grouped to the templates that produce the defects, and the retest result. | An automated accessibility score. Forty-nine of the fifty evaluator actions name manual testing. |
| “Data stays in India.” | Region configuration for compute, storage, backups and logs. The location of any managed service in the path. The failover region for each. The auditor guidelines put the same obligation on the testing organisation. | The primary region alone. Backups, log analytics, CDN edge caching and mail delivery are the four dependencies that quietly place data elsewhere. |
One habit makes the pack easier to defend: every export, scan and listing carries its source system, its filter and the date it was run, on the face of the document. The auditor guidelines expect observations to be supported by objective evidence compiled with the report, and the difference between evidence and assertion is usually just those three fields.
Reading the audit clearance certificate — six checks before you file it
The certificate arrives, someone attaches it to a hosting request, and nobody reads it until there is a problem. These six checks take five minutes and catch every version of that problem.
- 01 The issuing organisation, named in full, and its status: NIC, STQC, an STQC-empanelled laboratory, or an organisation empanelled by CERT-In. Check the empanelment against CERT-In’s own published list, not the letterhead.
- 02 The scope, read against your inventory: every hostname, every mobile app identifier, every API base path, and the admin interfaces. What is missing from the scope line is live and uncertified.
- 03 The environment tested, and the build, release or version identifier — matched to what you are about to deploy. A certificate whose scope names a staging hostname needs a sentence tying it to production.
- 04 The issue date, against the date of the last significant server-side change. If a release landed after testing closed, the certificate predates the system.
- 05 The validity condition on the face of the document — commonly one year from issue, or until a major change is made to server-side application code, whichever is earlier.
- 06 That the findings it rests on are closed, and that the department holds the full report and not only the certificate. The hosting provider files the certificate. The department lives with the findings.
The fifth is the one that determines what happens next year, and it is covered in full on safe-to-host certificate validity. The practical version: put the issue date and the annual anniversary into the same calendar the department uses for its hosting renewals, and put the on-change trigger into the release process rather than into someone’s memory.
When a GIGW security audit must be repeated — three triggers, two calendar-free
GIGW states the re-audit rule inside statement 5.3.1 itself, as a developer action: conduct 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. Read the second limb first. It is an event trigger, and it fires regardless of how recently the last certificate was issued. The full treatment, including how the rule appears on the face of a certificate, is on safe-to-host certificate validity.
| Trigger | Where it comes from | How to read it |
|---|---|---|
| Changes to the source code | GIGW 5.3.1, developer action: conduct 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. | An event trigger, not a calendar. A department that ships monthly cannot rely on an annual cycle. Agree in advance with the issuing organisation what counts as a change requiring re-testing, and write that definition into the release process so the decision is made by a rule rather than by whoever is on the release call. |
| The annual date | The same clause at its outer bound: at least once in a year. | The ceiling, not the plan. Certificates issued for government applications commonly carry the same condition on their face — one year, or until a major change is made to server-side application code, whichever is earlier. Read the certificate you actually hold rather than assuming twelve months. |
| New scope, new environment, updated components | Not a code change, but it lands the same way. The certificate names what was tested, 5.3.2 attaches to the environment, and 5.3.1 asks that the CMS, third-party plugins and code are updated to the latest versions. | A new module, integration or payment path is new scope and is uncertified whatever the certificate’s date says. A data-centre or cloud migration revalidates nothing automatically — the application may be unchanged while every configuration attribute is new. And updating a plugin changes what is running, which is the trigger departments most often argue about. |
There is one more trigger that sits outside GIGW: an incident. The CERT-In Directions of 28 April 2022 require mandatory reporting of the listed incident types within six hours of noticing them. Reporting is the immediate obligation. Re-testing is the consequence, because an incident that produced a code or configuration change has produced a re-audit trigger as well.
What drives the cost of a GIGW security audit — seven variables, no price list
There is no published schedule of charges for a safe-to-host engagement, and a page that invented one would be worse than useless in a budget note. What can be stated honestly is what moves the number, because every one of these variables is visible before a quote is requested — and six of the seven are inside the department’s control. For the STQC route, note that STQC states the security audit is charged separately from the website evaluation and that evaluation charges are deposited in advance through the Bharatkosh portal.
| Driver | How it moves the number |
|---|---|
| In-scope hostnames, applications and APIs | The largest single driver, and the one the department controls by writing the inventory honestly. Seven items is not one item, and a partner API still has to be enumerated endpoint by endpoint. |
| The ASVS level named in the scope | Level 2 adds authorisation testing across roles and records, session and token handling and business-logic abuse over Level 1. Level 3 adds design review and source-code verification. Leaving the level blank transfers the choice rather than saving money. |
| Whether infrastructure configuration review is in scope | The hosting-environment and system-administration attributes are a large body of work belonging to whoever administers the server. A scope covering only the application leaves the conformity file incomplete. |
| Mobile platform count | Each platform is a separate binary with separate client-side storage, certificate handling and embedded secrets. |
| Retest rounds | One retest is normal and is what the certificate follows. A second usually means the remediation window was under-resourced, and it is paid for in elapsed weeks as well as fees. |
| Whether a production-like staging environment exists | If it does not, building one is project work that has to finish before testing can usefully start — and the auditor guidelines expect the auditor to test on the environment the hosting provider supplies. |
| Documentation quality at handover | An API with published specifications, a role matrix and working test accounts tests faster and produces a stronger report for the same money than one the tester has to discover. |
The first year after go-live — conformity as a rhythm, not an event
GIGW is a lifecycle standard, and its own Annexure IV says the WIM is responsible for getting the website certified for guideline compliance and ensuring that it remains compliant throughout its lifecycle, with a technical team appointed for regular monitoring and for periodic security audit in line with major revisions. Everything in this table is assembled from requirements already covered above. The value of collecting them in one place is that it turns a pile of clauses into a calendar somebody can own.
| Item | Cadence | Owner | Evidence it produces |
|---|---|---|---|
| Log retention and review | Continuous retention, reviewed on a stated frequency | Infrastructure administrator | 180-day rolling retention configured within Indian jurisdiction, plus the dated review record with a named reviewer. |
| Patching and version currency | On vendor release, reviewed monthly | Developer and infrastructure administrator | The change log showing the CMS, plugins, libraries, frameworks and system components moved to current approved versions. |
| Content review, archival and link checks | Per the Content Review, Content Archival and Website Monitoring policies | Content team and developer, under the WIM | The last-reviewed date on the homepage, the archive holding expired notices, and broken-link tool output with what was fixed. |
| Disaster recovery drill | At least once in a year | Infrastructure administrator with the hosting service provider | The drill record: date, scope, cutover time, defects found, changes made. |
| Incident reporting readiness | Contacts checked quarterly, reporting within 6 hours of any reportable incident | WIM and the technical team | The current CERT-In point-of-contact details, the on-call rota, and the incident log — including a nil return. |
| Policy review and WIM continuity | Annually, and immediately on a change of post-holder | WIM | Re-approval records, and the WIM contact details on the website matching the Website Quality Manual. |
| Re-audit | At least once in a year, or on any source-code change, whichever is earlier | WIM with the issuing organisation | The next engagement booked against the earlier of the two triggers, and the trigger itself wired into the release process. |
The CERT-In Directions of 28 April 2022 — GIGW is a standard, these are law
A government department going live is standing inside four documents at once, and they do different kinds of work. Conflating them is how a department ends up satisfied that a certificate has discharged an obligation that was never about certificates.
| Instrument | Who issued it, and when | Who it applies to | How it bites |
|---|---|---|---|
| GIGW 3.0 | NIC, 2009. Second version 2019. The third formulated jointly with the STQC Directorate of MeitY and CERT-In, its cybersecurity chapter by CERT-In. Adopted by DARPG into the Central Secretariat Manual of Office Procedure. | Indian government websites, portals, web applications and mobile apps at any organisational level, Central and State, including district administrations and local governments. | A conformity standard, assessed at go-live and carried through the lifecycle. Its cybersecurity chapter is where the production-hosting gate lives. |
| CERT-In Directions, 28 April 2022 | Issued under sub-section (6) of section 70B of the Information Technology Act, 2000, reference No. 20(3)/2022-CERT-In, effective 60 days after issue. | Service providers, intermediaries, data centres, body corporate and Government organisations — so a government department is squarely inside the scope. | A legal obligation with punitive consequences: non-compliance may invite punitive action under sub-section (7) of section 70B of the IT Act, 2000 and other laws as applicable. |
| CERT-In auditor guidelines, Version 3.0 (May 2018) | Guidelines for CERT-In Empanelled Information Security Auditing Organizations. Version 3.0 of May 2018 is the version published at cert-in.org.in when this page was reviewed in September 2026. | The empanelled organisation doing the testing — not the department being tested. | Shapes what a competent engagement looks like from the other side of the table — the most useful document a department can read before writing a scope of work. GIGW adds that CERT-In advisories issued from time to time are updates to its cybersecurity chapter, so check for later guidance as well as a later version. |
| STQC Website Quality Certification (CQW) | A certification scheme operated by the STQC Directorate, MeitY. | Government and private website owners seeking formal recognition of GIGW conformity. | Voluntary recognition rather than a hosting gate — but it consumes the security clearance as an input, so the two work in sequence. |
The Directions of 28 April 2022 deserve a closer look: a government organisation is named in their scope, and one of their requirements is quoted directly inside GIGW’s hosting attributes. They were issued under sub-section (6) of section 70B of the Information Technology Act, 2000 and became effective sixty days after issue. CERT-In was appointed the national agency by notification dated 27 October 2009, and the rules governing its functions and duties were notified on 16 January 2014.
| Direction | What it requires | What it means at go-live |
|---|---|---|
| Clock synchronisation | Connect to the NTP Server of NIC or NPL, or to NTP servers traceable to these, for synchronisation of all ICT system clocks. Entities spanning multiple geographies may use another accurate and standard time source, but their time source shall not deviate from NPL and NIC. | A configuration item, set before launch and evidenced from the server. It is also what makes every other log defensible: unsynchronised clocks across web, application and database tiers make an incident timeline unreconstructable. |
| 6-hour incident reporting | Mandatorily report the cyber incidents listed in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. Channels: incident@cert-in.org.in, phone 1800-11-4949, fax 1800-11-6969. | Not a control you build, a capability you staff. Six hours is a rota question before it is a technology question — and GIGW adds NIC-CERT at incident@nic-cert.nic.in as a parallel route for the NIC estate. |
| Point of contact | Designate a Point of Contact in the format at Annexure II of the Directions and keep the details current with CERT-In. CERT-In may order information up to and including near real-time, and failure to furnish it is treated as non-compliance. | A named person with a working address, updated when they move on — the item most likely to be correct on the day of launch and wrong eighteen months later. Note that this Annexure II belongs to the Directions and is a contact form, while GIGW’s own Annexure II is the conformity matrix. |
| 180-day logs in India | Mandatorily enable logs of all ICT systems and maintain them securely for a rolling period of 180 days, maintained within the Indian jurisdiction. | GIGW’s hosting-environment attributes incorporate this directly, so it is simultaneously a legal obligation and a GIGW conformity item. If you are procuring hosting, the Directions also put five-year subscriber-record obligations on your data-centre, cloud or VPS provider — a reasonable question to ask during procurement. |
Annexure I of the Directions — the twenty reportable categories, in full
The six-hour clock only means something if the people on the rota can recognise a reportable incident without looking it up, so here is the list in full. For a public-facing government site the categories most likely to trigger first are (iv) defacement or intrusion with unauthorised changes, (iii) unauthorised access, (viii) denial of service, (x) attacks on e-governance applications, and (xi) and (xii) data breach and data leak. Category (xx) ties this hub to AI-specific testing: an AI or machine learning incident is already a mandatorily reportable class.
- i. Targeted scanning or probing of critical networks and systems
- ii. Compromise of critical systems or information
- iii. Unauthorised access of IT systems or data
- iv. Defacement of a website, or intrusion into a website and unauthorised changes such as inserting malicious code or links to external websites
- v. Malicious code attacks — virus, worm, Trojan, bots, spyware, ransomware, cryptominers
- vi. Attacks on servers such as database, mail and DNS, and on network devices such as routers
- vii. Identity theft, spoofing and phishing attacks
- viii. Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks
- ix. Attacks on critical infrastructure, SCADA and operational technology systems, and wireless networks
- x. Attacks on applications such as e-governance and e-commerce
- xi. Data breach
- xii. Data leak
- xiii. Attacks on Internet of Things devices and associated systems, networks, software and servers
- xiv. Attacks or incidents affecting digital payment systems
- xv. Attacks through malicious mobile apps
- xvi. Fake mobile apps
- xvii. Unauthorised access to social media accounts
- xviii. Attacks or malicious activity affecting cloud computing systems, servers, software and applications
- xix. Attacks or malicious activity affecting systems related to big data, blockchain, virtual assets and exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing and drones
- xx. Attacks or malicious activity affecting systems, servers, software and applications related to artificial intelligence and machine learning
Condensed from Annexure I of the CERT-In Directions dated 28 April 2022. Read the Direction itself before relying on a category boundary in an incident.
STQC CQW certification — and how it consumes this work
Safe-to-host clearance lets you deploy. The STQC Website Quality Certification scheme is the separate, formal recognition that the site conforms to GIGW as a whole. The two are connected deliberately: GIGW’s introduction says the certification of cybersecurity aspects by STQC may be done on the basis of the safe-to-host certificate issued by the cybersecurity auditors empanelled by CERT-In or STQC, or by the auditors of STQC or NIC. Understanding that dependency is what stops a department paying for the same testing twice.
Two routes, chosen first
STQC publishes two paths: directly through STQC Labs, or through an STQC-empanelled laboratory (SETL) whose empanelment scope covers GIGW evaluation, in which case STQC Certification appoints a validator to supervise the SETL’s assessor. Either way STQC is explicit that STQC Labs and SETLs can only perform evaluation and shall not issue certificates — only the STQC Directorate at Electronics Niketan issues Website Quality Certificates, as per ISO/IEC 17025 and ISO/IEC 17065.
Application and Website Quality Manual
The application goes in with the website quality manual, VA reports of the application and database server, the network architecture, a recent security clearance report, details of the data centres, and the charges. That prerequisite list is the most useful part of the scheme for planning, because it is the evidence pack a department going live should be assembling anyway.
Adequacy review, then assessment
The assessor reviews the quality manual for adequacy and gives feedback. A manual describing policies the department has not approved fails here. The assessment team then evaluates the website using test tools and manually, and assesses back-end processes for compliance with the scheme requirements.
Security audit, then the certificate
After satisfactory assessment results, the security audit may be conducted through STQC, an STQC-empanelled lab, NIC or a CERT-In-empanelled organisation and submitted to STQC, which then issues the Certificate of Registration and the Certification Mark. STQC states the security audit is charged separately, and that CERT-In-empanelled vendors need to register with STQC.
Validity and surveillance
The certificate remains valid for three years with annual surveillance and surprise surveillance audit. Note the asymmetry: the CQW mark runs for three years while the security clearance behind it runs to the annual-or-on-source-change rule, so the security work recurs several times inside one certification cycle.
A department that builds the prerequisite file during the go-live project walks into certification with the submission already done. One that treats certification as a later project rebuilds it from memory. Two notices on STQC’s downloads list are worth opening before you plan the work: the transition plan for Website Quality Certification under GIGW 3.0, and the notice making an IAAP-certified auditor review report a prerequisite for GIGW evaluation under the scheme.
Writing the GIGW security audit scope of work — what it should say
The highest-value hour in a safe-to-host project is the one spent writing down what is being tested, in enough detail that nobody can later disagree. The CERT-In auditor guidelines call this reducing or eliminating the expectation gap, and expect the deliverable structure to be agreed with the auditee before commencement.
Scope of the assessment
The assessment covers the public web application at [hostname], the citizen sub-applications at [hostname] and [hostname], the administrative console at [hostname], the REST interfaces published under [base path], and the Android and iOS builds of [app name], version [x.y.z]. Testing is performed against the staging environment at [hostname], which is configured identically to the intended production environment in build, operating system, web server, database, TLS configuration and web application firewall policy. Any component not listed above is outside the scope of this assessment and is not covered by any certificate issued on its completion.
Standards and method
Application testing follows the OWASP Application Security Verification Standard, version 5.0.0, at Level 2, this being a citizen-facing transactional application holding personal data — with coverage of the OWASP Top 10 risk categories stated in the report, and OWASP MAVS applied to the mobile builds. Infrastructure and platform configuration is reviewed against the applicable CIS Benchmarks for the operating system, web server, database and container platform in use. Testing is manual and tool-assisted. Tool output alone is not treated as a finding without verification.
Raise the level to 3 only where compromise carries national-security, life-safety or critical-infrastructure consequence — and expect it to bring design review and source-code-level verification with it. Drop to Level 1 only for a site with no authentication and no personal data. Name the ASVS version alongside the level, because the level definitions changed between ASVS 4.0.3 and 5.0.0.
Exclusions and safety
Denial-of-service and flood testing are excluded. Exploitation of findings that would risk service availability or data integrity is performed only with prior written approval and within an agreed window. Any tool installed in the environment is installed with the system administrator present, listed in the report, and removed on completion with the department’s acknowledgement.
Deliverables and closure
Deliverables are: a findings report with severity ratings and closure timelines by severity, a remediation tracker, a retest report covering every finding raised, and, on satisfactory retest, the audit clearance certificate naming the scope, the environment and the build tested. All assessment data is held on systems located in India, encrypted at rest, and destroyed on completion, with written confirmation to the department.
Illustrative wording, not a template to copy. Every engagement has its own scope, environment and constraints. The value is in the questions this forces you to answer before testing starts. The bracketed fields are where the real work is.
How a GIGW go-live slips — three failures specific to this gate
The technical reasons an application fails its testing are covered separately on why applications fail safe-to-host. These three are different: they are GIGW-specific, they are scheduling and accountability failures rather than defects, and each one is a decision taken early whose consequence arrives late.
The audit was scheduled after the launch date
Plan backwards from the launch, not forwards from the sprint plan. Statement 5.3.1 requires the audit to have happened and the certificate to have been issued before hosting in a production environment, and clearance follows three phases — test, remediate, retest — not one. The phase that gets compressed is remediation, and it is the phase that depends on the department’s own developers and infrastructure administrators rather than on the testing organisation.
The hosting environment was treated as the provider’s problem
Statement 5.3.2 is a government organisation action. The department is answerable for the hosting environment being secured, whoever operates it. Log retention, WAF posture, region configuration, DR drills and network exposure are departmental obligations discharged through a provider, not delegated away — and a provider’s own certification is evidence about the provider, not about your tenancy.
Policies exist as drafts, and no WIM has signed them
Approval is the requirement, not authorship. Statement 5.3.3 wants three documents approved by the government organisation, 5.4.3 wants ten approved by the WIM, and 5.4.1 wants a WIM not below the rank of a Joint Secretary. A well-written policy with no signature and no nominated WIM fails all three at once, and it fails them in a week when nobody has time to convene an approval.
Sources
Every GIGW, STQC and CERT-In statement on this page was read from the document below, not from a summary of it. All were read on 18 September 2026. The GIGW cybersecurity chapter carried a last-updated date of 8 September 2026 when read. The CERT-In auditor guidelines cited are Version 3.0 of May 2018, the version published at cert-in.org.in on that date — and GIGW itself says CERT-In advisories issued from time to time are to be treated as updates to its cybersecurity chapter, so check CERT-In’s publications for later guidance as well as for a later version of that document. Statement numbering follows the GIGW 3.0 manual. Confirm it against the current published text before citing it in a submission.
- GIGW 3.0 manual (PDF), guidelines.india.gov.in
- GIGW 3.0 — Cybersecurity: guidelines and attributes
- GIGW 3.0 — all guidelines and attributes
- GIGW 3.0 — Introduction
- GIGW 3.0 — Scope and objective
- GIGW 3.0 — New features
- GIGW 3.0 — Annexure II, matrix to check conformity
- GIGW 3.0 — Valid CERT-In security audit certificate
- STQC — Website Quality Certification scheme
- CERT-In Directions under s.70B(6), 28 April 2022 (PDF)
- CERT-In — Guidelines for empanelled auditing organisations, v3.0 (PDF)
- CERT-In — list of empanelled organisations
- OWASP — Application Security Verification Standard (ASVS)
- registry.gov.in — gov.in domain registration
Frequently Asked Questions
What is GIGW compliance?
Does GIGW apply to state government websites and PSUs?
What does GIGW require before a government website goes live?
Who can issue the GIGW security audit clearance certificate?
Which security standards does GIGW reference, and at what ASVS level?
How long is a GIGW security audit certificate valid?
What changed between GIGW 2.0 and GIGW 3.0?
Do the CERT-In Directions of 2022 apply to a government department?
Can our development vendor do the GIGW security audit?
What does the hosting provider actually ask for at submission?
Can the GIGW security audit be done remotely?
What does a GIGW security audit cost?
What is the difference between GIGW compliance and CQW certification?
What happens if a government website goes live without the certificate?
How long does GIGW go-live clearance take?
Related Reading
What a Safe-to-Host Certificate Is
The audit clearance certificate GIGW 5.3.1 requires before a government application is hosted in production.
Read moreHow 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 moreWhy Applications Fail Safe-to-Host
The finding classes that recur, and the ones that cost a second retest cycle.
Read moreThe CERT-In Directions, 28 April 2022
Six-hour incident reporting, 180 days of logs in India, NTP synchronisation — read from the direction itself.
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 moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read more