ISO 27001 Clause 10.2: nonconformity and corrective action that holds

The auditor asks for the log entry behind a failed control. You find a closed ticket, dated the day the fix shipped, with "human error" as the cause. That is how a minor finding becomes a repeat finding. This guide covers ISO 27001 Clause 10.2 for CISOs and compliance leads at regulated UK firms and B2B SaaS companies: the full lifecycle, how auditors sample and grade it, and how to run it from the ticketing system you already use.

What does ISO 27001 Clause 10.2 require?

ISO 27001 Clause 10.2 requires you to respond when the ISMS breaks its own rules: bring the failure under control, find and eliminate its cause, check whether the same weakness exists elsewhere, verify the fix worked, and amend the ISMS if the gap was systemic. Records of each nonconformity and its outcome are mandatory.

A nonconformity is the ISMS (information security management system) breaking its own rules: a control not operating, a requirement unmet, a process skipped. In ISO 27001 nonconformity and corrective action are linked ideas, because the second is the planned response that stops the first recurring. Auditors test the steps almost in the order the clause writes them.

The lifecycle runs in seven steps:

1. Control the failure. Contain it, fix the immediate problem and manage the fallout.
2. Find the cause. Examine what went wrong and why.
3. Sweep for look-alikes. Check whether the same weakness lives anywhere else.
4. Apply the fix. Carry out whatever action that judgement demands.
5. Verify. Confirm later that the fix worked.
6. Amend the ISMS. Change policy, process or training when the gap was systemic.
7. Keep records. Retain what each nonconformity was, what you did, and what the fix achieved.

The response must be proportionate to the damage the failure could do. A trivial lapse earns a two-line record. Anything that touched data or a customer earns the full cycle.

Clause 10.2 is the enforcement arm of continual improvement. Internal audit feeds it and management review receives its output. A supervisor or an enterprise client's diligence team reads the same trail to judge whether you learn from failure or merely survive it.

What is the difference between correction and corrective action?

Correction deals with the failure in front of you: isolate the endpoint, revoke the credential, restore the backup. Corrective action removes the reason it happened so it cannot recur. Clause 10.2 expects both, recorded separately, so the trail shows the cause was dealt with and not just the symptom.

Take an API key committed to a public repository. Rotating the key and purging the commit history is the correction. Adding secrets scanning to the pipeline and changing how developers receive credentials is the corrective action. The first takes an hour, and the second changes how the firm works.

Record each move in its own fields on the same log entry:

• Correction: what was contained, by whom and when, with the isolation log or revocation record attached.
• Corrective action: the cause removed, the owner, the due date and the change ticket that delivered it.
• Proportionality note: why the depth of response matched the risk.

The classic failure is stopping after the correction. The credential is rotated, the ticket is closed, and the process that leaked it survives. The incident returns six months later with a different key, this time in front of a customer.

How are minor and major nonconformities graded?

A minor nonconformity is an isolated lapse in a control that otherwise works; certification proceeds with an agreed action plan. A major is a systemic breakdown or an absent required control, and it blocks certification until fixed and verified. Shallow root cause or missing verification grades minor, aggregating to major as a pattern.

Certification bodies typically apply these rules to Clause 10.2 failures:

• Major: no functioning corrective action process at all.
• Major: externally raised findings, such as pen-test results, that never entered the process.
• Graded up: a prior finding left unresolved.
• Minor: a shallow root cause or missing verification step in one record.
• Minor aggregating to major: the same shallow pattern repeated across records.

Grading is why the detail in the following sections matters. A certification body that sees weak root-cause work or reopened findings starts questioning the whole system, which is how minors compound into certificate-threatening majors. One thin record is a lapse, and a log full of them is a pattern.

You can grade yourself before the auditor does. Sample five entries from your log and ask whether each would survive the audit-room questions covered later in this guide.

How do you do root cause analysis beyond 'human error'?

Use 5 Whys or a fishbone sketch and keep asking until you reach a process, tooling or training gap. If a person could make the mistake, something let them. Recording "human error" as the cause invites the auditor to dig, and leaves the failing process intact.

Run the 5 Whys as a short conversation with the people who did the work, not as a form. Take a customer export emailed to the wrong recipient:

1. Why did the file reach the wrong person? The analyst picked the wrong autocompleted address.
2. Why could they email it at all? There was no approved way to share exports with customers.
3. Why not? The sharing route was never defined when the reporting feature launched.
4. Why not? The launch checklist has no data-sharing review.

The cause is a missing checklist step, not a careless analyst. Adding a data-sharing review to the launch checklist is the corrective action, and the next feature launch is its first real test.

A root cause that no process change can fix is a description, not a cause.

When several factors contributed, sketch a fishbone with branches for people, process, tooling and suppliers, then run the 5 Whys down each branch that matters. A photographed whiteboard counts as a genuine root cause record. A templated form filled in retrospectively carries far less weight.

The NCSC cyber incident response guidance poses the same question for post-incident reviews: could security improvements have prevented the incident or enabled earlier detection? It asks for tactical fixes and strategic solutions together, and notes that some strategic weaknesses only show up across several incidents. That is the case for reading the log as a trend, not only entry by entry.

