Govtech app development in India 2026: the 4 gates every citizen-services build must clear

Summary. A citizen-services application in India is not judged the way a commercial app is. It is judged against GIGW 3.0, the Guidelines for Indian Government Websites and Apps published by the National Informatics Centre under MeitY, and against certification schemes that sit outside your release pipeline. GIGW 3.0 requires conformity with Level AA of WCAG 2.1 and added 17 new success criteria over GIGW 2.0, which was built on WCAG 2.0. It carries a cybersecurity chapter formulated by CERT-In, referencing ISO 27001, the OWASP Application Security Verification Standard, the OWASP Top 10 and Center for Internet Security benchmarks. Government organisations must obtain a "safe to host" certificate from auditors empanelled by CERT-In or STQC, and the guidelines are the basis for Website Quality Certification from the STQC Directorate. The guidelines draw their legal weight from the Rights of Persons with Disabilities Act 2016 and the Information Technology Act 2000, and their scope pages were last updated on 7 August 2026. The platforms you must integrate with are equally specific: as of August 2026, digitalindia.gov.in reports 833.56 crore DigiLocker documents issued, 138 crore Aadhaar numbers generated, 10.89 crore UMANG registrations and more than 6,000 published APIs on API Setu. Above all of it sits NITI Aayog's DPI@2047 roadmap of April 2026, which targets a USD 30 trillion economy and USD 18,000 per capita income by 2047. Four gates, and a build plan that ignores any one of them will not ship.

The GIGW 3.0 manual itself was refreshed in July 2026, and the Digital Personal Data Protection Act 2023 governs every citizen record these systems touch.

Most govtech projects that slip do not slip on features. They slip because accessibility conformity, a safe-to-host certificate and DigiLocker integration were treated as post-development activities rather than as design constraints.

The four gates, and when each one bites

GIGW 3.0 organises its requirements under four focus areas: quality, accessibility, cybersecurity and lifecycle management. Each one has a different failure mode and a different point in the project where it becomes expensive.

The lifecycle gate is the one commercial teams underestimate most. GIGW 3.0 stresses the need for a dedicated Web Information Manager, a senior official from the department who heads the website management team. That is a client-side role you cannot fill for them, and it has to exist before certification is realistic.

Gate 1: quality, which really means integration

The single most consequential line in GIGW 3.0's quality section is the one about integration. The guidelines call for API-level integration with platforms including India Portal, DigiLocker, Aadhaar-based identity, single sign-on, data and citizen engagement platforms, and language translation tools.

That is not an optional enhancement. It is what makes a citizen-services app part of India's Digital Public Infrastructure rather than a departmental silo. The numbers on digitalindia.gov.in in August 2026 give a sense of what you are plugging into:

Two engineering consequences follow. First, your data model needs to accommodate verifiable credentials fetched at runtime rather than files uploaded once and stored. Second, if UMANG is a viable channel for the service, building a standalone app may be the wrong plan entirely, and that question belongs in the first design workshop rather than in month six.

The wider policy direction reinforces the point. NITI Aayog's DPI@2047 roadmap, published through its Frontier Tech Hub, sets out DPI 2.0 spanning 2025 to 2035 and DPI 3.0 spanning 2035 to 2047, targeting a USD 30 trillion economy and USD 18,000 per capita income by 2047. MeitY Secretary S Krishnan said of the roadmap: "India's aspiration of becoming a Viksit Bharat by 2047 requires new approaches that can deliver growth at both scale and speed while ensuring inclusion across society."

Inclusion across society is an engineering requirement in that sentence, not a slogan. It is the next gate.

Gate 2: accessibility is a design constraint, not a test

GIGW 3.0 upgraded the accessibility baseline from WCAG 2.0, which GIGW 2.0 used, to Level AA of WCAG 2.1. In all, 17 new success criteria were added. The additions target three groups specifically: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.

That third group is the one that changes mobile builds. WCAG 2.1's mobile-oriented criteria cover orientation, pointer gestures, target sizes and motion actuation. A design system built for a commercial app and then handed to a government project will typically fail on several of them at once, and the fix is a design change rather than a code change.

