Data Center RFP Checklist: Requirements to Include Before Contacting Providers

A data center RFP should make qualified providers answer the same business, technical, commercial, and implementation questions. If the requirement is incomplete, each provider fills the gaps differently. The resulting proposals may look comparable while describing different services, risks, and costs.

This checklist helps IT, finance, procurement, and operations teams build one normalized requirement before contacting colocation providers. It applies to new deployments, contract renewals, migrations, consolidations, disaster recovery environments, and capacity expansions.

Before issuing a data center RFP, document these requirements:

• Business objective, decision deadline, and target deployment date
• Current and projected equipment footprint
• Initial, peak, and future power requirements
• Rack-density and cooling requirements
• Space, cabinet, cage, suite, receiving, and staging needs
• Electrical and mechanical resilience expectations
• Carrier, cloud, bandwidth, cross-connect, and path-diversity requirements
• Physical security, audit, and regulatory requirements
• Remote-hands, access, monitoring, and support expectations
• Migration sequence, dependencies, testing, and acceptance criteria
• Recurring, one-time, overage, escalation, and exit costs
• Contract term, renewal, expansion, reduction, assignment, and termination rights
• Required response format and weighted evaluation criteria

Do not ask providers for a generic proposal. Give every bidder the same requirements workbook, pricing schedule, assumptions, and response deadline.

The data center market in 2026 continues to face strong demand, limited power availability, grid-reliability concerns, rising costs, supply-chain constraints, and staffing pressure. These conditions make capacity, delivery dates, and provider assumptions more important during sourcing. Uptime Institute Global Data Center Survey Results 2026

Starting with provider tours or budgetary quotes often creates three problems:

1. Each provider interprets the deployment differently.
2. Important requirements surface after pricing has anchored the decision.
3. The team spends time evaluating sites that never met the operating need.

Build the requirement first. Then identify providers with the location, capacity, design, services, and delivery timeline to respond.

Open the RFP with the reason for the project. State whether the organization is addressing a renewal, migration, consolidation, expansion, resilience gap, data center exit, acquisition, cloud placement decision, or new deployment.

Include:

• Executive sponsor and project owner
• Technical, security, finance, legal, and procurement stakeholders
• Current contract expiration and notice dates
• RFP issue date, question deadline, response deadline, finalist selection, and award date
• Required deployment, migration, and production dates
• Approval process and decision authority
• Whether the organization expects a site tour, design workshop, proof of capacity, or reference checks

State which information is mandatory and which items allow an alternative. Providers should identify every exception rather than silently changing the requirement.

Providers need enough detail to validate space, power, cooling, access, and migration feasibility. Supply the initial deployment and a realistic growth case.

Specify:

• Number and type of cabinets
• Cabinet dimensions, weight, and manufacturer when relevant
• Server, storage, network, security, and appliance inventory
• Equipment depth, rail, airflow, and clearance requirements
• Initial and projected cabinet count
• Maximum expected rack density
• Growth assumptions for years one, two, and three
• Private cage or suite requirements
• Storage, staging, build room, office, and workbench needs
• Asset handling, shipping, receiving, and disposal requirements

If final equipment lists are not ready, provide a minimum, expected, and maximum case. Ask each provider to state which case its proposed space and infrastructure support.

Headline pricing per kW is not useful until the RFP defines what the power commitment represents. State the initial load, maximum planned load, growth profile, and required delivery design.

Include:

• Initial committed IT load in kW
• Expected measured load and peak load
• Maximum kW per cabinet
• Voltage, phases, amperage, receptacles, and plug types
• A-side and B-side feed requirements
• Usable load required during maintenance or component failure
• Metering location, interval, and reporting requirements
• Overage threshold and expected process for adding capacity
• Generator, UPS, battery, and distribution expectations
• Required evidence of capacity for the proposed deployment area
• Expansion capacity and reservation period

Ask providers to separate usable IT load from facility overhead and explain how billing works. Use the colocation pricing per kW guide to compare the complete monthly and full-term cost after responses arrive.

Facility-wide cooling capacity does not prove that the proposed cabinet row supports your equipment. Define the density and cooling requirements at the deployment location.

Include:

• Average and peak kW per cabinet
• Highest-density cabinet
• Airflow direction and containment requirements
• Environmental operating ranges
• Temperature and humidity monitoring expectations
• Hot-aisle or cold-aisle containment
• Rear-door heat exchanger or liquid-cooling requirements
• Leak detection and water-management expectations
• Cooling redundancy during maintenance and failure conditions
• Process for approving future high-density equipment

Ask for the supported density at the proposed cabinets, not only the facility average. Require providers to identify design changes, additional charges, or lead times needed to support future density.

