A colocation facility is a third-party data center that rents space, power, cooling, and network access for customer-owned servers. Organisations use colocation when they want physical control over hardware without building and operating their own facility. The customer still owns the servers and must manage the platform placed inside the rack.
Colocation Facility as a Data Center Control Model
A colocation facility is not just rented floor space, it is a shared physical environment where you outsource the building’s shell, power, cooling, and network plant while keeping ownership of the servers and their runtime stack.
That separation matters because the facility operator controls the property and core utilities, while the customer controls the hardware estate, operating system, applications, and the security posture inside the rack. In practice, colocation sits between owning a private data center and consuming fully managed hosting.
What Customers Actually Buy and What They Still Own
The commercial promise of colocation is predictability: committed rack space, power density, carrier access, and environmental controls. For organisations that need physical custody of their own servers, it can be a practical way to avoid the capital cost and operational burden of building a facility.
The trade-off is that “someone else runs the building” does not mean “someone else runs the environment.” Customers still own hardware lifecycle decisions, patching, hardening, backup design, and remote administration. If the server is misconfigured, compromised, or under-provisioned, the colocation provider is usually not the party that corrects it.
Security Boundaries, Trust, and Operational Dependencies
Colocation introduces a clear boundary between facility security and system security. Physical access controls, power redundancy, fire suppression, and network cross-connects reduce some classes of risk, but they also create dependencies on provider procedures, visitor control, and resilience of the shared infrastructure.
The security model is strongest when responsibility is explicit. The provider protects the site and platform utilities; the customer protects the machine, the operating system, and the services that run on it. When those boundaries are unclear, gaps appear in incident response, maintenance windows, remote hands requests, and accountability for loss or outage.
When Colocation Is the Right Fit
Colocation is typically chosen when an organisation wants tighter physical control than cloud or managed hosting provides, but does not want to operate its own building. It is common where latency, hardware customisation, regulatory posture, or legacy infrastructure needs make customer-owned equipment the preferred model.
It is less attractive when the organisation cannot sustain the operational discipline required for owned hardware. In that case, the savings from avoiding a facility may be outweighed by the burden of lifecycle management, spares, patch coordination, and on-site support orchestration.
Risk and Threat Considerations
Colocation concentrates physical, environmental, and connectivity dependencies into a third-party site, so outages or control failures in the facility can affect many customer systems at once. The main risks are loss of availability, weak segregation of tenants, and overreliance on the provider for physical protections and emergency response.
Failure mechanism: A power, cooling, access-control, cross-connect, or provider-process failure can disrupt systems even when the customer’s own hardware and software are functioning correctly. Shared infrastructure also creates exposure if remote-hands procedures, visitor controls, or rack-level segregation are weak.
Impact: The result can be downtime, data exposure, delayed recovery, or correlated outage across multiple customer workloads. In regulated or time-sensitive environments, a colocation incident can become a business continuity problem rather than a narrow facilities issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PE-18 — Location of Information System Components | Colocation directly concerns offsite placement of system components. |
| PE-6 — Monitoring Physical Access | Colocation depends on monitoring who enters shared facility areas. | |
| CP-2 — Contingency Plan | Colocation risk is strongly tied to outage response and recovery planning. | |
| Recommendation — Document and control where colocated system components may be installed and serviced. Monitor physical access to colocation spaces and review entry records for anomalies. Include colocation-specific outages in contingency planning and recovery testing. | ||
| NIST CSF 2.0 | GV.SC-05 — Supply Chain Risk Management | Colocation is a third-party dependency with operational and resilience implications. |
| Recommendation — Assess provider dependency and document colocation responsibilities in supplier risk management. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Colocation is a supplier relationship that affects security controls and accountability. |
| A.7.1 — Physical security perimeters | The term centers on third-party physical facility controls. | |
| Recommendation — Set security requirements and service responsibilities in the colocation contract. Define and verify the physical perimeter protecting customer-owned equipment. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Colocation relies on controlled network interconnects and resilient infrastructure. |
| Recommendation — Inventory and secure network cross-connects and infrastructure paths in the facility. | ||
Related resources from NHI Mgmt Group
- Who is accountable when a termination event does not revoke facility access?
- Who is accountable when biometric passwordless access is deployed in a shared facility and access policy is misconfigured?
- Why do cloud, colocation, and self-hosted data centers create different security and accountability risks?
- What happens when emergency access in an energy facility is not tightly governed?