The guidelines are explicit that these are not aspirational. They are based on international standards including ISO 23026, WCAG 2.1, the Rights of Persons with Disabilities Act 2016 and the Information Technology Act 2000. The RPwD Act reference is the one that gives accessibility non-conformity legal weight rather than merely audit weight.

GIGW 3.0's structure makes ownership unusually clear. Every guideline is written under five heads: the statement of the requirement, the benefits, the government organisation action, the developer action, and the evaluator action. That means for every checkpoint, someone can point at the row and say which party owed the work. Use that structure directly as the traceability matrix in your delivery plan. It is already written for you.

Teams already running accessibility audit and remediation on commercial products will find the discipline transfers. The bar is comparable to what Indian SaaS companies face under the EU Accessibility Act and WCAG 2.2 audits, with a different evidence trail and a different certifying body.

Gate 3: cybersecurity, and the safe-to-host certificate

GIGW 3.0 incorporates a cybersecurity chapter formulated by CERT-In covering websites, web portals, web applications and mobile apps. It deals with security across design, coding, implementation, testing and deployment, and is based on industry practices including ISO 27001, the OWASP Application Security Verification Standard, the OWASP Top 10 and Center for Internet Security benchmarks.

Two operational facts matter more than the standards list.

First, the chapter must be read alongside advisories CERT-In issues over time, which are treated as updates to the guidance. Your security baseline is therefore a moving target, and a project plan that treats security as a one-time gate at user acceptance testing will be out of date before go-live.

Second, government organisations must continue to obtain a "safe to host" certificate issued by cybersecurity auditors empanelled by CERT-In or STQC, or by auditors of STQC or NIC. That is an external dependency with its own queue. Book it early.

A practical sequencing that works:

1. Pick the OWASP ASVS level appropriate to the service in week one, and write the acceptance criteria from it rather than from a generic checklist.

1. Run static and dependency scanning from the first sprint, not from the hardening sprint.

1. Engage the empanelled auditor before feature-complete, so the first findings arrive while there is still budget to fix them properly.

1. Keep an evidence pack, not just a passing scan. Certification asks what you did, not only what the tool reported.

1. Re-baseline against current CERT-In advisories before the audit rather than against the advisories that were current at kickoff.

The security controls also intersect with the Digital Personal Data Protection Act 2023 engineering work any citizen-data system needs. Citizen data in a government system is personal data, and consent, retention and breach-response design belongs in the same architecture review as the OWASP controls, not in a separate legal workstream.

Gate 4: lifecycle management, or who owns this in year three

The lifecycle chapter covers the policies, processes and plans a department needs so the website management team can maintain quality, accessibility and security across the whole life of the site. It also stresses a dedicated Web Information Manager: a senior official from the department heading that team.

For a vendor, this changes what "done" means. A handover that consists of source code and a deployment runbook does not satisfy the lifecycle gate. What is needed is:

• A documented content lifecycle: who creates, who reviews, who retires, and on what schedule.

• A monitoring approach. GIGW 3.0 guides on a centralised monitoring dashboard to identify issues and alert on non-conformity, which means non-conformity has to be detectable automatically rather than at the next audit.

• Tooling for content creators. The guidelines are explicit that content creators must be supported with the right tools and technologies for accessible content creation. A CMS that lets an author publish an image without alternative text will produce non-conformity indefinitely, regardless of how conformant the initial build was.

• A named WIM on the client side, and a training path for the team reporting to that person.

The honest version of this for a buyer: the build is the cheap part. Whoever writes your content model decides whether the site is still conformant in year three.

Where this typically goes wrong

Four failure patterns repeat across public-sector delivery, and all four are avoidable at planning time.

Accessibility retrofitted after UI sign-off. The design is approved, built, and then audited. Colour contrast, focus order, target size and gesture alternatives all fail together, and the fix is a redesign. Bring the WCAG 2.1 Level AA criteria into the design review, and treat the 17 criteria added in GIGW 3.0 as the specific checklist for anything mobile.

Integration discovered late. A department assumes documents will be uploaded; GIGW 3.0 points at DigiLocker. Retrofitting a verifiable-credential fetch into a build designed around file uploads touches the data model, the UI and the audit trail at once.

