Most businesses know they need backups.

That's not really the problem anymore.

The more important question is:

Could you actually recover from them?

Imagine arriving at work tomorrow and discovering that:

• your server won't start
• important files have been encrypted by ransomware
• somebody deleted a critical SharePoint folder
• a Microsoft 365 account has been compromised
• a database has become corrupted
• a laptop containing important work has been stolen
• your main business application is unavailable

You contact whoever manages your backups.

Then comes the question that really matters:

“When was the last successful restore test?”

If nobody knows the answer, you don't yet know whether you have a recovery strategy.

You simply have backups.

And those are not the same thing.

Backup and Recovery Are Different

A backup is a copy of your data.

Recovery is your ability to use that copy to restore the business to an acceptable operational state.

That distinction is critical.

A backup system can report:

SUCCESS

every night while still leaving you unable to recover properly.

Why?

Perhaps:

• important folders were excluded
• the database wasn't backed up correctly
• retention was too short
• backup credentials were compromised
• ransomware encrypted the backups
• nobody knows the recovery procedure
• the restore takes three days
• an application licence or configuration is missing
• the backup itself is corrupted

A green tick tells you a backup job ran.

A successful restore tells you the backup works.

What Should a Business Back Up?

Start with a deceptively simple question:

What information and systems does the business actually need to operate?

The NCSC recommends identifying the data your organisation needs and making backups of it. Examples include email, websites, invoicing information, documents, presentations, contacts and customer information.

For a typical SME, that could include:

• Microsoft 365 data
• SharePoint
• OneDrive
• email
• accounting data
• CRM information
• customer records
• databases
• shared files
• server data
• application configuration
• virtual machines
• website data
• line-of-business applications
• device configurations

Don't start by asking:

“Which backup product should we buy?”

Start with:

“What would stop us operating if we lost it?”

Then make sure the backup strategy protects it.

Synchronisation Is Not the Same as Backup

This causes enormous confusion.

OneDrive is excellent.

SharePoint is excellent.

Cloud synchronisation is incredibly useful.

But synchronisation and backup perform different jobs.

Suppose a file is corrupted and the change synchronises.

The corrupted version may synchronise too.

Suppose somebody with sufficient permissions deletes information.

That deletion may propagate.

Suppose an attacker gains control of an account.

They may be able to manipulate the cloud data the user can access.

Cloud platforms frequently provide versioning, recycle bins and retention features, and these can be extremely useful recovery mechanisms.

But don't assume:

“It's in the cloud, therefore our backup strategy is complete.”

The NCSC specifically warns organisations to ensure previous file versions are protected from accidental or malicious deletion and notes that cloud synchronisation can propagate encrypted files.

Understand exactly what your cloud platform protects, for how long, and how you would recover from different scenarios.

The 3-2-1 Backup Rule

A useful starting point remains the 3-2-1 rule.

The NCSC describes it as:

3 copies of important data

on:

2 devices/storage types

with:

1 copy offsite.

For example:

Production data

local backup

separate cloud/offsite backup

This helps protect against scenarios such as:

• hardware failure
• theft
• fire
• accidental deletion
• ransomware
• local storage failure

But 3-2-1 alone isn't enough for modern ransomware.

There is another question:

Can an attacker destroy all three copies?

Ransomware Changed the Backup Conversation

Older backup strategies were often designed primarily around hardware failure.

A server dies.

Replace it.

Restore yesterday's backup.

Modern ransomware creates a different problem.

Attackers understand backups too.

The NCSC says attackers may target backup systems early in destructive ransomware attacks, deleting or destroying backup data specifically to make recovery more difficult and increase pressure on the victim.

That means a backup connected to the same environment, accessible using the same compromised administrator credentials and deletable by the attacker may not provide the protection you think it does.

Modern backup planning therefore needs to consider:

Can the backup survive an attacker who actively wants to destroy it?

Keep a Backup Isolated

The NCSC recommends offline backups that are kept separate from normal systems or an appropriately designed cloud service.

Traditionally, this might mean:

• removable storage disconnected after backup
• tape stored securely elsewhere
• storage isolated from the production network

Modern cloud backup systems can achieve similar protection through logical separation and access controls.

The important principle is:

