Data Centre Due Diligence Checklist: How to Evaluate Uptime, Security, Connectivity, and Disaster Recovery

Overview

Choosing data centre hosting, colocation, dedicated server hosting, or a VPS is a risk decision as well as a technical one. A facility may advertise redundant power, carrier connectivity, DDoS protection, or a Tier classification, but those labels do not explain exactly what is covered, how the service is measured, or what happens during an incident.

Start by documenting your requirements before comparing providers. Record the workloads involved, acceptable downtime, recovery time objective (RTO), recovery point objective (RPO), data residency requirements, traffic patterns, compliance obligations, and the people responsible for approving a service failure or emergency change. This prevents a vendor from defining “resilience” in terms that do not match your business.

For broader infrastructure selection, see Colocation vs Dedicated Servers vs Cloud Hosting. If location is part of the decision, also review the data centre location comparison before treating a facility’s security and availability claims as sufficient.

Ask for written answers and supporting evidence. A sales presentation is useful for understanding the offer, but contracts, service descriptions, operating procedures, audit reports, and test records are more useful for assessing risk. Where a provider cannot disclose sensitive details, ask for an appropriate summary, independent attestation, or controlled review process.

Checklist by scenario

For a website, ecommerce platform, or SaaS application

• What exactly does the hosting uptime SLA cover: power, network availability, hardware, virtual machines, or the complete application?
• How is uptime measured, from which monitoring points, and over what reporting period?
• Are maintenance windows excluded, and how are emergency maintenance and provider-caused configuration errors treated?
• What redundancy exists for utility power, UPS systems, generators, cooling, network equipment, and upstream connectivity?
• Is DDoS protection included, optional, or limited by traffic type, attack size, or response time?
• What is the escalation path for a live incident, and can the provider provide status updates at an agreed frequency?
• Can you test restores from backups, and are backup storage and recovery systems separated from production?

For customer-facing services, do not assess availability in isolation. A highly resilient facility cannot compensate for an untested application deployment, a single database dependency, or credentials held by one person. Pair the provider review with synthetic monitoring, deployment rollback procedures, and an application-level recovery test.

For colocation and bare metal deployments

• What rack power is committed, how is it delivered, and what happens if your equipment exceeds the agreed draw?
• Is the facility carrier-neutral, and which carriers, internet exchanges, cloud on-ramps, or cross-connect options are available?
• Are A and B power feeds genuinely independent beyond the rack, including distribution paths and upstream equipment?
• What access controls apply to staff, contractors, visitors, and remote-hands personnel?
• How are equipment deliveries, asset movements, visitor logs, CCTV, and access records managed?
• What remote-hands tasks are included, how are they authorised, and how are actions recorded?
• What is the process for replacing failed hardware, receiving spares, disposing of storage media, and decommissioning the rack?

Power terminology requires particular care. Ask the provider to describe the actual design rather than relying only on N, N+1, 2N, or Tier language. The guide to data centre redundancy can help structure those questions, while the colocation planning checklist covers practical capacity concerns.

For regulated, sensitive, or location-restricted data

• Where are production systems, backups, logs, support tools, and disaster recovery environments physically located?
• Which legal entities and subprocessors can access or process the data?
• What certifications or independent assurance reports are available, and what systems and locations do they cover?
• How are encryption keys generated, stored, rotated, and separated from the data they protect?
• Can the provider support your retention, deletion, legal hold, and access-review requirements?
• How quickly must security incidents be reported, and what information will the notification include?
• What happens to data and media when the contract ends?

Do not treat a certification logo as proof that every service is covered. Confirm the report’s scope, assessment period, exceptions, and relevant service boundaries. The overview of data centre certifications is a useful starting point for separating certification claims from the controls you actually need.

For hybrid cloud or multi-region deployments

• Can workloads fail over to another site without depending on the failed facility’s network or identity service?
• Are replication links encrypted, monitored, and tested under realistic load?
• Which DNS, routing, certificate, secrets, and observability components remain single points of failure?
• Are data residency and cross-border transfer requirements consistent across primary, standby, and backup regions?
• Can you move the workload to another provider using standard images, documented exports, or reproducible infrastructure code?

