05 Nov 2026 5 min read Government Website

Compliant on Paper: Why GIGW 3.0 Doesn't Make Government Websites Secure

Cyber Moral analysis. A companion to "The Ceremony."

India does not lack rules for secure government websites. It has had a national standard since 2009, and its current version, GIGW 3.0, requires a security audit before any site goes live and another every year or whenever the code changes.

The problem is everything around the rules. How a website is bought, who builds it, who checks it, who patches it, and when the money arrives all pull against what the guidelines ask for. Read on paper, the system is strict. Followed in practice, it produces sites that are compliant on the day of the audit and drift from then on.

This piece looks at four places where that happens: the guideline itself, the tender, the silos between agencies, and the budget calendar.

What GIGW 3.0 actually asks for

GIGW 3.0 is a serious document. MeitY launched it in 2023, with NIC, STQC and CERT-In behind it, and it covers websites, web apps, portals and mobile apps across their whole life, from design to retirement.

Requirement	What it says	Who checks
Security audit before go-live	Statement 5.3.1: no production hosting without an audit clearance ("safe to host") certificate	NIC, STQC, an STQC-empanelled lab, or a CERT-In-empanelled auditor
Re-audit	At least once a year, or whenever the source code changes, whichever is earlier	The same bodies
Quality certification	Certified Quality Website (CQW) mark, valid three years with annual and surprise surveillance audits	STQC Directorate
Accessibility	WCAG 2.1 Level AA	STQC, during certification
Ownership	A Web Information Manager named for each ministry or department	The department itself

Two details matter for what follows. First, the first safe-to-host certificate is issued on a staging copy, not the live site, and a typical certificate says it is valid only until the code or content changes, or for one year. Second, by one count, only 3 of GIGW 3.0's 88 mandatory guidelines are about cybersecurity; the rest cover quality, accessibility and lifecycle management.

In other words, the standard expects security to be maintained. It does not, and cannot, maintain it. That job falls to the contract, the vendor and the department, which is where the trouble starts.

Where it breaks

Each step has its own check, and each check can pass. None of them is about whether the live site is secure today, and the shortfall at the end feeds the next tender.

The tender: pressure that lands on security

Government web work has long defaulted to the lowest compliant bid, L1. The finance ministry loosened that in October 2021, allowing quality-cum-cost selection (QCBS) for works and non-consultancy services. But QCBS is capped at 30% weight for quality, limited to contracts up to Rs 10 crore, and needs an official to declare the job "quality-oriented." The Economic Survey 2020-21 explained why L1 persists: "No decision maker wants to exercise discretion for the fear of future questioning."

For a vendor, L1 sets a simple incentive. Everything in the tender that can be ticked off at handover gets done. Everything that costs money afterwards gets priced as close to zero as possible. Security is mostly the second kind: patching, log retention, dependency upgrades and re-audits after each change.

The pressure does not stop at price. Practitioners describe tenders shaped before they open, with specifications written around a preferred bidder, side payments to intermediaries, and a few friendly bids lodged to make the contest look real. These practices are hard to prove case by case. But when the winning price only works if security is skipped, the outcome is the same whether the cause is collusion or plain under-bidding.

The result is a familiar contract: a build fee, a thin annual maintenance contract that covers uptime, and security left to the original audit certificate.

Silos: everyone owns a piece, nobody owns the whole

A single government website touches at least six parties, and each answers a different question.

Party	What it owns	What it does not see
MeitY and NIC	The guideline, and often the hosting	Whether a given department's code is patched
CERT-In	Advisories, auditor empanelment	Which sites run the affected software
STQC	Quality certification and surveillance audits	Changes made between audits
Empanelled auditor	One audit, on one version	Anything deployed after the retest
Vendor	The code, under a fixed contract	Work the contract does not pay for
Department	The budget and the Web Information Manager	Usually, the technical detail

Each party can do its job correctly and the site can still be exposed. The auditor certifies version 1.0; the vendor ships 1.3; CERT-In publishes an advisory; the department reads it in a circular weeks later and asks the vendor, whose contract does not cover it.

The gaps show up in the numbers. In Goa in September 2024, the Leader of Opposition cited state IT department figures showing that 45 of 62 government websites had not renewed their security audits, with renewals for 17 others pending for over a year. No rule was missing. Each renewal simply belonged to someone who had other priorities.

The budget calendar: why unfinished pays

The financial year adds an incentive that has nothing to do with technology. Funds not spent by 31 March generally lapse, and a department that underspends risks a smaller allocation next year. So money is spent late and fast.

The CAG has documented this repeatedly. Its state finance audits for 2023-24 found 12 of 16 states and union territories breaching spending limits; the finance ministry's ceiling for March is 10% of the annual budget, yet Maharashtra spent 25.14% in March and Gujarat 19.32%.

Websites are an easy place for that money to land, and the calendar shapes how they are built:

Launch by March, finish later. A portal that goes live in the last weeks of the year counts as spent money. Missing features, accessibility fixes and security hardening move to "phase two."
Phase two needs a new budget line. A site that fully met the requirement would leave nothing to fund next year. A site that falls short creates the case for the next allocation.
Audits get squeezed. A safe-to-host audit on staging, findings closed in a hurry, then changes pushed after the retest to meet the launch date: the certificate is valid on paper and stale in fact.

None of this needs anyone to break a rule. It only needs a system that rewards spending on time more than it rewards a site that is secure a year later.

Closing the gap

The fixes are mostly about money and ownership, not new rules.

Make security a paid line item for the life of the contract. Price patching, log retention and re-audits into the annual maintenance contract, with a deadline in days after any critical CERT-In advisory.
Disqualify bids that cannot cover the security annexure. Use QCBS where the law allows it, and treat a price below the cost of the required controls as non-responsive.
Tie audits to what is running. Require the certificate to name the deployed version or code hash, and make an expired or outdated certificate a reason to suspend hosting.
Name one owner, in writing. Give the Web Information Manager the authority to take a site offline during a critical vulnerability without waiting on a file.
Publish compliance status. A public register of each site's audit date, certificate validity and software version would make drift visible to the people the site serves.
Stop rewarding the March launch. Release later-phase funds against a passed audit of the live site, not against a go-live date.

GIGW 3.0 already says what a secure government website looks like. Until the contract, the budget and one named owner all point the same way, it will describe the sites we certify, not the sites we run.