Disaster Recovery Is Not Just About Data — Can Your Team Still Work?

When engineers talk about disaster recovery, the first topic is usually data.

Backups.
Replication.
Snapshots.
Cloud storage.
Recovery points.

All of those matter.

But there is another failure mode that is easy to overlook:

Your data survives, but nobody can reach the systems needed to work.

That is the gap between data recovery and business continuity.

Imagine the office disappears from the network

Consider a small company with one office.

The office contains:

• employee PCs
• network equipment
• a VPN gateway
• perhaps a NAS or file server
• access paths to private systems
• a public IP address used in allowlists

Then something happens.

A flood.

A fire.

An earthquake.

A prolonged power outage.

Or simply an ISP failure that lasts much longer than expected.

The company has already moved its important files to cloud storage.

So the data survives.

That is good.

But the next morning, employees are working from home, a temporary office, a hotel, or another branch.

Now a different question appears:

How do they actually get back to work?

If the answer still depends on the original office network, the recovery plan has a hidden dependency.

"But we already use Microsoft 365"

For some businesses, this really does solve most of the problem.

If almost everything your team uses is SaaS and securely accessible from anywhere, losing the office network may have relatively little impact.

But many environments still contain systems such as:

• private cloud applications
• internal administration tools
• development environments
• databases that should not be exposed to the public Internet
• supplier or partner systems protected by IP allowlists
• legacy applications reachable only through a private network

In those environments, protecting the data is only half of the problem.

The other half is reachability.

Your office IP can be a hidden dependency

IP allowlists are a good example.

Suppose an administration system only accepts connections from your office public IP.

Normally:

Employee
   |
   v
Office Network
   |
   v
Office Public IP
   |
   v
Admin System

The source IP is known, so the system allows the connection.

This can be useful as an additional access-control layer when combined with proper authentication, MFA, and application-level authorization.

But now imagine the office Internet connection disappears.

An employee working from home has a completely different public IP.

Employee
   |
   v
Home Internet
   |
   v
Different Public IP
   |
   X
Admin System

The application is still running.

The credentials still work.

The data is still safe.

But the employee cannot access it.

That means a BCP plan may need more than data backups.

It may also need a backup network path and, depending on the system, an alternative Internet exit.

Alternative exits need preparation too

You cannot wait until the disaster happens and then decide which IP address should be trusted.

If a partner system or administration console uses an IP allowlist, the backup exit IP should be registered before it is needed.

For example:

Primary Office IP
        +
Backup Site IP
        |
        v
    IP Allowlist

If the workflow requires a stable source IP, the backup connection must also provide one.

The backup exit could be:

• another company location
• a secondary office
• a temporary recovery site
• a cloud-hosted environment

The right answer depends on the business.

The important part is that the alternative path exists and has already been tested.

Stop treating the office as the center of the network

A traditional small-office architecture often looks like this:

Remote User
     |
     v
 Internet
     |
     v
Office VPN Gateway
     |
     v
Office LAN
     |
     v
Business Systems

This works.

But the office is doing a lot of jobs.

It is:

• the workplace
• the VPN endpoint
• the network gateway
• sometimes the Internet exit
• sometimes the place where business systems live

That creates a large blast radius when the office goes offline.

A different architecture is to make the office just one place from which people connect.

For example:

Home --------\
Branch -------\
Mobile --------> Private Network ---> Cloud VPC ---> Business Systems
Office -------/

Now the cloud environment can remain available even if the office disappears.

The office is still useful.

It just stops being a requirement for the rest of the company to operate.

Recovery should be a change of location, not a network rebuild

Imagine the office is unusable and several employee laptops were damaged too.

You ship temporary PCs to employees.

That sounds simple, but a replacement laptop is not automatically a working environment.

You may still need to:

• install required software
• enroll the device
• distribute credentials
• recover MFA access
• install the VPN client
• validate endpoint security
• confirm access to private systems

This is why the best BCP test happens before the disaster.

The goal should not be:

Build the emergency network when the emergency happens.

It should be:

Use the same access architecture during normal operations, so the emergency changes the employee's location rather than the entire network design.

For example:

