The Many Layers of Data Protection: From Cyber to Connectivity to Recovery
In the last post, we talked about disaster recovery and business continuity as a social contract, not a pretty Visio diagram: getting the right people to agree on what “good” looks like before anything catches fire. DR/BC was framed as planning, people and buy‑in first; tooling second.
This one is about what happens next.
Once you’ve got that impact agreement, RPO/RTO, and priorities, you still need to turn it into something that actually works under pressure. That’s where the layers come in: cyber security, connectivity, and recovery working together, not as three independent shopping lists.
Think of it as building a stack that can fail safely:
- Connectivity: Can you still reach what you need to diagnose and recover?
- Cyber security: How small can you make the blast radius when (not if) something slips through?
- Data protection and recovery: When you pull the big red handle, do you have clean copies and a realistic way to bring them back?
Let’s walk through those layers and what the building blocks look like in practice.
Layer 1: Connectivity – if you can’t reach it, you can’t recover it
When people say “data protection”, they usually start with backup software and storage. But in a real incident, you very quickly rediscover that the network is the foundation.
Some unglamorous but critical questions:
- How do you get into your environment if your primary DC, VPN concentrator, or main MPLS/SD‑WAN hub is the thing that’s down?
- Do you have path diversity for your key sites and clouds, or is there a single cable everyone’s been politely ignoring?
- Can you isolate “dirty” segments when you’re dealing with a cyber event, while still reaching the systems you need to recover?
You see this reflected in how the more modern providers bundle networking (SD‑WAN, multi‑cloud connect, circuit management) alongside backup and DR in the same portfolio, because the transport and the recovery story are now joined at the hip.
Building blocks to look for:
- Dual, diverse connectivity for critical locations and clouds.
- Out‑of‑band access for management and DR tooling.
- Network designs that support segmentation and isolation during an incident, not just “fast when it’s sunny”.
Layer 2: Cyber security – shrinking the blast radius
The second layer is the one that usually dominates budgets and headlines: preventing and detecting bad things.
The important bit for data protection is not just “keep attackers out”, but containment and survivability:
- Strong identity (MFA everywhere, least privilege).
- Endpoint protection plus EDR/XDR so you can actually see what’s happening.
- Network controls to stop lateral movement when something lands.
- Hardening for management planes, backup repositories, and DR environments so they don’t become patient zero.
There’s growing recognition that “data protection” and “cyber resilience” are two sides of the same coin. One keeps copies safe and recoverable; the other tries to ensure you still have a clean island to recover into.
What this layer should give you:
- Telemetry to understand what was hit and when (crucial for choosing clean restore points).
- Enough segmentation that you can quarantine parts of the estate without killing recovery tooling.
- Confidence that your backup/DR infrastructure isn’t the easiest thing to compromise.
Layer 3: Data protection – copies, immutability, and coverage
Only now do we get to what most people badge as “data protection”: backups, replicas, and retention.
Some realities:
- One backup product is rarely enough. You probably need a combination of VM‑level, database‑aware, SaaS‑aware, and long‑term archive.
- Immutability and air‑gapping aren’t optional anymore. Attackers know where your backups live, and they go there early.
- Protecting “where the data actually is” includes SaaS (Microsoft 365, etc.), not just on‑prem kit and VMs.
You can see this in how providers are layering services:
- Cloud backup that covers on‑prem, public cloud, and SaaS workloads, often with immutable object storage behind it.
- Platform‑agnostic coverage so mainframe, x86, Unix, and SaaS don’t all end up as separate, orphaned islands.
- Secondary, isolated copies (vaults, cyber‑recovery environments) specifically intended to survive a ransomware‑style event.
Building blocks here:
- A coherent 3‑2‑1 strategy: multiple copies, media types, and locations – with at least one copy immutable and/or logically air‑gapped.
- Coverage for:
- Core infrastructure and databases,
- SaaS like Microsoft 365,
- “Long tail” workloads and file shares that quietly run the business.
- Documented, tested restores – not just “job succeeded” reports.
Backups are just one layer – necessary, not sufficient.
Layer 4: Recovery – where the plan meets the platform
This is where your last post really bites: when something goes wrong, can you recover on purpose, not by improvisation?
On the technology side, the market has been moving from “here’s your backup console, good luck” towards full‑blown recovery platforms:
- DRaaS that gives you a ready‑to‑run secondary platform – compute, storage, networking and all – not just copies of disks.
- Cyber incident recovery services that explicitly combine modern data protection with managed recovery expertise for breach scenarios.
- Management planes (cloud consoles) that let you see and control backup, DR, and cloud resources from a single place.
A subtle but important point: in a real disaster, your DR environment is production for as long as you’re failed over. It needs the same performance, security controls, and monitoring as “the real thing”.
Building blocks here:
- Documented runbooks that humans can follow at 3am (which you already covered in the previous post).
- Automated orchestration where it makes sense (multi‑VM app stacks, network re‑plumbing, DNS changes), with clear decision points for humans to approve.
- The ability to run real tests – including cyber‑style scenarios – without putting production at risk.
Layer 5: Visibility, governance, and continuous improvement
Even if you assemble all the right components, they drift. Architectures change; new SaaS apps appear; someone quietly stands up a critical workload in a cloud region that isn’t in any DR plan.
That’s why a fifth layer – call it governance and observability – matters:
- Single‑pane‑of‑glass portals so you can actually see what’s protected, what’s not, and where you’re meeting your own objectives.
- Regular, meaningful reporting on backup success, RPO/RTO achievement, DR test outcomes, and security posture.
- Compliance and privacy controls are baked into the platform, not bolted on from a spreadsheet afterwards.
This is also where many organisations lean on external partners – not just for tools, but for continuity consulting and hard questions about where the risks really are.
Where vendors like 11:11 meet the challenge
Without turning this into a product pitch, it’s worth noting the pattern you can see from providers in this space, 11:11 Systems included:
- A resilient cloud platform that deliberately bundles cloud, backup, disaster recovery, security, and networking under one roof, so customers can modernise, protect and manage from a consistent foundation.
- An emphasis on end‑to‑end data protection services – from simple offsite backup through to DRaaS, cyber incident recovery, and consulting – rather than isolated point products.
- Increasing focus on cyber resilience programmes: webinars, playbooks and services explicitly connecting data protection with cyber‑recovery readiness.
That direction of travel aligns pretty closely with the layered model above: providers are trying to give you more of the stack – connectivity, security, data protection, and recovery – in one place, while still playing nicely with the rest of your ecosystem.
It doesn’t mean a single vendor will magically solve everything. It does mean you can judge offerings by how well they:
- Fit into your service‑centric view of the world from the first post,
- Cover multiple layers coherently (not just “we have a checkbox in that column”),
- Help you test and prove your recovery outcomes ahead of time.
Bringing it together: a practical checklist
If you want something tangible to take back to your own environment, try this as a starting point:
- Restate the social contract. For each key service, confirm RPO/RTO and acceptable impact with the business – in plain language.
- Map the layers for each service:
- Connectivity paths (normal and “everything’s on fire”),
- Security controls that protect it,
- Backup/replication mechanisms,
- Recovery platform and runbook.
- Find the orphans. Look for services that rely on a single network path, have no immutable copy, or can’t be sensibly recovered anywhere.
- Test end‑to‑end. Not just “can we restore a VM?”, but “can users actually do their jobs in the recovered environment – including after a cyber event?”.
- Evolve the stack, not just the slideware. When you change architecture, SaaS, or providers, run it back through the same layered lens.
Because at the end of the day, when the lights go out, nobody’s going to thank you for the diagram. They’re going to judge you on whether you can still tell a coherent story about how you’ll connect, contain, and recover – and then actually do it.
