Please note that this is a page from a previous version of Continuity Central and is no longer being updated.

To see the latest business continuity news, jobs and information click here.

Business continuity information

Plan-Do-Check-Act: what’s it all about?

In the fourth and final article of a series discussing subject areas aimed at those managing a business continuity management system (BCMS) and in particular, those systems certified to ISO 22301, Hilary Estall looks at the Plan-Do-Check-Act (PDCA) model found in management system standards, such as ISO 22301. Is it just another acronym to be banded about by those in the management systems ‘know’ or does it translate into something meaningful? What does the PDCA model add for those involved in implementing a BCMS?

During this short series of articles I have so far focused on aspects specifically about BCMS auditing but I wanted to end with a broader subject. For those of you who are familiar with management system standards, whether it be ISO 22301 or another British or International standard, you will understand the concept of the PDCA cycle. I am not about to regurgitate this for you, but think there is merit in taking a closer look at its make-up.

The PDCA Model – A quick history lesson

The Plan-Do-Check-Act model (or cycle as it used to be referred as) has been around for quite a while. It is also known as the Deming Cycle and came into existence when two Americans, Dr Deming and Dr Juran, were considering the impact of Kaizen, the Japanese philosophy of continuous improvement, in the 1970s. Today, when management system processes are identified in a standard, each process is categorised into one of the four PDCA phases. ISO 22301 is no different.

Components of PDCA in terms of business continuity management systems

When you first obtain your copy of ISO 22301 you will probably turn to the page which starts to describe the requirements. Even better, you may start by reading through the Terms and Definitions in Section3 . What you may not have done is read through the preamble in pages iv – vi. For those of you with a copy of the standard, I suggest you take another look and for those readers who don’t have a copy of ISO 22301, I’ll talk you through one section in particular, the Introduction.

The PDCA model applies to the ‘Requirements’ of a management system standard (MSS) and thanks to the publication of Annex SL, this now follows a similar format for all new and revised MSS. We can therefore apply the model to ISO 22301 clauses 4 through to 10.

The components of PDCA in ISO 22301 are stated as follows:

Clause 4 is a component of Plan. It introduces requirements necessary to establish the context of the BCMS as it applies to the organization, as well as needs, requirements, and scope.

Clause 5 is a component of Plan. It summarizes the requirements specific to top management’s role in the BCMS, and how leadership articulates its expectations to the organization via a policy statement.

Clause 6 is a component of Plan. It describes requirements as it relates to establishing strategic objectives and guiding principles for the BCMS as a whole. The content of Clause 6 differs from establishing risk treatment opportunities stemming from risk assessment, as well as business impact analysis (BIA) derived recovery objectives.

NOTE. The business impact analysis and risk assessment process requirements are detailed in Clause 8.

Clause 7 is a component of Plan. It supports BCMS operations as they relate to establishing competence and communication on a recurring/as-needed basis with interested parties, while documenting, controlling, maintaining and retaining required documentation.

Clause 8 is a component of Do. It defines business continuity requirements, determines how to address them and develops the procedures to manage a disruptive incident.

Clause 9 is a component of Check. It summarizes requirements necessary to measure business continuity management performance, BCMS compliance with this International Standard and management’s expectations, and seeks feedback from management regarding expectations.

Clause 10 is a component of Act. It identifies and acts on BCMS non-conformance through corrective action.

[Source BS ISO 22301:2012]

To me, this brief look at how the PDCA applies to a BCMS provides one glaring observation; the majority of time, focus and effort has to be placed on planning the BCMS. Not writing the plan, exercising it or reviewing its effectiveness (although these are all important BCMS activities!) So why do organizations still miss this point and rush into developing the business continuity management elements?

Perhaps we need to take a step back and remind ourselves what the purpose of a (BC) management system is. By establishing a set of controls and processes including policies and objectives, an organization is able to measure its effectiveness in achieving these objectives and therefore gauge improvement. The elements by which this is measured will include the structure of the organization and its context in the wider community, its resources and management support, its planning activities, operation and processes by which it measures its performance. In other words, there’s a whole lot to do before you get to developing business continuity management arrangements. My one caveat to the PDCA model across clauses 4 to 10 is that, in my opinion, developing a business impact analysis should also come under the planning phase. The purpose of the BIA is to understand business activities and how they may be affected during and following a disruption. The output of this supports the need to plan how best to prioritise resumption of these activities. Essentially, during the BIA process the organization is trying to fully ‘understand itself’.

In my capacity as an auditor, my experience of organizations coming to ISO 22301 and therefore business continuity management is very mixed. Some have existing knowledge of BCM but have rarely developed a BCMS and vice versa. The desire to go straight to the development stage of BCM is clear and to some extent understandable, but probably because the intent of a management system is lost in the context of the standard’s main subject area. There may be pressure from management to develop plans in order to placate would be customers or meet the demands of tender applications. But if the end goal is to develop a BCMS, time spent thinking about what it is the business wants and needs and who it’s doing it for, will pay dividends later on.

Tips for planning your BCMS:

1. Identify the intended purpose and outcomes of the BCMS; what do you want it to give you and why?

2. Having ascertained who your interested parties are, carry out a detailed analysis of what you believe they expect from your business. Are there assumptions being made over and above what has been laid down in a contract?

3. Have you agreed a realistic timescale for developing the BCMS? Are there specific pressures dictating this and how might they impact on implementation?

4. Has your management team agreed to provide suitable and sufficient resources to support the implementation and maintenance of a BCMS? Do you/they really understand what’s involved?

5. Identify the risks and opportunities associated with implementing and maintaining a BCMS. Now is the time to be honest and flag up potential issues which could prevent you achieving your BCMS objectives. Lack of resource is a regular reason cited!

6. Establish a Business Continuity Policy which reflects your business, its needs and strategic goals. Don’t be tempted to copy someone else’s!

7. Identify business continuity objectives which reflect your business aspirations and remember that they must be measurable, relevant and allocated to suitable resource for monitoring and, ultimately, achievement!

8. Determine the level of information required by the various groups of interested parties (staff, contractors, suppliers etc) and develop a programme of communication events. Be clear on who needs to know what and when.

9. Decide how you will document your BCMS and make it accessible to all appropriate parties. (This may be determined by existing systems or use of company wide information portals).

10. Determine a suitable scope for the BCMS. Drivers for this may include customer or supplier requirements or operational boundaries. Too narrow and it may be meaningless for the organisation but too broad and it may be unwieldy to implement in one go.


Managing the expectations of senior management can be a tricky business at the best of times but if they are not given the opportunity to fully comprehend what’s involved with developing (and maintaining) a BCMS, they will be reluctant to give the necessary support (particularly manpower) to the programme. If you have been tasked with implementing a BCMS, it rests with you to provide a balanced view on how it will materialise and the potential threats along the way.

If I can offer one piece of advice to you it is to PLAN your BCMS carefully, be realistic in your goals and develop a clear implementation programme to follow. Good Luck.

The author

Hilary Estall, MBCI and IRCA BCMS Lead Auditor is Director of Perpetual Solutions Limited, a business continuity and management systems consultancy practice.


•Date: 4th September 2014 • UK/World •Type: Article • Topic: Business continuity standards

Business Continuity Newsletter Sign up for Continuity Briefing, our weekly roundup of business continuity news. For news as it happens, subscribe to Continuity Central on Twitter.

How to advertise How to advertise on Continuity Central.

To submit news stories to Continuity Central, e-mail the editor.

Want an RSS newsfeed for your website? Click here