PDCA cycle: what is it, and how do you apply it within ISO 27001?

Key takeaway

Documenting Plan, Do, Check and Act won’t make your ISMS mature. What makes it mature is the way the four phases connect. Risks drive your controls, you implement those controls and measure how well they work, and what you learn shapes the next cycle. Without that loop, PDCA is just four separate activities. With it, you have a management system that improves over time.

Plan, Do, Check, Act. It sounds simple, and in theory it is. The cycle is almost a hundred years old, and ISO 27001 is still built around it. Knowing the four steps is easy. Making them work in a real ISMS is where most organisations struggle. This blog explains what PDCA means in an ISO 27001 context, how each phase fits the standard, and the most common mistakes to avoid when building your information security management system.

 

PDCA in a nutshell

PDCA stands for Plan, Do, Check, Act: four steps you repeat to improve a process in a structured way. It isn’t a quick fix, and you’re never really “done”. Risks, vulnerabilities and threats keep changing, so the cycle has to keep running. You adjust, then go round again. Without that repetition, cybersecurity becomes a collection of loose pieces: a firewall here, a training session there, and nobody checking whether it all still holds together.

 
  1. Plan: where are your risks, and what will you do about them?
  2. Do: put those measures into practice.
  3. Check: do they hold up under pressure? Test them.
  4. Act: what have you learned, and how will you feed that into the next cycle?

The PDCA cycle, also known as…

PDCA is also known as the Deming cycle or the Deming wheel. Confusingly, the man whose name is most often attached to the method never called it that himself.

Who invented the PDCA cycle?

The method was first developed by Walter A. Shewhart, an American physicist and quality pioneer. In the 1930s, he was working at Bell Labs on a practical problem: how to produce telephone components that were consistently free of defects. He called his model the Shewhart cycle and based it on the scientific method: hypothesis, experiment, evaluation. The term PDCA (Plan-Do-Check-Act) wouldn’t appear until later.

What is the difference between PDCA and PDSA?

William Edwards Deming, a protégé of Shewhart, took up the concept and brought it to Japan in the 1950s. From there, it became known around the world, which is why the method also carries his name. The term PDCA as we know it today only emerged during that period: Japanese participants in Deming’s lectures reworked his model into “Plan-Do-Check-Act”. Deming himself never adopted that term. He preferred Plan-Do-Study-Act (PDSA), because he felt “Study” better captured the point. For him, the third step meant learning from what had happened, not merely checking it.

In practice, the distinction makes little difference. Whether you say PDCA or PDSA, the underlying idea is the same: structured, continuous improvement.

Is the PDCA cycle still relevant today?

You won’t find PDCA mentioned in ISO 27001 anymore. But the principle is still very much there. You can still apply it to the clauses of the standard, even if the text itself no longer uses the term. That’s why PDCA remains a useful lens: once you sort the clauses into four familiar steps, they become far easier to understand and put into practice. And it gives you a practical way to achieve the continual improvement that every ISO management system standard requires.

Clauses 1 to 3 (Scope, Normative references, Terms and definitions) are left out of this overview. They are purely informative and contain no actual requirements. The real work starts at clause 4.

What does the PDCA cycle look like in practice within ISO 27001?

On paper, it sounds simple. But if you’re building an ISMS today, four abstract words won’t get you very far. Each step needs to be made concrete. Which risks do you identify in Plan? Which measures belong in Do? How do you test in Check whether they actually work? And what does adjusting course look like in practice in Act?

Here’s how the four steps translate into an ISO 27001 implementation:

1. Plan

  • Map the context of your organisation: internal and external issues, and who your interested parties are
  • Define the scope of the ISMS: which processes, locations and systems does it cover?
  • Get management involved: have them help shape the information security policy and actively champion it, rather than simply sign it off
  • Assign roles and responsibilities
  • Carry out a risk assessment: identify your critical business processes and the risks attached to them, and set the criteria you’ll use to evaluate those risks
  • Use the results to decide on risk treatment: which measures take priority?
  • Set measurable information security objectives
  • Provide the resources, competence, awareness and communication needed to actually carry all of this out

2. Do

  • Implement technical measures (e.g. multi-factor authentication, network segmentation)
  • Roll out new procedures, such as an incident response plan
  • Train staff and management on their role within those procedures

3. Check

  • Continuously monitor whether your measures are working effectively
  • Collect metrics such as response times or the number of reported incidents
  • Analyse reported incidents and near misses
  • Evaluate that data: do the results meet the objectives you set?
  • Carry out internal audits to formally check whether the ISMS as a whole still meets the standard
  • Test your readiness through exercises (e.g. a phishing simulation or a tabletop exercise)

4. Act

  • For every nonconformity or incident, look beyond the symptom and find the underlying cause: root cause analysis
  • Update policies and procedures based on those audit findings or incidents
  • Escalate structural shortcomings to management
  • Feed the lessons learned back into the Plan phase, so the next cycle starts with a clearer picture instead of the same blind spot

What are common PDCA mistakes in an ISO 27001 implementation?

Risk assessment done. Finished?

You can have a technically flawless risk assessment. But if nobody owns it, nobody has the time or resources to act on it, and management doesn’t back it, it’s just another file sitting somewhere in the cloud.

Many organisations reduce Plan to a single step: the risk assessment. It’s important, of course, but it only covers clause 6. The full Plan phase also includes the context of the organisation (clause 4), leadership and management commitment (clause 5), and the resources and competence needed to act on it (clause 7).

Published. But put into practice?

Clause 8 covers operation, and in this context that means more than publishing a policy on the intranet. You need an operational plan: concrete actions, each with an owner and a deadline.

Having a policy is a statement of intent. Implementing it means acting on it, day after day. As long as a policy isn’t reflected in how people actually work, it still belongs in Plan.

Checking once a year? That’s not “Check”.

The internal audit (clause 9.2) is the best-known part of Check, but it isn’t the only one. Clause 9.1 requires monitoring and measurement: continuously assessing whether your measures work, not only when the auditor is due. An organisation that only checks once a year misses everything that changes in between. Check also includes the management review (clause 9.3), where management assesses whether the ISMS is still relevant and effective, and what needs to change.

In short, Check is an ongoing process of measuring and following up, with the annual internal audit and management review as formal checkpoints on top. Without that ongoing monitoring, you may only discover at the next audit, sometimes months later, that something went wrong long ago.

The hole is patched. The problem remains.

When something goes wrong, whether an audit finds a nonconformity or a real incident occurs, most organisations assume Act simply means fixing that one issue. A vulnerability has been found? Roll out the patch, tick the box, done.

Clause 10 asks for more. You also need to investigate the root cause: why the problem happened in the first place. Only when that root cause is fed back into Plan does the cycle truly close. That’s how you prevent the same weakness from resurfacing a few months later in a different form.

Subscribe op onze nieuwsbrief

Ontvang updates rond onze blogs, events en meer.


Cingulum doet er alles aan om je privacy te beschermen en te respecteren. Je kunt je op elk moment afmelden voor onze mailings. Voor meer informatie over hoe wij jouw gegevens verwerken, lees ons privacybeleid.

More To Explore

Maak kennis met ons.

Plan een vrijblijvend kennismakingsgesprek in met een van onze experts. Samen zoeken we naar de beste securityoplossing voor jouw organisatie.

Consultants working together