The Indian Enterprise Web Hosting RFP Checklist: Evaluating SLAs, Security & GST Billing
A hosting RFP should fix five things before vendors reply: the sections it contains, the twelve questions every host must answer in writing, a weighted scoring grid, GST-compliant commercials, and exit terms. Score WebJi® and every competitor on the same rows. Evidence beats promises: sample invoices and restore drills over verbal uptime claims.
For procurement and IT teams writing a hosting tender: the document structure, the scoring maths and the answers that should disqualify a vendor.
knowledge
- Read time
- 2 min
- Sections
- 4
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What is a hosting RFP, and when does an Indian company need one?
A hosting RFP (request for proposal) is a written document that states your workload, demands fixed answers from each vendor on the same questions, and forces every reply into a comparable, scoreable shape. It is justified when more than one department signs off the purchase, when the workload is business-critical, or when procurement rules require competitive bids. For a single brochure site it is overkill — comparing plan pages directly is faster and cheaper.
Most hosting disputes trace back to words nobody defined before signing: "uptime", "support", "backup". The RFP's job is to convert each of those promises into a measurable line item with a question and an evidence demand attached. This guide gives the document structure, the twelve questions, a workable scoring grid and the red flags that should end a vendor's candidacy.
What sections should the hosting RFP document contain?
An RFP that vendors can answer without follow-up questions has eight sections, each with a fixed purpose; skip one and the replies stop being comparable. The table says what belongs in each.
| Section | What it must contain |
|---|---|
| 1. Background & current state | The site or app's stack, traffic pattern, data volumes, and why you are buying. |
| 2. Scope of services | Hosting type expected (shared, VPS, cloud, dedicated), environments needed, and what stays in-house. |
| 3. Requirements | Outcomes, not hardware names: response time, concurrent users, storage growth, IOPS, restore time. |
| 4. SLA & uptime definition | The uptime formula, whether maintenance is excluded, how downtime is measured and credited. |
| 5. Security & compliance | Data location in writing, TLS baseline, malware scanning, and CERT-In style 180-day log retention. |
| 6. Backup & recovery | Cadence, encryption, off-site copies, and proof that a restore has actually been drilled. |
| 7. Support model | Hours, channels, first-reply average, escalation path, and language of the support desk. |
| 8. Commercials, migration & exit | INR pricing with GST treatment, renewal rates, migration plan, exit terms and data-export format. |
Attach the evaluation criteria and the reply deadline inside the document itself, so no vendor can claim it did not know how the score would be built. An NDA annexure comes first when the workload description is commercially sensitive.
What are the twelve questions to ask every host?
Twelve checkpoints cover an Indian hosting purchase; each row is one question plus the evidence that makes the answer checkable rather than comforting. Send the same twelve rows to every vendor, WebJi® included, and score them on the grid below.
| # | Checkpoint | Question to ask | Evidence to demand |
|---|---|---|---|
| 1 | Uptime definition | Is maintenance excluded? How is downtime measured? | SLA clause with the formula |
| 2 | Credit mechanics | What credit per missed hour, and how is it claimed? | Written credit schedule |
| 3 | Data location | Where do the app, database and backups rest? | Location map in writing |
| 4 | Log retention | Are 180-day CERT-In style logs kept? | Retention policy document |
| 5 | Backup cadence | Daily? Encrypted? Off-site? Restore-tested? | Restore drill report |
| 6 | Migration terms | Is migration included, and is a test copy moved first? | Method statement |
| 7 | Support hours | 24/7? First-reply average? Which languages? | Historical reply statistics |
| 8 | Invoicing | INR invoicing with a GST breakdown on the invoice? | Sample invoice |
| 9 | Security baseline | Minimum TLS version, WAF, malware scanning? | Control list per item |
| 10 | Scalability path | Can you upgrade without reinstall or downtime? | Written upgrade procedure |
| 11 | Exit clause | Data export format? Notice period? Exit fees? | Exit terms in the contract |
| 12 | References | Same-sector clients with outcomes? | One reference call |
How do you weight and score the answers?
Score every checkpoint zero to two — zero for a verbal answer, one for a document, two for a document with evidence — then apply weights so the grid reflects what actually fails in production. A drill report or sample invoice earns its two; a promise earns its zero. One workable weighting for a business-critical Indian workload:
| Criterion | Weight | What earns full marks |
|---|---|---|
| Technical fit | 30% | Every requirement answered with numbers, not adjectives |
| SLA & support | 20% | Uptime formula plus measured first-reply statistics |
| Security & compliance | 20% | Data location, TLS baseline and log retention in writing |
| Commercial & TCO | 20% | INR pricing with GST treatment and renewal rates shown |
| Migration & references | 10% | Method statement plus one completed reference call |
Two reading rules keep the grid honest. A vendor whose raw row totals stay under sixteen of twenty-four checkpoints answered with evidence is promising rather than proving, whatever the weighted total says. And any zero on rows 3, 5 or 11 — data location, restore drills, exit — should end the candidacy outright, because those three are the ones you cannot fix after signing.
Which answers are red flags?
Red flags are answers that sound strong and prove nothing: an uptime number without a formula, a security promise without a control list, a price without its renewal. Treat each of these as a scored zero and a follow-up question in writing.
- "100% uptime": every real SLA excludes maintenance and defines measurement; a perfect number means the formula is missing.
- Verbal-only security answers: "military-grade", "fully secured" with no TLS version, WAF or scanning detail.
- No sample GST invoice: a vendor who will not show invoice format before signing will argue about it after.
- First-year price only: renewal rates and exit fees withheld until contract stage.
- "Unlimited" undefined: unlimited storage or traffic without a fair-use definition is a limit you have not been shown.
- No restore drill: backups that have never been restored are files, not recovery.
- Pressure to sign: a discount that expires before your scoring grid is complete is a discount on your diligence.
What should the commercials section pin down?
The commercials section must fix five numbers in INR: the first-term price, the renewal price, the GST treatment on the invoice, the SLA credit value, and the exit cost. A vendor quoting only the opening figure has quoted a fraction of the spend. Ask for the renewal column in the same table as the first year, and for a sample invoice showing the GST breakdown — claimable input credit depends on it.
To sanity-check the capacity side of any quote, the cloud server cost calculator gives an indicative INR band in seconds, and the WebJi® pricing page publishes the current INR figures for shared, VPS, cloud and dedicated plans. For the migration row, the migration service page and the free-migration terms spell out what is included and what stays subject to approval.
How does WebJi® answer these rows?
The same twelve rows apply to WebJi®: the uptime mathematics is published, prices sit on the pricing page in INR before 18% GST, and scoping questions get written answers. The published hosting SLA page is the starting point for rows 1 and 2, and contact puts the remaining rows to the desk. Sized workloads — cloud, dedicated or multi-server — are quoted per configuration, which is exactly what section 3 of your RFP should be asking for anyway.
Three closing habits keep the document alive: rerun the checklist at every renewal, not only the first purchase; refresh the evidence file — sample invoices, drill reports, reply statistics — quarterly; and retire any vendor whose answers drift from documented to verbal between the sales call and the support ticket.
Frequently asked questions
Should the RFP name specific hardware?
No. Specify outcomes — response time, concurrent users, restore time, first-reply time — and let each vendor propose the architecture. Naming hardware invites checkbox theatre: every bidder quotes the same parts and the differences move to the rows you can no longer see.
How long should an enterprise hosting RFP run?
Two to three weeks is enough for twelve checkpoints: one week for vendors to answer in writing, one for scoring and clarifications, one for reference calls. Longer timelines rarely improve answers — they mostly let promising vendors go quiet.
How many vendors should receive the RFP?
Three to five. With fewer than three you have no competitive pressure; with more than five, evaluation effort explodes and vendors start replying with brochures instead of row-by-row answers. Include at least one vendor sized very differently from the others.
What weighting suits a regulated Indian business?
Shift weight to security and compliance — data location, log retention, access control — and take it from commercial, not from technical fit. A bank, hospital or listed company should also demand the compliance evidence as an annexure to the contract, not just as an RFP reply.
Last editorial update: 15 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. Free migration* (subject to terms & approval), INR pricing and 24/7 email support in Hindi & English — average first reply under 60 minutes.