Normal day:

Office / Home
      |
      v
Private Network
      |
      v
Cloud Systems


Disaster day:

Temporary Location
      |
      v
Same Private Network
      |
      v
Same Cloud Systems

That is a much easier recovery model to practice.

Outbound connectivity changes the recovery requirements

There is another practical issue: inbound connectivity.

A traditional self-hosted VPN often assumes something like this:

Internet
   |
   v
Public IPv4
   |
   v
Port Forward
   |
   v
VPN Server

That can work perfectly well.

But at a temporary or backup location, you may not control those conditions.

You might encounter:

• CGNAT
• IPv4 over IPv6
• double NAT
• a building-wide upstream router
• an ISP that does not provide directly reachable IPv4
• firewall policies you cannot change

This is why outbound-oriented network designs can be useful for BCP.

Instead of requiring the recovery site to accept inbound VPN connections, the recovery site establishes an outbound connection to the VPN infrastructure.

That reduces the number of network assumptions that need to be recreated during recovery.

Where HomeGrid VPN fits

Full disclosure: I'm the founder of HomeGrid VPN.

HomeGrid VPN is one implementation of this model.

It uses a Hub & Spoke architecture in which devices, locations, and cloud environments connect outbound to a Cloud Hub.

A cloud environment can participate in the same private network as remote users and other locations.

Conceptually:

Home --------\
Branch -------\
Mobile --------> Cloud Hub ---> Cloud VPC
Office -------/                   |
                                  v
                           Business Systems

The Cloud Hub is part of the VPN path.

It is not necessarily the Internet exit.

That distinction is useful because private access to a cloud VPC and Internet egress are two different problems.

For example, an organization could use:

Employee
   |
   v
Cloud Hub
   |
   +------> Cloud VPC
   |
   +------> Selected Internet Exit

If a workflow depends on a specific source network or public IP, another location can be selected as the Internet exit.

That alternative IP still needs to be prepared in advance if external systems use allowlists.

For HomeGrid VPN, Cloud VPC connectivity is available with the Platinum plan (dedicated server plan).

The architecture does not eliminate infrastructure dependencies.

HomeGrid VPN still depends on its Cloud Hub and on Internet connectivity to reach it.

What changes is that the organization does not have to make one physical office the center of every access path.

Cold standby can be enough

Not every small company needs automatic failover.

In fact, automatic network failover adds its own complexity.

For many small businesses, a cold standby design can be reasonable.

For example:

Normal:

Office Exit
    |
    v
Internet


Emergency:

Backup Exit
    |
    v
Internet

The backup site does not have to carry production traffic every day.

It only needs to be:

• configured
• reachable
• tested
• approved by any required IP allowlists

When the primary location fails, an administrator can switch to it manually.

Simple recovery processes are often easier to understand and test than highly automated systems that are rarely exercised.

Three questions worth testing

You can learn a lot about your BCP architecture without simulating an earthquake or flooding the office.

Try asking:

1. What breaks if nobody can enter the office tomorrow?

Do not start with servers.

Start with business processes.

Which systems become unavailable?

Which workflows require the office network?

2. Which systems depend on the office public IP?

Look for:

• partner portals
• administration systems
• cloud firewalls
• IP allowlists
• database access rules
• third-party APIs

If you need a backup Internet exit, register its IP before the incident.

3. Can the company operate for one day without the office network?

Actually test it.

Have a small group work from home or another location.

Do not let them use the office LAN.

See what fails.

The interesting problems are often not the ones documented in the BCP spreadsheet.

They are the dependencies nobody remembered were dependencies.

The real BCP question

A disaster recovery plan should absolutely answer:

Is our data safe?

But there is another question worth asking:

If employees cannot enter the office tomorrow, how many steps stand between them and being able to work again?

If the answer requires:

• rebuilding the office LAN
• replacing a VPN appliance
• recovering a particular public IP
• recreating firewall rules
• changing employee access methods

then the business may still be more dependent on the office than it appears.

A better goal is not to make the office unnecessary.

It is to make the office replaceable.

Because disaster recovery is not just about preserving data.

It's about keeping the business connected.