A compromise of the production environment shouldn't automatically give an attacker the ability to destroy every recovery copy.

The NCSC's ransomware-resistant backup principles specifically recommend making on-premises backup solutions capable of being isolated from the wider environment.

Immutability Matters

Another important concept is immutable backup storage.

In simple terms, once backup data has been written, it cannot simply be altered or deleted during its protected retention period.

That's valuable against ransomware.

Imagine an attacker compromises an administrator account.

They encrypt production data.

Then they try to delete the backups.

If the attacker can simply select:

Delete all backups

your recovery strategy may disappear with your production environment.

A ransomware-resistant backup architecture should make destructive actions significantly more difficult.

The NCSC's cloud backup principles recommend mechanisms that protect backups against deletion or alteration and allow recovery from previous versions even when newer backup data becomes corrupted.

Protect the Backup System Itself

Your backup platform is one of the most valuable systems in the company.

Treat it accordingly.

Protect:

• administrator accounts
• backup consoles
• storage credentials
• encryption keys
• management interfaces
• deletion permissions

Use strong authentication and least privilege.

Don't give every administrator unrestricted access to backup deletion simply because that's convenient.

The NCSC specifically recommends restricting access to credentials and servers used for backups because attackers may target backups to obtain information or destroy the organisation's ability to recover.

Backup security is part of cybersecurity.

Retention Matters More Than “Last Night Was Successful”

Imagine ransomware entered your network three weeks ago.

You discover it today.

Your backup platform keeps:

seven days of backups.

Every backup you have may therefore contain the problem.

This is why retention matters.

The NCSC recommends retaining backup history rather than relying on a single rolling copy and notes that organisations should consider how long a compromise could exist before being detected.

A business might choose a structure such as:

• frequent recent backups
• daily backups retained for several weeks
• monthly backups retained for longer periods

The exact policy depends on:

• business requirements
• available storage
• regulatory obligations
• data-change frequency
• risk
• recovery requirements

The key principle is:

Keep enough history to recover to a known-good point before the problem began.

RPO: How Much Data Can You Afford to Lose?

Backup frequency shouldn't be chosen arbitrarily.

Ask:

How much work could we afford to lose?

This is your Recovery Point Objective, or RPO.

Suppose your accounting system is backed up once every night.

If it fails at 4:30pm, you may lose almost an entire day's changes.

Can the business tolerate that?

If yes, a daily backup may be adequate.

If losing four hours would be unacceptable, you need a shorter RPO.

Different systems can have different requirements.

For example:

Archive: 24 hours may be acceptable.

Shared documents: perhaps several hours.

Critical transactional database: potentially minutes.

Don't buy backup capacity first and then let it dictate your recovery requirements.

Define the business requirement first.

RTO: How Long Can You Afford to Be Down?

The second important measurement is Recovery Time Objective, or RTO.

Ask:

How long can this system be unavailable before the impact becomes unacceptable?

An organisation may technically have a backup but discover that restoring it requires:

48 hours.

If the business can only tolerate four hours of downtime, that backup design doesn't meet the requirement.

Again, different systems may have different priorities.

Your customer database might need to return first.

An old archive server might be able to wait.

Recovery planning therefore isn't simply:

“Restore everything.”

It's:

“Restore the most important services in the correct order.”

Test Your Restores

This is the section I would consider the most important in the article.

Test your backups.

The NCSC repeatedly recommends regular restore testing and monitoring of backup health.

Don't simply check that the backup dashboard is green.

Actually restore something.

For example:

• restore a deleted file
• restore a folder
• recover a mailbox item
• restore a database into a test environment
• recover a virtual machine
• perform an application-level recovery
• test a complete disaster-recovery scenario

Record:

Did it work?

How long did it take?

Was anything missing?

Who performed it?

Could somebody else follow the procedure?

Did the recovery meet the RTO?

Until you've successfully restored something, you're relying on an assumption.

Monitor Backup Failures

Backups should not be something somebody checks occasionally.

A failed backup should generate an alert.

Repeated failures should be investigated.

Monitor:

• backup success
• missed backups
• storage capacity
• unusual deletion activity
• repository health
• retention
• protected-device coverage
• security events

The NCSC's ransomware-resistant principles also recommend alerting when significant changes or privileged actions occur within backup systems.

