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

Cyber resilience is not about preventing every attack. It is about ensuring the business can survive one.

Modern ransomware groups target identities, backup infrastructure, and recovery processes because they understand a simple truth: if recovery fails, the business fails. Organizations that assume compromise, isolate recovery assets, and regularly test restoration capabilities can recover faster, reduce operational disruption, and protect customer trust.

Perfect resilience does not mean perfect security. It means building systems that contain damage, preserve recoverability, and restore operations with confidence.

Resilience is ultimately a business continuity discipline with cybersecurity components, not the other way around.

Why Cyber Resilience Is a Business Continuity Problem

Downtime has consequences that extend far beyond IT.

Lost revenue, contractual penalties, regulatory scrutiny, reputational damage, and customer churn can quickly exceed the direct cost of a cyberattack. The question executives should ask is not, “Can we prevent every attack?” It is, “How quickly can we recover critical operations?”

A mature resilience strategy protects business outcomes rather than individual servers. Technology enables recovery, but resilience exists to keep the organization functioning.

Identity Is the New Perimeter

Most ransomware operators do not smash through firewalls. They log in.

Compromised credentials, stolen tokens, service accounts, and abused administrative privileges have become preferred attack methods. Once attackers obtain identity control, they move laterally into virtualization platforms, backup environments, and cloud infrastructure.

This reality reinforces a core Zero Trust principle: trust nothing implicitly and continuously verify everything.

Modern cyber resilience architectures should assume identities, devices, and networks may already be compromised. Access should be granted based on least privilege, strong authentication, and continuous validation rather than network location.

Identity systems deserve the same protection traditionally reserved for production workloads because identity has become the control plane for everything else.

Strong MFA, privileged access management, separation of duties, and continuous monitoring are no longer optional safeguards. They are foundational requirements.

Attackers are surprisingly polite. They rarely kick down the door. They usually ring the bell and sign in with stolen credentials.

Architecture Layers and Why They Exist

Cyber resilience is fundamentally built around Zero Trust concepts. Every layer should assume that the layer above it may eventually be compromised.

Production systems should not have unrestricted access to backup infrastructure. Backup administrators should not share privileges with domain administrators. Recovery vaults should not trust production domains. Trust relationships should be minimized and continuously scrutinized.

Resilience depends upon deliberately limiting blast radius. The objective is not simply preventing compromise. The objective is ensuring compromise remains contained.

Production Layer

The production environment exists to run the business.

Its purpose is to prevent compromise, reduce attack opportunities, and contain incidents before they spread.

Controls include hardened operating systems, segmentation, endpoint detection, vulnerability management, identity protection, secrets management, and supply-chain controls.

The goal is not perfection. The goal is buying time.

Operational Backup Layer

The backup layer exists to preserve data and enable operational recovery.

Attackers understand this layer is often the organization’s insurance policy. Modern ransomware groups routinely target backup software, disable agents, delete snapshots, and abuse administrative privileges before encrypting production systems.

Operational backups should be isolated from production administration and protected with Zero Trust principles:

• Verify identities continuously.
• Enforce least privilege.
• Separate duties.
• Require MFA.
• Assume credentials may eventually be compromised.

If production catches fire, backups should not be standing next to the gasoline.

Cyber Recovery Vault

The recovery vault exists for worst-case scenarios.

Its purpose is not convenience. Its purpose is survival.

The vault should maintain strict trust boundaries. Production systems should be able to write forward but never authenticate backward into the recovery environment. There should be no direct trust relationships, shared credentials, or unrestricted administrative paths between the environments.

Zero Trust is particularly important here because attackers frequently spend weeks attempting to compromise recovery mechanisms before launching ransomware.

The recovery vault represents the organization’s final safety net. If attackers compromise production and operational backups, this layer preserves recoverability.

How Attackers Target Backup Environments

Modern ransomware operators have become remarkably good at studying recovery architectures.

Common techniques include:

• Stealing backup administrator credentials
• Exploiting shared service accounts
• Deleting snapshots and retention policies
• Encrypting backup repositories
• Disabling agents and monitoring systems
• Abusing Active Directory privileges
• Targeting virtualization platforms
• Using legitimate tools to avoid detection

Several major incidents have demonstrated the same lesson repeatedly: attackers often spend days or weeks destroying recovery options before encrypting production systems.

Encryption is frequently the final act, not the opening scene.

Lessons Learned From Real Incidents

Without naming specific organizations, several patterns emerge from public investigations:

• Shared identities create shared failures.
  • Domain administrators should not also administer backup environments.
• Untested backups are dangerous assumptions.
  • Successful backup jobs do not guarantee successful recovery.
• Recovery takes longer than expected.
  • Restoring infrastructure, applications, DNS, and identity services is considerably more complicated than restoring data.
• Communication becomes difficult.
  • Email and collaboration platforms may be unavailable during an incident. Out-of-band communication plans matter.
• Identity recovery determines everything else.
  • Without Active Directory and DNS, restoring applications becomes far more difficult.

Measuring Resilience

Cyber resilience should be measured.

Useful metrics include:

Metrics transform confidence into evidence.

Maturity Model

Organizations do not need to build the perfect architecture overnight.

Good

• MFA enabled
• Daily backups
• Quarterly restore tests
• Basic incident response procedures

Better

• Immutable backups
• Separate backup administration
• Monthly restore testing
• Recovery playbooks
• SIEM integration
• Partial recovery exercises

Best

• Cyber recovery vault
• Clean-room recovery
• Automated recovery orchestration
• Continuous validation
• Multi-party approval
• Quarterly tabletop exercises
• Dedicated ransomware resilience team

Resilience is a journey, not a shopping list.