Stop asking when the answer names something you can change and later test: a process step, a tool setting, a training gap. That answer also hands you the verification check for closure.

What is the 'where else?' sweep and why do auditors insist on it?

The 'where else?' sweep is a look-alike review: when one repository leaks a secret or one team skips the joiner process, you check every sibling repository, system or team for the same weakness. The clause requires it, and small firms skip it most often, so the weakness resurfaces in a neighbouring system at the next audit.

Run the sweep in four moves:

1. State the weakness in general terms. "A secret committed to a repository" travels further than "the billing repo leaked a key".
2. List the siblings. Other repositories, systems, teams and suppliers that share the process or tooling.
3. Check each one. Script it where you can, such as a secrets scan across every repository in the organisation.
4. Record every result. A clean result is evidence that the sweep happened.

An entry that cannot show where else you looked reads as a shallow record. A second occurrence in a sibling system confirms it, and feeds the pattern grading described earlier.

The skipped joiner process works the same way. If one team missed it, pull the joiner records for every other team before you close the entry.

When is a nonconformity considered closed?

A nonconformity is closed once you have verified the fix worked, not when it is implemented. In practice that means a re-test or check at the end of a 30–90 day verification window, recorded with a date after the fix. Closing on implementation day is the most common way findings return.

Match the window to how often the failure could recur. A fix to a weekly process proves itself quickly. A change to a quarterly process needs the longer end of the range, or a deliberate test that forces the process to run. Write the end date into the record when the fix ships, so the re-test is scheduled rather than remembered.

The closure entry then needs three things:

• A dated re-test or follow-up check. The date falls after the fix, and the result sits on the record.
• A recurrence rule. If the failure returns inside the window, the record reopens instead of a new ticket starting from zero.
• The ISMS amendment, where the cause was systemic. Link the updated policy, process or training material to the record.

How do you build a unified nonconformity register in Jira or your existing tracker?

Keep one log for everything: audit findings, incident-derived failures, pen-test results, supplier lapses, in your existing ticketing system such as Jira or ServiceNow. Each entry carries the failure, containment, cause, a named owner, due date and status. A separate compliance silo is where entries go missing.

Beyond those fields, three habits keep the log honest:

• One named owner per action. A person with a due date, not a team, because everyone's accountability is no one's.
• Change management routing. Technical fixes run through your normal change process, and the change ticket links back to the entry.
• Escalate, don't re-date. An overdue action goes to the owner's manager, and any new date is recorded as a decision rather than quietly moved.

Regulators expect the same discipline. The ICO personal data breach guidance states that "Article 33(5) requires you to document the facts regarding the breach, its effects and the remedial action taken". Failure, impact and fix fields in the log line up with those three elements for any breach that enters it.

Fixes applied informally outside the log are the other way a register fails. The work is real, but it is invisible at exactly the moment it needs to count.

Stand the log up before your first internal audit. Its findings are the first real test of the workflow, and a register that already holds them answers the auditor's opening question.

What do auditors check in ISO 27001 Clause 10.2?

Auditors trace two or three entries through the full cycle with their artefacts, cross-check that findings from internal audit, pen tests, incident reports and helpdesk actually landed in the log, and compare closure dates with verification dates looking for same-day closes. An empty log at an established company reads as under-reporting, not excellence.

Expect questions like these in the room:

• Walk me through this entry from detection to verification.
• How did you establish the cause? Show me the analysis.
• Where did you check for the same weakness elsewhere?
• What is your evidence the fix worked, and when did you gather it?
• Your pen test raised six issues. Where are they in this log?
• How do open and overdue items reach management review?

You can rehearse this in an hour. Pick two entries at random and walk them yourself with the artefacts attached. Then take your latest pen test report and tick each finding against a log entry.

At this scale, auditors accept a practical evidence set:

• A log showing the whole lifecycle per entry, not just open and closed flags.
• Containment artefacts such as isolation logs and revocation records.
• Change tickets and updated policies linked from the actions that produced them.
• Retraining or communication records where the fix involved people.
• Dated verification results and management review minutes showing trends reached leadership.

A rigorous procedure that nobody follows isn't a control. It's a finding waiting for an audit.

How can GRC engineering automate the corrective action loop?

Integrations create entries automatically from audit findings, incident post-mortems, pen-test reports and failed control checks. The ticket workflow blocks closure until containment, cause, owner and verification exist. A timer schedules the re-test at the end of the monitoring window, and closure velocity, ageing and recurrence rate compute continuously for management review.

Each mechanism turns a section above into the default path. Intake answers the "is everything in the log?" question before it is asked, and the workflow makes the clause's sequence the path of least resistance. The timer ends same-day closure, and the telemetry replaces the reporting exercise. The NIST SP 800-61 Revision 3 incident response profile takes the same view: lessons learned are fed into improvement and used to inform every function.

At a 50-person firm, steady state is a few hours a month of triage plus the verification checks. The human layer is judgement: triage, root-cause discipline and holding owners to verified closure, which a fractional CISO can supply between audits. The return is a trail that enterprise diligence teams trust.

Frequently asked questions