One-language content. A citizen-facing service in a state where most users are not comfortable in English will underperform regardless of how well it is engineered. The guidelines call for language translation tool integration, and Indic language app localization is a delivery workstream with its own testing needs, not a translation ticket at the end.

No evidence trail. Certification is an evidence exercise. Teams that tested well but recorded nothing end up re-running the whole verification cycle. Build the QA and test automation pipeline so it emits the artefacts the evaluator will ask for.

A fifth pattern is procedural rather than technical. GIGW 3.0 tells government organisations to assess their existing websites and apps against the guidelines, identify areas needing improvement, draw up time-bound implementation plans, and then obtain certification. Projects that skip the assessment step and go straight to a build often discover mid-delivery that the scope was remediation of an existing estate rather than a new application, or the reverse. The conformity matrix in Annexure II exists to make that determination cheap, and reading it takes a day.

One more constraint deserves naming. Hosting for government systems carries its own residency and control expectations, which interact with every other gate: the safe-to-host audit covers the deployed environment, not just the code. Teams that treat data residency and cloud architecture as a late infrastructure decision usually find the audit reopens architectural questions they thought were settled months earlier.

What a realistic delivery plan looks like

A citizen-services build that clears all four gates tends to run in five stages. The sequencing matters more than the duration, which varies with scope.

Two things are worth saying plainly to any buyer. Accessibility work done at stage three costs a fraction of the same work done after stage four. And the certification bodies are external: STQC and the empanelled auditors set their own timelines, so the go-live date is only partly yours to control.

Who this is for

This work fits departments and public sector undertakings modernising a citizen-facing service, state government agencies building a new portal or app, and govtech startups selling into government who need their product to survive a GIGW 3.0 assessment. It also fits system integrators who have won the contract and need a delivery partner who has read the conformity matrix rather than skimmed the summary.

It is a poor fit if the requirement is a brochure site with no citizen transaction, or if there is no client-side owner willing to take the Web Information Manager role. Without that role, the lifecycle gate cannot be closed, and the certification will stall no matter how good the build is.

Engagement usually starts with a conformity assessment of what already exists, mapped against the GIGW 3.0 matrix, before anyone writes code. That assessment is what tells you whether you are remediating or rebuilding, and it is a materially different conversation from a feature-list estimate.

FAQ

How eCorpIT can help

eCorpIT is eCorp Information Technologies Private Limited, a Gurugram-based technology consulting organisation founded in 2021, CMMI Level 5, MSME certified and ISO 27001:2022 certified, with senior-led engineering teams and partnerships with AWS, Microsoft and Google. We start public-sector work with a conformity assessment against the GIGW 3.0 matrix, so a department knows whether it is remediating or rebuilding before committing budget. From there we design applications aligned with GIGW 3.0 and WCAG 2.1 Level AA requirements, build the DigiLocker, Aadhaar-based identity and API Setu integrations, prepare the evidence pack an empanelled auditor will ask for, and hand over with the content lifecycle documentation and authoring tools the lifecycle gate expects. Talk to us at /contact-us/.

References

1. Guidelines for Indian Government Websites and Apps — National Informatics Centre, MeitY.

1. Scope and objective of GIGW 3.0 — GIGW 3.0.

1. New features of GIGW 3.0 — GIGW 3.0.

1. GIGW 3.0 focus areas — GIGW 3.0.

1. GIGW 3.0 guidelines and attributes — GIGW 3.0.

1. Annexure II: matrix to check conformity — GIGW 3.0.

1. Policy templates for STQC certification — GIGW 3.0.

1. Website Quality Certification — STQC Directorate.

1. Digital India — MeitY, Government of India.

1. India outlines two-phased DPI roadmap to achieve USD 30 trillion economy by 2047 — The Tribune, 27 April 2026.

1. DPI@2047 for Viksit Bharat: a strategic roadmap — NITI Aayog.

1. GIGW 3.0 manual — National Informatics Centre.

1. National Informatics Centre — Government of India.

Last updated: 7 August 2026.