Business Continuity, Disaster Recovery, and Incident Response practice questions

2

Differential backups capture all changes since the last full backup, so each one is cumulative. Only Monday noon and Tuesday noon differentials exist before Wednesday's attack; Wednesday's noon backup had not yet run, so two restores are needed.

5.5 hours, MTD met

Downtime runs from the 10:00 AM disaster to full service resumption at 3:30 PM, totalling 5.5 hours. That is within the 8-hour maximum tolerable downtime, so the MTD is met even though the 4-hour RTO was exceeded.

Incremental backup daily

Incremental backup copies only data changed since the last backup, whether full or incremental, so each run is small and fast. This directly satisfies the stem's constraints of minimising storage space and backup time, accepting slower restoration.

Data breach

Encrypted outbound traffic to an unknown external IP from a server with no legitimate external role indicates data exfiltration, the defining mechanism of a data breach. Confidentiality of stored data is compromised, distinguishing it from availability or access-control incidents.

Saturday

The GDPR mandates that a data controller must notify the relevant supervisory authority of a personal data breach without undue delay and, where feasible, no later than 72 hours after becoming aware of it. Since the organisation discovered the breach on Wednesday, the 72-hour period commences from that point. Counting forward, 72 hours from Wednesday leads directly to Saturday, making it the precise deadline for notification under these regulations.

Total downtime 8 hours, MTD met

The total downtime is calculated by summing the 5 hours required to restore the application from backup and the 3 hours for additional configuration, equalling 8 hours. This 8-hour total downtime precisely meets the Maximum Tolerable Downtime (MTD) of 8 hours specified in the scenario. Consequently, the MTD constraint is satisfied.

2 hours

The Recovery Time Objective (RTO) defines the targeted duration for restoring a business function or application to an operational state after an outage. In this scenario, the IT team estimates system recovery will take 2 hours. This timeframe directly represents the RTO, as it signifies when the critical application itself becomes available again. The additional manual data reconciliation, while crucial for full data integrity, occurs after the system is operational and does not extend the RTO, which must satisfy the 4-hour Maximum Tolerable Downtime.

3.5 hours

Data from the last incremental backup at 11 AM to the failure at 2:30 PM could be lost.

Maximum Tolerable Downtime (MTD)

MTD defines the longest period a business function can remain unavailable before unacceptable consequences occur, making it the direct measure of maximum tolerable outage. RTO and RPO are derived from it, not equivalent to it.

Fast backup process

Incremental backups capture only data altered since the previous backup, so each run copies a small fraction of the dataset. This minimal data volume is what makes the backup process fast, satisfying the speed characteristic the question asks for.

Backs up data changed since the last backup (any type)

An incremental backup copies only blocks or files modified since the most recent backup of any type, whether full or incremental. This changed-data scope is the defining mechanism that distinguishes it from differential and full backups.

Unauthorized access to sensitive files

Unauthorised access to sensitive files is a direct breach indicator: it shows the confidentiality control has already failed, with an identity reaching data outside its granted permissions. Monitoring file-access audit logs surfaces this anomaly, satisfying the stem's requirement for a common breach indicator.

Unusual outbound network traffic

Unusual outbound network traffic indicates exfiltration, where compromised hosts or malware send stolen data to external command-and-control or drop servers. Egress monitoring and flow logs detect this deviation from baseline, satisfying the stem's requirement for a common breach indicator.

4 (Sunday full and Monday, Tuesday, Wednesday incrementals)

Incremental backups capture only changes since the previous backup, so restoration requires the Sunday full plus every incremental through Wednesday. That totals four backup sets: the full and Monday, Tuesday and Wednesday incrementals, reflecting Thursday's failure point.

Full backup

A full backup captures the entire dataset, so on its own it contains every file needed for a restore. Combined with the latest differential, which holds only changes since that full, the pair restores the system.

Differential backup

A differential backup captures only changes since the last full backup, so restoring requires just that latest full plus the most recent differential. This two-piece restore chain is exactly the minimal set the stem specifies, unlike incremental backups which need every intervening increment.

