The three corrective actions the previous lesson closed on — immutable backups in a separate account, a quarterly restore test and a deletion alert — are not incident response: they are another discipline. The response plan tells you how to act when the diaries of 40 clinics are at a standstill, but not how long they can be at a standstill before the business cannot take it, nor how much data you can afford to lose, nor how Rubén and the clinics carry on serving people while the system is down, nor how long a restore that nobody has ever timed really takes. This lesson answers those four questions and closes the module with the artefact that in 02-06 would have changed the outcome more than any other: a verified backup.

1. Business continuity and disaster recovery: two different plans
2. The business impact analysis (BIA)
3. RTO and RPO: what they are, how they are set and what they cost
4. Backup strategies
5. The restore test: the heart of the lesson
6. The ransomware scenario, which breaks the classic plans
7. High availability is not a backup
8. The written plan: DRP and emergency procedures
9. Testing the plan, and cadence
10. Metrics and continual improvement

They are complementary and not interchangeable. An excellent DRP with no BCP means that during the 12 hours of recovery the clinics can do absolutely nothing and lose their patients; an excellent BCP with no DRP means you can cope by hand for a few days, but nobody knows when the system will come back or whether the data still exists.

And a point of vocabulary: in this context "disaster" does not mean earthquake. For an SME like Nimbus the realistic disasters are, in order of likelihood: ransomware, a mass accidental deletion, a prolonged outage at the cloud provider, a migration error that corrupts data and, a long way behind, a fire at the office. The plan is written against the first ones, not the last.

The BIA (Business Impact Analysis) is the mandatory starting point, and it answers a single question per process: if this stops, how much does it hurt and from when? Without a BIA, recovery objectives are set by intuition or by what the technology already does, which is exactly the wrong way round.

You identify business processes, not systems. The system is the means; the process is what the customer pays for.

The MTPD (Maximum Tolerable Period of Disruption) is the longest the business can bear that process being interrupted before suffering harm that can no longer be repaired. Three rules for setting it properly:

• The business sets it, not technology. Marta and Rubén know at what point a clinic starts ringing its patients to reschedule; Lucía does not.
• Not everything is critical. If every process in your BIA has an MTPD of 1 hour, you have not done a BIA: you have made a wish list, and the result will be that nothing gets prioritised.
• Impact is not linear. Look at the table: two hours of outage are an inconvenience and twenty-four are a crisis. That is why the BIA is measured in bands, not with a single number.

One observation about the Nimbus case worth internalising: the most critical process (bookings, MTPD of 4 h) is not the one that handles the most data, and the one that handles the most sensitive data (history and attachments) tolerates considerably more disruption. Confidentiality and availability have different priorities, which is why the risk register in 04-01 gave the outage a higher ALE than the leak despite it being far less serious per event.

• RPO (Recovery Point Objective): how much data you can afford to lose, measured in time. An RPO of 1 hour means that, in the worst case, you lose the last hour's work. It is determined by the backup frequency.
• RTO (Recovery Time Objective): how long you can take to come back. It is determined by the architecture and the procedure, and it must always be less than the MTPD.

The difference between asynchronous and synchronous replication deserves a sentence: with asynchronous replication the write is acknowledged to the client before it reaches the copy, so it is fast and may lose the last few seconds; with synchronous replication nothing is acknowledged until both copies have it, which guarantees an RPO of zero at the cost of latency on every write and of a problem in the secondary zone degrading the primary.

Nimbus's objectives, derived from the BIA and not from wishful thinking:

And the rule that avoids the circular conversation: RTO and RPO are derived from the MTPD in the BIA, and only then do you check whether the budget allows them. If it does not, you do not change the number on the sheet: you document the gap as an accepted risk in the 04-01 register, with a signature. An RTO committed to a customer and not achievable is, as well as a lie, a breach of contract.

A typical and sensible scheme for Nimbus: a weekly full backup, a daily incremental and continuous shipping of the PostgreSQL transaction log — the last of these is what makes a 15-minute RPO possible, because it enables point-in-time recovery.

It already appeared in 02-04; here it is developed, because each digit answers a different failure:

The last two digits are what separate this rule from the classic 3-2-1, and they are exactly the ones Nimbus was missing in 02-06. The fourth digit — immutability — is what prevents the deletion at 02:10 on day 20; the fifth — verification — is what would have revealed, weeks earlier, that the only alternative copy was an external disk five weeks old that nobody had tested.

There is one nuance about immutability that decides its effectiveness: it must be in an account whose credentials production does not know, and with retention locked in such a way that not even the administrator can shorten it during the period set. If the same set of credentials that manages production can turn off the retention, immutability is a label, not a control.

