A government software contract is shaped by the buyer's procurement rules before it is shaped by the technology. The rules decide how bids are scored, what evidence each payment needs, where the system may run and what an auditor can ask for years later. This guide lists those rules for a supplier and the document each one produces.
What GFR 2017 sets for a software supplier
The General Financial Rules, 2017 govern how central ministries and departments spend. Four provisions matter most to a software bid. We give the topics and not rule numbers, because we could not check the numbers against the Department of Expenditure's text updated to 31 January 2026. Find each provision there before you cite it in a bid.
| Provision | What it says | What it means for you |
|---|---|---|
| Principles of public buying | Procurement follows stated principles, including a description of the need that is functional and does not name a brand | Write your proposal against the functional description, not against a product |
| Buying through GeM | Procurement through GeM is mandatory for goods and services available there | Check whether your service sits in a GeM category before anything else |
| Two-bid system | For complex, high-value purchases, technical and financial bids arrive in separate covers; financial bids are opened only for technically acceptable offers | A weak technical score ends the bid before your price is read |
| Performance security | A performance security applies to contracts, as the bid documents specify | Budget cash or a guarantee for it |
The two-bid system is written for complex purchases. Read the evaluation clause in your own tender to see how technical and financial bids are handled.
How the pieces connect
GeM. The GFR provision on buying through GeM makes the Government e-Marketplace the default channel for what it lists. A software service that is not a listed category goes through the department's own tender. Establish which route applies at the first read of the notice.
Evaluation. A published scoring formula rewards answers written to its headings. A strong design buried under the wrong heading scores like a weak one.
Eligibility. Tender documents set turnover and past-work floors. Check them before you spend time on a response. If you miss a floor, the usual routes are a consortium with a firm that meets it or a different tender.
Payment. Funds are released against milestones, each with evidence in a form the tender prescribes. Working software that arrives without that evidence leaves the milestone open.
Where the system may run
The MeitY Guidelines for Procurement of Cloud Services say MeitY has empanelled cloud providers for three deployment models: public cloud, virtual private cloud and government community cloud. Providers list their empanelled offerings through GeM. The guidelines describe themselves as advisory, so the tender states which hosting it accepts.
This decides the architecture in week one. It limits which managed services you can use, how you deploy and sometimes the runtime. For the data-residency rules that sit beside it, see cloud migration for Indian companies.
Testing and certification
STQC, the Standardisation Testing and Quality Certification Directorate, is an attached office of MeitY. Its site lists software testing and assessment, and information security testing and assessment, among its services. Whether your tender names STQC or another auditor for security clearance is a question for the tender text.
Treat the audit as a schedule line with its own duration. The evidence it asks for, such as a threat model, test records and a change log, costs little to keep while you build and a good deal to rebuild afterwards.
What an auditor can ask years later
Public systems are audited after the fact. The Comptroller and Auditor General's Standing Order on Auditing in an IT Environment, dated 6 August 2020, says an audit log should ideally record which records or fields were added, amended or deleted, from what to what, and who made the change. It also treats missing audit trails as an obstacle to auditing a computerised system. The questions that follow are simple: who approved this, on what authority, and what did the record say before.
Build for those questions:
- Approval chains as data. Government work runs on recorded approvals in a set order, often with a delegation that changes by value band. Model the chain, the delegate and the date, so a paper file is not needed beside the system.
- An audit trail you can replay. Record who acted, when, on whose authority, and the record before and after. The fields an AI audit trail must hold show the same design applied to model decisions.
- Accessibility tested before go-live. Fixing it on a live citizen service costs more than starting with it.
- Personal data handled to the Act. Forms that collect citizen details fall under the DPDP Act. The website and forms checklist shows the duties item by item.
Identity and data exchange
Decide early which identity and verification routes the department is authorised to use. Document-based verification and inter-department data exchange are design choices you can plan. Anything that depends on an authorisation the department does not hold is a blocker, so ask in the pre-bid meeting.
Build-Operate-Transfer in the public sector
A public body often wants a capability in-house eventually but lacks the staff to begin there. A structure that builds the platform, runs it for an agreed period and then transfers it with documents and trained people gives the committee its likely first question in advance: who runs this after the contract. The stage-by-stage guide to BOT covers the mechanics.
What a response should contain
Build the response from the tender's own headings. A sound order of work:
- A compliance matrix that lists every clause and says where in your response it is met.
- An approach note that answers the functional description, using the buyer's terms for the processes.
- A hosting statement that names the deployment model and, where required, the empanelled offering.
- A delivery plan with milestones that match the payment table, one evidence item per milestone.
- A security and testing plan that names the auditor, the evidence you will keep and the days set aside for clearance.
- A support and handover section covering who operates the system after go-live and what is transferred.
Keep each item self-contained. An evaluator scores sections one by one, often in separate sittings.
Pre-bid checklist
| Question | Where the answer sits | Document it produces |
|---|---|---|
| Is this service in a GeM category? | The GFR provision on GeM and the GeM catalogue | Route decision note |
| Do we meet the turnover and past-work floors? | Tender eligibility clause | Eligibility sheet |
| How is the bid scored? | Tender evaluation clause | Response outline mapped to the headings |
| Where must it be hosted? | Tender and MeitY cloud guidelines | Hosting decision record |
| Who audits security, and when? | Tender testing clause | Audit schedule line |
| What evidence does each payment need? | Milestone table in the contract | Evidence list per milestone |
| What must the audit trail hold? | Department's own rules | Audit-trail specification |
Questions bidders ask
Does every government software purchase go through GeM?
No. Under the GFR provision on GeM, the duty applies to goods and services available on GeM. What is not listed goes through the department's own procurement. The tender notice tells you which.
Can a small firm bid?
It can if it clears the eligibility floors in the tender. The floors are set per tender, so a consortium or a partner that meets them is the usual route when a firm falls short.
Where do the pre-bid meetings matter?
They are where ambiguity in the specification is cleared on the record. Written answers from the buyer bind the evaluation more firmly than a verbal assurance, so ask in writing.
Where Brihat fits
Brihat Infotech's government and PSU practice covers departmental digitisation, e-governance platforms and Build-Operate-Transfer engagements. Start a conversation.