pingpong
All vendor management guides

Vendor management Guide

How to Run an RFP for Cloud Hosting or Infrastructure

A good cloud or infrastructure RFP starts with an inventory of the workloads you need to host. From that inventory, you ask every vendor to price the same reference environment and score responses against weighted criteria you set in advance. The contract terms that matter most are SLAs, data ownership, price protection and exit rights, so treat those as evaluation criteria, not something you fix after you pick a winner.

pingpong September 24, 2026

1. Define what you are actually buying

"Cloud hosting" covers very different services. Before writing anything, decide which model you are open to:

  • Public cloud (IaaS/PaaS): you run workloads on a hyperscaler or smaller cloud provider, often through a reseller or partner.
  • Managed hosting: a provider runs the infrastructure and some of the operations layer for you.
  • Colocation: you own the hardware and rent space, power and connectivity.
  • Hybrid or multi-provider: a mix of the above.

Then build a workload inventory. For each application, record compute and storage needs, traffic patterns, uptime requirements, data sensitivity and where the data must live. This inventory is the backbone of the RFP. Without it, vendors will propose whatever suits their catalog.

Finally, name the decision makers. Most infrastructure RFPs need an engineering lead, a security owner, finance and procurement. Agree up front who holds the final call and who can veto on security or compliance grounds.

2. Turn the inventory into requirements

Split requirements into must-haves (pass/fail) and scored items. Must-haves keep you from wasting time on vendors who cannot qualify.

Typical must-haves:

  • Data residency in specific regions or countries
  • Security certifications your customers or regulators expect (for example SOC 2 Type II, ISO 27001, or sector-specific standards)
  • Minimum availability commitment for production workloads
  • Encryption at rest and in transit, with clarity on who manages keys

Typical scored items:

  • Architecture fit and migration approach
  • Support model: response times by severity, named contacts, escalation path
  • Monitoring, logging and incident communication
  • Backup, disaster recovery, and tested recovery time and recovery point objectives
  • Tooling and APIs, including infrastructure-as-code support
  • Roadmap and financial stability of the vendor

Write each requirement so it can be answered with evidence. "Describe your incident notification process, including time to first customer notice for a Severity 1 event" gets a usable answer. "Do you have good incident management?" does not.

3. Structure pricing so bids are comparable

Cloud pricing is the hardest part to compare. Vendors use different units, discounts and bundles. Fix this by giving every bidder the same reference workload and a mandatory pricing template.

Include in your reference workload:

  • Compute: instance sizes or vCPU/RAM, hours per month, steady-state versus burst
  • Storage: volume, tier, growth rate per year
  • Data transfer: especially outbound (egress), which is often underestimated
  • Backup and DR copies
  • Support tier
  • Managed services such as databases, load balancers or security tooling

Ask for pricing broken out as:

Line item | Unit | Unit price | Monthly qty | Monthly total
Year 1, Year 2, Year 3 totals
Commitment required (spend or term)
Discount applied and conditions
One-time costs: migration, onboarding, professional services

Ask bidders to price at least two scenarios, for example current volume and a growth case. That exposes how pricing behaves as you scale and whether discounts disappear past a threshold. Also ask directly: what costs are not included in this quote?

4. Run the process on a fixed timeline

Publish a timeline with the RFP and stick to it. A common structure:

  1. Issue RFP with requirements, pricing template and evaluation criteria summary.
  2. Written Q&A window, usually one to two weeks. Share all answers with all bidders.
  3. Response deadline. Reject late or incomplete submissions, or you lose leverage and fairness.
  4. Shortlist two or three vendors based on scoring.
  5. Technical deep dives with your engineers, not just sales teams.
  6. Proof of concept for critical workloads where fit is uncertain. Define success criteria before it starts.
  7. Reference checks with customers of similar size and workload type.
  8. Best and final offer, then contract negotiation.

For a mid-size infrastructure decision, many teams find six to twelve weeks realistic. Rushing the proof of concept or reference checks is where most regret comes from.

5. Score with weights you set in advance

Agree the scoring model before responses arrive, so no one reverse-engineers the weights to favor a preferred vendor. An illustrative weighting, to adjust to your priorities:

  • Technical fit and architecture: 25%
  • Security and compliance: 20%
  • Total cost over contract term: 25%
  • Support and service levels: 15%
  • Migration plan and risk: 10%
  • Commercial terms and flexibility: 5%

Use a simple 1 to 5 scale per criterion, with written definitions of what a 1, 3 and 5 look like. Have evaluators score independently first, then meet to discuss big gaps. Record the rationale. It helps if a losing bidder asks for feedback, and it protects the decision internally.

Compare cost on a three-year total cost basis, including one-time migration fees, support and expected growth, not the monthly headline figure.

6. Negotiate the terms that carry the real risk

Put your key contract positions in the RFP and ask bidders to confirm acceptance or propose changes. That turns contract terms into a scored factor rather than a post-award fight.

Terms to focus on:

  • SLA and credits: how availability is measured, exclusions, credit levels, and a right to terminate after repeated breaches.
  • Price protection: caps on annual increases and a right to benefit from list price reductions.
  • Commitment flexibility: ability to shift committed spend across services or regions, and what happens if you under-consume.
  • Data ownership and access: your data stays yours, with export in usable formats at any time.
  • Security obligations: breach notification timelines, audit rights or access to audit reports, subprocessor disclosure.
  • Exit assistance: transition support and reasonable egress costs on termination.

Example clause for exit:

On expiry or termination for any reason, Provider will, for up to 90 days, continue to provide the Services at the then-current rates and provide reasonable assistance to migrate Customer Data to Customer or a successor provider. Provider will make all Customer Data available for export in a standard, machine-readable format and will not charge data transfer fees above the published standard rates for such export.

7. Plan ongoing management before you sign

Infrastructure contracts drift. Usage grows, new services get switched on and committed spend gets missed. Set up governance at signing:

  • Assign a contract owner and a technical owner.
  • Agree a monthly cost and usage review, with tagging so spend maps to teams.
  • Schedule quarterly service reviews covering SLA performance, incidents and roadmap.
  • Track commitment burn-down against the contract so you are not surprised at true-up.
  • Put renewal and notice dates in a calendar at least six months ahead, which gives time to rerun a lighter competitive process if needed.

Keep your RFP documents and scoring. They make the next renewal far faster.

Let pingpong run it for you

pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.

Common questions

Should we issue an RFP directly to hyperscalers or go through resellers and partners?

It depends on your spend and how much support you need. Large buyers often negotiate directly, while smaller buyers may get better support, billing flexibility or bundled services through a partner. You can include both in the same RFP, but ask partners to disclose which underlying provider and discounts their pricing relies on.

How many vendors should we invite?

Many buyers invite four to six vendors that pass a basic qualification check, then shortlist two or three for deep dives. Inviting too many creates evaluation work without improving the outcome. Inviting only one or two weakens your negotiating position.

How do we avoid surprise costs after signing?

Require a detailed pricing template, ask bidders to list what is not included and model egress and growth explicitly. In the contract, cap price increases and confirm how new services are priced. After signing, review usage monthly and track spend against commitments.