ISMS managers tense up when a nonconformity is raised. From the standard's point of view, though, finding one is not the problem. The problem is a nonconformity closed with containment alone, recurring the following year.
That is exactly what clause 10 addresses. Correction and corrective action are different things, and corrective action includes removing the cause and verifying that the removal worked. Write corrective action reports without that distinction and the audit finding will be "root cause analysis insufficient." In surveillance and recertification audits, whether last year's findings genuinely stopped recurring is the sharpest line of questioning.
This article covers clause 10 (Improvement) as a flow: detecting a nonconformity, completing corrective action, reviewing effectiveness, and leaving a record of continual improvement.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
What Clause 10 Asks For
In the 2022 edition, clause 10 has two subclauses: 10.1 continual improvement and 10.2 nonconformity and corrective action — the reverse of the 2013 order. See Transitioning to ISO/IEC 27001:2022.
| Subclause | Intent |
|---|---|
| 10.1 Continual improvement | Continually improve the suitability, adequacy, and effectiveness of the ISMS |
| 10.2 Nonconformity and corrective action | When a nonconformity occurs: (1) react to it and deal with the consequences, (2) evaluate the need for action to eliminate the cause, (3) implement any action needed, (4) review the effectiveness of that action, (5) change the ISMS if necessary. Retain records of the nature of the nonconformity, the actions taken, and the results |
The essential point is that 10.2 has two stages.
Correction versus corrective action
| Correction | Corrective action | |
|---|---|---|
| Purpose | Deal with the event that occurred | Eliminate the cause so it does not recur |
| Timescale | Immediate to days | Weeks to months |
| Example: a leaver's account was still active | Delete the account | Tie offboarding to permission revocation and add a monthly review |
| Example: supplier check sheets not collected | Collect from that supplier | Define reminder cadence and escalation for non-returns |
| Example: no restore test performed | Run the test now | Put it in the annual plan with a named owner and deputy |
| Record | Date and content | Root cause, action taken, effectiveness verification |
| If you stop here | The auditor will raise it | Properly closed |
Closing reports with correction alone is extremely common. "Deleted the account. Done." leaves the cause in place, and the same nonconformity returns next year.
"Evaluate the need for action to eliminate the cause"
The standard does not require corrective action for every nonconformity. It requires that you evaluate the need — reviewing the nonconformity, determining its causes, and determining whether similar nonconformities exist or could potentially occur.
Concluding that the cause was transient and recurrence unlikely is a legitimate outcome. But record the basis for that conclusion. The record must distinguish between "we evaluated and judged action unnecessary" and "we skipped the evaluation."
Preceding clauses: Clause 4: Context, Clause 5: Leadership, Clause 6: Planning, Clause 7: Support, Clause 8: Operation, and Clause 9: Performance Evaluation. For the overview, What Is an ISMS.
What You Actually Produce
Essentially two artefacts: a nonconformity register and corrective action reports. The register tracks counts and status; the reports carry the substance of each case.
| Artefact | Fields to include |
|---|---|
| Nonconformity register | Reference, detection date, source, summary, severity, owner, correction completion date, decision on whether corrective action is needed, planned and actual completion dates, effectiveness verification date, status |
| Corrective action report | The facts (when, where, what), the requirement or internal rule breached, correction taken and date, root cause analysis, whether similar cases exist, corrective action and deadline, results, method and outcome of the effectiveness review, whether ISMS documents were revised |
See Writing Corrective Action Reports.
Where nonconformities come from
Listing detection sources up front reduces what never reaches the register.
| Source | Typical example | Risk of going unregistered |
|---|---|---|
| Internal audit | Findings in the audit report | Low |
| External audit | Stage 1, stage 2, surveillance findings | Low |
| Security incidents | Misdirected email, malware, loss, unauthorised access | Medium |
| Monitoring and measurement | Missed targets, threshold breaches | High — often not treated as nonconformities at all |
| Day-to-day observation | Procedures diverging from reality; rules that cannot be followed | Highest |
| Interested parties | Customer audits, gaps surfaced while answering check sheets | High |
| Revised laws or guidelines | Existing rules no longer meet new requirements | Medium |
Whether you have a route for "day-to-day observation" is what separates a live ISMS from a dormant one. A single simple form anyone can submit, triaged by the secretariat, works in practice.
How to review effectiveness
Corrective action is not finished until you review whether it worked. This is the most commonly missing element, so give it a field in the template.
| Type of corrective action | How to verify effectiveness | Timing |
|---|---|---|
| Revised procedure or rule | Sample post-revision records and check they follow the new rule | 1–3 months after |
| New mechanism or tool | Measure detection counts or automation rate after deployment | 1–3 months after |
| Training or communication | Comprehension test, or fewer errors in the relevant records | Next training or one quarter |
| Change to roles or structure | Confirm the process now completes under the new structure | After one cycle |
"We implemented it, therefore it is effective" is not an effectiveness review. Confirming implementation closes the action; effectiveness is judged by whether the outcome changed.
Recording continual improvement
10.1 prescribes no procedure, so people often ask what to record. In practice three things suffice:
- Management review outputs — improvement opportunities and decisions to change the ISMS. This is the core evidence
- History of revisions to security objectives — records of changing next period's objectives in light of this period's results
- Records of improvement suggestions and how they were handled — observations that never became nonconformities
Conversely, if the management review minutes contain no decisions, the evidence of continual improvement is thin. This is where clauses 9 and 10 connect. See Management Review in Practice.
Where It Goes Wrong
1. Root cause analysis stops at "the owner failed to check"
The most common pattern. Attributing cause to a person produces actions like "remind everyone to be careful," and it recurs.
To go one level deeper, ask why that person could not do it.
| Shallow cause | One level deeper | Resulting corrective action |
|---|---|---|
| Owner forgot to revoke permissions | Offboarding has no revocation step | Add revocation to the leaver checklist; define the HR-to-IT handoff |
| Owner did not know the procedure | Revisions are not communicated | Define a communication flow on document revision; record the notification date in the revision history |
| Too busy to perform it | The frequency exceeds what the workload allows | Revise the frequency; automate what can be automated |
| Following the rule makes work impossible | The rule does not fit reality | Revise the rule to fit reality, including a documented exception path |
That last row matters. When a rule cannot be followed, the subject of correction is the rule, not the person. Revising it is not lowering the bar — it is converting the control into one that can actually operate.
2. Similar cases are never checked
10.2 asks you to determine whether similar nonconformities exist or could potentially occur. Fix one and close, and the same structural problem persists elsewhere.
If one department failed to collect supplier check sheets, check the others and record that you did.
3. No deadline, or deadlines ignored
Without deadlines the register fills with "in progress," and the auditor reads that as improvement not functioning.
The practical answer is to define the extension procedure in advance: record the reason and the new date, and obtain approval. Nothing then sits silently overdue.
4. Only audit findings appear in the register
Some organisations manage only external audit findings as nonconformities, with nothing found internally. To an auditor that signals an inability to find your own problems.
Managing internal audit findings, incidents, and missed targets in the same register makes the breakdown of sources itself an indicator of maturity.
5. Incident response is disconnected from corrective action
When an incident occurs, recovery (correction) is pursued urgently — but it often never gets registered as a nonconformity, so cause elimination never happens.
Make "raise a nonconformity" the final step of the incident response procedure. See Building an Incident Response Procedure.
What Auditors Look At
Clause 10 carries more weight in surveillance and recertification audits than in the initial one, because the focus is whether previous findings genuinely closed.
| Focus | Typical question | Preparation |
|---|---|---|
| Correction vs corrective action | "Does the action in this report eliminate the cause?" | Give the template separate fields for each |
| Depth of analysis | "How did you conclude this was the cause?" | Record the analysis trail — records examined, people interviewed |
| Similar cases | "Has the same thing happened elsewhere? Did you check?" | State the scope and result of the check in the report |
| Effectiveness review | "How did you confirm the action worked?" | Keep method, timing, and result as fields |
| Recurrence of prior findings | "What happened to the finding from the last surveillance?" | Track prior findings in the register through to effectiveness verification |
| Register coverage | "Are all your nonconformities from external audits?" | Include internal audit, incidents, and missed targets |
| Evidence of improvement | "How has the ISMS improved over the past year?" | Show management review decisions and their implementation |
Arriving at a recertification audit with prior findings still open is the worst case. See Preparing for Surveillance Audits, Preparing for Recertification, and Common Nonconformities.
Healthcare Examples
Build medical information into your severity definitions
The same "misdirected email" has very different impact depending on recipient and content. Making cases involving medical information or special care-required personal information a separate severity band keeps corrective action prioritisation consistent. See Reporting Obligations After a Data Breach.
Connect customer reporting to the corrective action report
Contracts with hospitals normally impose incident reporting obligations. Writing the customer report and the internal corrective action report separately makes them diverge. Treat the internal report as authoritative and produce the customer version as an extract.
Register nonconformities that occur at suppliers
Events at a cloud provider or maintenance supplier require a decision on whether to treat them as your own nonconformity — they bear on the effectiveness of your supplier management control, so at minimum record that you evaluated them. See Supplier Security Management.
Treat guideline revisions as a detection source
Revisions to Japan's three-ministry guidelines can leave existing procedures short of new requirements. Running that as a separate "revision project" leaves no trace in your improvement records. Register it as a nonconformity or an improvement opportunity and it becomes clause 10 evidence. See Japan's Three-Ministry Guidelines.
Large events produce long-running corrective actions
After ransomware recovery ends, eliminating the cause — network segmentation, stronger authentication, redesigned backups — takes months. Do not carry a multi-month programme in a single report; split it into phases with their own deadlines. For the hospital side, see First Response to a Ransomware Attack.
Conclusion
- Correction and corrective action are different. Closing on correction alone draws a finding and recurs next year
- What is required is not always corrective action but an evaluation of the need to eliminate the cause — record the basis even when you decide action is unnecessary
- Corrective action is not complete until effectiveness is reviewed. Not "we did it," but "did the outcome change?"
- Do not stop root cause analysis at "the owner failed to check." Go down to why that person could not do it. When a rule cannot be followed, fix the rule
- State explicitly whether similar cases exist or could occur
- Register internal audit findings, incidents, missed targets, and day-to-day observations too — a register containing only external findings signals you cannot find your own problems
- Evidence of continual improvement centres on management review decisions and their implementation
Pottech supports ISMS certification and operation with a focus on healthcare: designing corrective action report templates, working alongside you on root cause analysis, and connecting incident response to nonconformity management. In year-two support we make sure the previous audit's findings are genuinely closed.
See ISMS Certification Support for scope and pricing, or contact us to discuss your situation.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee
- Personal Information Protection Commission, Japan
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: interpretation of requirements and the handling of certification are governed by the standard itself and by the publications of accreditation and certification bodies. Whether a breach must be reported depends on the specifics of the case.