Test the complete recovery path, not merely the existence of a second region. A second site that has never served production traffic may have undocumented dependencies, stale credentials, incompatible versions, or insufficient capacity.

What to double-check

Uptime and service credits

Read the SLA definitions line by line. Check the availability calculation, measurement method, exclusions, maintenance rules, notification deadlines, claim process, and maximum remedy. Service credits may acknowledge a breach, but they do not restore data, lost sales, or customer trust. Establish your own monitoring and retain incident records so that the provider’s report is not the only account of an outage.

Security controls and access

Ask how privileged access is approved, logged, reviewed, and removed. Confirm whether provider staff can access the operating system, hypervisor, management plane, backups, or support tickets. For physical facilities, verify visitor escort rules, two-factor access where appropriate, camera coverage, alarm handling, and procedures for lost access cards. For hosted environments, ask about vulnerability management, malware response, network segmentation, and security event escalation.

Disaster recovery and backup evidence

Request the latest relevant summary of a backup restore or disaster recovery exercise. It should identify the systems tested, the achieved recovery time, the amount of data restored, unresolved issues, and the owner of follow-up actions. Clarify whether backups are immutable or otherwise protected from ordinary administrative deletion, and whether they are isolated from ransomware affecting production credentials.

Connectivity and latency

Obtain the facility’s available carrier and cross-connect information, but validate performance from the regions that matter to your users. Routing can change, and a nearby site is not automatically the fastest site. Use the guidance on testing website speed from multiple regions and reducing website latency to supplement the provider’s network description.

Exit planning

Ask how to export databases, images, snapshots, logs, DNS records, configuration, and audit evidence. Confirm the format, fees if any, notice period, support available during migration, and the deadline for secure deletion. Ensure your contract does not require access to a portal that could be unavailable during a dispute or serious incident. A practical exit test can be as valuable as an onboarding test.

Use a scoring template

Score each provider from 0 to 3 for every category: 0 means no answer or unacceptable evidence, 1 means a partial answer, 2 means documented controls with open questions, and 3 means documented controls that meet your requirement and have been tested or independently assessed. Weight availability, recovery, security, compliance, connectivity, and exit capability according to workload risk. Keep “not applicable” separate from zero, and record the evidence behind every score.

Common mistakes

• Relying on a Tier label alone. A Tier 3 data centre or Tier 4 data centre reference does not replace review of the specific service, contract, maintenance model, and operating procedures.
• Confusing facility resilience with application resilience. Redundant power does not protect against application defects, expired certificates, bad deployments, or an unavailable third-party dependency.
• Accepting “backup” without asking about restore. A backup that cannot be located, decrypted, or restored within your target window is not a complete recovery capability.
• Ignoring management-plane risk. Production may be distributed across multiple sites while identity, DNS, monitoring, secrets, or orchestration remains concentrated in one place.
• Leaving compliance review until signature. Confirm data locations, subprocessors, breach procedures, retention, and audit rights before architecture and procurement decisions become difficult to change.
• Failing to verify verbal promises. Put material answers in the statement of work, service description, security schedule, or SLA rather than relying on meeting notes.

When to revisit

Review this checklist before each seasonal planning cycle, annual renewal, major migration, or significant change in workload. Revisit it sooner after an outage, security incident, material provider change, acquisition, facility move, new compliance requirement, or change in data residency needs.

Update the assessment when your architecture changes: adding a region, adopting hybrid cloud hosting, moving from VPS hosting to dedicated servers, introducing a payment system, or changing backup and identity tools can create new dependencies. Ask the provider for updated certifications, service descriptions, subprocessor lists, incident summaries, and recovery-test results rather than carrying old evidence forward indefinitely.

To turn the checklist into an action plan, assign an owner to each unanswered question, set a decision date, and label every risk as accepted, mitigated, transferred, or blocking. Keep the final scorecard with the contract and architecture records. After onboarding, run a controlled restore, review access logs, validate monitoring, and test the documented escalation route. Due diligence is most useful when it continues into operations and gives you a clear basis for renewing, improving, or exiting the service.