Cost and Complexity Considerations

Perfect architectures are expensive.

Not every organization requires air-gapped vaults, dedicated clean rooms, or fully automated recovery workflows. Smaller organizations can achieve meaningful resilience through immutable backups, separation of duties, and regular testing.

Every additional layer increases cost and operational complexity.

A practical design balances:

• Recovery objectives
• Regulatory requirements
• Risk tolerance
• Staffing capabilities
• Budget constraints

The most sophisticated architecture nobody can operate is not resilient. It is expensive decor.

The Recovery Pyramid

Recovery is not simply restoring data. Dependencies matter.

Many organizations instinctively think data sits at the foundation of recovery. In reality, identity sits at the bottom of the stack. Applications depend on infrastructure, infrastructure depends on identity, and users depend on everything above them.

                Users
                  ▲
            Applications
                  ▲
                 Data
                  ▲
            Infrastructure
                  ▲
               Identity

Identity services such as Active Directory, DNS, certificate services, and authentication platforms form the foundation of modern environments.

Without identity, recovering applications becomes significantly more difficult. Systems may exist, but users cannot authenticate, applications cannot communicate, and trust relationships break down.

Recovery efforts should prioritize foundational services before restoring higher layers.

An outage involving identity often turns even simple recoveries into archaeological expeditions.

ToDo:  Add an explanation for each layer here
Identity
Infrastructure
Data
Applications
Users

People, Process, and Technology

Technology alone does not create cyber resilience.

Successful recovery depends on people making informed decisions and processes providing clear guidance during stressful situations.

People

Cross-functional participation matters. IT, security, operations, legal, compliance, communications, and executive leadership all play critical roles during an incident.

Cyber resilience is not an IT responsibility delegated to a few administrators. It is an organizational responsibility.

Process

Playbooks, testing, escalation procedures, and communication plans transform chaos into coordinated action.

Organizations should maintain:

• Documented incident response procedures.
• Recovery playbooks.
• Quarterly tabletop exercises.
• Defined roles and responsibilities.
• Out-of-band communication methods.

Backups without recovery procedures are merely expensive collections of files.

Technology

Technology enables recovery but does not guarantee it.

Immutable backups, isolated recovery vaults, malware scanning, orchestration, and monitoring provide the foundation, but technology only works when people understand it and processes support it.

The most advanced platform in the world cannot compensate for missing procedures or untested assumptions.

Cyber resilience is strongest when people, processes, and technology reinforce one another rather than operate independently.

Technology enables resilience, but people and processes determine whether it succeeds. Organizations rarely fail because they lacked another security product. More often, they fail because assumptions went untested, responsibilities were unclear, or recovery procedures had never been practiced.

Simple Architecture Diagram

                    +----------------+
                    | Production      |
                    | Applications    |
                    +----------------+
                             |
                             | Backup Data
                             v
                 +-----------------------+
                 | Operational Backups    |
                 | Immutable Storage      |
                 +-----------------------+
                             |
                             | One-Way Replication
                             v
              ==================================
                 TRUST BOUNDARY / LOGICAL GAP
              ==================================
                             |
                             v
                +-------------------------+
                | Cyber Recovery Vault     |
                | Golden Images            |
                | Malware Scanning         |
                | Clean-Room Recovery      |
                +-------------------------+

        No reverse trust relationships permitted.

Closing Thoughts

Cyber resilience is not defined by the number of security products deployed. It is defined by architecture, testing, and discipline.

Organizations that invest in immutable backups, isolated recovery environments, and practiced recovery procedures are protecting far more than infrastructure. They are protecting revenue, customer trust, and business continuity.

Attackers only need one good day.

Resilient organizations spend their time preparing for the day after.

That promise was real, and it still holds. Replication solves availability.

But availability and recovery are not the same problem.

Somewhere along the way, the distinction blurred. Part of this is structural: the same platforms that replicate often also snapshot, version, and present everything under one dashboard. When a vendor markets continuity and protection as a single feature set, customers can reasonably assume they’ve covered both problems with one tool. They haven’t. Replication started to be spoken about as if it also protected against data loss, corruption, or attack. It does not. It was never designed to.

Replication Does Exactly What You Ask

Replication is simple at its core. It copies change.

Every write to the source is reflected at the target. Every update is propagated. Every deletion is honored. It does not interpret the change, and it does not validate the outcome. It keeps two systems aligned.

This is its strength.

It is also its limit.

If the source data becomes encrypted, the replica receives encrypted data. If a user deletes a critical dataset, the deletion is mirrored. If an application silently corrupts records over time, replication preserves that pattern perfectly.

Replication is not failing in these moments. It is succeeding. It is doing exactly what it was built to do.

• Replication keeps systems synchronized
• Replication keeps systems available

It does not decide whether the data is worth keeping.

The Moment That Exposes the Gap

The difference between availability and recovery becomes clear under stress, not during normal operations.

Consider a ransomware event that begins quietly. Files are encrypted in place, but the encryption process itself can run for hours before triggering an alert, if anything alerts at all. New writes continue, but they are no longer meaningful. Replication, running as designed, keeps pace with every change. By the time anyone notices, the corrupted state has already been faithfully copied across.

Soon you have two environments:

• A primary system that is encrypted
• A replica that is also encrypted

Failover still works. Systems still start. From an infrastructure perspective, everything is healthy.

But from a business perspective, nothing is usable.

This is the moment where many teams realize they never had a recovery path. They had redundancy, not resilience.

Recovery Requires Separation From the Present

To recover, you need distance from the current state.

You need the ability to say, with confidence, that the present data set is not trustworthy and that a prior state is. That requires more than a second copy. It requires history.

