Ask three different companies what “cyber resiliency” means, and you’ll get three different answers, and all three can be right.

It depends entirely on who owns recovery. As you move from an enterprise, to a traditional co-location provider, to a cloud-enabled co-location provider, the definition doesn’t just change in emphasis. The scope of what’s actually being protected changes.

If this sounds familiar, it should. It’s the same shared responsibility model that AWS and Azure use to define where their obligations end and the customer’s begin, applied here to physical infrastructure and colocation facilities instead of cloud services. The line moves for the same reason in both cases: whoever operates a given layer owns recovery for that layer.

Enterprise: everything is in scope

For an enterprise, cyber resiliency means restoring business operations, not just IT systems. That distinction matters more than it sounds like it should. Recovering a server is not the same as recovering the business function that server supports.

That requires understanding application dependencies, protecting identity services, securing backup and recovery platforms, maintaining immutable recovery points, and regularly validating recovery procedures. Whether workloads run on-premises, in a co-location facility, or in AWS or Azure, the objective stays the same: critical systems come back securely and within defined recovery objectives. The enterprise owns every layer, so it has to plan for every layer.

Traditional co-location: the provider’s job shrinks

Move to a traditional co-location provider and the picture narrows. Cyber resiliency here is less about protecting customer data and more about keeping the facility and its services trustworthy and recoverable after an incident.

Some of this is visible even on a standard site visit, the rest is standard practice across the industry. That typically covers:

• Physical security: badge access, biometrics, CCTV, mantraps, visitor management
• Infrastructure resiliency: power redundancy (N+1, 2N), UPS and generators, cooling redundancy, multiple network carriers, environmental monitoring
• Operational Technology security: building management systems, HVAC controls, generator controllers, power distribution units, industrial control systems
• Corporate IT resiliency: identity services, ticketing, DCIM systems, customer portals, billing, monitoring platforms
• Network resiliency: identity services, DDoS protection, firewalls, management network isolation, recovery of routing infrastructure

These systems are increasingly ransomware targets in their own right. But notice what’s missing: customer workloads and customer backups are generally not part of the provider’s recovery plan. A colo can have excellent cyber resiliency and still leave you exposed, because your data was never inside its plan to begin with.

Cloud-enabled co-location: the scope grows with the service

Once a co-location provider starts offering managed services beyond leased space, cyber resiliency expands considerably. Managed hosting, managed VMware, managed storage, managed backup, bare metal, private cloud, DRaaS, managed security: each of these pulls more of the customer’s environment into the provider’s responsibility.

That expanded scope generally includes:

Customer platform recovery, covering VMware clusters, storage arrays, SAN infrastructure, hypervisors, Kubernetes platforms, and private cloud platforms.

Backup platform resiliency, meaning the provider protects the backup systems themselves: immutable backup repositories, air-gapped copies, isolated recovery vaults, backup administrator MFA, backup credential separation, and recovery validation. The goal is making sure backup infrastructure stays available, secure, and recoverable during a cyber incident, not just during a routine outage.

Once a provider owns managed services, “cyber resiliency” stops being a facilities conversation and becomes an operational one.

Identity is usually the first recovery priority, and the one people underplan

Across all three models, one pattern holds. Identity often becomes the first thing that has to come back, before almost anything else can be recovered.

That means Active Directory, Entra ID synchronization, DNS, PKI, and certificate services. It means determining clean recovery points and scanning for malware before trusting anything, then recovering through an isolated environment and validating before cutting back over to production.

Most recovery conversations start with storage and backup targets. They should start with identity. Nothing else comes back cleanly if the identity layer is still compromised, or if you can’t prove it isn’t.

The real question isn’t whether you have cyber resiliency

The mistake I keep seeing is treating cyber resiliency as something you can confirm with a checkbox on a vendor questionnaire. It’s not a feature. It’s a boundary line, and that line moves depending on what you’re actually paying a provider to run.

Before trusting a recovery plan, whether it’s your own or a provider’s, the first question isn’t “do we have cyber resiliency.” It’s “whose plan is it, and where does it stop?”

Knowing whose plan it is only gets you halfway. The other half is the question behind my last post: has that plan actually been tested, or has it only been assumed? Replication is not recovery. Ownership without validation is not resiliency either.

#CyberResilience #DisasterRecovery #BackupAndRecovery #ITInfrastructure