PDCA in ISO 27001: The Cycle Is Still There

Plan-Do-Check-Act has not disappeared from ISO/IEC 27001 in any practical sense. The current standard does not require an organisation to label its ISMS process with the four PDCA stages, and auditors should not demand a PDCA diagram. Yet its requirements still create a repeating pattern of planning, operation, evaluation and improvement.

That distinction resolves a common argument. PDCA is a useful explanatory and operating model, not an extra set of requirements. Conformity is assessed against ISO 27001 clauses and the organisation’s own ISMS commitments, not against a decorative cycle.

Why people think PDCA was removed

Earlier management-system materials often displayed PDCA explicitly. As ISO standards adopted a common high-level structure, the visible organisation shifted toward context, leadership, planning, support, operation, performance evaluation and improvement.

A changed standards structure does not remove the logic of managing and improving a system. That principle remains sound, but current implementation should be based on ISO/IEC 27001:2022 rather than older clause or control references.

The ISO overview of ISO/IEC 27001 describes an ISMS that manages risk and promotes continuing adaptation. The standard’s clauses provide the auditable requirements; PDCA helps teams understand how those requirements work together over time.

An AuditPrepared mapping of the cycle

The mapping below is an explanatory model. It is not official clause text, and individual requirements can support more than one stage.

PDCA stage	ISO 27001 activity	Typical output
Plan	Understand context and stakeholders, set scope and policy, assess risk, choose treatment, set objectives	Scope, risk criteria, risk results, treatment plan, objectives
Do	Provide resources and competence, control information, operate treatments and processes	Procedures, configurations, training, supplier actions, operating records
Check	Monitor and measure, evaluate results, conduct internal audit and management review	Metrics, audit findings, review decisions, trend analysis
Act	Correct problems, address causes and improve the ISMS	Corrections, corrective actions, changed controls, improved methods

Clauses 4 through 7 contain much of the foundation and planning. Clause 8 is strongly associated with operation. Clause 9 evaluates performance. Clause 10 drives improvement. Leadership in clause 5 is not a one-time Plan activity; it should influence every stage.

For a direct walkthrough of requirements, use the ISO 27001 clauses 4–10 guide.

Plan: make decisions before collecting documents

Planning begins with the organisation’s purpose and environment. What services, information, locations, technologies and dependencies matter? Which interested parties have relevant requirements? Where will the ISMS boundary sit, and what interfaces could undermine it?

Risk assessment then turns context into prioritised decisions. The organisation needs consistent criteria, credible risk identification and accountable evaluation. Risk treatment selects controls and other actions. Objectives translate policy direction into measurable outcomes.

Strong planning evidence includes:

• approved scope with boundaries and interfaces;
• context and interested-party analysis linked to decisions;
• documented risk criteria and repeatable assessment results;
• treatment choices and acceptance authority;
• a Statement of Applicability that explains inclusion and exclusion;
• objectives with owner, measure, resources and due date.

Weak planning is visible when the scope copies a certificate ambition, the risk register lists generic threats, or objectives cannot be measured. The point is not document volume; it is decision quality.

Do: operate the choices in real work

The Do stage turns planned treatments into behaviour and technical state. People need competence, resources and awareness. Procedures and records need control. Operational processes need owners and criteria.

For a privileged-access control, implementation evidence may include the approved rule, role model, system configuration and workflow. Operating evidence includes requests, approvals, system logs, access reviews and exception closure. Both are necessary: design without use is theory, while unexplained system output lacks governance.

Operational control should be proportionate. A small organisation may use a straightforward approval flow; a complex enterprise may automate identity governance. ISO 27001 does not require identical tools. It requires the organisation to operate what it determined was necessary and retain evidence where required.

The Do stage also includes controlled change. New suppliers, acquisitions, remote-work patterns and system migrations can invalidate assumptions made during Plan. Significant changes should therefore loop back into context, risk and treatment rather than waiting for an annual review.

Check: evaluate results, not activity alone