Recovery depends on three properties:

• The ability to retain multiple points in time
• The assurance that those points cannot be altered
• The means to restore them cleanly and predictably

This is not what replication provides. Replication gives you now. Recovery requires access to then.

This is where backup systems operate.

Backup Is a Governed System, Not a Passive Copy

It is common to describe backup as “another copy of the data.” That description is too shallow to be useful.

A well-designed backup system enforces structure and control around data over time. It introduces discipline where replication introduces speed.

A backup system defines:

• When data is captured
• How long it is retained
• Who can access or delete it
• Whether it can be altered
• How it is validated before use

It creates separation from production systems, often at multiple levels:

• Separate infrastructure or storage tiers
• Independent credentials and access paths
• Policies that prevent modification during retention windows

It also requires something that is often overlooked: testing. A restore point only has value if it can be used. Confidence comes from verification, not assumption.

None of this runs itself. A backup system needs an owner: someone accountable for checking that retention windows match policy, that restores actually complete, and that access controls haven’t quietly drifted. A backup plan with no one reviewing it is just an unverified assumption with better marketing.

This is why backup is not just a storage function. It is a control system for data over time.

• Backup establishes history
• Backup enforces integrity
• Backup enables recovery

Governance Has Caught Up to the Reality

Modern governance frameworks no longer treat replication as a complete answer, and for good reason. Frameworks like the NIST Cybersecurity Framework and the EU’s DORA regulation define resilience in terms of outcomes, not infrastructure:

• Can the organization restore operations after a disruption
• Can it do so with trusted data
• Can it do so within acceptable timeframes

To meet those outcomes, certain capabilities are required:

• Isolation, so that a single compromise does not spread
• Immutability, so that protected data cannot be altered
• Versioning, so that multiple recovery points exist
• Validation, so that recovery is predictable

Replication plays a role, but it addresses only one dimension. It improves uptime. It does not, on its own, give you a path back to a trustworthy state.

A Clear Boundary Matters

The confusion persists because the tools often coexist, and the terminology overlaps. Systems that replicate may also take snapshots. Storage platforms may offer versioning alongside replication. Vendors present these features as a unified story.

But the boundary is operational, not marketing-driven.

• Replication is about continuity of service
• Backup is about recoverability of data

Blending the two leads to false confidence. Separating them leads to better design.

What a Complete Approach Looks Like

A resilient architecture uses replication and backup together, but it assigns them clear roles.

Replication handles:

• Infrastructure failure
• Site outages
• Rapid failover needs

Backup handles:

• Ransomware
• Data corruption
• Human error
• Unknown or delayed failure conditions

The two systems should not share the same assumptions. They should not depend on the same trust boundaries. Each exists to address a different type of risk.

The Difference That Matters

In practice, the distinction comes down to a simple question during a crisis: are you trying to stay running, or are you trying to get your data back?

Replication helps you stay running. Backup allows you to get your data back.

Both are necessary. Neither replaces the other.

Final Thought

Replication preserves the current state, whatever it may be.

Backup preserves the ability to step away from that state when it is no longer trustworthy.

In 20+ years doing backup and recovery work, the failure I’ve seen more than any other isn’t exotic. It isn’t ransomware outsmarting a vendor’s tooling. It’s a backup that existed, looked fine on a dashboard, and had never once been restored. Not at one company. Across nearly every environment I’ve walked into. The job completed. Nobody ever asked if the data on the other end actually came back.

That’s the gap. Not a missing tool. A missing question.

So ask it. Pull a backup this week, not a test file, an actual production restore, and see what comes back. If you don’t already know the answer, you don’t have a recovery plan. You have a green checkmark and a guess.

ABCP vs CBCP — at a glance

What ABCP really means

ABCP is designed to validate baseline competence in Business Continuity Management.

DRI explicitly positions ABCP for:

• Individuals new to the profession
• People with less than two years of BC experience
• Professionals transitioning from adjacent fields (IT, ops, emergency management, risk)

ABCP confirms that you:

• Understand BCM concepts and terminology
• Know how risk assessment, BIA, strategies, and plans fit together
• Can participate meaningfully in a BC program

ABCP does not require:

• Documented work products
• Essays
• References
• CEAPs for maintenance

[dri-anz.org], [dri.ca]

ABCP answers the question:

“Do you understand business continuity well enough to work in the field?”

What CBCP really means

CBCP is DRI’s flagship credential and is explicitly experience‑validated.

DRI requires CBCP candidates to:

• Demonstrate ≥2 years of hands‑on BC/DR experience
• Document experience in five Professional Practices
• Submit five essays showing real decisions, trade‑offs, and outcomes
• Provide references who can verify that experience

At least two essays must cover:

• Business Impact Analysis
• Business Continuity Strategies
• Plan Development & Implementation
• Exercising, Testing, and Maintenance

[drii.org], [dri-anz.org]

CBCP signals that you:

• Can design and lead a BC program
• Have performed BIAs, strategy selection, plan builds, and exercises
• Understand governance, crisis communications, and lifecycle maintenance

CBCP answers the question:

“Can you be trusted to own or lead a business continuity program?”

Exam note (important)

Both certifications use the same DRI Qualifying Exam.

The difference is not the test — it’s the experience validation:

• ABCP = pass the exam + apply
• CBCP = pass the exam + prove your work

[dri-italy.it], [drii.org]

Upgrade path (ABCP → CBCP)

DRI explicitly allows upgrading without retaking the exam:

1. Earn ABCP
2. Accumulate qualifying BC experience
3. Submit CBCP application (essays + references)
4. Pay the CBCP fee

[dri-italy.it]

This is a very common path.

Which one should you choose?

