Skip to content
ResourcesContact
Sign inTalk to a lawyer
Compute Infrastructure

/

Resources

Colocation

The pre-signing checklist for a colocation MSA

What to verify before signing an AI-era colocation MSA, whether you are the buyer, compute customer, or provider.

LegalBooks Legal Team

Attorneys licensed in the US (California & Nevada) and Canada (Ontario)

Aug 5, 2026 · 10 min

Before signing a colocation MSA, verify the facility can physically deliver what it sells - and check different things depending on who you are. A colo buyer verifies per-rack power density, cooling, and site control. A compute buyer relying on someone else's colo secures flow-down and continuity rights. A provider verifies the buyer can actually pay.

A colocation MSA is the master services agreement under which a data-center provider supplies space, power, and cooling for a customer's own hardware, usually for a fixed term at a monthly recurring charge (MRC). The MSA sets the specifications, the service levels, and who bears which risk.

AI hardware has pushed data-center density past what most existing facilities were built for. Average rack power roughly doubled in two years - from about 8 kW to 17 kW - and is projected to reach 30 kW by 2027 (McKinsey, Oct 2024, via Network World), while a single Nvidia GB200 NVL72 rack draws 120–130 kW. That gap is why a colocation MSA has to be verified against the physical plant before signing, not after. The checklist below is organized by who you are in the deal.

If you're the colo buyer: verify the facility can run your hardware

If you are placing your own hardware in a provider's facility, the pre-signing job is to confirm the building can physically run it - at your density, with your cooling, for your term. The check most colo buyers skip is per-rack power density.

Per-rack power density

Per-rack (or per-cabinet) power density is where "enough power" and "enough space" quietly come apart. A facility can offer your full contracted megawatts and still cap each rack below what your GPUs draw - leaving you to spread hardware across more cabinets (more space, more cost) or run racks below full load. Traditional colocation was provisioned for roughly 5–10 kW per rack; AI racks commonly need 50–70 kW and reach 120–130 kW for a GB200 NVL72, with Nvidia's Vera Rubin platform projected up to 246 kW per rack (Schneider Electric, 2026). One reason this gets missed: only about one in five operators report being ready to support current high-density requirements (Schneider Electric, 2026).

What to negotiate so you are not stranded:

  • Buy power, not cabinets. Contract in kW/MW with a guaranteed kW-per-rack, so a per-cabinet ceiling lower than your hardware draws cannot strand you.

  • Match cooling to the density. The cooling method must dissipate the rated kW-per-rack. A density number the cooling cannot handle is worthless.

  • Build in density headroom. A right to raise kW-per-rack over a multi-year term, as hardware gets denser, so you are not locked to today's ceiling.

  • Nail provisioned vs. drawn power. Whether you pay for provisioned power or drawn power - the "stranded power" question - and how it reconciles on the invoice.

Cooling required by rack density

Rack density Viable cooling
Up to ~20 kW/rack Air cooling
~20–100 kW/rack Rear-door heat exchangers
~100–175 kW/rack Direct-to-chip liquid cooling
Above ~175 kW/rack Immersion cooling

Source: JLL research, via Network World, 2026. For reference, per-chip draw has climbed from 400 W (A100) to 700 W (H100) to 1,000 W (B200).

The rest of the colo buyer's checklist

  • Tier and redundancy - as built, not as marketed. Verify the Tier III / N+1 / 2N claim against commissioning documents and one-line diagrams. A Tier III facility is "concurrently maintainable," meaning any component can be taken offline for maintenance without disrupting IT operations (Uptime Institute). Critically, Uptime Institute certifies Design, Construction, and Operations separately - so a Tier III design certification does not prove the built, operating facility performs to that standard. Ask which certificate the provider actually holds.

  • Power energized on time. Confirm the contracted power is actually live by the date you need it. Securing new utility capacity can take three to four years in major U.S. markets, and "time to power" now rivals time to deployment (Schneider Electric, 2026). A signed capacity number is not the same as energized capacity - check the utility interconnection status.

  • Site control and lender protection (SNDA). Determine whether the provider owns or leases the site. If it leases, require a subordination, non-disturbance, and attornment (SNDA) agreement so a foreclosing lender or a terminated landlord cannot disturb your possession (McLane Middleton). Match the provider's ground-lease term to your term.

  • PUE on the right basis. Power usage effectiveness (PUE) is total facility energy divided by IT-equipment energy (ISO/IEC 30134-2). Air-cooled sites run around 1.55–1.67; liquid-cooled sites around 1.10–1.20 (Schneider Electric, 2026). If power is billed on gross facility load rather than IT load, you are paying for the overhead - define the basis in the MSA.

  • Permits - current and complete. Confirm building, environmental, and air permits (for backup generators) exist, are current, and are not near expiry, and that the MSA says who bears the risk if a permit lapses mid-term.

If you're the compute buyer relying on someone else's colo