Monitoring should answer whether the ISMS and its controls achieve intended outcomes. Counts such as training completions, alerts or closed tickets can be useful, but they are not automatically measures of effectiveness.

Choose measures that support decisions. Examples include privileged-access review completion with overdue risk, critical vulnerability age by asset importance, restore success against recovery needs, supplier remediation aging, and recurrence of incident causes.

The ISO 27001 KPI design guide explains how to connect a metric to an owner, threshold, evidence source and management response.

Internal audit provides independent evaluation of planned arrangements and actual operation. Management review brings together performance, changes, risks, opportunities, audit results and resource needs so leaders can decide. See management review that drives decisions for evidence expectations.

Check is weak when dashboards contain only green status, internal audits examine document presence rather than samples, or management minutes record “noted” without decisions.

Act: correct, learn and improve

Correction addresses the observed problem. Corrective action addresses its cause and aims to prevent recurrence. The difference matters.

If a leaver retained access, disabling the account is a correction. Investigating why the HR feed failed, repairing the integration, checking for similar cases and verifying the fix are corrective-action activities. A credible record shows containment, impact, cause analysis, action owner, due date and effectiveness review.

Improvement is broader than responding to nonconformity. Teams may simplify a risk method, automate evidence collection, improve supplier tiers or redesign measures before a failure occurs. Continual does not mean constant change; it means the organisation repeatedly looks for and acts on opportunities to make the ISMS more suitable, adequate or effective.

The cycle then restarts. Improvement changes context, controls or assumptions, which may require new planning and operating evidence.

One practical cycle: onboarding a cloud service

Consider a finance team adopting a new cloud platform.

Plan

The service owner identifies data, users, integrations, legal and contractual requirements, supplier dependencies and business impact. Security risk is assessed. Required access, logging, backup, incident and exit controls are selected. Acceptance authority is clear.

Do

The contract is approved, identity integration configured, administrators restricted, logs connected, backup responsibilities confirmed, users trained and operating procedures launched. Records show who approved each important decision.

Check

The owner reviews access, alert coverage, supplier reporting, incidents, restoration evidence and contractual performance. Internal audit samples the onboarding decision and current operation. Management sees material exceptions.

Act

The team closes immediate gaps, investigates systemic causes and adjusts the cloud onboarding process. Lessons feed future risk assessment and supplier due diligence.

The value of PDCA is visible here: it prevents supplier review from ending at contract signature.

Audit questions for each stage

Plan questions

• What changed in context, obligations or stakeholder expectations?
• How did those changes affect scope, risk and objectives?
• Who accepted remaining risk, and on what basis?

Do questions

• How were selected controls translated into operating responsibilities?
• Which records prove execution across the period?
• How are exceptions approved, time-limited and monitored?

Check questions

• Which measures reveal effectiveness rather than effort?
• How was the internal-audit sample chosen?
• What decisions did management make from the results?

Act questions

• Were immediate corrections separated from cause-based action?
• How was action effectiveness verified?
• What changed in the ISMS as a result?

Use the ISO 27001 clause explainer to connect these questions to the relevant requirements.

Pass, partial and fail patterns

Pass: decisions connect across the cycle. Risks lead to treatments, treatments produce records, evaluation finds meaningful results, and improvement changes the system with verified effect.

Partial: the organisation completes each formal activity, but the links are weak. Metrics do not influence review, audit findings do not affect risk, or actions close without effectiveness checks.

Fail: planning is generic, operation cannot be evidenced, reviews are ceremonial, and repeated problems have no cause analysis. A PDCA diagram does not compensate for missing operation.

Use PDCA as a navigation aid

Teams may organise work in sprints, service-management flows or another improvement method. ISO 27001 does not force them to rename those practices. PDCA remains valuable because it asks four durable questions: Did we make a reasoned plan? Did we operate it? Did we evaluate what happened? Did we learn and improve?

That operating rhythm is also central to maintaining ISO 27001 after certification. The cycle is still there wherever an ISMS moves from intent to evidence and back into better decisions.