The audit is over and you have findings. The certification body wants a response for each one: what you corrected, why it happened, and what you will change so it does not happen again. The first draft usually comes back.
Rejected responses share a shape. They restate the finding, describe the one fix already made, and promise to "remind staff". None of that addresses the cause, and none of it shows the fix worked.
This article covers what clause 10.2 of ISO/IEC 27001:2022 actually requires, how to find a cause that stands up, how to write a response your certification body will accept, and how to prove effectiveness afterward. How findings are graded is covered separately in major vs minor nonconformities.
Correction is not corrective action
ISO/IEC 27000 defines the two terms differently, and the difference is the whole subject.
Correction is action to eliminate a detected nonconformity. You fix the instance.
Corrective action is action to eliminate the cause of a nonconformity and prevent it recurring. You fix the reason the instance happened.
Say an auditor samples leavers and finds a contractor whose cloud console account was still active three weeks after their contract ended. Disabling the account is the correction. Finding out why the leaver process missed it, and changing the process, is the corrective action.
Most responses do the first well and the second poorly. Certification bodies need both.
What clause 10.2 requires, step by step
Clause 10.2 sets out a sequence. Your response should show each step, in this order.
React to the nonconformity. Take action to control and correct it, and deal with its consequences. For the contractor account, that includes checking the account's activity after the end date.
Review the nonconformity. Establish what happened and which requirement it breaches.
Determine the causes. Not the symptom, the cause.
Determine whether similar nonconformities exist, or could occur. This is the step most often skipped. If one contractor account survived, check every contractor account in every in-scope system.
Implement the action needed. Change the process, system, or responsibility that allowed it.
Review the effectiveness of the corrective action. After it has had time to operate.
Make changes to the ISMS if necessary. Update policies, procedures, the risk assessment, or the Statement of Applicability if the finding exposed a gap in them.
The clause adds that corrective actions shall be appropriate to the effects of the nonconformities encountered. A minor lapse does not need a redesign, and a systemic failure is not closed by one reminder email.
You must also keep documented information as evidence of the nature of each nonconformity, the actions taken, and the results of any corrective action.
Finding a cause that holds up
Cause analysis does not need a named technique, but it does need discipline. Asking "why?" repeatedly until you reach something you can change is enough for most findings, provided you stop at the right place.
"Human error" is never the cause. People make mistakes in every process. The question is why the process let the mistake through. Why did nothing catch it? Why did the step depend on someone remembering?
"Lack of training" is rarely the cause either. It is tempting, because the fix is easy. But if the person knew the rule and the process still failed, training changes nothing.
For the contractor account, a sound chain might run like this:
The account was not disabled because nobody was told the contract ended.
Nobody was told because contractors are not in the HR system, which triggers offboarding for employees.
Contractors are not in the HR system because they are engaged by individual teams through purchase orders.
The cause is that contractor offboarding has no trigger. The corrective action is to create one: for example, recording contractors with end dates in the identity provider, and reviewing upcoming end dates on a schedule. Re-sending the offboarding policy would have fixed nothing.
Writing a response your certification body accepts
Certification bodies vary in their forms, but they look for the same content. A response that contains every item below rarely comes back.
- Not done:
Finding reference and requirement: the clause or control cited, in the auditor's words
- Not done:
Extent: what you checked to find similar cases, and what you found
- Not done:
Correction: what was done to fix the instances, with dates
- Not done:
Cause: a short, specific statement, not a restated finding
- Not done:
Corrective action: the change to process, system, or responsibility, with an owner and a due date
- Not done:
ISMS changes: any updated documents, by name and version
- Not done:
Effectiveness check: how and when you will confirm it worked
- Not done:
Evidence: attached, or referenced where the auditor can find it
Keep it short. Long narratives make the auditor hunt for the cause. A clear answer in five lines does more than two pages.
For a major nonconformity, the certification body needs to verify that the correction and corrective action are effective before it can recommend certification. That may mean a follow-up visit or a review of documents. For a minor, it usually accepts your plan and verifies it at the next audit. The deadlines for both are in its procedures, so read them on day one.
Proving the fix worked
Effectiveness is the part auditors check most carefully at the next visit, and the part teams most often forget. A corrective action is effective when the process now produces the right result without someone watching it.
That takes time. If the fix was a new contractor end-date review, its effectiveness is shown by the next few reviews happening and catching what they should. Note the date of the first one that can demonstrate it, and look at the result.
Good effectiveness evidence has three qualities:
It comes from the system, not from a person's account. An export from the identity provider showing contractor end dates and disable dates is stronger than a statement that the process is followed. The reasons are set out in screenshots vs system-generated evidence.
It covers a period, not a moment. One clean record proves little. A run of them proves the process.
It tests the same thing the auditor tested. If the finding came from sampling leavers, re-sample leavers.
If the effectiveness check fails, the nonconformity is not closed. Go back to the cause analysis. The first cause you found was probably not the real one.
Internal findings follow the same rules
Clause 10.2 applies to every nonconformity, not only those raised by a certification body. Findings from your internal audit, incidents that reveal a control failure, and problems staff report all go through the same steps.
This matters for two reasons. An external auditor will sample your internal findings and check that they were handled properly. And the management review must consider trends in nonconformities and corrective actions, under clause 9.3.2. A log of internal findings that were corrected but never analyzed gives top management nothing to review.
Treat the internal audit as the place to practice. See running the ISO 27001 internal audit for how to raise findings that are worth working through.
How TrustLynce helps
TrustLynce records each finding in the auditor portal with its requirement, owner, corrective action, and attached evidence, so the response the certification body sees is the record you already keep. Evidence for the effectiveness check can be collected on a schedule from the systems involved, so the run of records is there when the next audit asks for it.