Retention and versioning. Nimbus keeps: 7 daily copies, 4 weekly, 12 monthly and 1 annual. Long retention is not a whim: silent corruption or a logical deletion can be discovered weeks later, and with only seven days of retention the problem has already been replicated to every copy.

Encrypting the backup, with the key outside the environment (03-07). Backups contain the same data as production and travel to less closely watched places, so they go encrypted. And the key cannot be where the encrypted thing is: if the backup key lives in the same secrets manager the attacker already controls, encryption contributes nothing against double extortion. Separate custody, with a tested key recovery procedure — losing the backup key is losing the backup.

What is backed up besides the data, which almost nobody includes: the infrastructure configuration (ideally as code, versioned in the repository), the definition of the cloud resources, the secrets — encrypted and held separately — the certificates, the identity provider configuration and the recovery documentation itself. Restoring a database without being able to rebuild the infrastructure that serves it stretches the RTO by days.

And what a backup does NOT cover. This is the part that produces surprises: replicated logical deletion — if you delete a row and the copy synchronises, the copy deletes it too; propagated corruption, when an application error has spent weeks writing incorrect data that every copy faithfully contains; data that lives only in a SaaS that nobody exports; and schema changes, because a six-month-old backup may not be restorable into the current application without a migration process.

An unverified backup is not a backup: it is a hope. That sentence sums up the entire module, and in the 02-06 case it was literal: a backup existed and it was no good. The three things you only discover by genuinely restoring are that the file is intact and readable, that the procedure works with the documentation that is actually written down, and how long it really takes — which is always longer than the estimate.

Five decisions in the script that are matters of method. It is timed, because the most valuable output of the test is not "it worked" but "it took 55 minutes" compared with the committed RTO. The hash is verified before restoring, so you do not discover the corruption halfway through. The row count is compared against production, because pg_restore can finish successfully having restored a truncated backup. Referential coherence is checked with the orphan rows query, which catches a partial restore that the overall figures would hide. And the environment is destroyed at the end, because it contains real patient data and a forgotten test environment is exactly the A-22 with a "to be reviewed" classification from the 01-04 inventory.

The report's findings field is what justifies the whole exercise: the test must produce findings. A restore test that comes out perfect first time almost always means the easy thing was tested.

Traditional recovery plans were designed against technical failure: a disk that breaks, a data centre that floods. Ransomware with double extortion breaks four assumptions of that model:

Hence the four specific requirements against ransomware. Real immutability, with locked retention nobody can shorten. Isolation of the backup credentials: the account that writes the backups must not be able to delete them, and the one that reads them to restore must be a different one and out of production's reach. An offline or logically isolated copy as a last resort. And an RTO calculated for the full-rebuild scenario, not for restoring a file: if Nimbus promises 4 hours and its ransomware scenario requires 3 days, it has a commitment it cannot meet and it needs to know that before signing it.

Validation note. The decision on paying a ransom, the notification obligations arising from exfiltration and the insurance cover conditions are legal and contractual questions, not technical ones. They are taken up with legal advisers, with the compliance lead and with the insurer, whose policy usually imposes specific procedures (04-01, 04-05).

The decisive row is the third. A replica is not a backup, because it replicates errors with the same diligence with which it replicates correct actions. Confusing the two is one of the most expensive and most frequent mistakes: "we have high availability" does not answer "and what if somebody deletes the appointments table?".

As well as redundancy, the BCP relies on graceful degradation: designing the system so that, on a partial failure, it keeps offering the essentials. At Nimbus that means that if the attachments bucket does not respond, the diary must carry on working in appointment read-only mode instead of returning a general error. Every degree of degradation the system can sustain reduces the per-hour impact in the BIA, and it is usually cheaper than moving up a rung on the RTO table.

Restoring in the wrong order stretches the RTO and produces confusing errors. The order derives from the dependency map in the 01-04 inventory:

Two warnings about the diagram. Step 7 is deliberately left until last: re-enabling the integrations before validating can fire off hundreds of e-mails or duplicate charges with restored data. And step 8 is not optional: reconciliation — checking which appointments were created between the RPO and the disaster and are missing — is the work that turns a technical restore into a business recovery.

While the RTO runs, the business has to carry on. This is the part of the plan that is not technical and the part customers are most grateful for:

The first row contains the most profitable idea in this lesson: an automatic daily export that each clinic already has in its inbox turns an operational catastrophe into an inconvenience, costs next to nothing and works even if the whole of Nimbus has vanished.

The quarterly partial drill has the best cost-to-value ratio and is the one Nimbus cannot skip. The annual full one is best done in a planned window and with customers warned: a drill that goes wrong in an agreed slot is learning; the same failure in a real disaster is a crisis.

