Backups
What is genuinely covered, at what frequency, and — critically — whether the backup system can be reached and destroyed using credentials that a ransomware operator would obtain along the way.
Business Continuity
Business Continuity & Resilience
Recovery that has been tested rather than assumed — and a realistic answer to how long your business would be down.
The problem
A backup is a job that runs. Recovery is a capability.
Most organisations have the first and have never verified the second. The gap between them only becomes visible on the worst possible day.
The common pattern is a nightly job reporting success for years, a continuity document containing a recovery time somebody estimated once, and no test to connect the two. The backup is usually protecting a database. The business needs an application, its configuration, its integrations, the server it runs on and the people who know how it fits together.
There is a second, sharper problem. Backups reachable with production credentials are not protection against ransomware, because a competent attacker will have those credentials before they encrypt anything. Deleting the backups first is standard practice, not an unlucky outcome.
What we provide is evidence in place of assumption: measured recovery times, a backup architecture that survives a compromise of your network, and a plan the senior team has actually read.
What changes
- Recovery time
- Measured by test, not estimated
- Backup reach
- Isolated from production credentials
- Coverage
- Application layer, not just the database
- Microsoft 365
- Gap identified and addressed if justified
- Runbooks
- Followable by someone other than the author
- Rehearsal
- Tabletop exercise with the senior team
Scope
What a resilience engagement covers
Scope follows the criticality ranking agreed at the start. Protecting everything equally is how continuity budgets get spent in the wrong places.
Recovery
The distinction that matters: a backup is a job that runs, recovery is a business capability. We establish what it would actually take to get each system back, in order, with the people available.
Ransomware resilience
Immutable or credential-isolated copies, segmentation, privileged access reduction, and the assumption that the attacker had access for weeks before encryption rather than minutes.
Microsoft 365 data
Retention and recycle bins are not backup in the sense most businesses assume. We set out exactly what the platform recovers, what it does not, and whether the gap justifies independent backup for your obligations.
Recovery testing
An actual restore into an isolated environment, timed and documented. Almost every first test reveals a missing component — usually configuration or an integration rather than the database everyone worried about.
Critical systems
A ranked list of what the business genuinely cannot operate without, agreed with operations rather than assumed by IT, including the dependencies that only become visible when something stops.
Recovery planning
Realistic recovery time and recovery point objectives, measured rather than aspirational, and an honest comparison against what the business currently expects.
Documentation
Runbooks that a competent person could follow at 3am without the individual who built the system — held somewhere still reachable when the network is down.
Supplier dependencies
Which third parties you depend on to keep operating, what their own resilience looks like, what your contract actually commits them to, and who you would call.
Incident response
Who decides, who communicates, who to notify and in what order, what to say to customers, and what to do in the first hour — rehearsed before it is needed.
Recovery testing
The test is the point
Everything else in a continuity engagement is preparation for one exercise: restoring a critical system into an isolated environment, timing it, and writing down what went wrong.
It is uncomfortable, and it is the only part that produces a number you can rely on. A documented four-hour recovery objective that has never been attempted is a statement of hope. A measured figure — even an unwelcome one — lets the board make a real decision about what to spend.
Tests are run outside business hours where necessary, in an isolated environment, with no effect on production. The output is a timed sequence, a list of what was missing, and a corrected runbook.
What first tests commonly reveal
- Application configuration was never in scope, only the database
- Integration credentials and certificates were not captured
- The restore depends on a person who no longer works there
- The runbook lives on the system being recovered
- Licensing or activation blocks a rebuild
- The measured time is several times the documented objective
Process
How a continuity engagement runs
Ranking first, because it determines everything else. Protecting all systems to the same standard is neither affordable nor necessary.
- 01
Establish what matters
A short workshop with operations and finance to rank systems by business impact over time. Not every system needs the same protection, and pretending otherwise is expensive.
- 02
Review what exists
Backup coverage, storage architecture, credential exposure, retention and the Microsoft 365 position — assessed against the ranking rather than in isolation.
- 03
Test recovery for real
A timed restore of at least one critical system into an isolated environment, documenting every gap. This is where assumptions meet evidence.
- 04
Close gaps and rehearse
Fix what the test exposed, write the runbooks, and run a tabletop exercise with the senior team so the plan has been read before it is needed.
Reassurance
Proportionate, and without the fear-based sales pitch
Resilience is routinely sold on statistics about how many businesses fail after a cyber incident. We do not find that useful, and it tends to produce either paralysis or an over-specified purchase.
The better approach is arithmetic. If your core system were unavailable for three days, what would that cost — in lost revenue, in staff unable to work, in contractual exposure, in the effort of reconstructing what was lost? Set that against the cost of reducing three days to four hours. Sometimes the investment is obviously justified. Sometimes the honest conclusion is that three days is survivable and the money belongs elsewhere.
Either answer is a legitimate outcome. What is not legitimate is not knowing which one applies to you.
FAQ
Business continuity: common questions
Our backups run every night and report success. Is that not enough?
It tells you a job completed. It does not tell you whether the right things were included, whether the backup can be reached and deleted by an attacker who has compromised your network, or how long a full recovery would take. In our experience the first recovery test almost always reveals a missing component — commonly application configuration or an integration rather than the database itself.
Does Microsoft back up our Microsoft 365 data?
Microsoft protects the platform and provides retention policies, recycle bins and litigation hold. Those cover a good deal of accidental deletion. They do not amount to a backup you control, and recovery of data deleted or maliciously altered outside those windows is limited. Whether that gap justifies third-party backup depends on your regulatory obligations and how much history you would need to reconstruct — we give you the specifics rather than a blanket recommendation.
How often should recovery be tested?
At least annually for critical systems, and after any significant change to the environment. The first test is the valuable one; subsequent tests are largely confirming that the documented process still matches reality. A test that has never been performed is an assumption, however well the backup software is configured.
What is the difference between RTO and RPO, in practical terms?
Recovery time objective is how long the business can operate without a system. Recovery point objective is how much recent data it can afford to lose. They drive different technical decisions and cost money in different ways, and the useful exercise is agreeing them with the people who run the business rather than with IT.
Do we need a formal business continuity plan document?
You need something people would actually use under pressure, which for most SMEs is a short set of runbooks, a critical systems list and a one-page incident plan with names and numbers. A long formal document has value where a client contract or standard requires one, but it is not what gets you operating again.
Can you help during an active incident?
We can help with containment, assessment and recovery co-ordination, and we work alongside your insurer's appointed responders where a policy is in place. Existing clients get priority. Be aware that if you hold cyber insurance, most policies require you to notify the insurer before engaging anyone, so that call should come first.
Find out how long you would really be down.
A short conversation establishes whether your current position is defensible. If it is, we will say so and you will have spent nothing.