Choose ABCP if:

• You have <2 years of BC/DR experience
• You’re changing careers or adding BC to your role
• You want a recognized credential now, without documentation burden

Choose CBCP if:

• You already lead or co‑own BC activities
• You’ve done BIAs, written plans, run exercises, or managed incidents
• You can clearly describe why decisions were made — not just what

DRI itself says:

“If you have less than two years of industry experience, you should apply for the ABCP certification.” [drii.org]

Bottom line

• ABCP = foundation + credibility
• CBCP = experience + authority

If you want, I can:

• Help you self‑assess whether your current work qualifies for CBCP
• Map your resume to the Professional Practices
• Recommend ABCP‑now vs CBCP‑later with a timeline

OK so same question for both of these, what are the top courses I can do at both Coursera and LinkedIn learning to get me started on these?

Below is a practical, starter‑friendly list of the top Coursera and LinkedIn Learning courses that map cleanly to both ABCP and CBCP, with notes on why each is useful and how far it will take you.

Important framing (so expectations are right):
Coursera and LinkedIn Learning are excellent for building foundations and confidence, especially for ABCP and early CBCP prep.
They do not replace DRI training (BCLE 2000 / Professional Practices), which is still the gold standard for the CBCP exam and application.

Coursera — Best courses to get started

These are the strongest CBCP/ABCP‑aligned courses currently on Coursera, focusing on BIA, BC/DR planning, risk, and incident response.

1. Business Continuity and Disaster Recovery (Packt)

Best single Coursera course for both ABCP and CBCP

Why it’s top‑tier

• Explicitly covers:
  • Business Impact Analysis (BIA)
  • Risk assessment
  • Business Continuity Plans (BCP)
  • Disaster Recovery planning and testing
• Directly aligns with multiple DRI Professional Practices
• Beginner‑to‑intermediate friendly

Best for

• ABCP: Excellent primary prep
• CBCP: Strong refresher + terminology alignment

Take this first on Coursera.

2. Incident Response, BC, and DR Concepts (ISC²)

Best conceptual clarity course

Why it’s valuable

• Clearly distinguishes:
  • Incident Response vs Business Continuity vs Disaster Recovery
• Helps avoid common exam and real‑world confusion
• Especially helpful if you come from IT, security, or ops

Best for

• ABCP: Conceptual grounding
• CBCP: Framing BC within incidents

3. Disaster Recovery and Business Continuity (Packt)

More depth than Course #1

Why it’s useful

• Expands on DR strategies, backup models, and recovery approaches
• Reinforces BIA and risk concepts
• Good for people who want repetition with more examples

Best for

• ABCP: Optional depth
• CBCP: Reinforcement

4. Risk Management and Incident Response (Packt)

Best Coursera option for risk + BIA thinking

Why it helps

• Explicitly references Business Impact Analysis
• Teaches risk evaluation frameworks
• Useful for CBCP essay thinking (decision‑making and tradeoffs)

Best for

• ABCP: Optional
• CBCP: Very helpful

Coursera “starter stack” (recommended order)

1. Business Continuity and Disaster Recovery
2. Incident Response, BC, and DR Concepts
3. Risk Management and Incident Response

That alone gives you solid ABCP readiness and a strong CBCP foundation.

LinkedIn Learning — Best courses to get started

LinkedIn Learning is less exam‑oriented but excellent for real‑world context, leadership language, and applied thinking—especially valuable for CBCP essays.

1. Business Continuity Planning Foundations

Best LinkedIn Learning starting point

Why it matters

• Introduces:
  • BCM lifecycle
  • Governance concepts
  • BIA → strategy → plans → testing
• Clear, non‑technical explanations
• Matches DRI terminology surprisingly well

Best for

• ABCP: Excellent foundation
• CBCP: Reinforces structure

2. Disaster Recovery Foundations

Best DR‑focused course on LinkedIn Learning

Why it helps

• Covers DR strategies, recovery sites, and testing
• Supports CBCP requirements around recovery strategies
• Pairs well with Coursera’s Packt courses

Best for

• ABCP
• CBCP

3. Risk Management Foundations

Key for CBCP maturity

Why it’s valuable

• Helps frame risk decisions (not just controls)
• Useful language for CBCP essays
• Supports Professional Practice: Risk Evaluation & Control

Best for

• ABCP: Optional
• CBCP: Strongly recommended

4. Crisis Management Foundations

Underrated but important

Why it matters

• CBCP explicitly tests crisis communications and leadership
• Helps with Professional Practice: Crisis Communications
• Builds executive‑level framing

Best for

• ABCP: Optional
• CBCP: Very useful

LinkedIn Learning “starter stack”

1. Business Continuity Planning Foundations
2. Disaster Recovery Foundations
3. Risk Management Foundations
4. Crisis Management Foundations

How to use these depending on your goal

If your goal is ABCP

Do:

• Coursera:
  • Business Continuity and Disaster Recovery
  • Incident Response, BC, and DR Concepts
• LinkedIn Learning:
  • Business Continuity Planning Foundations
  • Disaster Recovery Foundations

That is more than enough for ABCP exam readiness.

If your goal is CBCP

Do all of the above, plus:

• Coursera:
  • Risk Management and Incident Response
• LinkedIn Learning:
  • Risk Management Foundations
  • Crisis Management Foundations

Then move to: DRI Professional Practices BCLE 2000 (or equivalent DRI course)

Key takeaway

• Coursera = technical + structural learning
• LinkedIn Learning = applied + leadership language
• DRI training = exam + certification authority

Used together, Coursera + LinkedIn Learning give you a very strong launchpad for both ABCP and CBCP.