And one rule that closes the module's cycle: every test produces findings, and every finding becomes an action with an owner and a date that goes into the 04-01 risk register and, where relevant, into the 04-03 control catalogue. Without that, testing is a ceremony.

The metric that most surprises people the first time they measure it is coverage: there is almost always some critical system — the identity provider configuration, the ticketing tool, the data in a SaaS — that nobody was backing up because everyone assumed the provider did it. It is the shared responsibility from 04-04 showing up in practice.

• Having backups and never having restored them. It is the mistake of the whole module, and in 02-06 it was literal. Tip: the quarterly test in the calendar, with a report and findings; with no report, the test did not happen.
• Setting the RTO by what the technology already does. You get a comfortable, false number. Tip: the BIA and the MTPD first, the technology afterwards, and if it does not reach, document it as an accepted risk with a signature.
• Backups reachable with the same credentials as production. That is what allowed the deletion on day 20. Tip: a separate account, locked retention and backup credentials production does not know.
• Confusing high availability with backup. The replica replicates the errors. Tip: always ask yourself "and what if somebody deletes the table?".
• Encrypting the backup and keeping the key inside the encrypted environment. Tip: separate custody and a tested key recovery procedure.
• Backing up the data and not the configuration. Restoring a database without being able to stand up the infrastructure stretches the RTO by days. Tip: versioned infrastructure as code, and in the backup too.
• Retention that is too short. Corruption discovered three weeks later is already in every copy. Tip: tiered daily/weekly/monthly/annual retention.
• A plan that exists only in the system that can go down. Tip: a printed, out-of-band copy, just like the response plan.
• Forgetting the BCP. A perfect DRP leaves the business at a standstill for the duration of the RTO. Tip: start with the daily diary export; it is almost free.

Nimbus wants to launch a teleconsultation module for the clinics. The business estimates that if the module goes down, the clinics can reschedule by phone, but more than 2 hours of outage during the morning means losing the day's consultations, and that losing the records of a consultation already carried out is unacceptable because they are clinical data.

1. Set the module's MTPD, RTO and RPO, justifying them.
2. Choose the technical strategy using the table in section 3 and state the relative cost.
3. Propose two graceful degradation measures that reduce the per-hour impact without moving up a cost rung.

This is another company's last restore test report:

Identify everything that makes this report fail to demonstrate that the company can recover, and rewrite the fields that are missing.

Nimbus has committed to an RTO of 4 hours for the API and the database, measured in the quarterly test (55 minutes). Estimate the real RTO in the face of ransomware like the 02-06 incident by breaking it down into phases, say where most of the time sits and propose three measures that would reduce it. Finish by saying what Marta should do about the 4-hour commitment.

Exercise 1

