The Deming Cycle – view it as a framework for action

By | 2nd August 2018

The Deming Cycle has been around for a long time in information assurance and information security. It crops up in almost every introductory course on these topics, and can be found in a variety of frameworks and standards – for example, ISO/IEC 27001:2005 made the Deming cycle a core part of the ISMS until the 2013 version of the standard made it less prominent.

Also known as the Plan-Do-Check-Act cycle (PDCA), it was originally developed for industrial processes and has found wider application outside of it’s original business sectors. It’s similarity to the scientific method is not an accident, it being a basis for the cycle.

Like many management techniques, a layer of complexity masks its ready application requiring further analysis and study. Viewing it as a course concept in passing, and not putting it into action is also common. It really needs to be embedded in an organisational setting to have the fullest impact.

PDCA is a continuous loop, iterating through four stages: Plan, Do, Check and Act. It’s the core of the ISMS continuous improvement activity in 27001:2005, and is put forward outside of 27001 as a general information security management technique in many places.

What can we scope out for the PDCA stages? Let’s pull apart PDCA to see what we can learn from it, and how it could be applied.

Central to PDCA are problems (or “challenges”). These are inefficiencies, issues and underperforming processes where improvement is sought. We step through the PDCA stages to find a way forward to optimise or address these challenges.

Plan – in the plan phase we should be identifying problems, the stakeholders, setting measurable goals, work out what problem(s) we are experiencing, set out the statement of the problem. We should also develop and understanding of the system as-is, which is experiencing the problem and use this to work out the causes of the issues being experienced, allowing us to collect data and start to zero in on the most likely cause.

Do – armed with our understanding of the problem and the relevant systems and processes related to it, in this phase we set out the experiment we are going to execute including the success criteria. These experiments are “in test” and not production. Throughout this process, we communicate with the stakeholders as the experiments are executed. As experiments are executed, we collect data for later analysis.

Check – with the experiment(s) completed, we collate the data and analyse the results. We look at our original hypotheses from the Plan phase, and decide if they were correct or not. If we’re not happy with the original hypotheses, we go back to the Plan phase and update them, repeating the experimentation. If we are happy with the hypothesis, experiment, and experimental data, we move onto the next phase (Act).

Act – in this phase we’re going to put in place the production version of the tests undertaken in the Do phase (experiments). We’ve identified the improvements we need to make, and so this phase is concerned with productionizing the full scale solution. This covers all the familiar topics of production service introduction. Monitoring should be a key part, as well as continuous improvement. Training, standardisation, and development and embedding of new processes are expected here.

So, looking at the above, we can see PDCA is a loop, but the feedback from the Check to the Plan phase in the event of experimental data that does not meet the criteria is often overlooked. It is not, strictly speaking, a plain cycle.

Plan, Check and some elements of Act are an excellent basis for agendas in my view, and the entire framework is a good a place as any to manage INFOSEC in organisations large and small. While the leg work of putting place experiments and productionising processes is more suited to tigers teams and similar, the cycle is highly beneficial to both technical security and assurance activity.