Volg ICTI

Information security and PDCA (Plan-Do-Check-Act)

| Sieuwert van Otterloo | Security

Standards such as ISO 27001 require you to use a method for continuous improvement in your information security policy. PDCA or Plan-Do-Check-Act is the preferred method for most information security teams and we recommend you to use this method, described in this article.

The steps of  PDCA

PDCA can be applied whenever you consider making a change in your organisation. Whenever you decide to install new firewalls, change the content of a training, decide on a new policy or ask people to change the way devices are installed. For each change, the basic four steps are the same: Plan – Do – Check – Act.

  • Plan: Before changing anything, you need to write down what activity you are trying to improve, how you will determine the effect of the change. There must be some way of measuring effectiveness. You should also know what the current value is before improvement and what the target or expected value is after the change. The metric can be anything as long as it is relevant to your company. It can be number of incidents, time spent on device configuration, or the average score of a security quiz. Ideally it relates to organisation goals, such as customer value, cost savings or time to market.
  • Do: Once you have goals, metrics and before-value, you make the change that you intend to make. This can be installing the new firewall, modify the training, or install devices in a new way.
  • Check (or Study): Once the change has been made you should be able to measure the effect by looking at changes in the metrics. You will of course expect an improvement, but take care to actually measure what has happened. Many improvement actions will result in no change or even a worsening. For instance if you add more material to a training, it is possible that the training becomes too difficult for people to follow and they actually learn less.
  • Act: The action will depend on the result of the check step. If the change was successful, you should make the change permanent by instructing everyone, updating documentation or modify process description. You should also update the ‘current values’ of your metrics: the new better values after the change should become the baseline value for future improvements. If the change was not an improvement.

The image below, inspired by a similar image by Johannes Vietze on Wikipedia, illustrates the idea of adjusting the metrics every step. After a successful change you reach a higher quality level and the new level becomes the baseline for evaluating the next change proposals.

PDCA_Deming-Improvement

The origins of PDCA: The Deming cycle

W._Edwards_DemingPlan-Do-Check-Act is also called the Deming Cycle because it was popularised by William Edwards Deming (image from Wikipedia). Deming was an American productivity consultant who lived from 1900-1993. Deming himself popularised his improvement cycle when visiting Japan after the second world war. He based his ideas on continuous improvement on the work of Walter Shewhart, and always referred to ‘his’ cycle as the Shewhart cycle.

The cycle is called Plan-Do-Check-Act because it consists of these four steps (plan, do, check and act). Deming himself renamed the check step to study, so a better name would have been Plan-Do-Study-Act or PDSA. Whatever name you choose, it all refers to the same framework for achieving continuous improvement. Deming developed the cycle when teaching in Japan in the 1950s.

The cycle was invented for improvement of manufacturing processes, but is now used for all kinds of processes, including enterprise processes such as information security. It was actually a mandatory method is the 2005 version of ISO 27001. In the current 2013 version one can choose which improvement method to use. PDCA is still the most commonly used method, either because of its simplicity or because it is easily mapped to existing continuous improvement efforts in an organization.

Why continuous improvement is important

PDCA is based on the idea of continuous improvement. This idea of continuous improvement is actually more important than the exact steps of PDCA. The PDCA/PDSA model was developed to aid improvement in production processes. Different assembly factories such as car factories used to have large differences in productivity. Experts such as Deming were hired by companies in order to understand these differences and make improvement to less efficient factories to make them more efficient.

One of the key insights from these expert visits is that one cannot improve a factory in one step. Each factory has a complex process with many different activities that are interdependent. Each factory has many smaller inefficiencies in many different steps, that all add up to the difference in productivity. A consultant visiting once is not able to pinpoint one big issue and make a single improvement. Consultants therefore concluded that they should not focus on immediate changes. Instead they focus on creating a culture of continuous improvement. They teach line workers, team leaders and other staff the importance of improving their part of the process. Indeed of Deming’s key principles is:”Put everybody in the company to work to accomplish the transformation”. The entire factory staff is thus responsible for and involved in identifying issues and proposing process changes.

The importance of experiments and validation

Another core idea behind PDCA is the importance of experimentation and validation. PDCA is based on an experimental, data driven approach to improvements. For example, suppose one factory worker believes a part is redundant, and proposes to just leave out the part. This proposal is interesting but risky. It does save time and money to leave one part out of a car. However one cannot be sure without careful testing whether this causes problems later on in the production process or the finished product. PDCA handles this problem by insisting on measuring the results of changes, and having people evaluate each change to see if it actually works. This idea of continuous improvement is now part of many improvement methodologies, such as the Toyota Production System, Total Quality Management, Lean manufacturing and Six Sigma.

Within information security, there is a risk of getting stuck at a mediocre security level. After the initial start of the information security team, the easy fixes are implemented and it will not be clear which controls are important and which are more trouble than value. Experimentation and validation will help you to only implement valuable controls.

Note that when you use a standard such as ISO 27001 or Security Verified, the idea of continuous improvement will be implemented at multiple layers. The internal audit plan is an example of an annual PDCA cycle. The information security team meetings will be based on PDCA. In each information security area, you will probably implement checks and information collection steps that provide feedback loops.

Applying PDCA in practice

In order to apply Plan Do Check Act, you first need to make sure that information security is seen a recurring activity and not as a project. This is why our recommended first step for information security is to create a permanent information security team. Once the team is in place, we recommend that the team implements PDCA in the following way:

  • A regular information security team meeting is scheduled at fixed intervals (e.g. monthly or quarterly). Having regular meetings (both with the team and with management) helps in getting continuous improvement.
  • The information security team meeting should have an agenda based on PDCA. So a first step could be to look back at the metrics and the feedback on last meetings decisions (Check/Study), make decisions about the previous changes (Act) and then to decide on new actions / controls to implement (Act). The ‘Do’ happens between the meetings.
  • You should also apply continuous improvement to the way the information security team works. You can do this by ending information security meetings with a short feedback round on the effectiveness of the meeting
  • The ‘check’ part is often facilitated by including feedback collection in every activity. For instance any meeting, training or workshop can start with a quiz to understand initial knowledge and end with a feedback form where people can provide feedback and suggestions on the training.
  • When discussing new controls to implement, the security team should understand that measuring effectiveness is necessary in order to improve. One way to do this is by first implementing controls that generated new data, such as logging, before implementing controls that restrict users.
  • It is important that you are not running too many experiments. The idea behind PDCA is that you do experiments one after another. If you run multiple experiments there is a risk that two experiments have an impact on the same metric. If this happens, you will not know which of the experiments worked and you have to redo the experiments. Good information security teams therefore take their time and make only a few changes every month or quarter.

The PDCA method is typically included in the information security policy document  and explained briefly in information security trainings. One of the simplest ways to include this is by including a link to this page or to another book/reference explaining the method.

More information

This article is part of our series on information security. Other articles in the series are getting started with information security,  asset inventorybasic risk managementpassword policytwo factor authentication, and cryptographic controls. This series was created in order to help obtain organisations obtain information security certification.

For more information on the historic background of PDCA and Deming, we recommend the paper ‘Evolution of the PDCA cycle’. An interesting book on the manufacturing background of continuous improvement is ‘The machine that changed the world‘.

 

Author: Sieuwert van Otterloo
Dr. Sieuwert van Otterloo is a court-certified IT expert with interests in agile, security, software research and IT-contracts.