(1) MTPD = 2 hours, because that is the limit the business sets before harm that cannot be repaired (the day's consultations are lost). The RTO must be less than the MTPD, so it is set at 1 hour, leaving room for detection and the decision, which also consume MTPD — a very common mistake: setting RTO = MTPD and then discovering that the time to detect and decide had already used it up. The RPO ≈ 0-5 minutes, because losing the record of a consultation already carried out is unacceptable: it is clinical data that may also have evidential value.

(2) With an RTO of 1 h and an RPO of minutes, the table in section 3 places the solution at asynchronous replication to another zone with manual promotion (× 2), not at synchronous replication (× 3-4). Asynchronous replication with a lag of seconds meets a 5-minute RPO comfortably, and manual promotion fits within 1 hour if the procedure is written down and tested. Paying for synchronous here would be over-engineering: the RPO required is not zero, it is "minutes", and that distinction is worth twice the cost.

(3) Two graceful degradation measures: (a) have the teleconsultation application save the notes of the consultation in progress locally on the practitioner's device and synchronise them on recovery, so that an outage does not destroy work already done — this reduces the impact of the RPO without changing the data architecture; and (b) a degraded mode in which, if the video service fails, the platform still lets you view the record and log the consultation, offering an alternative phone link: the business process is preserved even though its most expensive component has failed. Both reduce the per-hour impact in the BIA and neither moves up a cost rung.

Exercise 2

Problems with the report:

Missing fields: hash_verified: true, backup_tested: {recent: ..., old: ...}, rows: {appointments, customers, orphans} with deviation_vs_production_pct, rpo_actual, executed_by and procedure_sufficient: true|false, environment_destroyed: true, findings with at least one observation and actions with an owner and a date.

Exercise 3

Breakdown of the real RTO in the face of ransomware:

Most of the time is not in restoring, but in rebuilding and in trusting. Restoring is 3 % of the total; the remaining 97 % is discovering the scope, standing up a clean environment and verifying that you can go back.

Three measures that genuinely reduce it: (a) complete and tested infrastructure as code, which turns the 8-24 hours of rebuilding into 1-2 hours of applying a template — by some distance the highest-impact measure; (b) detective controls (C-08, C-09 from 04-03), which cut the detection phase from days to hours and also reduce the scope to be investigated; and (c) a prepared recovery environment in a separate account, with the network and the roles already defined, so you do not have to create it under pressure.

What Marta should do about the 4-hour commitment. Not leave it as it is. She has three defensible options and one unacceptable one. She can qualify the commitment — 4 hours for technical failure, a different, declared objective for security compromise scenarios, which is what serious providers do; she can invest in infrastructure as code and a prepared recovery environment to bring the ransomware scenario closer to 4 hours; or she can formally accept the risk with a management signature and an expiry (04-01) while she does the above. What is unacceptable is leaving the number as it stands in the contract: an RTO committed to and not achievable is a breach of contract waiting for its date, and it also falsifies the residual risk in the register.

You have closed the module with the discipline that decides whether the company survives. You distinguish BCP and DRP as complementary and not interchangeable plans — the business carrying on versus the technology coming back — and you know that for an SME "disaster" does not mean earthquake: it means ransomware, mass deletion, a provider outage or a corrupt migration. You know how to build a BIA by identifying business processes and not systems, with its MTPD set by the business and not by technology, measured in bands because impact is not linear, and with the observation that reorders priorities: at Nimbus the most critical process by availability is not the one handling the most sensitive data.

You have RTO and RPO — how long you take to come back and how much data you lose — their relationship with the MTPD, the table that translates each objective into a technical strategy and a relative cost, the difference between asynchronous and synchronous replication, and the rule that avoids the circular conversation: they are derived from the BIA and, if the budget does not reach, the gap is documented as an accepted risk with a signature, you never change the number on the sheet. You know the backup strategies — full, incremental and differential — and the 3-2-1-1-0 rule digit by digit, with the last two digits as the protagonists because they are exactly the ones Nimbus was missing in 02-06: the 1 for immutable, which only counts if the retention is locked and the backup credentials are unknown to production, and the 0 for verified. You know what else has to be backed up besides the data — configuration, infrastructure as code, secrets, certificates and the recovery documentation itself — and what a backup does not cover: replicated logical deletion, propagated corruption, data that lives only in a SaaS and schema changes.

You take away the heart of the lesson: an unverified backup is not a backup, it is a hope, with the four types of test, a restore script for an isolated environment that times the real RTO, verifies the hash before restoring, compares row counts against production, checks referential coherence and destroys the environment at the end, and a report in which the findings field is what justifies the exercise. You know why ransomware breaks the classic plans — reachable backups that get encrypted, rebuilding rather than restoring, a multiplied RTO and confidentiality that cannot be recovered — why high availability is not a backup — it replicates the DELETE with the same diligence — and what graceful degradation contributes. And you have the written plan: the start-up order by dependencies with its two warnings, the manual emergency procedures headed by the most profitable idea in the lesson — the daily diary export each clinic already has in its inbox — the complete DRP template, the testing cadence with the quarterly partial drill as the non-negotiable piece, and the metrics, among which coverage always reveals some critical system nobody was backing up.

With this, Module 4 is complete and forms a system. You know what to protect and in what order of priority, through a defensible risk assessment with its living register, its signed appetite and its four treatment strategies (04-01). You know under what rules, with a document hierarchy that makes decisions outlive whoever took them and an exceptions register with mandatory expiry (04-02). You know with what measures, with a control catalogue classified by nature and by function, measured by coverage and not by existence, and traced through to its evidence (04-03). You know how far your perimeter reaches, with a third-party map, proportionate due diligence, contractual clauses and the software supply chain (04-04). You know how to react, with a plan written beforehand, preserved evidence, honest communication and a blameless post-mortem (04-05). And you know how to come back, with objectives derived from the business and verified backups (04-06).

But notice one word that has appeared in all six lessons without ever being developed: verify. The control catalogue requires you to check that MFA covers 100 % of accounts; the monthly external scan has to discover whether port 5432 has been reopened; the exfiltration alerts have to exist and fire; the per-tenant authorisation tests have to run on every merge; and somebody has to actively look for the vulnerabilities before the attacker does. All of that is technical work with specific tools that this module has named without teaching.

In Module 5: Security Tools and Techniques we move from management to execution: vulnerability analysis tools (05-01) to find what is exposed, monitoring and detection techniques (05-02) to finally build the detective controls Nimbus lacks, penetration testing (05-03), network security (05-04), application security (05-05), endpoint hardening (05-06) and cloud and container security (05-07). We stop asking what is worth protecting and start checking, with tools in hand, whether it really is protected.