4–6 Week Study Plan (Coursera + LinkedIn Learning only)

Week 1 – Foundations of Business Continuity (Core concepts)

Goal

Understand what BCM is, why it exists, and how the BC lifecycle fits together.

Coursera

Business Continuity and Disaster Recovery (Packt)

• Modules:
  • Introduction to BC & DR
  • BCM fundamentals & terminology
• Focus on:
  • BCM purpose
  • Recovery concepts (RTO, RPO)
  • High‑level lifecycle

[coursera.org]

LinkedIn Learning

Business Continuity Planning Foundations

• Focus on:
  • Governance and program structure
  • Executive buy‑in
  • How BC fits into the organization

[solutionsreview.com]

Outcome:
You can explain BCM clearly to a non‑technical audience (this is critical for both ABCP and CBCP).

Week 2 – Risk Assessment & Business Impact Analysis (BIA)

Goal

Master risk evaluation and BIA, which are mandatory CBCP subject areas and heavily tested.

Coursera

Continue Business Continuity and Disaster Recovery (Packt)

• Modules:
  • Risk assessment
  • Business Impact Analysis (BIA)
• Focus on:
  • Identifying critical functions
  • Impact categories (financial, operational, reputational)
  • Dependencies and prioritization

[coursera.org]

LinkedIn Learning

Risk Management Foundations

• Focus on:
  • Risk framing
  • Likelihood vs impact
  • Decision‑making language

[solutionsreview.com]

Outcome:
You can describe how BIAs drive strategy, not just how to fill out a template.

Week 3 – Incident Response, Continuity & Recovery

Goal

Clearly distinguish Incident Response vs Business Continuity vs Disaster Recovery.

Coursera

Incident Response, BC, and DR Concepts (ISC²)

• Modules:
  • Incident Response
  • Business Continuity
  • Disaster Recovery
• Focus on:
  • When each plan is triggered
  • How they interact during a disruption

[coursera.org]

LinkedIn Learning

Disaster Recovery Foundations

• Focus on:
  • Recovery strategies
  • Testing and validation
  • Technology vs business recovery

[solutionsreview.com]

Outcome:
You can confidently answer exam questions like “Which plan activates when X happens?”

Week 4 – Plan Development, Testing & Maintenance

Goal

Understand how plans are built, tested, and kept current—a major CBCP expectation.

Coursera

Finish Business Continuity and Disaster Recovery (Packt)

• Modules:
  • Plan development
  • Testing & exercising
  • Continuous improvement

[coursera.org]

LinkedIn Learning

Crisis Management Foundations

• Focus on:
  • Crisis communications
  • Stakeholder messaging
  • Leadership decision‑making

[solutionsreview.com]

Outcome:
You understand plan lifecycle management, not just plan creation.

At this point (end of Week 4)

You are:

• Ready for ABCP
• Well‑positioned to begin CBCP‑level thinking
• Fluent in BCM terminology, structure, and intent

Optional Extension (Weeks 5–6) – CBCP Depth

Week 5 – Strategy Selection & Trade‑offs (CBCP maturity)

Coursera

Risk Management and Incident Response (Packt)

• Focus on:
  • Strategy selection
  • Risk trade‑offs
  • Decision rationale

[coursera.org]

LinkedIn Learning

Revisit:

• Risk Management Foundations
• Crisis Management Foundations

Outcome:
You can articulate why one strategy was chosen over another (CBCP essay skill).

Week 6 – CBCP Readiness & Self‑Assessment

Activities (no new courses)

• Re‑watch key modules on:
  • BIA
  • Strategy development
  • Exercising/testing
• Practice explaining:
  • A disruption scenario
  • Your response decisions
  • Lessons learned

Outcome:
You’re ready to transition into DRI Professional Practices and BCLE 2000.

What this plan does not replace

• DRI Professional Practices
• BCLE 2000
• CBCP application essays & references

But it dramatically reduces ramp‑up time and makes formal DRI training much easier.

1. Core Principles of a Perfect Cyber‑Resilient Architecture

A truly resilient design must deliver:

• Continuity — operations continue even during an attack
• Integrity — backups cannot be altered, encrypted, or deleted
• Recoverability — rapid, orchestrated restoration to a known‑good state
• Visibility — ability to detect malicious activity early
• Adaptability — lessons learned feed back into the system
• Containment — The architecture must prevent compromise from spreading across environments, including backup and recovery planes

These align with modern cyber resilience frameworks.

2. The Architecture: What “Perfect” Looks Like

A. Multi‑Layered Backup Architecture

1. Production Layer (Primary Systems)

• Hardened OS and applications
• MFA everywhere
• Network segmentation
• Least‑privilege access
• Continuous patching and vulnerability management
• Endpoint protection + EDR/XDR
• Identity Protection
• Supply chain/third-party risk (compromised software updates are a leading ransomware vector)
• Secrets management (hardcoded credentials in scripts routinely expose backup systems)

2. Backup Layer (Operational Backups)

• Immutable storage (WORM, object lock, or filesystem immutability)
• Separation of duties (backup admins ≠ domain admins)
• MFA + RBAC for backup platform
• Encrypted in flight and at rest
• Frequent backups aligned to RPO
• Automated backup verification
• Backup infrastructure isolation
• Hardening the backup server OS
• Restricting inbound connections to the backup servers
• Monitoring the backup service account

3. Isolated Recovery Layer (Cyber Recovery Vault)

• Physically or logically isolated from production
• Strictly controlled access (just‑in‑time, MFA, break‑glass)
• Immutable, air‑gapped or logically gapped copies
• Malware scanning on ingest and before restore
• Golden images / golden configs stored here
• No direct domain trust with production

