Skip to main content
Policy Authority
Category: Business Continuity

ICT Continuity

Also known as: Information and Communication Technology Continuity, ICT Readiness for Business Continuity
Simply put

ICT continuity is the practice of making sure that an organization's information and communication technology services stay resilient and can be restored quickly enough after a disruption. It focuses on the technology, systems, and data an organization needs to keep its business running. The required level and speed of recovery are typically determined by an assessment of which ICT resources the business depends on.

Formal definition

ICT continuity refers to the management processes and technical arrangements that ensure required information and communication technology services are resilient and can be recovered to predetermined levels within the timescales the organization requires. In many frameworks it functions as a subset of, and support for, broader business continuity: ICT continuity requirements are commonly derived from the business impact analysis (BIA), which identifies the ICT resources needed to support prioritized business activities. It is oriented toward preserving, protecting, and recovering systems and data and toward aligning ICT capabilities with the organization's business continuity objectives, rather than encompassing all continuity of business operations. As addressed in ISO/IEC 27001 Annex A control 5.30 on ICT readiness for business continuity, its scope is the readiness of ICT systems to support business continuity objectives; the entry does not cover specific implementation, tooling, or recovery-time parameters, which vary by organization.

Why it matters

Organizations increasingly depend on information and communication technology to deliver their core activities, so a disruption to critical systems or data can quickly cascade into a wider interruption of business operations. ICT continuity matters because it establishes, in advance, which technology services must be resilient and how quickly they need to be recovered, rather than leaving these decisions to be made under the pressure of an active incident. When the underlying technology cannot be restored within the timescales the business requires, continuity plans that assume the availability of those systems may fail in practice.

ICT continuity is also significant because it connects technology recovery to business priorities rather than treating them in isolation. In many frameworks, ICT continuity requirements are derived from the business impact analysis, which identifies the subset of ICT resources needed to support prioritized business activities. This linkage helps ensure that recovery effort and investment are directed at the systems and data that genuinely matter to the organization, and it provides a defensible basis for the recovery levels and timescales an organization sets.

As a discipline oriented toward preserving, protecting, and recovering systems and data, ICT continuity supports broader organizational resilience and, where relevant, the availability, integrity, and confidentiality of critical information. It should be understood as a subset of and support for business continuity rather than a substitute for it; addressing ICT readiness alone does not, on its own, guarantee continuity of all business operations.

Who it's relevant to

Business continuity and resilience managers
Professionals responsible for organizational resilience rely on ICT continuity to ensure that the technology underpinning prioritized business activities can be recovered within required timescales. Because ICT continuity is a subset of and support for broader business continuity, these practitioners use the business impact analysis to translate business priorities into ICT recovery requirements.
IT and infrastructure teams
Those who operate and manage ICT systems are central to preserving, protecting, and recovering systems and data. They implement the technical arrangements needed to keep required services resilient and to restore them to predetermined levels, working from the recovery requirements the organization has defined.
Information security and risk practitioners
Practitioners working under frameworks such as ISO/IEC 27001 engage with ICT continuity through Annex A control 5.30 on ICT readiness for business continuity. Their focus includes ensuring ICT systems can support business continuity objectives and, where relevant, the availability, integrity, and confidentiality of systems and data.
Public sector and e-government operators
Government and public service operations that depend on ICT for uninterrupted service delivery use ICT continuity planning to help ensure the availability, integrity, and confidentiality of critical systems and data, tailoring readiness to the specific activities and dependencies of their operations.

Inside ICT Continuity

Business Impact Analysis (BIA) for ICT services
The process of identifying critical information and communication technology services, mapping their dependencies, and estimating the operational and financial consequences of their disruption over time. It commonly informs recovery priorities and objectives, though the specific methodology and thresholds typically vary by organization and sector.
Recovery Time Objective (RTO)
The targeted duration within which an ICT service or system should be restored following a disruption. It expresses a recovery goal rather than a guarantee, and appropriate values depend on the criticality established through the BIA.
Recovery Point Objective (RPO)
The maximum acceptable amount of data loss measured as the time between the last usable backup and a disruption. RPO is distinct from RTO: RPO concerns data currency, while RTO concerns restoration speed.
ICT continuity strategies and arrangements
The predetermined options for maintaining or resuming ICT services, which may include redundancy, alternate processing sites, backup and restoration arrangements, and failover mechanisms. The selected approach typically reflects the organization's risk appetite and the criticality of the affected services.
ICT continuity plans and response procedures
Documented procedures that direct the response to and recovery from ICT disruptions, commonly including roles, escalation paths, communication arrangements, and defined recovery steps. These are management activities that operationalize continuity strategies.
Testing and exercising
Structured validation of ICT continuity arrangements through activities such as walkthroughs, simulations, or failover tests. Testing is intended to assess whether recovery objectives can plausibly be met and to identify gaps, rather than to prove that recovery will always succeed.
Relationship to broader continuity and resilience
ICT continuity is typically a component of an organization's wider business continuity and operational resilience efforts, addressing the technology dimension while depending on and supporting non-technology recovery arrangements.

Common questions

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