The RFP should state what the organization wants providers to price and show.

Request:

• Cabinet, cage, or private-suite configuration
• Floor plan showing the proposed deployment area
• Cabinet dimensions and locking options
• Clearances, ladder racks, cable trays, and power distribution
• Expansion location and adjacency
• Loading dock, freight elevator, receiving, and staging access
• Storage options and restrictions
• Floor loading and seismic requirements where applicable
• Demarcation and meet-me-room locations
• Distance between the deployment and cross-connect handoff points

Require providers to identify shared infrastructure and any facility areas outside their direct operational control.

Avoid using a certification label as the entire resilience requirement. State the operating outcome, maintenance expectations, and failure scenarios the deployment must support.

Include:

• Required electrical and mechanical redundancy
• Concurrent maintenance expectations
• Single points of failure the provider must disclose
• Utility-feed design and upstream dependencies
• Generator runtime, fuel agreements, and refueling plans
• Preventive-maintenance process and notification window
• Emergency maintenance and change-control process
• Incident escalation and communication requirements
• Business-continuity and disaster-recovery procedures
• Relevant test records and maintenance evidence
• Service levels, measurement method, exclusions, credits, and claim process

NIST SP 800-53 groups relevant controls under physical and environmental protection, contingency planning, incident response, maintenance, media protection, and supply-chain risk management. Use your organization’s selected framework to translate policy into provider evidence and contract obligations. NIST SP 800-53 Rev. 5

Carrier choice does not automatically create physical diversity. Define the full path and handoff requirements.

Include:

• Required carriers and acceptable alternatives
• Internet, Ethernet, wavelength, dark fiber, and private-network needs
• Bandwidth, latency, jitter, packet-loss, and availability objectives
• Cloud on-ramps and target cloud regions
• Cross-connect media, quantity, speed, and demarcation
• Meet-me-room and building-entry diversity
• Local-loop, conduit, and upstream carrier diversity
• Separate A-side and B-side pathways where required
• Routing, IP addressing, BGP, and DDoS requirements
• Installation lead times and circuit acceptance testing
• Letter of authorization and cross-connect workflow
• Recurring and one-time connectivity charges

Mplify’s service-attribute framework provides standardized terminology for Ethernet services and observable behavior between interfaces. Use clear service attributes and performance measures in the RFP instead of relying on product names alone. Mplify MEF 10.4 Subscriber Ethernet Services Attributes

CorePath’s resilient connectivity advisory explains how to evaluate carriers, physical routes, building entrances, and common failure domains.

List the controls and evidence your security, compliance, and customer obligations require. Do not request every certification by default. Match requirements to the workloads and data involved.

Include:

• Visitor approval and identity-verification process
• Biometric, badge, mantrap, escort, and cabinet-access requirements
• Video-surveillance coverage and retention
• Security staffing and incident escalation
• Access-log availability and retention
• Background-screening expectations
• Media handling and destruction procedures
• Security testing and vulnerability-management responsibilities
• Required certifications, attestations, and audit reports
• Evidence review process and confidentiality requirements
• Data-residency or geographic restrictions
• Customer audit and regulatory-exam rights

ISO/IEC 27001:2022 defines requirements for an information security management system built around risk management, confidentiality, integrity, and availability. ISO/IEC 27001:2022

For outsourced services, AICPA describes SOC reporting as a way for users to assess and address risks associated with service organizations. Ask for the relevant report, reporting period, scope, exceptions, subservice organizations, and management response. Do not treat the existence of a report as proof that every required control is in scope. AICPA SOC suite of services

The operating model affects staffing, response time, and total cost.

Specify:

• Authorized-user and visitor-management process
• Standard and emergency access hours
• Advance-notice requirements
• Remote-hands coverage and response targets
• Included support hours and hourly rates
• After-hours, holiday, and emergency rates
• Receiving, inventory, storage, and shipping process
• Reboot, cable, media, rack-and-stack, and escort tasks
• Ticketing, escalation, and communication channels
• Maintenance notifications and customer coordination
• Customer portal, monitoring, and reporting requirements
• Service-review cadence and named account roles

Ask for a rate card and sample support scenarios. This prevents vague support language from hiding recurring or emergency charges.

The provider response should cover more than space availability. Require a deployment plan with owners, dependencies, and acceptance criteria.

Include:

• Contract and design approval dates
• Cabinet, cage, power, and cross-connect delivery dates
• Carrier-order dependencies
• Equipment delivery, receiving, and staging sequence
• Site-access and badging lead times
• Migration waves and change windows
• Parallel-run requirements
• Rollback criteria and decision authority
• Testing for power, cooling, connectivity, security, and monitoring
• Documentation and asset-inventory handoff
• Production-acceptance criteria
• Existing-site decommissioning and exit obligations

