System availability, recovery planning, and business continuity.
This chapter explains how organizations keep critical systems available and recover when disruptions occur. The key ISC task is to connect technical resilience measures to operational risk, control objectives, and assurance implications.
Availability questions are not limited to backup technology. The exam often asks whether continuity planning, redundancy, recovery objectives, business impact analysis, or service commitments match the organization’s critical process risks.
| Continuity issue | What to verify | Common ISC trap |
|---|---|---|
| Disaster recovery | Whether restoration steps, roles, backups, and testing support recovery. | Having a plan that has never been tested. |
| Redundancy and replication | Whether duplicate capacity protects the right systems and data. | Assuming replication alone replaces recovery governance. |
| Business impact analysis | Which processes are critical and what downtime or data loss is tolerable. | Setting recovery priorities without business impact evidence. |
| RTO, RPO, uptime, and SLA | Whether commitments match operational needs and provider capability. | Confusing recovery time with recovery point or availability percentage. |
| Step | What to establish | Control implication |
|---|---|---|
| Identify critical processes | Business functions, systems, data, dependencies, and stakeholders. | Recovery priorities should come from business impact, not technology preference. |
| Set recovery targets | RTO, RPO, uptime, service level, and tolerance for manual workaround. | Targets define what continuity controls must achieve. |
| Design resilience | Backup, replication, redundancy, alternate sites, and provider commitments. | Resilience measures must match the risk and target. |
| Test the plan | Scenario testing, restore testing, failover testing, and role rehearsal. | Untested plans are weak evidence of recoverability. |
| Monitor and update | Incident results, system changes, vendor changes, and lessons learned. | Continuity planning must stay current as systems change. |
| Target or measure | What it answers | Common ISC confusion |
|---|---|---|
| RTO | How quickly a process or system must be restored. | Confusing restoration time with allowable data loss. |
| RPO | How much data loss is tolerable, measured by time. | Assuming frequent backups guarantee fast recovery. |
| Uptime percentage | How available the service is over a measurement period. | Ignoring when downtime occurs and which process is affected. |
| SLA | What the provider contractually commits to deliver. | Treating SLA language as proof that controls operate effectively. |
| BIA priority | Which process should be restored first and why. | Ranking technology assets without business impact evidence. |