ISO 27001 Control 5.29: Information Security During Disruption

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Control 5.29 is one of the trickier ones for organisations to get right, and I will be honest: it is a hard one to answer neatly. It asks you to plan how information security will be maintained during disruption. The difficulty is that during a major disruption, everything tends to go out of the window, security included.

When I audit this control, most people do not have a good answer. They point at the business continuity or disaster recovery plan in the hope that it is enough. Usually it is not, because those plans are about getting operations running again. They rarely say anything about keeping information secure while that happens.

This page covers what the control actually asks for, how security breaks down during disruption, whether you need a full business continuity plan, and the scenarios worth planning for.

What control 5.29 actually asks for

The requirement is that the organisation plans how to maintain information security at an appropriate level during disruption. Note the word “maintain”. The control is not asking how you recover. It is asking how you stay secure while you are disrupted and recovering. In practice:

• Knowing which information and systems are critical from a security point of view, and why.
• Planning how their security holds up during disruption: access, confidentiality, integrity of data, communications.
• Compensating controls for when normal ones are unavailable.
• Restoring normal security once the disruption is over, rather than leaving the emergency arrangements in place.
• Testing the arrangements, at least as a walkthrough.

In the 2013 edition this was covered by A.17.1.1 to A.17.1.3 (information security continuity). The 2022 revision brought them into one control.

Where 5.29 sits among the continuity controls

Business continuity in ISO 27001 is spread across several controls. 5.29 is the one that keeps security in the picture.

5.29 asks about security during disruption; 5.30 asks about recovering the technology. A business can have an excellent recovery plan and still fail 5.29, because the plan gets systems back without saying how they stay secure in the meantime.

How security breaks down during disruption

Think about what actually happens in a serious disruption. The office is unavailable, or a core system is down, or ransomware has taken out the file server. People are under pressure to keep the business going, and the normal ways of working are not available. So they improvise.

• Communication moves to whatever works. Personal email, WhatsApp, text messages, personal phones. Sensitive information goes with it.
• Access controls get relaxed. Shared passwords to get people working, admin rights handed out to speed things up, multi-factor authentication switched off “temporarily”.
• Data goes to unapproved places. Files emailed to home addresses, copied to USB sticks, uploaded to personal cloud storage to keep working.
• Approvals get skipped. Payments rushed through without the usual checks, which is exactly what fraudsters exploit during a crisis.
• Nobody switches it back. The temporary arrangements quietly become permanent.

None of this is malicious. It is people doing their best. But it is precisely when an organisation is most vulnerable, and attackers know it.

Planning to stay secure

The answer is not to forbid improvisation; it is to decide in advance what the secure alternatives are, so people do not have to invent them under pressure.

• Emergency communication. Decide what you will use if email or Teams is down, and how sensitive information is protected on it. A pre-agreed group on a secure messaging app, with personal details already collected, is far better than people improvising.
• Emergency access. Break-glass administrator accounts, securely stored and monitored, so nobody needs to share passwords or disable MFA to get in.
• Remote working. If the office is lost, can people work securely from home on managed devices? If not, what is the plan?
• Payment checks. Keep verification of bank detail changes and large payments in place during a crisis, and say so explicitly.
• Key people. If the ISMS lead or IT manager is unavailable, who acts, and do they have the access they need?
• Getting back to normal. A step in the plan to remove emergency access, revoke temporary permissions and review what was done.

Do you need a full business continuity plan?

This is one of the questions I am asked most often. ISO 27001 is an information security standard, not a business continuity standard, and it does not require a 200-page business continuity plan. For many smaller organisations, controls 5.29 and 5.30 can be met within the existing risk assessment, the risk treatment plan and a compact continuity procedure. Larger organisations, or those with complex IT, regulatory obligations or significant customer commitments, will need more. A full continuity management system is ISO 22301 territory.

What an auditor will expect to see is a documented view of what is critical, how security is maintained during disruption (not just how operations are restored), recovery objectives for critical systems, and evidence of testing.

