Category: Business Continuity

ICT Continuity

Also known as: ICT Readiness for Business Continuity, IRBC, ICT Service Continuity

Simply put

ICT continuity is an organization's ability to keep its information and communication technology (ICT) systems running, or to restore them quickly, so that essential business activities can continue during and after a disruption. It focuses on protecting and recovering the technology, data, and services that the business depends on. In practice, it is planned around which systems the business identifies as most critical.

Formal definition

ICT continuity encompasses the capabilities, plans, and controls that enable information and communication technology systems to support an organization's business continuity objectives, including the ability to react in advance of, or upon detection of, a disruptive event. ICT continuity requirements are typically derived from the business impact analysis (BIA), which identifies the subset of ICT resources needed to sustain prioritized business activities and their associated availability, integrity, and confidentiality needs. Within ISO/IEC 27001, this discipline is addressed by Annex A control 5.30 (ICT readiness for business continuity), which aims to ensure ICT systems can support continuity objectives; as an Annex A reference control, its applicability is determined through the Statement of Applicability and informed by risk assessment rather than being universally mandated. ICT continuity is generally scoped as a subset of broader organizational business continuity management and does not, on its own, guarantee uninterrupted service or freedom from disruption.

Why it matters

Modern organizations depend on information and communication technology for nearly every prioritized business activity, so a disruption to critical systems can quickly cascade into a disruption of the business itself. ICT continuity matters because it turns a general aspiration to "stay operational" into a planned capability: the organization identifies which systems, data, and services are most critical and puts controls and recovery arrangements in place to protect and restore them. This capability includes the ability to react in advance of a disruptive event or upon detection of one, rather than only responding after an outage has fully materialized.

A defining feature of ICT continuity is that its requirements are derived from the business impact analysis (BIA). The BIA identifies the subset of ICT resources needed to sustain prioritized business activities, along with their associated availability, integrity, and confidentiality needs. Without this linkage, continuity investment risks being misdirected, protecting systems that are not essential while leaving critical dependencies under-resourced. Grounding ICT continuity in the BIA helps ensure that recovery priorities reflect what the business actually needs to keep running.

It is important to set expectations honestly: ICT continuity is generally scoped as a subset of broader organizational business continuity management, and it does not, on its own, guarantee uninterrupted service or freedom from disruption. It reduces the likelihood and impact of ICT-related interruptions and shortens recovery, but the outcomes depend on scope, risk assessment decisions, and how thoroughly plans are tested and maintained.

Who it's relevant to

Business Continuity and Resilience Managers

These professionals own the linkage between the business impact analysis and ICT recovery arrangements. ICT continuity gives them a structured way to translate prioritized business activities into the specific ICT resources that must be preserved, protected, and recovered, and to position ICT readiness as a component of the broader business continuity management program.

IT and Infrastructure Teams

Teams responsible for systems, data, and services implement and operate the capabilities that support continuity objectives, including the ability to react ahead of, or on detection of, a disruptive event. They rely on the BIA to understand which resources are critical and what availability, integrity, and confidentiality needs those resources must meet.

ISO 27001 Practitioners and Compliance Managers

For organizations pursuing or maintaining ISO/IEC 27001 certification, ICT continuity maps to Annex A control 5.30 (ICT readiness for business continuity). Practitioners decide, through the Statement of Applicability and informed by risk assessment, whether and how this reference control applies, and document how ICT capabilities support the organization's continuity objectives within the defined ISMS scope.

Auditors and Assessors

Auditors examine whether ICT continuity requirements are grounded in the BIA and whether the associated plans and controls are consistent with the organization's stated continuity objectives. They evaluate applicability decisions recorded in the Statement of Applicability, keeping in mind that this control is selected based on scope and risk rather than being universally required, and that its presence does not guarantee freedom from disruption.

Inside ICT Continuity

ICT Readiness for Business Continuity

The practices ensuring that information and communications technology services can be recovered and sustained to support an organization's continuity objectives. In ISO/IEC 27001, related requirements are addressed through Annex A reference controls, though the specific control selection depends on the Statement of Applicability and the underlying risk assessment.

Recovery Objectives

Parameters such as recovery time and recovery point targets that define acceptable service interruption and data loss. These are typically established through business impact analysis and vary by organization and scope rather than being fixed by the standard.

Redundancy and Resilience Measures

Technical arrangements such as backup systems, failover capacity, and alternative processing sites intended to maintain availability of ICT services. In a SOC 2 context, these controls are most relevant when the Availability category of the Trust Services Criteria is included in scope, which is optional and selected during scoping.

Testing and Exercising

Periodic validation of continuity and recovery arrangements to confirm they function as intended. The frequency and rigor of testing typically depend on the organization's risk profile, scope, and the expectations of the auditor or certification body.

