A method dating back to the 1930s, yet it still underpins almost every ISO certificate, every audit and every compliance manager’s spreadsheet. How can a model that’s nearly a century old still be so alive and kicking? In this blog, we explain what the PDCA cycle actually is, how it forms the foundation of ISO 27701, and which pitfalls come up most often when applying it to a privacy programme.
It’s a way of thinking.
The Plan-Do-Check-Act (PDCA) cycle has survived thanks to its versatility. It’s a way of thinking about improvement that applies to almost any process. And while other methods such as Six Sigma and Lean came along later, they didn’t replace PDCA. They were built on the same logic. Strip away the layer of technical jargon and you’ll find the same four steps in each of them. As long as there are processes to improve, that core principle will stand. Even when we run those processes with data analytics or AI instead of pen and paper.
What is the PDCA cycle?
The PDCA cycle is a four-step method (Plan, Do, Check, Act) that helps you improve processes gradually and in a repeatable way.
- Plan: decide what you want to improve and how you’ll go about it.
- Do: put that approach into practice, ideally on a small scale first.
- Check: assess whether the result matches what you set out to achieve.
- Act: adjust based on what you’ve learned, then repeat the whole cycle.
You probably already apply this logic without even realising it. Trying out a new recipe? You’ll likely give it a test run first. Too bland? You adjust the seasoning. Taking too long to cook? You tweak the temperature. Only when the result is right do you serve it to your guests. Adjusting a training plan after noticing it isn’t working follows the very same logic. That, in essence, is exactly what the PDCA cycle does. The difference is that it’s applied in a structured way to a process, tool or department within an organisation, or to the organisation as a whole.
The PDCA cycle, also known as…
PDCA is also known as the Deming circle or the Deming wheel. Confusingly enough, the man whose name is most often linked to the method never called it that himself.
Who invented the PDCA cycle?
The method was originally developed by Walter A. Shewhart, an American physicist and quality pioneer who worked at Bell Labs in the 1930s on a key question: how do you consistently produce telephone parts without defects? He called his model the Shewhart cycle and based it on the scientific method: hypothesis, experiment, evaluation. Incidentally, the term PDCA (Plan-Do-Check-Act) didn’t exist yet at that point. That came later.
What is the difference between PDCA and PDSA?
William Edwards Deming, a student of Shewhart, adopted the concept in the 1950s and took it to Japan, where it gained worldwide recognition. That’s why the method also bears his name. The term “PDCA” as we know it today only emerged during that period: Japanese attendees of Deming’s lectures reworked his model into “Plan-Do-Check-Act”. Deming himself never used that term, though. He spoke of Plan-Do-Study-Act (PDSA), because he felt “Study” was the better word. To him, the point was to genuinely learn from what had happened, rather than simply to check it.
In practice, the distinction makes little difference… whether you say PDCA or PDSA, it comes down to the same underlying idea of structured, cyclical improvement.
Is the PDCA cycle still relevant today?
Yes, and that’s no coincidence. Take the standard that’s making waves in the privacy world right now, ISO 27701. It’s built on the same fixed structure of chapters, known in ISO terms as “clauses”. These aren’t optional guidelines. They’re literally the chapters you’ll find in the official text of the standard itself. To obtain and maintain certification, your organisation must be able to demonstrate that it complies with every single clause. On top of the mandatory internal audits your organisation has to carry out periodically, an external auditor checks this again each time. And at its core, that structure is nothing more than Plan-Do-Check-Act in a different guise.
- The clauses “Context of the organisation”, “Leadership”, “Planning” (including the risk assessment) and “Support” together make up your Plan phase. This is where you define what your organisation does, who is responsible for what, which risks are at play and which resources and competences you need.
- The “Operation” clause, where you actually implement the measures, is your Do phase.
- The “Performance evaluation” clause, covering internal audits and management review, is your Check phase.
- And the “Improvement” clause, with its corrective actions, is your Act phase.
This means that a certification audit for ISO 27701 always assesses you against the same framework: did you plan, did you implement, did you check and did you adjust? In other words, PDCA is the very blueprint the standard is built on.
What does the PDCA cycle look like in practice within a privacy programme?
The answer becomes clearest when you apply the four steps to an actual ISO 27701 project. After all, if you want to achieve ISO 27701 certification, there’s no way around this cycle.
The four steps of the PDCA cycle in a privacy context.
- Plan:
- Map out your processing activities (Record of Processing Activities, or ROPA)
- Identify risks through a PIA (Privacy Impact Assessment)
- Set privacy objectives (e.g. reducing the amount of unnecessarily collected data)
- Do:
- Implement technical and organisational measures (e.g. encryption, access management)
- Test a new procedure or tool in a single department first, before rolling it out across the organisation
- Train employees on existing and new procedures
- Check:
- Carry out internal audits
- Analyse data breach notifications and complaints
- Use spot checks to verify whether procedures are actually being followed
- Act:
- Update policies and procedures based on audit results
- Include structural shortcomings in the management review
- Embed improvements structurally so they last, and demonstrate this during your next ISO 27701 certification audit
A single PDCA cycle rarely solves everything in one go, and that’s not the intention either. The first time you work through your Record of Processing Activities, you’ll mainly discover where the gaps are. Only after a few cycles do you start to recognise patterns: which departments are structurally lagging behind, which risks keep coming back and where your policy still needs fine-tuning. That’s how a privacy programme grows: in small, measurable steps rather than giant leaps.
To find out where you stand in terms of maturity, you don’t need to wait until you’ve completed a few cycles yourself. With this self-assessment, you can map your organisation’s current maturity level in just a few minutes. It’s a great starting point if you want to know straight away where your first or next cycle should focus. Because once you know where you stand, the next question follows naturally: what’s the best next step? Our colleagues wrote a comprehensive e-book on exactly that, Privacy in practice: How to build a programme that really works.
What are common PDCA mistakes within a privacy programme?
A good model is worth very little when it’s applied carelessly. On paper, the Plan-Do-Check-Act cycle looks easy to apply, with four simple steps you can repeat endlessly. On the work floor, however, it can quickly turn into an empty formality. These are the four pitfalls we see most often when organisations use PDCA within a privacy or ISO 27701 project.
1. The Check phase becomes a formality instead of an evaluation.
An audit may be completed, but the real question remains: does the organisation actually do what its policy prescribes? A Record of Processing Activities can look perfect on paper and still fail to reflect everything employees do day to day. Here, “Check” means asking whether reality matches what’s written down, rather than simply whether the document exists. The Check phase should really be seen as an investigation that verifies whether the document truly corresponds to what employees actually do.
Ultimately, responsibility for a proper Check phase lies with the business itself, even though it’s usually the DPO (Data Protection Officer) who takes the initiative: kicking off a ROPA update, giving advice or organising training. That supporting role has the best chance of success with enough time and complete information about what’s happening within the organisation. In practice, the DPO doesn’t always receive that information in time or in full. That’s why even the most motivated DPO depends on what departments choose to tell them. And so this phase becomes exactly what it should never be: a formality.
Sound familiar? The DPO’s annual questionnaire asks: “Does your team use any new tools that process personal data?” The sales team answers with a confident “no”. They’re not lying. It simply never occurred to them that the AI note-taking tool they’ve started using during client calls counts as “a tool that processes personal data”.
Tip: link your Check phase to verifiable evidence, as a questionnaire alone isn’t enough. The DPO must be able to investigate, rather than just ask around.
2. Documentation is mistaken for improvement.
An internal privacy policy that’s “reviewed” every year, yet only the date at the top ever changes… It shouldn’t happen, but we come across it more often than you’d think. It’s usually down to a lack of time, cost-cutting or other priorities. As long as nothing happens in the Act phase, or as long as that phase has no concrete impact on processes or behaviour, it’s nothing more than window dressing.
Sound familiar? The Record of Processing Activities is neatly updated to a two-year retention period for job applicant data. Once the document has been updated, the task is considered done. Nobody ever set up automatic deletion in the recruitment tool, so CVs from candidates five years ago are still being kept…
Tip: make sure every policy change is carried out as a concrete action.
3. No ownership per phase.
Even when a DPO does everything right, things can still go wrong. It isn’t their job to hold departments accountable or force them into action. Put differently, the DPO informs, advises and monitors, but has no authority to make the IT department change a system. That responsibility stays with the organisation or its management. Ideally, ownership is defined as early as the Plan phase. Management typically appoints a specific owner or SPOC (Single Point of Contact) for each process, often in consultation with the DPO. If that doesn’t happen, findings from internal audits may well end up gathering dust in a report without ever being followed up. Without a clear owner per phase, the cycle grinds to a halt at precisely the moment it matters most.
Sound familiar? Last year’s audit report still contains a few open action points. Nobody ever picked them up, because they were assigned to “the team”, and no one in “the team” felt personally responsible.
Tip: link every finding to a name and a deadline. Make sure unresolved action points are escalated to management.
4. The cycle stops after one round.
Is it wise to wait until the next audit to review your Record of Processing Activities or PIA? Absolutely not. Yet many companies don’t give it a second thought, as there will always be other priorities. Understandable, but that’s how your Plan-Do-Check-Act cycle comes to an abrupt end. Over time, the same gaps creep back in. New processing activities go unregistered and responsibilities shift without the policy keeping pace.
Sound familiar? The Record of Processing Activities was originally drawn up by the HR manager as an extra task alongside their day-to-day work. Since then, no fixed moment has ever been scheduled to review it. It’s just sitting somewhere on a shared drive.
Tip: schedule periodic reviews.