Scenarios worth planning for

• Ransomware. Both a security incident and a continuity event. Plan containment, and restoring from backup without reintroducing the infection.
• Cloud provider outage. Your continuity may depend on services you do not control. Decide on alternatives or acceptable downtime.
• Key person unavailable. If the person who holds the keys is away during an incident, who acts?
• Office unavailable. Can staff work securely from elsewhere, and what does emergency remote working do to your controls?
• Major supplier failure. Your IT provider, payroll bureau or hosting provider goes down or goes bust.

Walk through two or three of these as a team once a year. The walkthrough is where you discover that the emergency contact list is on the file server that has just been encrypted.

What auditors will look for

If I were auditing you, this is how I would work through 5.29.

1. Your continuity arrangements, and specifically where they address security, not just recovery.
2. Critical information and systems. Which are they, and why?
3. Emergency arrangements. How would people communicate and access systems if normal routes were unavailable, and how is that secured?
4. Compensating controls. What replaces a control that is unavailable during disruption?
5. Return to normal. How are emergency permissions removed afterwards?
6. Testing. When were these arrangements last walked through, and what did you learn?

Common issues

• Pointing at a business continuity or disaster recovery plan that says nothing about security.
• Treating having backups as having a continuity plan.
• Treating it as IT-only, when HR, finance, operations and management all have a part to play.
• No plan for emergency communication, so sensitive information ends up on personal email and messaging apps.
• MFA disabled or passwords shared “temporarily” during an outage, and never restored.
• Emergency contact lists stored only on the systems that are down.
• No step to remove emergency access after the disruption.
• Arrangements never tested, even as a walkthrough.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• If email and Teams were down for a day, how would your team communicate, and how would sensitive information be protected?
• Could someone get administrator access in an emergency without sharing passwords or disabling MFA?
• Would payment verification still happen during a crisis?
• Where is your emergency contact list, and could you reach it if your systems were down?
• After your last disruption, was every temporary permission removed?

A worked example

No single client is described here. This is a composite of a disruption where recovery went fine and security did not.

A 30-person firm whose office lost power and connectivity for three days after a flood in the building.

What happened

• Staff worked from home. About a third used personal laptops, because managed laptops had been left in the office.
• The team moved to a WhatsApp group, which within a day included client names, a contract and a password.
• An administrator shared their account with a colleague to get a system running, with MFA disabled to make it easier.
• An email purporting to be from a supplier asked for payment to new bank details “while your office is closed”. It was nearly paid.
• Three months later, MFA was still disabled on that admin account.

What changed

• A short continuity procedure with a security section: emergency communication on an approved secure app, break-glass admin accounts, and payment verification that applies at all times.
• Laptops to go home with staff as standard, so working from home means working on managed devices.
• A “return to normal” checklist: review and remove all emergency access, reset shared passwords, and close the emergency channels.
• An annual tabletop exercise, with the flood used as the first scenario.

Operations recovered within a day. The security problems took three months to find, and one of them was nearly very expensive.

How control 5.29 links to other clauses and controls

• Control 5.30, ICT readiness for business continuity. Recovering the technology within the time the business needs.
• Control 5.24, Information security incident management planning and preparation. Most disruptions start as incidents.
• Control 8.13, Information backup. Recovery depends on backups that work and are not compromised.
• Control 8.14, Redundancy of information processing facilities. Resilience that avoids some disruptions altogether.
• Control 6.7, Remote working. Emergency remote working needs to be as secure as the planned kind.
• Control 5.23, Information security for use of cloud services. Your continuity may depend on cloud services you do not control.

What I find in audits

Most of the organisations I audit have never tested a restore from backup (see 5.30), so the first real test of recovery tends to happen during the disruption itself. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• ISO 22301:2019, Business continuity management systems. The international standard for business continuity management.
• Incident management. NCSC guidance on planning for and responding to cyber incidents.
• Backing up your data. NCSC guidance for small organisations.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call