If you are buying compute - bare-metal or compute-as-a-service - and your provider runs it in a colocation facility you do not control, your pre-signing job is to reach through the contract to a building you will never see. Three protections matter most.

  • Flow-down of specs and SLA. The compute provider must pass through the underlying colo's commitments - tier, power, cooling, density, and uptime. Your SLA cannot be stronger than the facility it actually runs on; if the colo delivers Tier III and your contract implies Tier IV outcomes, the gap is yours to absorb.

  • Continuity and step-in rights. Secure a right to keep running, or to exit cleanly with your data and (where relevant) your models, if the provider loses or defaults on its colo site. You should not be evicted by a dispute two levels up the chain.

  • Clean title to the GPUs. Confirm the provider owns the hardware free of liens, so a financier cannot repossess the gear your workloads depend on. The lien-search and title mechanics are covered in our companion piece, five clauses that quietly cost you in GPU-capacity agreements.

If you're the provider: verify the buyer can actually pay

If you are the provider, the pre-signing check that matters most is whether the buyer can carry the monthly recurring charge for the full term - verified before you commit capacity, not only at signing.

Colocation and compute deals are capital-intensive, and committing power and space to a customer who cannot pay leaves you carrying financed, energized infrastructure against what may become an unsecured claim. Diligence the buyer's committed funds rather than a signature alone, and price the counterparty risk into security: deposits or prepayment, a standby letter of credit, or a parent or sponsor guarantee sized to the exposure. Then match what you commit to what you can safely carry - do not promise more power, or a longer term, than your own utility contract and ground lease reliably cover.

The one check you can't skip, by role

You are… The check you can't skip
Colo buyer Per-rack power density the facility can actually cool
Compute buyer (someone else's colo) Flow-down + continuity, so your SLA matches the real facility
Provider The buyer can carry the MRC for the full term

Key takeaways

  • Verify the plant, not the pitch. A colocation MSA should be checked against commissioning documents, the utility interconnection status, and the actual tier certificate before signing.

  • Per-rack density is the buyer's blind spot. Contract for kW-per-rack with cooling matched to it; total megawatts alone will not tell you whether your racks can run at full load.

  • A Tier III design certificate is not a Tier III building. Uptime Institute certifies design, construction, and operations separately - ask which one the provider holds.

  • Compute buyers should reach through the contract. Flow-down, continuity, and clean title protect you against a facility you never see.

  • Providers should verify the buyer can pay first. Committed funds and up-front security matter more than the signature.

Frequently asked questions

What is a colocation MSA?

A colocation MSA is the master services agreement under which a data-center provider supplies space, power, and cooling for a customer's own hardware, usually for a fixed term at a monthly recurring charge. It sets the specifications, service levels, and allocation of risk.

What should you verify before signing a colocation agreement?

Verify the facility can physically deliver what it sells: per-rack power density and matching cooling, the tier and redundancy as built rather than as marketed, whether contracted power is actually energized on time, site control and an SNDA if the provider leases, the PUE billing basis, and current permits. What to prioritize depends on whether you're the buyer, a compute customer relying on the colo, or the provider.

How do you verify a data center's Tier III rating?

Check which Uptime Institute certificate the provider actually holds. Uptime Institute certifies Design, Construction, and Operations separately, so a Tier III design certification does not prove the built, operating facility is concurrently maintainable. Ask for the constructed-facility or operational certification and the commissioning documents.

What rack power density do AI and GPU deployments need?

AI racks commonly draw 50 to 70 kW, and a single Nvidia GB200 NVL72 rack draws 120 to 130 kW - far above the 5 to 10 kW traditional colocation was built for. Air cooling is viable up to about 20 kW per rack; direct-to-chip liquid cooling is generally required from roughly 100 kW upward.

What is an SNDA and why does a colocation customer need one?

An SNDA (subordination, non-disturbance, and attornment agreement) protects a customer's possession if the provider leases its site and the landlord's lender forecloses. Without non-disturbance, a foreclosure could terminate the provider's lease and disrupt the customer's deployment. Colocation customers should require an SNDA whenever the provider does not own the building.

Verify before you sign - without slowing the deal

Every check above is easier to resolve before signing than to litigate after, and none of it has to slow a deal down. LegalLayer is a tech-native legal team built for compute infrastructure: in 2026 we have negotiated more than $266 million USD in client contract value; data-center work makes up the bulk, and drafts and redlines are back within six hours, guaranteed. We work every seat at the table - colo buyers, compute customers, and providers - as technical peers, licensed in the US (California and Nevada) and Canada (Ontario).

This article is general information, not legal advice. For advice on your specific situation, consult a qualified attorney. LegalBooks provides counsel for compute infrastructure deals across the US and Canada.

Before you sign

Pressure-test the agreement with counsel.

Talk to a data center lawyer

Keep reading

Deal types

10 min

Colocation vs. Bare-Metal vs. Compute-as-a-Service

How ownership shifts across the three GPU procurement models, and what your contract must cover in each.

Read article →

Benchmarks

11 min

What's Market in Data-Center Uptime SLAs (2026)

Uptime, measurement, credits, exclusions, and remedies: what is standard now, and which asks are negotiable.

Read article →

GPU capacity

9 min

5 GPU Capacity Agreement Clauses That Quietly Cost You

Five clauses that quietly move money in GPU-capacity agreements, and what to negotiate on both sides.

Read article →
TermsPrivacyContact

© 2026 LegalBooks