The PDCA Cycle in the ISMS: Plan-Do-Check-Act in Practice

Where Does the PDCA Cycle Come From?

The PDCA cycle traces back to the American physicist and statistician W. Edwards Deming, who popularized it in the 1950s as a tool for systematic quality improvement. Deming himself called it the "Shewhart Cycle," after his mentor Walter A. Shewhart, who had developed the basic concept as early as the 1930s. In Japan, where Deming significantly influenced the industrial quality movement after World War II, the cycle became the core element of Kaizen (continuous improvement) and shaped the rise of Japanese manufacturing.

The basic idea is compellingly simple: instead of solving problems once and then moving on to the next topic, improvements go through an endless loop of planning, implementation, review and adjustment. Each iteration brings the system one step closer to the ideal state. What worked in industrial manufacturing is excellently suited for management systems — and that is exactly why ISO has made the PDCA cycle the structural foundation of all modern management system standards.

ISO 27001 removed the explicit reference to PDCA from the normative text in the 2013 version and instead introduced the High-Level Structure (Annex SL), which provides a uniform framework for all ISO management systems. Nevertheless, the PDCA cycle is clearly recognizable in the structure of the standard: Sections 4-7 cover "Plan," Section 8 corresponds to "Do," Section 9 is "Check" and Section 10 stands for "Act." The logic remains identical; only the packaging has changed.

The Four Phases in the ISMS Context

Plan: Understand, Assess, Plan

The Plan phase is the foundation for everything that follows. Here you analyze the context of your organization, identify interested parties and their requirements, define the scope of your ISMS and establish the information security policy. The core of the Plan phase is the risk assessment: you identify threats and vulnerabilities, assess the likelihood and impacts of potential security incidents, and prioritize risks by criticality.

Based on the risk assessment, you create the risk treatment plan. For every risk above the defined acceptance level, you select a treatment option (mitigate, transfer, avoid or accept) and plan concrete measures. You define who is responsible for implementation, by when the measure should be implemented and what resources are needed.

The Plan phase does not end with a one-time analysis. With each cycle, you return here to reassess the risk landscape, check measures for currency and incorporate new requirements. Typical triggers for a renewed planning phase are changed business processes, new legal requirements, audit results or findings from security incidents.

In the ISMS, the Plan phase includes:

• Analyzing the organization's context (ISO 27001, Section 4)
• Defining the scope
• Establishing the information security policy
• Performing risk assessment and risk treatment planning
• Creating the Statement of Applicability (SoA)
• Defining security objectives and action plans
• Planning resources, competencies and communication channels

Do: Implement, Train, Operate

The Do phase brings plans to reality. Here, the planned security measures are implemented, policies are published, technical controls are configured and employees are trained. This sounds straightforward but is in practice the phase where most challenges arise. Between a well-formulated action plan and lived implementation, there is often a considerable gap.

A typical example: in the Plan phase, you decided to introduce multi-factor authentication for all remote access. The Do phase then encompasses selecting and procuring the MFA solution, technical integration into the existing infrastructure, creating instructions and training materials, piloting with a test group, rolling out to all users step by step, and updating the relevant policies.

In parallel with implementing individual measures, the Do phase includes the ongoing operation of the ISMS. This involves handling security incidents, patch management, managing permissions, conducting awareness training and maintaining ongoing documentation. The Do phase is not a one-time implementation phase but the steady state in which your ISMS spends most of its time.

In the ISMS, the Do phase includes:

• Implementing security measures
• Introducing policies and procedures
• Conducting awareness training
• Configuring and operating technical controls
• Handling security incidents
• Maintaining documentation
• Living operational processes

Check: Measure, Verify, Evaluate

The Check phase is the conscience of your ISMS. Here you verify whether the measures from the Do phase actually work, whether the defined security objectives are being met, and whether the ISMS overall meets the standard's requirements. Without a serious Check phase, you would not know whether your security measures exist only on paper or actually make a difference.

The most important instruments of the Check phase are the internal audit and the management review. The internal audit systematically checks whether documented processes and controls are actually implemented and meet the standard's requirements. The management review evaluates the overall ISMS performance at leadership level based on KPIs, audit results, incident reports and changed conditions.

Beyond that, the Check phase includes regular monitoring and measurement of security metrics (e.g., number of security incidents, patch compliance, training completion rate), analysis of log data and monitoring results, review of individual measure effectiveness, and evaluation of penetration tests or vulnerability scans.

In the ISMS, the Check phase includes:

• Conducting internal audits (ISO 27001, Section 9.2)
• Holding the management review (Section 9.3)
• Measuring and evaluating security metrics (Section 9.1)
• Verifying measure effectiveness
• Documenting audit findings
• Analyzing trends and patterns in security incidents
• Checking conformity with policies and standard requirements

Act: Correct, Improve, Adapt

The Act phase closes the loop and initiates the next cycle. Here you respond to the findings from the Check phase: you address nonconformities, initiate corrective actions and implement improvements. The Act phase is the engine of continuous improvement — it ensures that problems are not only identified but also resolved.

