How to build a datacenter shortlist before your first vendor call

Most procurement teams begin their datacenter search by contacting brokers or familiar vendor names and then attempting to build a structured evaluation from the responses they receive. The practical consequence of starting that way is that the information shaping the shortlist comes from parties with a financial interest in specific outcomes, the evaluation criteria emerge reactively from what vendors choose to emphasise in their responses, and the comparison becomes difficult to execute fairly because each vendor frames its offering differently. By the time a formal RFP is issued, the shortlist is already implicitly set by whoever engaged first and most effectively.

Working through the public record first reverses that sequence. The latency and geography filters are purely objective and eliminate a large fraction of the candidate universe without any vendor input. The connectivity filter, applied using publicly available network registry and exchange point data, narrows the field further to locations where the specific networks you need are independently confirmed as present. The operator credibility check confirms who actually runs the building before you give anyone the opportunity to characterise their own offering. By the time you make the first vendor call, you already have a shortlist of facilities that meet your objective criteria, and the conversation is about confirming specifics and negotiating terms rather than discovering whether the facility is viable.

The geography filter is the first and most mechanical step. Your latency requirements to your user population, to the clouds and networks you interconnect with, and to any regulatory or data-sovereignty jurisdiction constraints define a geographic envelope that can be drawn on a map before you know anything about specific facilities. The facilities within that envelope are your candidate universe. The facilities outside it are not on your shortlist regardless of their other characteristics.

Latency constraints are often more specific than teams initially estimate. A round-trip latency requirement for interactive applications that touches primary users, database writes, and CDN origin pull simultaneously may resolve to a geographic radius much tighter than the broad metro level that a first-pass search typically returns. The useful exercise before shortlisting is to map the specific networks and endpoints you connect to, estimate the round-trip time from each candidate metro, and establish the latency budget per hop. That exercise frequently eliminates two or three candidate metros that felt viable at the city level but do not survive a more precise latency analysis.

Jurisdiction requirements deserve equal attention at this stage, particularly for organisations with data-residency obligations, cross-border transfer restrictions, or insurance policy conditions that specify the acceptable countries for primary infrastructure placement. Listing the permissible jurisdictions explicitly before shortlisting rather than assuming compliance is verified later in the process means you do not build detailed evaluations for facilities you cannot use.

Once you have defined your geographic envelope, the network density filter narrows the candidate list to facilities where the specific connectivity you need is independently confirmed as available. The key distinction here is between carriers that are available at a location, meaning reachable through some commercial arrangement, and carriers that are present at a location, meaning physically there with their own equipment. For most colocation buyers the difference is significant because the redundancy benefits, the cross-connect economics, and the latency profile of a present carrier are all meaningfully better than those of an available carrier who routes through an external aggregation point.

The publicly available data for this filter comes from three sources. The internet exchange point membership directories list the networks physically collocated at each exchange and, by extension, at the facilities that host those exchanges. The PeeringDB facility records list the autonomous systems that have self-reported infrastructure at each facility, and those records are corroborated against live route origin data in the global routing system. The regional internet registry allocation records confirm which legal entities hold the address blocks announced by each network, which lets you cross-reference the carrier names on an availability list against the entities actually visible in the network records.

Working through this filter practically means identifying the two or three carriers whose presence is non-negotiable for your connectivity design, the internet exchange or exchanges you require on-net access to, and any specific networks you need to reach at minimum cross-connect cost. Checking each candidate facility against those requirements using the public records takes fifteen to thirty minutes per facility and produces a binary result: the facility has what you need in confirmed form, or it does not. The candidates that pass this filter have demonstrably better connectivity than those that do not, and you have documented evidence to support that conclusion rather than relying on the operator's own representation.

The operator credibility filter is the one most often skipped, partly because it requires a small amount of research into network registry records and partly because the question it answers, which is who actually runs this building, feels like it should be obvious from the facility's marketing materials. In practice the answer is not always obvious, and the gap between the presented operator identity and the verified operator identity is material often enough that skipping this filter is a meaningful source of procurement risk.

The verification uses the autonomous system registration, the IP block allocation record, and the exchange point membership data to confirm that the entity named as the operator has a genuine independent network presence at the location rather than operating as a reseller, a sublessee, or a managed-services customer of the actual owner. An operator that holds its own autonomous system, announces its own address blocks from the facility, and appears in exchange point membership records as an active participant has a fundamentally different risk profile from one that does not, because the former has infrastructure that is genuinely independent of its landlord while the latter may be dependent on the landlord's infrastructure in ways that a colocation agreement does not make explicit.

For shortlisting purposes this filter produces a confidence tier for each candidate facility: a verified operator where the public record confirms independent network presence, a network-confirmed presence where some evidence exists but the picture is incomplete, a public facility record where the operator is documented but the network verification is absent, and an unconfirmed listing where the facility name exists in a directory without independent corroboration. Moving a facility from an unconfirmed listing to a verified operator status before making a vendor call gives you a much better basis for the conversation and a much clearer view of the real risk profile of the infrastructure you are considering.

The output of a properly structured shortlisting process is a table of candidate facilities with a consistent set of independently verified attributes: geographic location, confirmed carrier count and names, exchange point presence, operator identity confidence tier, relevant certifications with expiry and scope, and any open questions that require vendor confirmation. That table is the basis for the RFP or vendor briefing document, and the questions it leaves open are the specific information requests you make of each vendor rather than the open-ended discovery questions that a less-prepared process requires.

A shortlist structured this way also gives you a defensible basis for explaining to internal stakeholders and approval committees why specific facilities were included or excluded without relying on vendor-provided materials. The exclusion of a facility because its carrier diversity does not meet the connectivity requirements, confirmed independently, is a much more defensible position than an exclusion based on a broker's recommendation or an unverified impression from a sales call. That defensibility matters increasingly in procurement processes that are subject to internal audit or external compliance review.

The viabandwidth datacenter directory is built specifically to support this shortlisting process. Each facility in the directory carries an operator confidence tier based on independent network verification, confirmed carrier and exchange presence, and publicly documented certifications. Searching by metro, carrier requirement, and certification type produces a filtered list of facilities that have been independently assessed against those criteria, providing a starting point for your shortlist that reflects what the public record confirms rather than what each operator has chosen to represent about itself.