For a managed business environment, IT should know a backup failed before the user needs to restore from it.

Don't Forget Laptops

Traditional backup strategies often concentrated on servers.

But employees increasingly store information on:

• laptops
• OneDrive
• SharePoint
• Teams
• SaaS applications

Ask where users are actually saving business information.

If important files exist only in:

C:\Users\Sarah\Documents

on one laptop, the business may have a gap.

Good device management should encourage or enforce approved storage locations and ensure important information is protected appropriately.

Don't Forget Microsoft 365 and SaaS

Another common assumption is:

“Microsoft has the data, so we don't need to worry about recovery.”

Microsoft provides extensive resilience, retention and recovery capabilities.

But businesses still need to understand:

• what is protected
• retention periods
• deleted-item recovery
• version history
• account compromise scenarios
• malicious deletion
• regulatory requirements
• how long recovery takes

The same principle applies to:

• CRM systems
• accounting platforms
• cloud file storage
• HR systems
• project-management platforms

SaaS does not eliminate your responsibility to plan for data recovery.

Back Up Configuration, Not Just Documents

Imagine your firewall fails completely.

You have a replacement unit.

Do you have the configuration?

What about:

• network configuration
• server configuration
• virtual machine configuration
• critical application settings
• scripts
• certificates
• infrastructure documentation

The NCSC specifically recommends considering backups of system configurations as part of recovery planning.

Recovering data is useful.

Recovering the environment required to use that data can be just as important.

A Backup Isn't Business Continuity

Backups form part of business continuity and disaster recovery.

They aren't the whole plan.

Suppose your office burns down.

Your offsite backup survives.

Excellent.

But:

• where will employees work?
• where will replacement equipment come from?
• who has access to backup credentials?
• how will communications operate?
• which services get restored first?
• who contacts customers?
• how will internet connectivity be restored?

Backup answers:

“Can we recover the data?”

Business continuity asks:

“Can the organisation continue operating?”

You need both.

What About Ransomware Recovery?

If ransomware strikes, don't immediately connect your backup repository and start restoring files onto compromised systems.

First establish that the environment is clean.

The NCSC recommends confirming that backup data is free from malware and restoring only to devices and networks you are confident are clean.

Otherwise, you risk:

restore → reinfection → encrypt everything again.

Recovery needs to be coordinated with incident response.

The Backup Questions Every Business Should Be Able to Answer

Ask whoever manages your IT:

1. What exactly are we backing up?
2. What aren't we backing up?
3. How frequently are backups taken?
4. How long are they retained?
5. Where are they stored?
6. Could ransomware reach them?
7. Can an administrator delete every backup?
8. How are backup accounts protected?
9. When did a backup last fail?
10. When was the last successful restore test?
11. How long would a full recovery take?
12. How much data would we lose?
13. Who is responsible for recovery?
14. What gets restored first?

If the answer to most of those is:

“I'm not sure.”

the business needs a backup review.

A Practical Backup Strategy for SMEs

There is no single architecture suitable for every organisation, but a strong starting point is:

Identify critical systems and data

↓

Define RPO and RTO

↓

Create multiple backup copies

↓

Keep at least one appropriately separated/offsite copy

↓

Protect backups against deletion and ransomware

↓

Use appropriate retention

↓

Protect backup administration

↓

Monitor every backup

↓

Test restores regularly

↓

Document recovery procedures

↓

Review the strategy as the business changes

That's considerably stronger than:

“We have a USB drive plugged into the server.”

How Hamilton Group Can Help

Hamilton Group helps businesses design backup and disaster-recovery strategies around recoverability, not simply whether a backup job displays a green tick.

We can help with:

• cloud backup
• Microsoft 365 data protection
• server backup
• workstation protection
• ransomware-resistant backups
• backup monitoring
• restore testing
• disaster recovery
• business continuity
• virtual machine protection
• infrastructure recovery
• cyber security
• managed IT support

We can also help businesses define realistic Recovery Point Objectives and Recovery Time Objectives, so the backup system is designed around what the organisation actually needs.

Because the question isn't:

“Do you have a backup?”

It's:

“If everything stopped tomorrow morning, could you recover—and how long would it take?”

Visit or call 0330 043 0069 to discuss backup, disaster recovery and business continuity.