Is ICT continuity the same as IT disaster recovery?
No. IT disaster recovery is typically a component of, rather than a synonym for, ICT continuity. Disaster recovery commonly focuses on restoring specific technology systems, data, and infrastructure after a disruptive event, whereas ICT continuity is the broader discipline of ensuring that information and communications technology services remain available or can be resumed within acceptable timeframes to support the organization's objectives. ICT continuity in turn generally sits within an organization's wider business continuity arrangements. Treating the terms as interchangeable can lead to gaps, since a working recovery capability for a single system does not by itself demonstrate continuity of the end-to-end services that depend on multiple components. This entry does not cover specific recovery tooling or vendor solutions.
Does having ICT continuity arrangements guarantee that services will not be interrupted?
No. ICT continuity arrangements are intended to reduce the likelihood and impact of disruption and to support timely resumption of services, but they do not guarantee uninterrupted availability. Residual risk typically remains after continuity measures are in place, and the effectiveness of arrangements depends on factors such as how well they are tested, maintained, and aligned with current dependencies. Qualified language is appropriate here: ICT continuity supports resilience objectives rather than assuring a particular outcome. Assessing whether arrangements are designed and operating as intended is generally an assurance activity distinct from the management activity of maintaining continuity capability.
How are recovery time and recovery point objectives typically used in ICT continuity planning?
Recovery time and recovery point objectives are commonly used as parameters that translate business requirements into technical continuity targets. A recovery time objective generally expresses the targeted duration within which a service should be resumed after disruption, while a recovery point objective generally expresses the maximum acceptable data loss measured back from the point of disruption. These objectives are typically derived from an impact analysis and then used to shape the design of backup, replication, and failover arrangements. This entry does not prescribe specific values, which vary by service criticality, jurisdiction, sector, and organizational risk appetite.
How does a business impact analysis inform ICT continuity requirements?
A business impact analysis is commonly used to identify critical business processes and the ICT services and dependencies that support them, and to characterize the potential consequences of their disruption over time. The outputs typically help prioritize which services warrant the most robust continuity arrangements and inform the setting of recovery objectives. In many frameworks the analysis is treated as a foundational input rather than a one-off exercise, since dependencies and priorities change. The specifics of methodology and scoring approaches vary across organizations and are outside the scope of this entry.
What role does testing and exercising play in maintaining ICT continuity?
Testing and exercising are commonly used to validate whether continuity arrangements perform as intended and to identify gaps before an actual disruption. Approaches may range from walkthroughs and tabletop exercises to more technical failover or recovery tests, with scope and frequency typically driven by service criticality and risk considerations. Findings are generally fed back into plan updates. It is worth distinguishing management's own testing from independent assurance over the continuity program; the latter is typically performed by functions with appropriate objectivity. This entry does not specify testing schedules, which vary by context and applicable requirements.
How should third-party and cloud service dependencies be addressed in ICT continuity?
Where ICT services rely on external providers, including cloud services, continuity arrangements typically need to account for those dependencies rather than assume they are covered by internal measures alone. This commonly involves understanding the provider's own resilience and recovery commitments, clarifying respective responsibilities, and considering concentration and single-point-of-failure risks. In some jurisdictions and sectors, particularly regulated ones such as financial services, there may be specific expectations regarding oversight of outsourced and third-party ICT arrangements; these vary by jurisdiction and sector and should be confirmed against applicable requirements. This entry does not provide legal advice or contract-specific guidance.

Common misconceptions

ICT continuity and disaster recovery are the same thing.
The terms are related but not identical. ICT continuity commonly refers to the broader capability to maintain and resume technology services in the face of disruption, while disaster recovery typically denotes the more specific arrangements for restoring systems and data after a significant outage. Usage varies across frameworks and organizations, so the intended scope should be stated explicitly.
Having backups means an organization has ICT continuity in place.
Backups address data recovery (relevant to RPO) but do not by themselves ensure that services can be restored within acceptable timeframes (RTO) or that dependencies, procedures, and personnel are prepared. ICT continuity encompasses strategies, plans, and testing beyond backup arrangements.
A completed ICT continuity plan guarantees services will recover as intended.
A plan sets objectives and procedures but cannot guarantee outcomes. Actual recovery depends on the nature of the disruption, the currency of arrangements, and execution. Testing and exercising provide evidence of likely effectiveness but do not eliminate residual risk.

Best practices

Base ICT continuity priorities on a business impact analysis so that recovery objectives, such as RTO and RPO, reflect the assessed criticality of each service rather than uniform assumptions.
Define and document RTO and RPO separately for critical ICT services, and confirm that selected continuity strategies are capable of supporting those targets.
Map dependencies between ICT services, supporting infrastructure, and third-party providers so that recovery arrangements account for the full chain needed to restore a service.
Test and exercise continuity plans on a regular basis using scenarios of varying severity, and use the results to identify and remediate gaps.
Maintain and version-control continuity plans, updating them following significant changes to systems, dependencies, or the risk environment, as well as after tests and actual incidents.
Align ICT continuity with the organization's broader business continuity and operational resilience arrangements to ensure technology recovery supports overall objectives, and reflect any jurisdictional or sector-specific requirements that apply.
Promotional banner for the Pentest Readiness checklist download