This layer is critical for ransomware resilience.

3. Security Controls That Must Wrap the Backup Ecosystem

A. Protect the Backups Themselves

• Immutable snapshots
• Air‑gap or logical gap
  • One-way replication/data diode – enforces hardware-level unidirectional flow, so a compromised production network cannot reach back to the vault
• MFA for all privileged operations
• RBAC with least privilege
• No shared service accounts
• API rate limiting and anomaly detection
• Backup infrastructure hardened and isolated

B. Detect Malicious Activity

• File‑system anomaly detection (encryption, mass deletion)
  • Backup size deviation alerting — a sudden 40% increase or decrease in backup job size is one of the earliest detectable signals of encryption or mass deletion activity.
• Behavioral ransomware detection
• Threat hunting using historical telemetry
• SIEM/XDR integration for backup events
• Alerts on unusual backup deletions or policy changes
• Backup deletion delay/approval workflows
  • 24–72 hour deletion delay
  • Multi-Party Approval

These align with modern ransomware detection guidance.

4. Incident Response & Recovery Readiness

A. Response Playbooks

• Documented ransomware response plan
• Out‑of‑band communication channels
• Pre‑defined roles and responsibilities
• Legal, PR, IR, and executive alignment

B. Recovery Playbooks

• Pre‑built orchestration workflows
• Golden master images for critical systems
• Clean‑room recovery environment
  • No outbound internet
  • No inbound connections
  • No trust relationships
  • Temporary identity provider
  • Forensic tooling
• Malware scanning before restore
• Prioritized application tiers (Tier 0 → Tier 3)
• Ability to restore AD, DNS, and identity systems first

C. Testing

*Annual is acceptable for full failover if partial restores are monthly and tabletops are quarterly.

Testing is a core pillar of cyber resilience.

5. Governance, Risk, and Business Alignment

A. Risk‑Driven Design

• Map critical business processes
• Define RPO/RTO by business impact
• Align cyber insurance requirements
  • Insurers increasingly require documented evidence of immutable backups, MFA, and tested recovery
• Maintain updated risk assessments and audits
• Data Classification – Not all data needs the same RPO/RTO or the same vault tier.
  • Tier recovery objectives by data sensitivity and business criticality; this is foundational to a cost-effective design

B. Executive & Cross‑Functional Engagement

• Cyber resilience is not an IT‑only function
• Requires business, legal, compliance, and operations
• Maintain a cross‑functional ransomware resilience team

6. What “Perfect” Looks Like in One Diagram

Three‑Tier Cyber‑Resilient Backup Architecture

The diagram below illustrates strict control-plane separation: production can write forward, but cannot authenticate, enumerate, or traverse backward into the recovery vault

The “Perfect Setup” Checklist

Identity & Access

• MFA everywhere
• No shared accounts
• Backup admins are isolated from the domain admins

Backup Platform

• Immutable storage
• Air‑gap or logical gap
• Automated verification
• Anomaly detection
• Encrypted everywhere

Recovery

• Clean‑room environment
• Golden images
• Malware scanning pre‑restore
• Orchestrated recovery workflows

Governance

• Documented IR/DR playbooks
• Quarterly tabletop exercises
• Annual full recovery tests
• Continuous improvement loop

Closing Thoughts

A truly cyber‑resilient organization is defined not by the tools it deploys, but by the discipline of its design, the rigor of its testing, and the clarity of its governance. Perfect resilience is not achieved in a single project—it is built through layered architecture, continuous validation, and cross‑functional ownership that aligns technology, risk, and business priorities. Organizations that invest in immutable backups, isolated recovery environments, and practiced recovery workflows are not merely improving IT outcomes; they are protecting revenue, customer trust, and enterprise survival. In an era where cyber incidents are inevitable, resilience is no longer optional—it is a core competency of modern leadership.

This layer doesn’t change by vendor, but each platform integrates differently.

Core Controls

• MFA, RBAC, identity tiering
• Network segmentation
• EDR/XDR
• Secrets management
• Patch/vulnerability management
• Zero‑trust access patterns

2. Backup Layer (Operational Backups)

This is where the vendors diverge the most.
Below is a vendor‑specific mapping of controls.

A. Immutability & Hardening

B. Anomaly Detection & Threat Monitoring

C. Backup Verification

3. Recovery Vault Layer (Isolated Cyber Vault)

This is where Dell shines — their Cyber Recovery Vault is one of the most mature vaulting solutions

A. Vault Architecture

B. Clean‑Room Recovery

Veeam’s Virtual Lab is a powerful clean‑room mechanism.

4. Recovery Orchestration (Tier 0 → Tier 3)

Veeam’s VDRO is extremely strong for automated, compliance‑driven DR.

5. Governance, Risk, and Compliance

All five vendors support:

• Immutable logs
• Audit trails
• Role separation
• Compliance reporting
• API‑driven governance

But each has strengths:

6. Full Architecture Diagram (Vendor‑Specific)

[Production Layer] – Hardened identity, MFA, segmentation – EDR/XDR, secrets management – Vendor agents / agentless integrations | v [Backup Layer] – NetBackup: Primary + Media + MSDP-C + AIR – Rubrik: CDM cluster + Atlas immutability + Radar – Commvault: CommServe + Media Agents + Hedvig + Metallic – Cohesity: DataProtect cluster + Helios + Threat Defense – Veeam: Backup Server + Hardened Linux Repo + SureBackup + Object Lock | v [Cyber Recovery Vault] – NetBackup: NCR / AIR vault / Object Lock vault – Rubrik: Cloud Vault / Polaris – Commvault: Cleanroom Recovery / Recovery Reserve – Cohesity: FortKnox – Veeam: Immutable Cloud Vault / Hardened Repo / Cloud Connect | v [Clean-Room Recovery] – Isolated network – Malware scanning – Orchestrated restore – Tier 0 → Tier 3 recovery

