Backup, disaster recovery and business continuity.

Three layers of protection

Fire, flood, a failed data centre, a deleted database, a ransomware attack, a supplier that goes out of business: sooner or later every organisation loses something it depends on. Three related disciplines prepare for that day.

• Backup keeps copies of data and systems so they can be restored after loss or damage.
• Disaster recovery (DR) is the plan and capability to bring technology services back after a serious disruption: which systems, in what order, where, and by whom.
• Business continuity (BC) is wider. It keeps the organisation's most important activities going during and after a disruption, including people, premises, suppliers and manual workarounds, not only technology.

They depend on each other. A backup that cannot be restored in time is of little use to the recovery plan, and a recovery plan that brings systems back in the wrong order, or without the staff to run them, does not keep the business going.

A frequent failure is not having no backups. It is having backups that nobody has tried to restore, recovery plans written years ago for systems that have since changed, and continuity plans that live in a document nobody has read. The rest of this course is about avoiding those gaps.

How much loss can you accept?

Recovery planning starts with the business, not the technology. A business impact analysis looks at each important activity and asks what happens, and how quickly harm grows, if it stops: lost income, customers unable to pay or be paid, regulatory breaches, safety risks, damage to reputation.

The analysis also shows the longest each activity can be disrupted before the harm becomes unacceptable, often called the maximum tolerable period of disruption. Recovery must be quicker than that.

From it, two objectives are set for each important activity and the systems that support it:

• The recovery point objective (RPO): how much data, measured in time, you can afford to lose. An RPO of 15 minutes means that after a failure you must be able to recover the data as it was no more than 15 minutes before. It drives how often you back up or copy data.
• The recovery time objective (RTO): how long the service can be unavailable before it must be working again. It drives how you recover: restoring from backup, switching to a standby system, or both.

Tighter objectives cost more. A payments system may need an RPO close to zero and an RTO measured in minutes; an internal reporting tool may accept a day of lost data and a few days' downtime. Setting objectives by business need, rather than asking for "zero" everywhere, puts the money where it matters.

Remember the dependencies. A service can only be recovered as fast as the slowest thing it needs: its database, its network, its identity system, its keys and certificates, and the people who know how to restore them.

Backups that survive

A long-standing rule of thumb is 3-2-1: keep at least three copies of important data, on two different types of storage, with one copy away from the main site. Because attackers now deliberately seek out and destroy backups, many organisations extend it: at least one copy that is offline or immutable, meaning it cannot be changed or deleted for a set period, ideally not even by an administrator, and backups checked to restore without errors.

Good backup practice also means:

• Back up everything needed to rebuild, not only data: system configurations, the code or images used to build servers, encryption keys stored securely and separately, and records of how it all fits together.
• Protect backups like production. Encrypt them, limit and monitor who can reach them, and use separate credentials, so that an attacker who takes over the main network cannot also delete the backups.
• Know what your cloud and software providers do and do not do. Under the shared responsibility model, a provider keeps its platform running, but protecting your data from deletion, corruption or an attack on your own account is often your responsibility. Check the contract rather than assuming.
• Test restores regularly, and time them. A restore test is the only real proof that a backup works, and timed restore and failover tests are how you learn whether the recovery time objective can be met.

Backups contain the same personal data as live systems, so data protection rules apply to them too. In Kenya, the Data Protection Act, 2019 applies. Section 41 asks organisations to consider measures such as encryption and the ability to restore personal data in a timely manner after an incident. Section 39 says it should be kept no longer than necessary. Section 42 requires a written contract with any provider that processes it for them.

Recovering technology

A disaster recovery plan turns objectives into action. It says, for each important system, how it will be brought back, in what order, by whom and where.

Common recovery approaches, from cheapest and slowest to most expensive and fastest:

• Backup and restore: rebuild systems and restore data from backups, often into a secondary site or cloud. Cheap to maintain, slowest to recover.
• Standby (sometimes called pilot light, warm standby or a warm or hot site, depending on how ready it is): a second environment is kept partly or fully ready and receives regular copies of data, so it can take over faster.
• Active-active: the service runs in two or more locations at once, and one can carry the load if another fails. Fastest, and the most complex and costly.

Replication and active-active copy mistakes, corruption and ransomware encryption as quickly as they copy good data, so they do not replace point-in-time backups.

A usable plan contains:

• The recovery order, following dependencies: identity, networks and core databases usually come before the applications that need them.
• Step-by-step runbooks that someone other than the author can follow under pressure.
• Contact details and decision rights: who declares a disaster, who approves switching to the standby site, who speaks to customers.
• Access that still works when the main systems are down, including a copy of the plan itself held outside the systems it describes.

After a cyber attack, check that restored systems and backups are free of the attacker's tools, and that stolen passwords and keys have been changed, before reconnecting them; otherwise the attack can start again.

And the plan includes coming back: moving operations back to the main site safely after the emergency, without losing the data created in the meantime.

Keeping the business running

Technology recovery is one part of business continuity. A continuity plan also covers:

• People: what happens if key staff cannot reach the office or are unavailable, and who can stand in for them.
• Premises: alternative places to work, and working from home.
• Suppliers: which outside services are critical, what their own continuity arrangements are, and what you would do without them.
• Manual workarounds: how essential activities can continue, at least partly, while systems are down.
• Communication: how staff, customers, regulators and the public will be informed, and by whom.

The international standard for a business continuity management system is ISO 22301:2019 (amended in 2024), which organisations can be certified against. A revised edition is being drafted, so check which version applies before planning a certification. Regulators also set expectations. In Kenya, for example, the Central Bank of Kenya's Guideline on Business Continuity Management (CBK/PG/14) expects banks to carry out a business impact analysis, set recovery time and recovery point objectives, and test their continuity arrangements at least once a year, and CBK's cybersecurity guidance for banks and payment service providers expects regular backups and tested recovery plans. In September 2026 CBK published revised draft prudential and risk management guidelines for public comment, and other sectors have their own regulators, so check the current rules that apply to you.

Plans only work if they are exercised:

• Tabletop exercises: the team talks through a realistic scenario, such as ransomware on a Monday morning, and finds the gaps in the plan.
• Technical tests: restoring systems from backup and switching to the standby site for real, then timing the results against the objectives.
• Review after every exercise, every real incident and every significant change to systems, suppliers or staff, updating the plan, the contact lists and the runbooks.

A plan that has never been tested is an assumption. Testing turns it into a capability.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.