Web Development for Government: GIGW 3.0, Security Audits and Hosting in India
In India, government websites and apps are expected to follow GIGW 3.0: WCAG 2.1 Level AA accessibility, a gov.in or nic.in domain, bilingual content, a security audit clearance before production and hosting within India. Developers must also support CERT-In directions such as 180-day log retention and a named point of contact for incidents.
On this page
Government websites carry duties that commercial ones do not: citizens depend on them, they hold sensitive data, and they are judged against published standards. This guide focuses on India, where Mindrops' public-sector work is, and on the requirements that most affect the people building and buying these sites. Other countries have their own standards, so check the rules that apply to you. The details below come from official Government of India sources, listed at the end, and are current as of October 2026.
The standards that apply
In India the central reference is GIGW 3.0, the Guidelines for Indian Government Websites and Apps. It was formulated by the National Informatics Centre (NIC) jointly with the Standardisation Testing and Quality Certification (STQC) Directorate and CERT-In. It covers websites, web portals, web applications and mobile apps of central and state government bodies, including district administrations and local governments. The guidelines state that all websites and apps owned by government organisations must comply, and that they form the basis for Website Quality Certification from STQC. They rest on WCAG 2.1, the Rights of Persons with Disabilities Act, 2016 and the Information Technology Act, 2000.
Separately, CERT-In issues directions under section 70B(6) of the IT Act, and failure to comply may invite action under section 70B(7). GIGW 3.0 also includes a cybersecurity chapter written by CERT-In, and CERT-In's advisories, as they are updated, are to be treated as updates to that chapter.
What GIGW 3.0 expects
| Area | Examples of what it requires | What it means for the build |
|---|---|---|
| Quality | A gov.in or nic.in domain, a contact page, responsive design, a bilingual site with a prominent language selector and Unicode text | Test layouts in Hindi and regional scripts, not just English |
| Accessibility | Conformity with WCAG 2.1 Level AA, accessible document formats | Semantic markup, keyboard operation, contrast, and HTML or accessible files rather than scanned images |
| Cybersecurity | A security audit clearance before production, protection against the OWASP Top 10, current CMS and plugins | Secure coding, a test environment for auditors and time to fix findings |
| Lifecycle | A Web Information Manager, approved policies, content archival and review | Admin tools for review, publishing workflow and archival |
GIGW 3.0 also stresses integration with government platforms through APIs, including India Portal, DigiLocker, Aadhaar-based identity, single sign-on and the MyGov citizen engagement platform, so plan for these early.
Accessibility in practice
GIGW 3.0 is built to WCAG 2.1 Level AA, which adds 17 success criteria over the earlier WCAG 2.0 baseline. WCAG 2.2 is the current W3C Recommendation (version dated 12 December 2024), and W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1. Designing to 2.2 AA is therefore compatible with GIGW, although certification is against GIGW itself.
The recurring failures are predictable: scanned PDFs with no text layer, images without text alternatives, forms without labels, low contrast, menus that cannot be used by keyboard and CAPTCHA that blocks assistive technology. Test with a screen reader and a keyboard as part of QA, not only with automated checkers.
Security: audit clearance and CERT-In directions
GIGW 3.0 expects a security audit clearance certificate, issued by NIC, STQC or a laboratory or auditor empanelled by CERT-In/STQC, before a site is hosted in production. Developers do not issue it for themselves. The audit expectation is recurring: at least once a year, or whenever the source code changes, whichever is earlier. GIGW also asks that the site be free of the risks in the latest OWASP Top 10 list, that the CMS, plugins and code are kept updated, and that incidents are reported to NIC-CERT and CERT-In.
CERT-In's directions of 28 April 2022 apply to government organisations as well as service providers, data centres and companies. They require:
- clocks of all ICT systems synchronised to NIC or NPL time servers
- mandatory reporting of specified cyber incidents within 6 hours of noticing them
- a designated point of contact for CERT-In
- logs of all ICT systems enabled and kept securely for a rolling 180 days, within Indian jurisdiction
For a developer this means building in structured logging, retention and time synchronisation from the start, and agreeing who will report incidents.
Hosting
GIGW 3.0 lists mandatory checks when choosing a hosting provider:
- web infrastructure hosted within India
- a data centre with business continuity and disaster recovery environments, in high availability, with a recovery drill at least annually
- hardened servers, with periodic vulnerability assessment and penetration testing
- a web application firewall available on demand
- logs kept for a rolling 180 days, with regular review
Many departments buy cloud capacity. MeitY's advisory Guidelines for Procurement of Cloud Services (March 2026) explain that MeitY has empanelled cloud providers for public cloud, virtual private cloud and government community cloud, with providers empanelling their offerings through GeM. The department selects the route. Your developer's task is to build something that runs and can be audited in that environment, and that can be moved out cleanly when a contract ends.
A delivery sequence that avoids audit surprises
- Agree the requirements. With the department's Web Information Manager, settle which GIGW checkpoints, languages, integrations and hosting environment apply.
- Design for accessibility and language. Build accessible, bilingual layouts from the first wireframe.
- Build securely. Follow OWASP guidance, add logging and time synchronisation, and set up a test environment for auditors.
- Test internally. Check accessibility, performance and vulnerabilities before the independent audit.
- Audit and fix. Submit to an authorised auditor, fix findings and re-test.
- Deploy. Release to the approved environment with monitoring, backups and a recovery plan.
- Hand over. Provide documentation and policies, and agree the patching and annual audit schedule.
What drives cost and timeline
- Scope and integrations. Citizen-facing services, workflows and links to government platforms add the most effort.
- Accessibility conformance. Designing for it is cheaper than fixing an inaccessible build.
- Languages. Every additional language adds content, fonts, layout testing and review.
- Security audit cycles. Allow time for audit, remediation and re-audit before go-live, and again after significant changes.
- Hosting environment. Disaster recovery, a firewall and logging requirements shape the architecture.
- Content migration and archival. Moving old content and deciding what to archive takes time and decisions.
- Approvals. Reviews and sign-offs often set the real schedule.
- Ongoing work. Patching, annual audits, content updates and support.
Risks and trade-offs
- Leaving the audit until the end of the project.
- Plugin-heavy CMS builds that are hard to patch and audit.
- Publishing documents as scanned images.
- Assuming that a developer's own testing replaces the independent audit.
- Relying on third-party scripts, fonts or services that sit outside the hosting rules; ask your auditor how to treat them.
- Locking the department to a vendor without source code, documentation or an exit plan.
How to choose a development partner
- Public-sector delivery history that you can verify, ideally with references.
- Audit experience: how they prepare for and respond to security audit findings.
- Accessibility evidence: testing with assistive technology, not only a promise.
- Bilingual and Unicode capability with proper testing.
- Environment fit: experience deploying to the department's chosen hosting or cloud setup.
- Handover: source code, documentation and knowledge transfer, so the department is not dependent on one vendor.
- Support terms: patch response times and annual audit support, in writing.
- Procurement readiness: registration on the buying portal the department uses, and clear commercial terms.
How Mindrops works on government projects
Mindrops builds software for public bodies, including the AI-automated grievance redressal platform for the Department of Posts, awarded via GeM in November 2025 (India Post case study), a media-monitoring web dashboard and Android app for BECIL (BECIL case study) and the History-of-Posting system for Central Goods and Services Tax (CGST) (CGST case study). Mindrops is GeM-verified, registered as an MSME and under Startup India, and CMMI Level 3. Web applications and portals come from our custom web application development service, with cybersecurity and VAPT support. The government industry page has more.
One clarification: the security audit clearance and STQC certification come from the authorised bodies named above, not from the development team, so we plan audit time into the schedule with the department. The client owns the source code, with documentation and knowledge transfer included.
Conclusion
A government website is built to a published standard and kept to it. Settle accessibility, security audit, hosting and policy owners at the start, and the build becomes much more predictable. To discuss a public-sector project, get a quote and we will respond as quickly as possible.