Documentation and Plans

Recorded procedures describing how ICT services are restored and maintained during disruption. Under ISO/IEC 27001, such documentation supports the ISMS requirements in clauses 4 through 10; under SOC 2, it provides evidence assessed for design and, in a Type II examination, operating effectiveness over the defined review period.

Common questions

Answers to the questions practitioners most commonly ask about ICT Continuity.

Is ICT continuity the same thing as business continuity?

No. ICT continuity focuses specifically on the readiness of information and communication technology (systems, infrastructure, data, and networks) to be recovered and available following disruption. Business continuity is broader, addressing the continuity of the organization's overall operations, including people, facilities, and processes. ICT continuity typically supports and enables business continuity objectives but is a narrower, technology-focused subset rather than a synonym.

Does having ICT continuity controls guarantee that systems will never go down or that an ISO 27001 certificate confirms uninterrupted availability?

No. ICT continuity measures aim to reduce the impact and duration of disruptions, not to eliminate the possibility of outages. An ISO 27001 certificate attests only that an ISMS meeting the clause 4-10 requirements has been assessed within its defined scope; it does not guarantee freedom from downtime or incidents. Similarly, if availability considerations appear in a SOC 2 report, that report attests only to the controls and period covered and does not guarantee continuous uptime.

How does ICT continuity relate to ISO 27001 Annex A?

ISO 27001 addresses ICT readiness for continuity within its Annex A reference controls, which are selected through the Statement of Applicability and informed by the organization's risk assessment. Because Annex A was restructured in the 2022 revision, the specific control reference and its placement depend on which edition applies, so you should confirm the version in use rather than assuming a fixed control number. Whether a given control applies to your ISMS depends on scope and risk decisions.

How does ICT continuity fit into a SOC 2 examination?

ICT continuity considerations most commonly become relevant when the Availability category of the Trust Services Criteria is included in scope. Availability is optional and selected based on scoping decisions, so it is not addressed in every SOC 2 engagement. Where it is in scope, a Type II report may assess both the design and operating effectiveness of related controls over the defined review period, whereas a Type I addresses suitability of design at a point in time.

What should we test to demonstrate ICT continuity controls are working?

In most engagements, evidence tends to include recovery testing exercises, backup restoration verification, and documented results against defined recovery objectives. For a SOC 2 Type II, testing typically covers operating effectiveness across the review period, so retaining dated records of exercises performed during that period is usually important. The exact expectations depend on the auditor, the criteria in scope, and the defined recovery requirements, so confirm what evidence will be accepted.

How often should ICT continuity arrangements be tested and reviewed?

The standards generally emphasize that continuity arrangements should be exercised and reviewed at planned intervals, but they do not universally prescribe a single fixed frequency; the cadence typically depends on risk, scope, and the organization's own defined requirements. Aligning testing frequency with any review period covered by a SOC 2 examination or with the ISMS review cycle under ISO 27001 is a common practical approach, though the specifics should be set through scoping and risk decisions.

Common misconceptions

ICT continuity controls are mandatory in every SOC 2 report.

ICT continuity relates most directly to the Availability category of the Trust Services Criteria, which is optional. Only the Security category (the Common Criteria) is required; the other categories, including Availability, are selected based on the scope of the engagement.

Meeting ISO/IEC 27001 continuity-related controls automatically satisfies SOC 2 availability expectations.

Mapping between the two frameworks is possible but partial. ISO 27001 Annex A reference controls are not the same as the SOC 2 Trust Services Criteria, and satisfying one framework does not automatically satisfy the other because they use different structures, criteria, and assessment approaches.

A SOC 2 report or ISO 27001 certificate guarantees that ICT services will not experience an outage or breach.

A SOC 2 report attests only to the controls and period covered and does not guarantee freedom from disruptions or breaches. An ISO 27001 certificate covers only the defined scope of the ISMS. Neither outcome is an absolute assurance of uninterrupted service.

Best practices

Derive recovery objectives from a business impact analysis rather than assuming fixed targets, since acceptable interruption and data loss vary by organization and scope.

When the Availability category is in scope for a SOC 2 examination, ensure continuity controls are documented so their design can be assessed and, in a Type II engagement, their operating effectiveness evaluated over the defined review period.

For ISO/IEC 27001, select continuity-related Annex A reference controls through the Statement of Applicability, justified by the risk assessment, and specify the applicable standard version when referencing control structures.

Test and exercise ICT recovery arrangements periodically, aligning frequency and rigor with the organization's risk profile and the expectations of the auditor or certification body.

Maintain current documentation of recovery plans and procedures so they provide sufficient evidence for either an attestation examination or a certification audit.

Treat any framework mapping between SOC 2 and ISO 27001 continuity requirements as partial, and validate each framework's requirements independently rather than assuming equivalence.