IT continuity plan for ISO 22301: structure and example
An IT continuity plan describes how you restore your IT systems when they fail. It covers each system separately, with fixed recovery times and a fixed order. It is the IT part of the business continuity plan and it draws on the business impact analysis. Within ISO 22301, it belongs to the continuity strategy and the procedures you must be able to show to an auditor.
One IT continuity plan for the whole company usually does not work. It works better if you have a short, practical page for each critical system.
What is the difference from a business continuity plan?
The business continuity plan covers the whole organisation: people, locations, suppliers and communication. The IT continuity plan covers only the technical side. It contains the steps a technician carries out, such as restoring a database or switching over to a second data centre.
| Plan | Question it answers | Who uses it |
|---|---|---|
| Business continuity plan | How do we keep the business running? | Management and process owners |
| IT continuity plan | How do we get the system back? | IT operations and on-call engineers |
Disaster recovery, the technical recovery of systems, is part of the IT continuity plan. The difference between these terms is explained on ISO 22301 for IT companies.
What goes into an IT continuity plan?
A useful plan has the same fixed parts for each system. That way, someone who does not know the system can still carry out the plan.
| Part | Content | Example for a customer portal |
|---|---|---|
| System and owner | Name, role, owner within the organisation | Customer portal, owner: head of customer service |
| Dependencies | Which systems and suppliers it needs | Database, authentication service, CDN (content delivery network) |
| MTPD, RTO and RPO | Maximum outage (MTPD), recovery time (RTO) and data loss (RPO) | MTPD 24 hours, RTO 4 hours, RPO 1 hour |
| Recovery steps | What you do, step by step | Restore the database from the latest backup |
| Alternative | What you do temporarily | Customers call an emergency number |
| Contact persons | Who you call, including outside office hours | Technical contact and supplier |
| Test date | When you last tested it | Failover test (switching to the standby), March, result good |
MTPD stands for maximum tolerable period of disruption, the longest outage you can accept. RTO (recovery time objective) is the recovery time, and RPO (recovery point objective) is the data loss. You do not fill these in by feel. They come from the BIA. Read RTO and RPO explained to see how you determine the data loss.
Example of a worked-out system
Suppose a software company runs a customer portal. The BIA has set that the portal must be back within four hours, and that a maximum of one hour of data may be lost.
The plan then includes, among other things:
- When an outage happens, the on-call engineer logs the incident in the incident channel within fifteen minutes.
- The engineer checks whether the primary database is available. If it is not, the engineer switches over to the standby in the second data centre.
- The engineer restores the latest backup, which is at most one hour old. That sets the RPO.
- The support team switches on a status page and sends customers a message.
- After recovery, the engineer checks that the data is complete and notes the time the portal worked again. That time is the evidence for the RTO.
Note: this example is fictional. You set the recovery times yourself, based on your own BIA and your own technical options.
How to set up the plan
Work in order of importance. Start with the system that causes the most damage when it fails.
- Make a list of all IT systems that support a critical process. Use the BIA for this.
- Assign the MTPD, RTO and RPO to each system, and have management approve them.
- Write a recovery procedure of one or two pages for each system.
- Make sure at least one person can carry out the procedure without the person who wrote it.
- Test the procedure and record the result.
Common mistakes
| Mistake | Result in a real outage | Better approach |
|---|---|---|
| One general plan for all systems | Nobody knows which system must be restored first | A separate page for each system |
| RTO and RPO are not aligned with the BIA | Recovery is technically not possible within the agreed time | Take the figures from the BIA |
| Backups that have never been restored | The backup turns out to be unusable only during the real outage | Restore a backup at least once a year |
| The plan is stored on a shared drive that goes down | Nobody can read the plan | Print a copy or keep one outside the network |
Checklist for one system
Use this list before you consider a system page finished:
- Are the owner and the replacement named?
- Do the MTPD, RTO and RPO match the BIA exactly?
- Does every step appear in the order a technician carries it out?
- Does it describe how you check the backup, and when you last did that?
- Is there a temporary alternative for users?
- Does the on-call engineer know where the plan is if the network fails?
- Has the plan been tested at least once in the last year?
If you answer no to any of these questions, the plan is not yet usable.
What auditors check
An auditor does not only check whether the plan exists. They ask whether it matches the BIA, whether it has been tested recently, and whether the results have been acted on. Evidence includes an exercise report, a measurement of recovery time and an action list with improvements. This approach fits with exercising and testing.
Frequently asked questions
Do I need to make an IT continuity plan separate from the business continuity plan? Not necessarily. It can be an annex. What matters is that the IT steps can be traced back to the BIA.
How often must the plan be updated? After every major change to systems, and at least once a year. See also the audit requirements.
Is this the same as an ISO 27001 continuity plan? There is overlap, but the ISO 27001 side focuses more on information security. Read the difference at ISO 22301 vs ISO 27001.
You can find more terms and answers in the ISO 22301 FAQ.