ICT readiness for business continuity

Plain-language summary

New in 2022: making sure the ICT systems the business depends on can be recovered within the times the business needs — planned from a business impact analysis, built into the infrastructure, and proven by testing rather than assumed from a backup report.

What the clause is really asking

Business continuity plans often say 'IT will restore systems' without anyone checking whether IT can. This control, new in 2022, closes that gap. It asks you to make the ICT side of continuity real — planned, put in place, kept up to date and tested — against the objectives the business has set for continuity and the ICT continuity requirements that follow from them. The chain runs like this: a business impact analysis identifies critical activities, how long each can be down and how much data loss is acceptable; those become recovery time and recovery point objectives for the supporting ICT services; ICT continuity plans and technical measures (redundancy, backups, alternative sites, failover, cloud recovery) are designed to meet them; and testing proves the objectives can be achieved. Roles, responsibilities and recovery procedures are documented and kept current. The common misunderstanding is that backups alone equal readiness; restoring dozens of servers from backup can take far longer than the business can wait. Where you depend on cloud or managed service providers, their recovery commitments must match your objectives and form part of the plan.

What auditors look for

Auditors ask for the business impact analysis and check that each critical activity has recovery time and recovery point objectives, then trace those objectives to the ICT services that support it. They ask for the ICT continuity or disaster recovery plan and the last test report for the most critical system, comparing the achieved recovery time with the objective. They check whether supplier and cloud recovery commitments match. They ask who would carry out the recovery and whether those people took part in the test. The hard question: your ERP must be back within eight hours; when did you prove it can be?

Typical evidence

Business impact analysis with recovery time and recovery point objectives; mapping of critical activities to ICT services; ICT continuity or disaster recovery plans with roles and procedures; redundancy and failover design records; disaster recovery test plans and reports showing achieved versus target times; supplier and cloud recovery commitments; plan review and update records.

How to comply — recommendations

Run a business impact analysis workshop with process owners, not IT alone, and agree recovery time and recovery point objectives for each critical activity. Map each activity to the systems, infrastructure and suppliers it needs. For each critical system write a recovery runbook: order of restoration, dependencies, credentials held offline, contacts. Check that the technical design can meet the objectives; if it cannot, either invest or change the objective with management sign-off. Test at least the top two systems every year with a real restore or failover, record the actual times and close the gaps. Update the plan after every significant infrastructure change.

Common nonconformities

No business impact analysis or recovery objectives for ICT services; ICT continuity plan not linked to business continuity objectives; disaster recovery never tested, or tested only in part; test results not compared with objectives; supplier recovery commitments not matching business needs; recovery runbooks missing or out of date; recovery depending on credentials or documentation stored on the systems being recovered.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $29Incident & Breach Response KitWhen something happens the questions arrive faster than the facts: is it an incident, how bad, is it a POPIA breach, who must be told and by when, what do we write, what do we keep. This kit answers them in order.
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.