For every nonconformity from an audit or every deviation from security objectives, you perform a root cause analysis. How you evaluate audit findings and derive actions is decisive here. Why did the problem occur? Is it due to a flawed process, inadequate training, insufficient resources or an outdated measure? The corrective action addresses not just the symptom but the cause, so the same problem does not recur.

Beyond correcting errors, the Act phase also involves proactive improvements. Perhaps the management review found that a particular process functions in compliance with the standard but is unnecessarily complex. Or a new threat landscape requires additional measures not envisaged in the original plan. These findings flow into the next Plan phase and continue the cycle.

In the ISMS, the Act phase includes:

• Addressing nonconformities (ISO 27001, Section 10.1)
• Performing root cause analyses
• Defining and implementing corrective actions
• Verifying the effectiveness of corrective actions
• Identifying and implementing improvement opportunities (Section 10.2)
• Updating the risk register and treatment plans
• Transferring findings into the next Plan phase

Concrete Example: Following a Risk Through the PDCA Cycle

Theory becomes tangible when you can follow it through a concrete case. Let us take a risk that exists in many mid-market companies: VPN connections for remote work are protected only with a username and password, without multi-factor authentication.

Plan: Identifying and Assessing the Risk

During the annual risk assessment, the ISMS team identifies the risk "Compromise of VPN credentials through phishing or credential stuffing." The assessment yields a high probability (phishing attacks are routine and stolen passwords are available in large quantities on the dark web) and high impact (an attacker with VPN access can reach the internal network and move laterally).

The risk is classified as "high" and the treatment option "mitigate" is selected. The planned measure: introduce MFA for all VPN connections. The IT manager is named as the risk owner, and a three-month implementation deadline is set. The estimated costs for licenses and implementation are documented in the risk treatment plan and approved by management.

Do: Implementing the Measure

The IT manager evaluates various MFA solutions and selects a TOTP-based solution with an authenticator app because it is cost-effective, requires no additional hardware and integrates well with the existing VPN infrastructure. Implementation runs in phases: first, the MFA solution is configured in a test environment and tested with a pilot group from the IT department. In parallel, the team creates a step-by-step guide for setting up the authenticator app.

After a successful pilot, MFA is rolled out department by department. Each department receives a brief introductory training session, and the helpdesk is prepared for typical questions and issues. Within six weeks, all 120 VPN users have been migrated to MFA. The VPN configuration is adjusted so that connections without a second factor are rejected from a defined cutoff date. The password policy and the remote access policy are updated.

Check: Verifying Effectiveness

Three months after full rollout, the ISMS team reviews the measure's effectiveness. The review covers multiple perspectives:

Technical verification: The VPN logs show that no connection without an MFA token is possible. A penetration test confirms that stolen credentials alone are no longer sufficient for VPN access.

KPI measurement: The number of successful login attempts with compromised credentials has dropped to zero. Previously, there were an average of two suspicious login attempts per month that indicated stolen passwords.

User feedback: Helpdesk tickets related to MFA declined to a minimum after an initial spike in the first month. Two employees complained that the additional step slows down the login, but this is operationally acceptable.

Audit finding: During the internal audit, it was found that five external service providers who also have VPN access have not yet been migrated to MFA because they are still contractually bound to the old access arrangement.

Act: Correcting and Improving

Based on the Check results, two actions are derived. First: the five external service providers will be migrated to MFA within six weeks, with contracts amended accordingly. This is a corrective action for the gap identified in the audit.

Second: the ISMS team recognizes that the measure is effective but has revealed an additional risk. TOTP codes can theoretically be intercepted through real-time phishing (adversary-in-the-middle). As a proactive improvement, migration to FIDO2-based phishing-resistant authentication for privileged accounts is proposed for the next planning cycle.

These findings flow into the risk register, the updated residual risk is reassessed, and the next PDCA cycle begins with an adjusted baseline.

Why Check and Act Are Often Neglected

Experience from countless ISMS projects reveals a recurring pattern: organizations invest substantial energy in the Plan and Do phases, then lose motivation for Check and Act. This has several reasons that reinforce each other.

The Feeling of Completion

After months of intensive work on policies, risk analyses and measures, it feels as though the work is done. The policies are written, the firewall is configured, the training has been delivered. The psychological urge to mark the project as "completed" and move on to the next topic is understandable — but fatal for an ISMS. An ISMS is not a project with a beginning and end, but a permanent process.

The Effort of Verification

Implementing measures feels productive. Measuring their effectiveness often feels like administrative overhead. Defining KPIs, preparing audit plans, conducting management reviews and evaluating results requires time and discipline but delivers no visible "new" result. Especially in small teams already under resource pressure, the Check phase is the first to be cut when things get tight.

Lack of Consequences

When no serious consequences follow an audit, when nonconformities are documented but never truly resolved, and when the management review is a box-ticking exercise without real discussion, then the entire PDCA cycle loses its effectiveness. The Act phase degenerates into lip service, and the next Plan phase is based on outdated assumptions.

