ISO 27001:2022 Annex A 5.30, ICT readiness for business continuity, asks an organisation to plan, put in place, maintain and test its ICT readiness, so that its systems, services and data can be recovered in line with its business continuity objectives and ICT continuity requirements. It is a corrective control that keeps information available during a disruption.
What Is the Purpose of ISO 27001:2022 Annex A 5.30?
ISO/IEC 27002:2022 states the purpose of control 5.30 as keeping the organisation’s information and other associated assets available during a disruption.
ISO/IEC 27002 describes ICT readiness as an important part of both business continuity management and information security management. Keeping information protected while a disruption is under way is the job of the neighbouring control, 5.29 Information security during disruption.
Key terms: BIA, RTO and RPO
| Term | What it means |
|---|---|
| Business impact analysis (BIA) | The process of analysing how a disruption affects the organisation as time passes (ISO 22301:2019, 3.5). Under 5.30, the BIA is where ICT continuity requirements come from. |
| Recovery time objective (RTO) | How quickly a service, and the systems and applications behind it, must be back to at least a minimum level after a disruption (ISO/IEC 27002:2022, 3.1.30). |
| Recovery point objective (RPO) | The point in time to which data must be restored after a disruption. In practice, it sets how much recent data you can afford to lose (ISO/IEC 27002:2022, 3.1.29). |
What Does Annex A 5.30 Ask For?
The control text in ISO 27001:2022 is a single sentence. The practical detail sits in ISO/IEC 27002:2022, and our ISO 27002 control 5.30 guidance covers it in more depth. In outline, the work runs in four steps.
1. Start with a business impact analysis
ICT continuity requirements are the output of the BIA. The BIA uses agreed impact types and criteria to assess how the impact of a disruption to business activities grows over time. The size and duration of that impact are used to pick out prioritised activities, and each prioritised activity is given an RTO.
The BIA then identifies the resources each prioritised activity depends on, including ICT services, and sets an RTO for those resources too. It can be extended to set the performance and capacity that ICT systems need during a disruption, and the RPO for the information those activities rely on.
2. Choose ICT continuity strategies
Using the BIA and a risk assessment that covers ICT services, the organisation selects ICT continuity strategies, with options for before, during and after a disruption. A single strategy can combine more than one solution.
3. Build, approve and test ICT continuity plans
Plans are then developed, implemented and tested so that ICT services reach the required availability within the required time frames. ISO/IEC 27002 also asks the organisation to make sure that:
- it has a suitable structure, with people who hold the necessary responsibility, authority and competence, to prepare for, limit and respond to a disruption
- its ICT continuity plans, including response and recovery procedures, are exercised and tested on a regular basis
- those plans are approved by management.
4. Record what each ICT continuity plan must contain
| Plan content | What it covers |
|---|---|
| Performance and capacity | How much performance and capacity the ICT systems must deliver to meet the continuity requirements and objectives from the BIA. |
| RTO for each prioritised ICT service | How quickly each service must be back, and the procedures for restoring its components. |
| RPO for each prioritised information resource | How recent the restored data must be, and the procedures for restoring that information. |
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
What Does Annex A 5.30 Look Like in Practice?
The worked example below follows one customer database through the control. The figures are illustrative only.
- The BIA shows that taking customer orders is a prioritised activity and that the impact of losing it rises sharply after half a day. The activity is given an RTO of 4 hours.
- Order-taking depends on the customer database, so the database is also given an RTO of 4 hours. Losing more than an hour of orders is not acceptable, so its RPO is 1 hour.
- The ICT continuity strategy is hourly backups to a second location plus a standby database server.
- The ICT continuity plan records the restore steps, the capacity the standby server needs, the plan owner and the date management approved it.
- A restore test is run and dated. The team notes how long the restore took and how much data was lost, compares both with the RTO and RPO, and turns any gap into an action.
For a step-by-step approach to putting this in place, see how to implement Annex A 5.30.
How Does 5.30 Relate to Business Continuity Planning and Disaster Recovery?
Business continuity planning covers how the whole organisation keeps its prioritised activities going during a disruption. Annex A 5.30 covers the ICT part of that picture: making sure the ICT services those activities need can be recovered in time. Our business continuity planning guide covers the wider plan.
In everyday use, disaster recovery means restoring ICT systems and data after a serious failure. Within the ISO 27001:2022 Annex A controls, that work sits mainly in 5.30, through the RTOs, RPOs and restore procedures in each ICT continuity plan. Neighbouring controls cover related ground.
| Annex A control | Title | How it relates to 5.30 |
|---|---|---|
| 5.29 | Information security during disruption | Keeps information protected while a disruption is under way; 5.30 keeps it available. |
| 5.30 | ICT readiness for business continuity | Plans, tests and maintains recovery of ICT services within the agreed RTOs and RPOs. |
| 8.13 | Information backup | Backups support recovery; ISO/IEC 27002 ties backup arrangements to business requirements such as the RPO. |
| 8.14 | Redundancy of information processing facilities | Duplicate facilities help meet short recovery times; ISO/IEC 27002 notes a strong relationship with 5.30. |
For further guidance, ISO/IEC 27002 points to ISO/IEC 27031 for ICT readiness, ISO 22301 and ISO 22313 for business continuity management systems, and ISO/TS 22317 for business impact analysis. If your organisation also falls under NIS 2, see our guide to NIS 2 business continuity and backup proof.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
NHS Professionals achieves ISO 27001 certification and improves their infosec management
Facing a tight six-month deadline and multiple existing frameworks to integrate, NHS Professionals needed a platform that could incorporate ISO 27001 without duplicating policies or adding risk to their already complex compliance landscape.
Xergy tool Proteus generates growth through ISO 27001 compliance using ISMS.online
As a start-up building software for highly regulated engineering sectors, Xergy needed ISO 27001 to generate growth through trust — and a proven external partner to handle the rigorous requirements without diverting the dev team.
How MAAS Aviation Built a Robust and Sustainable ISO 27001-Compliant ISMS
MAAS Aviation required strong technical foundations to support ISO 27001 alignment, and a platform to centralise compliance management.
How Blue Services Achieved Triple ISO Certification Success
Blue Services needed external support to guide them through ISO 27001, ISO 9001 and ISO 14001 implementation and best practices, and a platform to centralise their overall compliance management.
How Evolution Funding Cruised to ISO 27001 Certification Success
Achieving ISO 27001 certification was a core objective for Evolution Funding. The team needed a centralised platform with which they could implement the ISO 27001 standard and work through the compliance process.
How 4way Consulting Paved the Road to ISO 27001 Success
Handling sensitive client data across multiple standards, 4way needed a cost and time-efficient way to pursue ISO 27001 – without building an ISMS from scratch or relying on expensive external consultants.
Who Owns Annex A 5.30?
ISO 27001 does not name a role for this control. ISO/IEC 27002 asks for people with the right responsibility, authority and competence to respond to a disruption, and for ICT continuity plans to be approved by management. Each organisation decides who that is. One workable split is:
- top management approves the ICT continuity plans and accepts the RTOs and RPOs
- the business continuity lead or ISMS manager runs the BIA and makes sure ICT requirements feed into it
- the IT or ICT service lead owns the continuity strategies, the plans and the restore tests
- each prioritised ICT service has a named owner for its restore procedure.
What Evidence Shows Annex A 5.30 Is Working?
Records an auditor or a customer doing due diligence may ask to see include:
- the BIA, showing prioritised activities, the ICT services they depend on, and their RTOs and RPOs
- the risk assessment covering ICT services, and the ICT continuity strategies chosen from it
- the ICT continuity plans, including response and recovery procedures
- exercise and test records, with results and follow-up actions
- dated management approval of each plan.
What Changed From ISO 27001:2013?
Control 5.30 is new in ISO 27001:2022. It has no equivalent control in the 2013 edition of ISO 27001.
What Are All the ISO 27001:2022 Annex A Controls?
In the table below you’ll find more information on each individual ISO 27001:2022 Annex A Control.
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Organisational Controls | Annex A 5.1 |
Annex A 5.1.1 Annex A 5.1.2 |
Policies for Information Security |
| Organisational Controls | Annex A 5.2 | Annex A 6.1.1 | Information Security Roles and Responsibilities |
| Organisational Controls | Annex A 5.3 | Annex A 6.1.2 | Segregation of Duties |
| Organisational Controls | Annex A 5.4 | Annex A 7.2.1 | Management Responsibilities |
| Organisational Controls | Annex A 5.5 | Annex A 6.1.3 | Contact With Authorities |
| Organisational Controls | Annex A 5.6 | Annex A 6.1.4 | Contact With Special Interest Groups |
| Organisational Controls | Annex A 5.7 | NEW | Threat Intelligence |
| Organisational Controls | Annex A 5.8 |
Annex A 6.1.5 Annex A 14.1.1 |
Information Security in Project Management |
| Organisational Controls | Annex A 5.9 |
Annex A 8.1.1 Annex A 8.1.2 |
Inventory of Information and Other Associated Assets |
| Organisational Controls | Annex A 5.10 |
Annex A 8.1.3 Annex A 8.2.3 |
Acceptable Use of Information and Other Associated Assets |
| Organisational Controls | Annex A 5.11 | Annex A 8.1.4 | Return of Assets |
| Organisational Controls | Annex A 5.12 | Annex A 8.2.1 | Classification of Information |
| Organisational Controls | Annex A 5.13 | Annex A 8.2.2 | Labelling of Information |
| Organisational Controls | Annex A 5.14 |
Annex A 13.2.1 Annex A 13.2.2 Annex A 13.2.3 |
Information Transfer |
| Organisational Controls | Annex A 5.15 |
Annex A 9.1.1 Annex A 9.1.2 |
Access Control |
| Organisational Controls | Annex A 5.16 | Annex A 9.2.1 | Identity Management |
| Organisational Controls | Annex A 5.17 |
Annex A 9.2.4 Annex A 9.3.1 Annex A 9.4.3 |
Authentication Information |
| Organisational Controls | Annex A 5.18 |
Annex A 9.2.2 Annex A 9.2.5 Annex A 9.2.6 |
Access Rights |
| Organisational Controls | Annex A 5.19 | Annex A 15.1.1 | Information Security in Supplier Relationships |
| Organisational Controls | Annex A 5.20 | Annex A 15.1.2 | Addressing Information Security Within Supplier Agreements |
| Organisational Controls | Annex A 5.21 | Annex A 15.1.3 | Managing Information Security in the ICT Supply Chain |
| Organisational Controls | Annex A 5.22 |
Annex A 15.2.1 Annex A 15.2.2 |
Monitoring, Review and Change Management of Supplier Services |
| Organisational Controls | Annex A 5.23 | NEW | Information Security for Use of Cloud Services |
| Organisational Controls | Annex A 5.24 | Annex A 16.1.1 | Information Security Incident Management Planning and Preparation |
| Organisational Controls | Annex A 5.25 | Annex A 16.1.4 | Assessment and Decision on Information Security Events |
| Organisational Controls | Annex A 5.26 | Annex A 16.1.5 | Response to Information Security Incidents |
| Organisational Controls | Annex A 5.27 | Annex A 16.1.6 | Learning From Information Security Incidents |
| Organisational Controls | Annex A 5.28 | Annex A 16.1.7 | Collection of Evidence |
| Organisational Controls | Annex A 5.29 |
Annex A 17.1.1 Annex A 17.1.2 Annex A 17.1.3 |
Information Security During Disruption |
| Organisational Controls | Annex A 5.30 | NEW | ICT Readiness for Business Continuity |
| Organisational Controls | Annex A 5.31 |
Annex A 18.1.1 Annex A 18.1.5 |
Legal, Statutory, Regulatory and Contractual Requirements |
| Organisational Controls | Annex A 5.32 | Annex A 18.1.2 | Intellectual Property Rights |
| Organisational Controls | Annex A 5.33 | Annex A 18.1.3 | Protection of Records |
| Organisational Controls | Annex A 5.34 | Annex A 18.1.4 | Privacy and Protection of PII |
| Organisational Controls | Annex A 5.35 | Annex A 18.2.1 | Independent Review of Information Security |
| Organisational Controls | Annex A 5.36 |
Annex A 18.2.2 Annex A 18.2.3 |
Compliance With Policies, Rules and Standards for Information Security |
| Organisational Controls | Annex A 5.37 | Annex A 12.1.1 | Documented Operating Procedures |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| People Controls | Annex A 6.1 | Annex A 7.1.1 | Screening |
| People Controls | Annex A 6.2 | Annex A 7.1.2 | Terms and Conditions of Employment |
| People Controls | Annex A 6.3 | Annex A 7.2.2 | Information Security Awareness, Education and Training |
| People Controls | Annex A 6.4 | Annex A 7.2.3 | Disciplinary Process |
| People Controls | Annex A 6.5 | Annex A 7.3.1 | Responsibilities After Termination or Change of Employment |
| People Controls | Annex A 6.6 | Annex A 13.2.4 | Confidentiality or Non-Disclosure Agreements |
| People Controls | Annex A 6.7 | Annex A 6.2.2 | Remote Working |
| People Controls | Annex A 6.8 |
Annex A 16.1.2 Annex A 16.1.3 |
Information Security Event Reporting |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Physical Controls | Annex A 7.1 | Annex A 11.1.1 | Physical Security Perimeters |
| Physical Controls | Annex A 7.2 |
Annex A 11.1.2 Annex A 11.1.6 |
Physical Entry |
| Physical Controls | Annex A 7.3 | Annex A 11.1.3 | Securing Offices, Rooms and Facilities |
| Physical Controls | Annex A 7.4 | NEW | Physical Security Monitoring |
| Physical Controls | Annex A 7.5 | Annex A 11.1.4 | Protecting Against Physical and Environmental Threats |
| Physical Controls | Annex A 7.6 | Annex A 11.1.5 | Working In Secure Areas |
| Physical Controls | Annex A 7.7 | Annex A 11.2.9 | Clear Desk and Clear Screen |
| Physical Controls | Annex A 7.8 | Annex A 11.2.1 | Equipment Siting and Protection |
| Physical Controls | Annex A 7.9 | Annex A 11.2.6 | Security of Assets Off-Premises |
| Physical Controls | Annex A 7.10 |
Annex A 8.3.1 Annex A 8.3.2 Annex A 8.3.3 Annex A 11.2.5 |
Storage Media |
| Physical Controls | Annex A 7.11 | Annex A 11.2.2 | Supporting Utilities |
| Physical Controls | Annex A 7.12 | Annex A 11.2.3 | Cabling Security |
| Physical Controls | Annex A 7.13 | Annex A 11.2.4 | Equipment Maintenance |
| Physical Controls | Annex A 7.14 | Annex A 11.2.7 | Secure Disposal or Re-Use of Equipment |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Technological Controls | Annex A 8.1 |
Annex A 6.2.1 Annex A 11.2.8 |
User Endpoint Devices |
| Technological Controls | Annex A 8.2 | Annex A 9.2.3 | Privileged Access Rights |
| Technological Controls | Annex A 8.3 | Annex A 9.4.1 | Information Access Restriction |
| Technological Controls | Annex A 8.4 | Annex A 9.4.5 | Access to Source Code |
| Technological Controls | Annex A 8.5 | Annex A 9.4.2 | Secure Authentication |
| Technological Controls | Annex A 8.6 | Annex A 12.1.3 | Capacity Management |
| Technological Controls | Annex A 8.7 | Annex A 12.2.1 | Protection Against Malware |
| Technological Controls | Annex A 8.8 |
Annex A 12.6.1 Annex A 18.2.3 |
Management of Technical Vulnerabilities |
| Technological Controls | Annex A 8.9 | NEW | Configuration Management |
| Technological Controls | Annex A 8.10 | NEW | Information Deletion |
| Technological Controls | Annex A 8.11 | NEW | Data Masking |
| Technological Controls | Annex A 8.12 | NEW | Data Leakage Prevention |
| Technological Controls | Annex A 8.13 | Annex A 12.3.1 | Information Backup |
| Technological Controls | Annex A 8.14 | Annex A 17.2.1 | Redundancy of Information Processing Facilities |
| Technological Controls | Annex A 8.15 |
Annex A 12.4.1 Annex A 12.4.2 Annex A 12.4.3 |
Logging |
| Technological Controls | Annex A 8.16 | NEW | Monitoring Activities |
| Technological Controls | Annex A 8.17 | Annex A 12.4.4 | Clock Synchronization |
| Technological Controls | Annex A 8.18 | Annex A 9.4.4 | Use of Privileged Utility ProgramsAccess Rights |
| Technological Controls | Annex A 8.19 |
Annex A 12.5.1 Annex A 12.6.2 |
Installation of Software on Operational Systems |
| Technological Controls | Annex A 8.20 | Annex A 13.1.1 | Networks Security |
| Technological Controls | Annex A 8.21 | Annex A 13.1.2 | Security of Network Services |
| Technological Controls | Annex A 8.22 | Annex A 13.1.3 | Segregation of Networks |
| Technological Controls | Annex A 8.23 | NEW | Web filtering |
| Technological Controls | Annex A 8.24 |
Annex A 10.1.1 Annex A 10.1.2 |
Use of Cryptography |
| Technological Controls | Annex A 8.25 | Annex A 14.2.1 | Secure Development Life Cycle |
| Technological Controls | Annex A 8.26 |
Annex A 14.1.2 Annex A 14.1.3 |
Application Security Requirements |
| Technological Controls | Annex A 8.27 | Annex A 14.2.5 | Secure System Architecture and Engineering PrinciplesLearning From Information Security Incidents |
| Technological Controls | Annex A 8.28 | NEW | Secure Coding |
| Technological Controls | Annex A 8.29 |
Annex A 14.2.8 Annex A 14.2.9 |
Security Testing in Development and Acceptance |
| Technological Controls | Annex A 8.30 | Annex A 14.2.7 | Outsourced Development |
| Technological Controls | Annex A 8.31 |
Annex A 12.1.4 Annex A 14.2.6 |
Separation of Development, Test and Production Environments |
| Technological Controls | Annex A 8.32 |
Annex A 12.1.2 Annex A 14.2.2 Annex A 14.2.3 Annex A 14.2.4 |
Change Management |
| Technological Controls | Annex A 8.33 | Annex A 14.3.1 | Test Information |
| Technological Controls | Annex A 8.34 | Annex A 12.7.1 | Protection of Information Systems During Audit Testing |
Why Choose ISMS.online for Annex A 5.30?
ISMS.online makes implementing ISO 27001, and its Annex A controls such as 5.30, easier. With it you get:
- a step-by-step checklist that guides you through the whole ISO 27001 process
- guidance from the very first step, defining the scope of your ISMS
- support for identifying risks
- guidance on implementing the Annex A controls
- a simple and intuitive platform
- a platform for everyone in your organisation, not just highly technical people.
To see how ISMS.online can help you implement ISO 27001 and its Annex A controls, book a demo.
FAQs
Is a backup policy enough to meet Annex A 5.30?
No. Backups fall under control 8.13 and support recovery, but 5.30 asks for more: a business impact analysis, ICT continuity strategies chosen from it and a risk assessment, and plans that management approves and that are exercised and tested regularly.
Do all ICT services need the same recovery time?
No. Recovery times follow from how fast the impact of losing each activity grows. Each prioritised ICT service gets its own RTO, and each prioritised information resource gets its own RPO, so a system behind a critical activity may need a much shorter recovery time than one that can wait.