Bottom Line

This expanded version gives you a complete, five‑vendor cyber‑resiliency mapping that is:

• Architecturally consistent
• Accurate to each vendor’s capabilities
• Whitepaper‑ready
• Perfect for presentations, consulting, or internal standards

If you want, I can also create:

• A side‑by‑side maturity model for all five vendors
• A visual diagram set
• A CISO‑friendly executive summary
• A resume‑ready version showing multi‑vendor mastery

Just tell me where you want to take it next.

A modern, cyber‑resilient DR architecture must deliver:

• Zero‑trust security across identities, endpoints, networks, data, and workloads.
• Resilience against ransomware and destructive attacks (including AI‑assisted attacks).
• Rapid, automated recovery to minimize downtime.
• Immutable, independently stored backups across multiple zones/clouds.
• Automated testing to prove recoverability.
• AI‑powered anomaly detection, prediction, and orchestration.

A. Cyber Security Layer

Objective: Prevent, detect, and contain cyber threats before they compromise data.

Best Practices

• Zero Trust Framework
  • Identity-based access controls (MFA, conditional access).
  • Network micro‑segmentation.
  • Least privilege for admins.
    • Verify explicitly.
      Continuously authenticate and authorize based on all available data points,
      including user identity, location, device health, service or workload, data
      classification, and anomalies.
    • Use least-privileged access.
      Limit user access with just-in-time, and just-enough-access (JIT/JEA), risk-based
      adaptive policies, and data protection to help secure both data and productivity.
    • Assume a breach.
      Rather than acting as though the attack is coming, Zero Trust treats any
      situation as though the breach has already occurred. This not only improves
      prevention, but in the case of a breach, it can minimize its impact and help
      prevent cross-system access and further damage
• Endpoint + Server Hardening
  • EDR/XDR solutions with behavioral detection.
    • Endpoint Detection and Response
    • Extended Detection and Response
  • Privileged Access Workstation (PAW) model for admins.
• AI‑Driven Threat Detection
  • ML-based anomaly detection, e.g., sudden encryption activity.
  • AI‑powered behavioral baselines for users, devices, and applications.
• Security Controls
  • Continuous vulnerability scanning.
  • Automated patching.
  • Application allowlisting.
  • Secure configurations and baselines.

B. Data Protection & Backup Layer

Objective: Ensure reliable, protected, manipulatable‑proof data copies.

Best Practices

• 3‑2‑1‑1‑0 Backup Standard
  • 3 copies of data
  • 2 media types
  • 1 copy offsite
  • 1 immutable or air‑gapped
  • 0 errors verified via automated testing
• Backup Tiers
  1. Primary Hot Backup
     • A Primary Hot Backup is the fastest, most recovery‑ready form of data protection. It provides real‑time—or near‑real‑time—protection of production systems by continuously replicating block‑level or journaled changes to a secondary system.
       • Continuous replication or near-CDP.
         • Continuous Replication captures every write made on the primary system and instantly sends it to a secondary storage target with extremely low latency. There is no backup window—protection happens 24×7.
         • Near‑CDP replicates data at very short, frequent intervals (e.g., every 15 seconds, 30 seconds, 1 minute). It emulates CDP while reducing the infrastructure stress of true continuous write replication.
         • Fast RTO.
         • Not Ideal For
           • Cold/archive data
           • Low‑risk workloads
           • Systems with intermittent connectivity
         • Secondary Backup (Immutable)
           • WORM storage, object‑lock, or virtual air‑gap.
         • Tertiary Offline Copy
           • Tape, vault, or cloud deep-archive.
• Backup Security
  • Isolated backup network.
  • Backup admin identities are separate from production identities.
  • Immutable snapshots (cannot be deleted, even by admin).
• AI Integration
  • Detect anomalous backup patterns (e.g., sudden spike in changed blocks).
  • Predict backup failures before they happen.
  • Recommend optimal backup schedules based on usage patterns.

C. Disaster Recovery (DR) Layer

Objective: Maintain business continuity after failures or attacks.

Best Practices

• Define Recovery Objectives
  • RPO (Recovery Point Objective)
  • RTO (Recovery Time Objective)
• Multi‑Site DR
  • Active/active or active/standby, depending on application criticality.
  • DR should be in a separate region, cloud, or data center.
• Automated DR Orchestration
  • Runbooks codified as automation workflows.
  • Test failovers without impacting production.
• AI Integration
  • Predict DR capacity needs.
  • Recommend failover paths.
  • Autonomous failover using policy‑based ML decisions.

D. Cyber Recovery Vault (Isolated Recovery Environment – IRE)

Objective: Provide a last‑resort clean environment immune from attacks.

Key Vault Features

• Physically or logically isolated network.
• Multifactor administrative access with strict just‑in‑time elevation.
• Immutable copies are replicated on schedule but not continuously (prevents malware spread).
• DR Tools Inside the Vault
  • Malware scanning.
  • Forensic analysis.
  • Zero-trust access controls.
• AI Integration
  • AI‑driven malware scoring and clean-room validation.
  • AI-based anomaly detection on restored data.

3. AI‑Driven Enhancements Across the Stack

AI Use Cases

1. Threat Detection & Prevention
   • Behavioral analytics (UEBA/UEAI).
   • Real-time ransomware signature detection.
2. Backup & Recovery Optimization
   • Predict failures in backup chains.
   • Identify unusual encryption or deletions.
3. DR Recommendations
   • Predict which systems need the fastest RTO.
