ISO 27001 improvement, nonconformity and corrective action

ISO 27001:2022 clause 10 asks you to keep improving the ISMS (10.1) and to handle every nonconformity the same way (10.2): control and correct it, deal with its consequences, find its cause, decide whether action is needed so it does not happen again, take that action, check it worked and record it all. In 2022, 10.1 and 10.2 swapped places.

The requirement in plain English

Continual improvement (ISO 27001:2022 10.1). You keep making the ISMS more suitable, adequate and effective. Improvement can come from anywhere: audit results, incidents, measurements, management review decisions, staff suggestions. The 2013 edition put this clause second; the 2022 edition puts it first, which is worth knowing when you map old procedures to the new numbering.

Nonconformity and corrective action (ISO 27001:2022 10.2). When a nonconformity occurs, you:

1. contain it, fix the instance, and deal with what it has already caused;
2. decide whether its cause needs removing so it does not happen again, here or elsewhere: look at what happened, work out why, and look for the same problem in other places;
3. carry out whatever that decision calls for;
4. check later that the action really worked;
5. change the ISMS itself where the fix needs it.

Size the corrective action to the effects of the problem. You keep documented information on what the nonconformity was, what you did and what the corrective action achieved.

Two words do different jobs here. A correction fixes the instance: you remove the leaver’s account. A corrective action removes the cause: you change the leaver process so HR’s exit date reaches IT automatically. The standard asks for the first where it applies, and always asks you to decide whether the second is needed.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 45-person insurtech keeps one corrective action log for every source: internal audit findings, certification audit findings, incidents where a control failed, customer complaints and missed objectives. Each entry is a CAPA record with a short problem statement, the immediate correction and containment, the root cause with the evidence for it, the corrective action with an owner and date, and an effectiveness check scheduled for a set time after closure.

The effectiveness check is concrete: “sample ten leavers from the next quarter; all accounts removed within 24 hours”. A record cannot close until the check passes. If it fails, the record reopens and the cause is looked at again.

Root causes are written as causes, not as people’s names: “no trigger from HR to IT on exit” rather than “IT forgot”. Repeated causes across several records are flagged for the management review (ISO 27001:2022 9.3), where top management decides whether a bigger change is needed.

Improvement is visible beyond fixes: the log also holds opportunities raised by staff, and the risk process (ISO 27001:2022 6.1) picks up lessons from incidents (ISO 27001:2022 Annex A 5.27).

Evidence an auditor expects

• Record of each nonconformity and the action taken (required documented information): the auditor checks the description, the correction and the date.
• Results of corrective action (required): the auditor looks for an effectiveness check with evidence, not a closure date alone.
• Root cause analysis: usual rather than mandated in form; the auditor checks the cause is plausible and evidenced.
• Check for similar nonconformities: the auditor asks whether you looked elsewhere for the same problem.
• Previous audit findings: at surveillance, the auditor revisits last time’s findings and tests whether the fixes held.
• Improvement evidence: changes made to the ISMS over the year, traced to their trigger.

Common mistakes

Closing on the correction

The account is removed, the record is closed and the cause stays. The auditor finds the same finding a year later, now graded higher. Close only after the corrective action and its effectiveness check.

A root cause that names a person

“Human error” or a name ends the analysis too early. Ask why the error was possible, and fix the process that let it through.

No look for similar cases

One leaver kept access, but nobody checked the other leavers that month. Clause 10.2 asks whether similar nonconformities exist or could occur. Sample beyond the one case.

Effectiveness checks that check nothing

“Reviewed, effective” with no evidence does not meet 10.2. Decide the test when you set the action, and record the result.

Treating improvement as audit fixes only

If every change in a year came from an auditor, the system is not improving itself. Record improvements from incidents, staff ideas and measurements too.

How Sted helps

Related guides and terms

• Root-cause analysis for a CAPA: finding and proving the cause.
• Internal audit: the main source of nonconformities.
• Management review: where repeated causes and improvement decisions go.
• Records in Sted: how a CAPA record is opened, completed and closed.
• Corrective action: the term, and how it differs from correction.

Frequently asked questions