IT service continuity planning is one of the most underprepared areas in enterprise IT — most organisations only discover the gaps when an outage is already in progress. This guide explains how to use ITSM practices to build a recovery plan that is structured, testable and actually works when pressure is highest.
Why IT Service Continuity Still Fails in Most Organisations
Most IT teams acknowledge that continuity planning matters. Fewer have a plan that is current, tested and understood by the people who need to execute it. The gap is rarely about intent — it is about process.
Common failure patterns include:
- Recovery documentation that was written once and never updated after infrastructure changes
- No clear ownership of continuity tasks during an actual disruption
- Service dependencies that are undocumented, so teams restore systems in the wrong order
- Testing that is skipped because it requires downtime or coordination across departments
- Continuity plans stored in a location that becomes inaccessible during the incident that triggers them
The result is that when a major outage, ransomware event or data centre failure occurs, teams are improvising rather than executing. Every minute of unplanned improvisation adds to recovery time and business cost.
IT service continuity management (ITSCM) — one of the ITIL v4 practices — exists to close this gap. It provides a structured approach to identifying critical services, mapping dependencies, defining recovery objectives and testing the plan before it is needed. When ITSCM is embedded in your ITSM platform, it becomes a living process rather than a dusty document.
What ITSCM Actually Covers (and What It Does Not)
ITSCM is often confused with disaster recovery (DR) or business continuity planning (BCP). The three are related but distinct.
- Disaster recovery focuses on restoring specific technical components — servers, databases, network infrastructure
- Business continuity planning covers the broader organisation, including non-IT functions, staffing and facilities
- IT service continuity management sits between them: it is specifically concerned with ensuring that IT services can be recovered to agreed levels within agreed timeframes
ITSCM defines two key metrics for every critical service:
- Recovery Time Objective (RTO) — the maximum acceptable time to restore a service after disruption
- Recovery Point Objective (RPO) — the maximum acceptable data loss measured in time (how old can the last good backup be)
These metrics are not arbitrary. They should be agreed with the business owners of each service, documented in the service catalogue and reviewed whenever the service changes. Without agreed RTOs and RPOs, your recovery team has no target to aim at and no way to know whether recovery was successful.
ITSCM also covers continuity risk assessments, business impact analysis (BIA), recovery strategy selection and regular testing. Each of these feeds into a continual improvement cycle rather than a one-time project.
Building the Foundation: Service Mapping and Dependency Analysis
You cannot recover services in the right order if you do not know how they depend on each other. Service mapping is the foundational step in any credible continuity programme.
Start with your CMDB and asset inventory. A well-maintained CMDB shows you which configuration items underpin each service — the servers, virtual machines, databases, network devices, third-party integrations and end-user devices that must be available for the service to function.
For each critical service, document:
- The configuration items it depends on directly
- The services those CIs depend on (second-order dependencies)
- External dependencies such as cloud providers, SaaS platforms or third-party APIs
- The teams and individuals responsible for each layer
This dependency map becomes the backbone of your recovery runbook. When you know that restoring Service A requires Database B, which runs on Server C, which uses Storage Array D, you can sequence recovery steps correctly the first time rather than discovering the dependency chain during the incident.
Automated asset discovery tools like Odysseus accelerate this process by continuously scanning your network and updating the CMDB with current device and relationship data. Manual discovery is slow and quickly goes stale — automated discovery ensures your dependency maps reflect the actual environment rather than what it looked like when someone last updated a spreadsheet.
Defining Recovery Strategies and Writing Runbooks
Once you have mapped dependencies and agreed RTOs and RPOs with the business, you can select appropriate recovery strategies for each service tier.
Common recovery strategies include:
- Hot standby — a fully replicated environment that can take over in minutes, appropriate for Tier 1 services with RTOs under one hour
- Warm standby — a partially provisioned environment that requires some configuration before it can serve traffic, appropriate for Tier 2 services with RTOs of two to eight hours
- Cold standby — infrastructure that must be provisioned from scratch using backups, appropriate for Tier 3 services where longer recovery times are acceptable
- Cloud burst — using cloud capacity to restore services when on-premises infrastructure is unavailable
The right strategy depends on the RTO, the cost of the solution and the criticality of the service to the business. There is no universal answer — the goal is to match the recovery investment to the business impact of the outage.
Once strategies are selected, write recovery runbooks for each critical service. A good runbook includes:
- Step-by-step restoration instructions written for the person who will execute them under pressure
- Prerequisites — what must be restored before this runbook begins
- Verification steps — how to confirm the service is healthy before declaring recovery complete
- Escalation contacts if a step fails
- Estimated time for each step
Runbooks should be stored in your ITSM knowledge base and accessible even when primary systems are unavailable. Consider maintaining offline copies or hosting them in a separate environment from the services they recover.
Testing, Exercising and Improving the Plan
A continuity plan that has never been tested is a hypothesis, not a plan. Testing is the only way to find gaps before they become critical failures.
There are several testing approaches, each with different levels of disruption and confidence:
- Tabletop exercise — the recovery team walks through a scenario verbally, identifying gaps in the plan without touching production systems. Low disruption, good for initial validation and training.
- Walkthrough test — team members follow the runbook step by step in a non-production environment to verify accuracy of documentation
- Simulation test — a realistic scenario is simulated, including communication flows, escalations and decision-making under time pressure
- Full failover test — actual production traffic is failed over to the standby environment. Highest confidence, highest risk, typically done during a planned maintenance window
Most experts recommend running at least one tabletop exercise per quarter and a full or partial failover test at least annually. Any significant infrastructure change — a server migration, a new SaaS integration, a network redesign — should trigger a targeted review of the affected runbooks and a walkthrough test.
Test results should be captured as formal records in your ITSM platform. Failures, gaps and improvement actions should be logged as problems or continual improvement items so they are tracked to resolution. Linking test outcomes to your service management workflow ensures nothing is lost in email threads or spreadsheets.
Embedding ITSCM in Day-to-Day ITSM Operations
ITSCM should not live in isolation from the rest of your ITSM practice. The most resilient organisations treat continuity as an integrated discipline rather than a separate project that gets dusted off once a year.
Practical integration points include:
- Change management — every change request that affects a critical service should trigger a continuity impact assessment. If the change alters a dependency or recovery path, the relevant runbook must be updated before the change is approved.
- Incident management — major incident records should capture whether continuity procedures were invoked, how they performed and what improvements are needed. This feeds directly into the next test cycle.
- Problem management — recurring incidents that threaten service availability should be evaluated for their continuity implications, not just their root cause.
- Asset and configuration management — CMDB updates from automated discovery should trigger alerts when a CI supporting a critical service changes state or goes end-of-life.
Organisations that manage multiple clients or sites — such as MSPs — face additional complexity because each client may have different RTOs, RPOs and recovery strategies. A platform that supports multi-tenant service management and integrates asset data from tools like Odysseus makes this manageable at scale.
Key Takeaways
- IT service continuity management is a structured ITIL v4 practice, not a one-time project. It requires ongoing ownership, testing and improvement.
- Start with service mapping and dependency analysis. You cannot recover services correctly without knowing how they connect.
- Define RTOs and RPOs for every critical service in agreement with business stakeholders, not IT alone.
- Match recovery strategies to business impact and cost — not every service needs a hot standby.
- Write runbooks that a stressed engineer can follow at 2am without prior knowledge of the system.
- Test the plan regularly. Tabletop exercises are low-cost and reveal gaps quickly. Full failover tests provide the highest confidence.
- Integrate ITSCM with change, incident and problem management so the plan stays current as the environment evolves.
- Automated asset discovery keeps your CMDB and dependency maps accurate, which is the foundation everything else rests on.
TIKTING provides the workflow, knowledge base and change management integration needed to run ITSCM as a live process. Odysseus keeps the asset and dependency data current so your recovery plans reflect reality. You can explore both at itdevtech.com/blog.
Frequently Asked Questions
What is IT service continuity management?
IT service continuity management (ITSCM) is an ITIL v4 practice focused on ensuring that IT services can be restored within agreed timeframes after a disruption. It covers risk assessment, business impact analysis, recovery strategy selection, runbook development and regular testing. It sits between disaster recovery, which is technically focused, and business continuity planning, which covers the whole organisation.
How is ITSCM different from disaster recovery?
Disaster recovery is concerned with restoring specific technical components — servers, storage, networks — after a failure. ITSCM is broader: it focuses on restoring IT services to agreed service levels, which requires understanding business priorities, sequencing recovery correctly and verifying that services are functioning for users, not just that infrastructure is running.
What are RTO and RPO in service continuity planning?
Recovery Time Objective (RTO) is the maximum acceptable time to restore a service after a disruption. Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time — effectively, how old the last good backup can be. Both should be agreed with business stakeholders and documented for every critical service.
How often should continuity plans be tested?
Most experts recommend at least a quarterly tabletop exercise and an annual full or partial failover test. Additionally, any significant infrastructure change, new service dependency or major incident should trigger a targeted review and walkthrough of the affected runbooks. Untested plans should not be relied upon.
Who owns IT service continuity management?
Ownership typically sits with a senior IT manager, IT director or a dedicated service continuity manager. However, effective ITSCM requires active participation from business service owners who define acceptable RTOs and RPOs, infrastructure teams who execute recovery, and the service desk who manage communication during an incident. It is a shared responsibility, not a solo task.
What is a business impact analysis in ITSCM?
A business impact analysis (BIA) identifies which IT services are most critical to business operations and quantifies the consequences of their unavailability — financial loss, regulatory risk, reputational damage or operational disruption. The BIA output drives prioritisation of recovery strategies and investment decisions, ensuring the most critical services receive the most robust continuity arrangements.