Use the colocation migration guide to map dependencies, testing, cutover, rollback, and decommissioning work before the provider timeline becomes contractual.

Give providers a pricing template. Require a value or “not applicable” response for every line.

Ask for first-year recurring cost, each contract-year total, all one-time charges, and total committed spend. State the assumptions providers must use for taxes, usage, growth, and service quantities.

Do not wait until final negotiations to surface material terms. Ask providers to respond to a commercial requirements schedule.

Include:

• Initial term and renewal term
• Commencement and billing start
• Annual escalator and cap
• Capacity reservation and expiration
• Expansion pricing and right of first offer
• Reduction, contraction, and partial-termination rights
• Assignment rights after a merger, acquisition, or divestiture
• Provider relocation rights and customer approval
• Service levels, credits, exclusions, and sole-remedy language
• Insurance, indemnity, liability, and consequential-damage terms
• Security-incident notice and cooperation
• Audit rights and compliance obligations
• Chronic-failure and termination rights
• Auto-renewal and notice requirements
• End-of-term removal and restoration duties

The Colocation Contract Renewal Guide provides a structured review for notice dates, escalators, service levels, capacity rights, and exit exposure.

Tell providers exactly how to respond. A consistent response format reduces interpretation work and exposes exceptions.

Require:

• Executive summary
• Completed requirements matrix
• Exceptions and alternative-design schedule
• Proposed site and deployment location
• Technical design and single-line diagrams where relevant
• Capacity evidence and expansion plan
• Implementation schedule
• Security and compliance evidence index
• Service-level schedule
• Normalized pricing workbook
• Contract redlines or commercial exceptions
• References for comparable operating requirements
• Proposal validity period
• Named assumptions, exclusions, and dependencies

Reject responses that substitute marketing material for required answers. Allow supporting documents, but require each answer in the response matrix.

Set the scorecard before proposals arrive. This keeps a low headline rate or polished presentation from changing the decision criteria.

Define category weights based on business risk. Document the scoring scale and require evaluators to support low or high scores with evidence.

1. Is the proposed capacity available now, reserved for this project, or dependent on future construction?
2. What usable IT load and cabinet density does the proposed deployment area support?
3. Which electrical, cooling, carrier, and operational dependencies remain shared?
4. Which planned maintenance activities affect the proposed service?
5. How does the provider validate utility, generator, UPS, cooling, and fuel readiness?
6. Which carriers serve the facility, and which routes are physically diverse end to end?
7. Which security controls and audit reports cover the proposed service and location?
8. Which one-time and recurring charges sit outside the base quote?
9. What schedule assumptions or third-party dependencies affect the ready-for-service date?
10. What rights protect the customer if capacity, delivery, performance, or compliance commitments are missed?
11. What expansion capacity is available, how long is it reservable, and how will it be priced?
12. What obligations and charges apply when the customer reduces, relocates, assigns, or exits the deployment?

Before releasing the RFP, confirm that your team has approved:

• One requirements workbook
• One equipment and growth profile
• One pricing template
• One response matrix
• One evaluation scorecard
• One schedule and communication process
• One list of mandatory requirements
• One process for questions, exceptions, and changes

This work narrows the provider list and gives qualified bidders a fair basis for response.

Use the length required to define the decision. A requirements workbook, pricing schedule, and response matrix often matter more than a long narrative. Remove background that does not change provider design, qualification, price, contract terms, or implementation.

Issue enough of the requirement for providers to confirm fit and prepare comparable pricing. Schedule tours after the initial qualification step when possible. A tour should validate a proposed solution, not replace written requirements.

Yes. Send the same baseline requirement, assumptions, pricing template, and addenda to every bidder. Providers may propose alternatives, but they should first answer the stated requirement and identify every exception.

Invite providers that meet the mandatory location, capacity, technical, compliance, and delivery requirements. A larger list does not improve the result when several bidders never fit the project.

Independent support helps when the team lacks current market coverage, needs to normalize different provider designs, faces a renewal or migration deadline, or wants technical and commercial terms evaluated together.

A strong data center RFP gives every qualified provider the same decision context, technical requirement, pricing schedule, contract expectations, and response format. This creates a defensible comparison across fit, risk, implementation, and full-term cost.

CorePath Network Group helps organizations define requirements, identify qualified providers, run the RFP process, compare technical and commercial responses, and coordinate the selected path. CorePath is an independent, vendor-agnostic infrastructure advisor. CorePath does not operate a data center, sell carrier capacity, or act as an MSP. For standard sourcing engagements, the client pays no direct advisory fee.

Request a 20-minute Infrastructure Review →