On August 10, 2026, a strong earthquake was felt across much of Colombia. Within minutes, hundreds of managers were asking themselves the same question: "if that had taken down the server, how long until we were operating again?" Most had no answer. Not because they lacked the technology, but because they never wrote a plan.
Hoping it won't happen isn't a strategy. A fire, a flood, a ransomware attack, or a simple disk failure can leave a company unable to operate for days. The difference between the companies that come back in hours and the ones that lose customers — or close — is rarely size. It's whether they had a business continuity and disaster recovery plan that was tested and up to date. This guide walks through the concepts every manager should understand before the day they actually need them.
Continuity, disaster recovery, and contingency: they're not the same
These three terms get used interchangeably, and they shouldn't be. Understanding them keeps you from buying the wrong thing.
Business Continuity Plan (BCP) — this is the umbrella. It answers the question: how does the business as a whole — not just IT — keep operating through a serious disruption? It covers people, processes, suppliers, sites, and technology. It's a business plan, not a technical one.
Disaster Recovery (DR) — this is the technology piece of the BCP. It answers: how do we recover IT systems, data, and services after a disaster? This is where backups, replication, alternate sites, and recovery times live.
Contingency plan — this is the most ambiguous term. In workplace health and safety, it usually refers to physical emergencies (evacuation, fires, earthquakes). In IT, an "IT contingency plan" is practically a synonym for disaster recovery. When someone asks for a "contingency plan," the first step is to clarify whether they mean the physical emergency or the IT recovery: these are different projects, with different owners.
In short: the BCP contains DR, and DR is what IT sometimes calls contingency. This article focuses on IT continuity and disaster recovery, which is where a technology support partner makes the difference.
RPO and RTO: the two metrics that define everything
You can't design a plan without first setting two numbers. Everything else — budget, technology, provider — follows from them.
RPO (Recovery Point Objective) — how much data can you afford to lose? If your RPO is 24 hours, your last good copy is from yesterday, and everything captured today is lost if the disaster hits right now. Transactional systems (billing, ERP) usually demand an RPO measured in minutes.
RTO (Recovery Time Objective) — how long can you go without operating? An RTO of 8 hours means the company has to be running again within 8 hours — not that the backup takes 8 hours to restore. It includes preparing the environment, restoring, validating, and handing access back to users.
These two numbers aren't technical decisions; they're business decisions. The lower they are (less data lost, less downtime), the more the solution costs. The job of the plan is to balance the cost of an outage against the cost of preventing it. If you want to dig into how RPO and RTO translate into a backup strategy, see our business backup guide, which covers the 3-2-1 rule, retention, and immutability in detail.
The phases of a business continuity plan
A continuity plan isn't a document you write once — it's a cycle you keep alive. These are its phases.
- Business Impact Analysis (BIA). You identify the critical processes and how much it hurts when each one stops (per hour, per day). This is where the per-system RPOs and RTOs come from.
- Risk assessment. Which threats are realistic for your company and location: ransomware, hardware failure, an extended power outage, flooding, an earthquake, human error.
- Recovery strategy design. For each critical system, how it gets recovered: immutable backup, replication to another site or to the cloud, an alternate site, temporary manual procedures.
- Plan documentation. Roles, owners, contacts, exact recovery steps, the priority order of systems. A plan that lives only in one person's head is not a plan.
- Testing. Drills and real restores. An untested plan is just a hypothesis.
- Maintenance and improvement. Every infrastructure change, every new system, and every failed test feeds the next version of the plan.
The minimum structure of a documented plan includes: scope, critical processes with their RPOs/RTOs, roles and chain of command, per-system recovery procedures, a contact directory (internal and vendors), and a testing calendar.
ISO 22301 and ISO 27001: the reference frameworks
Two international standards give this work structure, and they show up more and more in tenders and in the requirements of large clients in Colombia.
ISO 22301 is the standard for Business Continuity Management Systems (BCMS). It defines how to structure, run, and improve continuity in a systematic way. It's the reference point when the question is "which international standard establishes a continuity management system?"
ISO 27001 is the information security standard. It isn't a continuity standard, but it overlaps: its continuity domain requires recovery plans, and a solid DR strategy is direct evidence of compliance.
You don't have to get certified to benefit. Using these standards as a checklist — even without pursuing the seal — already raises the quality of the plan and makes it easier to answer clients who do require them. In Colombia, Law 1581 on personal data protection also mandates security and availability measures that a DR plan helps you support.
How to test a plan (and the most common mistakes)
Mistake number one is not testing at all. Number two is "testing" by only confirming that the backup ran, without restoring anything. A backup you've never restored is a backup that doesn't know whether it works.
A real test includes: restoring a system in an isolated environment, measuring how long it took (did it meet the RTO?), verifying that the data is complete and consistent (did it meet the RPO?), and documenting what failed so you can fix it. The reasonable minimum is a monthly restore drill of the critical systems and a full drill at least once a year.
Other frequent mistakes: backups sitting on the same network as production (ransomware wipes them out along with everything else), outdated plans that point to servers that no longer exist, and depending on a single person who "knows how it's done."
What it costs in Colombia
Estimated ranges in COP — every case is different. A documented continuity plan, with its BIA, for an SMB usually costs on the order of several million in setup, depending on complexity. The disaster recovery side — replication, immutable backup, an alternate site in the cloud — has a monthly component that for a mid-sized company (500 GB to a few TB, running Microsoft 365) usually lands somewhere between 1 and 3 million COP a month, depending on the RPO and RTO you require. Take it as a reference, not a quote: the real number depends on your critical systems and recovery times.
If someone offers you "continuity" or "disaster recovery" for far less, ask what's included: the most important part is almost always missing — the restore testing and the immutability — which is exactly what makes the plan work on the day you need it.
A plan you don't test doesn't exist
Continuity and disaster recovery aren't a product you buy once — they're a capability you build and maintain. Start with two numbers — how much data you can afford to lose and how long you can be down — and everything else is designed from there.
At mitecni we help companies in Colombia design, implement, and test their disaster recovery and continuity plan: BIA, per-system RPO/RTO, immutable backup, and real restore drills. If you want to know how long it would take your company to get back up and running today, explore our Disaster Recovery service or request a free assessment.