Recovery Time Objective (RTO)

The 4-hour figure specifies maximum tolerable downtime for restoring the database, which is precisely RTO. The 1-hour data-loss tolerance is the RPO, and the 30-minute verification sits inside the RTO window, so 4 hours maps to recovery time, not data loss.

Using differential backups instead of incremental

Differential backups capture everything changed since the last full, so restoration needs only the latest full plus one differential set, cutting restore time versus replaying every incremental. The backup window stays similar because each differential remains smaller than a full backup.

Cost

Cost is a primary differentiator: a hot site duplicates fully provisioned infrastructure with near-instant failover, while a warm site holds partial equipment requiring restoration, making it markedly cheaper. Budget therefore directly determines which recovery site strategy is viable.

Recovery Time Objective (RTO)

RTO defines the maximum tolerable downtime, directly determining whether a hot site's near-instant failover or a warm site's slower restoration suffices. It is the primary factor distinguishing these strategies, alongside cost, satisfying the stem's selection criteria.

Requires only the last full backup and the latest differential backup for a full restore

Restoring from a differential backup needs just two sets: the last full backup plus the most recent differential. Because each differential accumulates all changes since that full, intermediate differentials are unnecessary. This two-file restore path satisfies the characteristic distinguishing differentials from incrementals, which require the full plus every incremental.

Backs up all data changed since the last full backup

Each differential backup captures every file modified since the last full backup, so the data set grows with each successive run until the next full occurs. This cumulative-since-full behaviour is the defining axis separating differentials from incrementals, which capture only changes since the previous backup.

Restore time is generally faster than incremental backups

Restoration requires only the last full backup and the latest differential, so recovery involves two restore operations rather than the full plus every incremental chain. Fewer restore steps mean faster recovery, satisfying the characteristic that differential restore time is generally quicker than incremental.

Documenting the timeline of events and actions taken

Documenting the timeline of events and actions taken reconstructs what occurred during the breach, forming the evidentiary basis for the post-incident review. This record supports identifying gaps and improving future response, satisfying the lessons learned phase's documentation requirement.

Updating the incident response plan based on findings

Updating the incident response plan translates lessons identified during the post-incident review into revised procedures, roles and controls. This closes the feedback loop the lessons learned phase demands, ensuring the organisation responds more effectively to comparable breaches in future.

Conducting a post-incident review meeting with all stakeholders

A post-incident review meeting gathers all stakeholders to discuss the breach, agree findings and assign improvements. This collaborative debrief is the core activity of the lessons learned phase, converting the documented timeline into actionable changes to people, process and technology.

Conduct a lessons learned meeting to identify improvements.

The NIST post-incident activity phase covers reviewing what occurred to improve future response. A lessons learned meeting gathers the team to examine decisions, gaps and successes, producing actionable recommendations. This satisfies the framework's requirement for post-incident review once containment and eradication are complete.

Retain evidence and logs for legal or regulatory purposes.

Retaining evidence and logs satisfies the post-incident activity phase's requirement to preserve data for legal proceedings, regulatory obligations, and future investigations. NIST SP 800-61 places evidence retention within post-incident activity, after containment and eradication, supporting lessons learned and potential prosecution.

Update the incident response plan based on findings.

Updating the incident response plan translates the lessons learned into durable improvements, satisfying the post-incident activity phase's requirement to feed findings back into preparation. NIST SP 800-61 places this within post-incident activity, alongside lessons learned and evidence retention, closing the lifecycle loop before the next incident.

A full backup copies all data regardless of change status.

A full backup captures every selected file irrespective of its archive bit or modification state, giving a complete baseline copy. Incremental and differential backups instead copy only changed data, so this statement defines the full backup type correctly.

A differential backup copies data that has changed since the last full backup.

A differential backup captures every block modified since the most recent full backup, accumulating changes across successive runs. This contrasts with incremental backups, which capture only changes since the previous backup of any kind. It correctly describes the differential backup type the database strategy evaluation requires.