4. Automated Incident Response
   • ChatOps + AI‑assisted triage.
   • Suggest isolation or failover actions.
5. Testing Automation
   • Generate and evaluate DR test scenarios.
   • Compare test outcomes to historical performance.

4. Testing & Validation Framework

A resilient system must prove it works.

A. Backup Testing

• Automated restore verification (checksum validation).
• Randomized restore tests weekly.
• Full restore simulation monthly.

B. DR Testing

• Quarterly failover tests.
• Annual full DR simulation (all systems).
• AI‑randomized “chaos” tests:
  • Simulate a ransomware attack
  • Simulate file corruption
  • Simulate region failure
  • Evaluate the time to detect and the time to restore

C. Cyber Resilience Testing

• Incident response tabletop exercises.
• Cyber‑range simulations.
• Penetration testing of:
  • Backup systems
  • DR orchestration tools
  • Vault access procedures

D. AI Validation

• Validate that AI did not produce false positives during failover tests.
• Monitor ML models for consistency and drift.

5. End‑to‑End Blueprint (High Level)

1. Secure the environment
   • Zero trust, segmented networks, strong identity protection.
2. Protect the data
   • 3‑2‑1‑1‑0 backups with immutability.
3. Deploy the Cyber Recovery Vault
   • Isolated restoration environment.
4. Enable AI Analytics
   • Threat detection + anomaly monitoring + automated recovery.
5. Automate DR runbooks
   • Policy-driven, testable, monitored workflows.
6. Implement rigorous testing
   • Backup tests, DR simulations, cyber-range exercises.
7. Continuous improvement
   • Lessons learned from tests and incidents feed back into the architecture.

The Namesakes of Carter-Smith VFW Post 5867

Carter-Smith Post 5867 in Lakeside, California, stands as a living tribute to two local heroes—Howard Fredric Carter and Rowland Hampton Smith—who gave their lives during the attack on Pearl Harbor on December 7, 1941. Both men were young, dedicated sailors whose sacrifice embodies the spirit of service and patriotism honored by the Veterans of Foreign Wars.

Howard Fredric Carter (1917–1941)

Caption: Howard F. Carter, Coxswain Third Class, USS Dobbin.

Howard was born July 13, 1917, in Medford, Oregon, to Mabel Rose Carter (McKay) and Harold Carter. The family later settled in Lakeside, where Mabel owned a beauty shop. Mabel lived to be 103, passing away in 2001 as the oldest living Gold Star Mother and the first Ladies Auxiliary President of Post 5867.

Howard graduated from Grossmont High School in 1936, remembered as a fine young man active in track, science clubs, and school performances. His yearbook goal was simple: “to be a bread and butter man.”

Standing 5’6”, with light brown hair and blue eyes, Howard enlisted in the U.S. Navy on December 11, 1936, for a four-year term at a base pay of $21 per month. After boot camp at Naval Training Center San Diego, he reported aboard USS Dobbin (AD-3). He advanced to Coxswain, Third Class in February 1941 and earned a Good Conduct Medal.

On December 7, 1941, Howard was manning Gun #4 aboard USS Dobbin when Japanese aircraft attacked. Bomb fragments struck him, causing fatal wounds to his lungs, thorax, and heart. He died at just 24 years old.

Howard’s remains were returned to San Diego and interred at Greenwood Memorial Park. In 2017, Post Commander Paula Jansen and Auxiliary President LeAnna Brown placed a VFW marker at his grave.

Rowland Hampton Smith (1921–1941)

Caption: Rowland H. Smith, Musician First Class, USS Oklahoma.

Rowland was born June 17, 1921, in San Diego to Susan and Harry Smith, who adopted him as their only child. He graduated from Grossmont High School in 1939, where he played in the school band and ran track.

On October 6, 1939, Rowland enlisted in the Navy for six years. Standing 5’7”, with red hair and blue eyes, he served aboard USS Yorktown, USS Indianapolis, USS Arctic, and USS Rigel, before transferring to USS Oklahoma in September 1941. A talented musician, he played piano and bugle for the ship’s orchestra and advanced to Musician, First Class on November 1, 1941.

On December 7, 1941, USS Oklahoma was moored at Battleship Row when Japanese torpedoes struck. The ship capsized within 12 minutes, trapping hundreds of sailors. Of 429 killed, Rowland was among those lost. His remains were never individually identified and rest in a group burial at the National Memorial Cemetery of the Pacific. His name is engraved on the USS Oklahoma Memorial, dedicated on December 7, 2007, at Ford Island, Pearl Harbor.

Rowland was only 20 years old.

Shared Honors and Legacy

Both Howard Carter and Rowland Smith were posthumously awarded:

• Purple Heart
• American Defense Service Medal
• World War II Victory Medal
• Asiatic-Pacific Campaign Medal
• Combat Action Ribbon

Their sacrifice is the foundation upon which Carter-Smith VFW Post 5867 was built. Chartered in 1946, the Post became a cornerstone of the Lakeside community, with its building constructed by volunteers using bricks donated by El Cajon veterans. Today, the Post continues to honor their memory through service, camaraderie, and commitment to veterans and their families.

Why Their Story Matters

Howard and Rowland were ordinary young men who answered their country’s call and paid the ultimate price. Their names live on not only in the annals of history but in the heart of Lakeside—a reminder that freedom is never free.

Additional Images

• USS Dobbin at Pearl Harbor
  
  
• Caption: USS Dobbin (AD-3) moored near Ford Island during the attack on Pearl Harbor.
• USS Oklahoma Memorial
  Caption: The USS Oklahoma Memorial honors 429 sailors and Marines lost on December 7, 1941.