The hosting section of a government tender is short and non-negotiable, and vendors who read it late lose weeks. It typically requires that the system runs in a data centre or cloud the Ministry of Electronics and Information Technology has empanelled, that the data stays in India, that a security audit is passed before the system goes live, and that the department can see what happened and when. This article explains what each of those means in practice and how to build so they are true by design.
Where the system may run
Central and state bodies procure hosting from a defined set of options: the government's own cloud services, the state data centres, or commercial cloud providers empanelled by the ministry after an audit of their facilities and controls. The large international providers have empanelled regions in India, as do several Indian providers. The tender will say which options are acceptable, and sometimes which one the department already uses.
The practical consequence for the build is that the architecture must be portable across those options. Use services that exist in every empanelled environment, or wrap the ones that do not behind an interface. Provider-specific managed services are convenient in a startup and a liability in a system that may have to move to a state data centre at contract renewal.
Data stays in India
Residency is simpler than in the private sector because there is no cross-border question to negotiate: the data, its backups, its logs and any analytics derived from it stay in Indian regions. The places teams get this wrong are the services around the application rather than the application itself: error tracking, email delivery, analytics, content delivery networks and AI providers that process data elsewhere by default. Each has to be either configured to an Indian region or replaced.
The other residency question is access. Who can reach production data, from where, and how is that logged? The answer is a list of named people, access through an audited path, and no shared credentials, which is also what an ISO/IEC 27001 control set asks for.
The security audit before go-live
Most tenders require a security audit by an empanelled auditor before the system is launched and after any significant change. The audit covers the application, the infrastructure and the processes around them, and it produces findings that must be closed before a certificate is issued.
The way to pass it is to build for it from the first sprint rather than to prepare for it in the last: input validation everywhere, authentication and session handling to a published standard, encryption in transit and at rest, dependency scanning in the pipeline, secrets outside the code, and a penetration test of our own before the auditor's.
Logs an auditor can read
A department has to be able to answer "who did what, and when" for any record, months later, without the vendor. That means an audit trail on every change to a citizen's record or an application's status, with the user, the time and the previous value; logs kept for the period the tender specifies, in a store the department controls; and reports that a non-technical officer can run. Build the audit trail as a feature, with its own screens, not as a log file somebody would have to search.
Continuity and recovery
A tender will state how quickly the system must be back after a failure and how much data may be lost, usually as a recovery time objective and a recovery point objective. Those two numbers decide the hosting design more than anything else in the document. A four-hour recovery target with an hour of acceptable loss can be met with hourly backups and a rebuild from infrastructure code; a fifteen-minute target with no data loss needs a second site kept in step, which costs several times as much to run.
Whatever the numbers, the backups stay in India, in a separate account or project from the live system so that one compromised credential cannot delete both, and the restore is rehearsed. A backup that has never been restored is an assumption, not a backup.
Plan the maintenance window too. Government systems often have periods when they must not go down, such as the last days of a filing deadline, and the department will expect releases to be scheduled around them. Put the calendar in the runbook.
Accessibility and the citizen's device
Government systems in India are used on low-end phones, on slow connections, and by citizens who cannot be expected to know the system. The guidelines for Indian government websites set accessibility and usability requirements, and a citizen-facing service is expected to meet them. In practice that means fast first loads, forms that work without JavaScript where possible, clear language in the local script, and interfaces tested with a screen reader. A system built to those constraints is also better for the department's own staff on their office machines.
Handover to the department
A public body will operate the system for years, often through a different vendor after the contract ends. The handover pack, the source code in the department's repository, the runbook and the training of departmental staff are therefore part of the deliverable, not an extra. The tender usually says so; a bid that prices them properly is more credible than one that does not.
How we build for it
Our GovTech and e-governance work follows the list above: portable architecture, Indian regions for every service, security built in from the first sprint, an audit trail as a feature, and handover as a stage of the process with its own artifacts.