What You Can Do About It

The key lies in institutionalization. Schedule internal audits and management reviews with fixed calendar dates, not as "we'll do it when we have time." Define clear KPIs with target values and review them quarterly. Ensure that every audit finding has an owner and a deadline and that implementation is actually tracked. And make the management review a genuine steering instrument where management actively makes decisions rather than merely acknowledging reports.

The Management Review as the Central Check Instrument

The management review is the most important instrument of the Check phase and at the same time the link between operational ISMS activities and strategic steering. ISO 27001 Section 9.3 defines mandatory inputs the review must consider: the status of actions from previous reviews, changes in internal and external issues, feedback on information security performance (incidents, KPIs, audit results) and opportunities for improvement.

An effective management review takes place at least annually — for dynamic risk landscapes, semi-annually or quarterly. It is not a mere information event but a decision forum: management decides on resource allocations, prioritizations and strategic adjustments to the ISMS. The management review minutes are mandatory documentation for certification and are regularly requested in external audits.

Typical decisions from a management review include approving additional budgets for new security measures, adjusting the scope, reevaluating risk acceptance criteria, or commissioning additional training. For the review to work, the ISO role must prepare results so that management can make informed decisions without wading through technical details.

Measure Tracking as an Act Tool

If the management review is the centerpiece of the Check phase, then consistent measure tracking is the centerpiece of the Act phase. Every measure arising from a risk assessment, audit, security incident or management review must be tracked: who is responsible? By when should the measure be implemented? How is effectiveness verified? What is the current status?

In practice, measure tracking often fails because of too many parallel systems. Audit findings land in one spreadsheet, risk assessments in another, incident measures in a ticketing system and management review tasks in meeting minutes. The result: no one has the overview, deadlines are missed, and at the next audit it turns out that half the measures are still open. Tools like ISMS Lite consolidate all measures in a central register with status, deadlines and responsible persons 500 Euro pro Jahr, without seat licenses, so the PDCA cycle does not fail because of documentation.

A central measure register in which all measures are captured and tracked regardless of their source solves this problem. It should contain at minimum: description, source (risk, audit, incident, review), responsible person, deadline, status, evidence of implementation and effectiveness assessment. Regular status reports to management create transparency and accountability.

Practical Implementation in Daily Operations

PDCA on a Small Scale

The PDCA cycle does not always have to span the grand arc from the annual audit to the management review. It works just as well on a small scale: an employee reports a suspicious email (Check). The ISO analyzes the email and determines that the spam filter did not detect it (Act/Plan). The filter rules are adjusted (Do). After one week, a check is made whether similar emails are now correctly filtered (Check). This micro-PDCA takes days rather than months and keeps the ISMS alive between the major reviews.

PDCA as a Mental Model

Independent of formal processes, it is worth internalizing PDCA as a mental model. Before you implement a measure: have you really understood the problem and chosen the right approach (Plan)? After implementation: have you verified whether the measure actually works (Check)? And if not: have you analyzed the root cause and adjusted the approach (Act)?

This thinking pattern prevents the most common mistake in information security — implementing measures and never looking at them again. Firewalls that are configured once and never reviewed. Policies written once and never updated. Training delivered once and never repeated. PDCA is the antidote to this "set and forget" syndrome.

Cycle Frequency

There is no fixed cadence for the PDCA cycle. ISO 27001 requires that internal audits and management reviews take place "at planned intervals" without specifying a concrete rhythm. In practice, an annual main cycle has proven effective for most mid-market companies, supplemented by quarterly KPI reviews and event-driven mini-cycles for security incidents or significant changes.

What matters is not frequency but seriousness. One thorough PDCA cycle per year delivers more than four superficial ones. At the same time, the interval between cycles must not be so large that problems go undetected for months. You find the right balance through the experience of the first one or two cycles: if the management review produces too many surprising findings, the interval is too long. If hardly any new findings emerge, the interval may potentially be extended.

The First Cycle Is the Hardest

When initially building an ISMS, the first PDCA cycle is naturally the most demanding. The Plan phase encompasses the complete initial risk assessment, the Do phase the implementation of all fundamental measures, the Check phase the first internal audit and the first management review. From the second cycle onward, things get easier because you build on existing structures and only need to consider the changes since the last cycle.

Do not be deterred by the effort of the first cycle. The value of the PDCA approach only becomes apparent from the second or third cycle, when you notice that your ISMS is actually improving: risks are assessed more precisely, measures work more accurately, audits run more smoothly and the security level rises measurably. That is precisely the difference between a living ISMS and a collection of documents gathering dust on a shelf.

Further Reading

• Building an ISMS: The Complete Guide for Companies
• Management Review per ISO 27001: Agenda, KPIs and Minutes
• Conducting an Internal ISMS Audit: Planning, Checklist and Report
• Risk Assessment in the ISMS: Methodology, Matrix and Practical Example
• Evaluating Audit Findings and Deriving Actions