Correction Versus Corrective Action

Correction Versus Corrective Action in ISO/IEC 27001 Audits: A Complete Guide for Lead Auditors

Introduction
When an ISO/IEC 27001 audit closes, the auditee has to respond to every nonconformity the audit team raised. Two terms sit at the centre of that response: correction and corrective action. They sound alike and are often used as if they meant the same thing, but ISO standards define them as different activities with different purposes.

A Lead Auditor must be able to:

• tell the two apart,
• judge whether the auditee has proposed and carried out both properly, and
• explain the difference clearly to management.

This guide covers what the terms mean, why the difference matters, how they fit into the audit closing and follow-up process, and how to handle exam questions on them.

1. What Are Correction and Corrective Action?

Correction
ISO/IEC 27000 and the ISO Harmonized Structure (Annex SL) define a correction as an action to eliminate a detected nonconformity. In plain terms, it is the immediate fix. It deals with the symptom, the specific problem in front of you, and does not ask why the problem happened.

Examples of correction:

• The auditor finds a former employee's account still active. The correction is to disable that account now.
• The auditor finds an expired firewall rule review. The correction is to carry out the overdue review.
• The auditor finds an unsigned confidentiality agreement for a contractor. The correction is to get the agreement signed.
• The auditor finds a backup that was never tested. The correction is to perform the restore test.

Corrective Action
A corrective action is defined as an action to eliminate the cause of a nonconformity and to prevent recurrence. It deals with the root cause. It asks why the nonconformity happened and changes the system so it does not happen again.

Examples of corrective action, matching the cases above:

• Active ex-employee account. Root cause analysis shows HR does not notify IT when people leave. Corrective action: build an automated leaver workflow linking the HR system to identity management, and add a monthly account reconciliation.
• Expired firewall review. The cause is that nobody was assigned to it and there was no scheduling mechanism. Corrective action: assign a role, add the review to the compliance calendar, and set up automated reminders.
• Unsigned contractor agreement. The cause is that the procurement onboarding checklist has no NDA step. Corrective action: update the procurement procedure and train procurement staff.
• Untested backup. The cause is that the backup policy has no testing requirement. Corrective action: revise the policy, define the test frequency, and assign accountability.

A Third Related Concept: Preventive Action
Older standards, such as ISO/IEC 27001:2005, had a separate preventive action requirement. It addressed potential nonconformities that had not yet occurred. Since the 2013 revision, the idea is built into risk-based thinking, mainly clause 6.1 (Actions to address risks and opportunities). Exam questions sometimes use preventive action as a distractor, so be ready for it.

2. Why Is the Distinction Important?

a) Avoiding symptom-only fixes
Many organisations fix the visible problem and move on. The same nonconformity then reappears at the next surveillance audit. Correction alone does not improve the management system. Only corrective action deals with systemic weakness.

b) Compliance with Clause 10.2 of ISO/IEC 27001:2022
Clause 10.2 (Nonconformity and corrective action) requires the organisation, when a nonconformity occurs, to:

1. React to the nonconformity and, as applicable, take action to control and correct it and deal with the consequences. This is correction.
2. Evaluate the need for action to eliminate the cause(s), so that it does not recur or occur elsewhere, by:
   • reviewing the nonconformity,
   • determining its causes, and
   • determining whether similar nonconformities exist or could potentially occur. This is root cause analysis leading to corrective action.
3. Implement any action needed.
4. Review the effectiveness of any corrective action taken.
5. Make changes to the ISMS, if necessary.

The clause also says corrective actions must be appropriate to the effects of the nonconformities encountered. Documented information must be kept as evidence of:

• the nature of the nonconformities and any subsequent actions taken, and
• the results of any corrective action.

c) Certification decisions
Under ISO/IEC 17021-1 and ISO/IEC 27006, certification bodies must review the auditee's corrections and corrective actions before granting or maintaining certification.

• Major nonconformities: the certification body normally needs evidence that both the correction and the corrective action have been implemented and verified, sometimes through a follow-up visit.
• Minor nonconformities: it is often enough to accept the auditee's plan for correction and corrective action, with implementation checked at the next audit.

d) Continual improvement
Corrective action is one of the main ways the ISMS improves (Clause 10.1). Without it, the PDCA cycle does not close properly.

e) Credibility of the auditor
A Lead Auditor who accepts a correction as if it were a corrective action has failed to assess the auditee's response adequately. That weakens the integrity of the certification.

3. How It Works in Practice: The Audit Closing and Follow-up Process

Step 1: Nonconformity is raised
During the audit, the auditor records a nonconformity statement with three parts:

• the requirement,
• the evidence, and
• the nonconformity itself.

It is graded as major or minor.

Step 2: Closing meeting
The audit team leader presents the findings. The auditee is told what is expected and by when. This is typically:

• a correction and corrective action plan within a defined period (for example 30 days for minors), and
• for majors, implementation evidence within a defined period, often up to 90 days.

Step 3: Auditee performs correction
The auditee fixes the immediate issue, often right away and sometimes even during the audit. An auditor may note that a correction was made on site, but the nonconformity is still recorded, because correction does not erase the fact that the system failed.

Step 4: Root cause analysis
The auditee investigates why the nonconformity happened, using techniques such as:

• the 5 Whys,
• Ishikawa (fishbone) diagrams,
• fault tree analysis, or
• Pareto analysis.

The real root cause is rarely "human error" alone. A good analysis asks why the system allowed the human error.

Step 5: Corrective action plan
The auditee defines actions that address the root cause, with owners, deadlines and resources. It also checks whether similar nonconformities exist elsewhere, sometimes called the extent of the problem. For example: are other departments' leaver processes also broken?

Step 6: Auditor review of the response
The Lead Auditor assesses three things:

• Is the correction adequate? Does it remove the detected problem?
• Is the root cause analysis credible? Does it go deep enough?
• Is the corrective action appropriate? Does it address the identified root cause and match the significance of the nonconformity?

Step 7: Verification of implementation and effectiveness
Depending on the grading, verification is done through:

• documentary evidence,
• an on-site follow-up visit, or
• the next surveillance audit.

Effectiveness means the nonconformity has not recurred and the system change works.

Step 8: Closure
Once verified, the nonconformity is closed in the audit records.

Summary Comparison

• Purpose. Correction eliminates the detected nonconformity. Corrective action eliminates its cause to prevent recurrence.
• Focus. Correction deals with the symptom. Corrective action deals with the root cause.
• Timing. Correction is immediate or short-term. Corrective action is medium to long-term.
• Analysis required. Correction needs no root cause analysis. Corrective action requires it.
• Scope. Correction covers the specific instance. Corrective action covers the system and similar instances elsewhere.
• Effectiveness review. For correction, you check that the issue is fixed. For corrective action, you check that the issue does not recur.
• Clause reference. Correction is 10.2 a). Corrective action is 10.2 b) to e).

4. Common Pitfalls Seen by Auditors

• Retraining as a default. "Retrain the employee" is often offered as corrective action when the real cause is a missing control or an unclear procedure.
• Root cause equals restated problem. For example: "Root cause: the account was not disabled." That describes what happened, not why.
• Correction labelled as corrective action. "Corrective action: disabled the account." That is only a correction.
• No effectiveness review. The action is implemented, but nobody checks whether it worked.
• No extent check. The fix is applied to one system while the same weakness remains in others.
• Disproportionate action. Rewriting the whole ISMS for a minor clerical error, or making trivial changes for a major systemic failure.

5. Role of the Auditor: Do Not Consult
A third-party certification auditor must stay impartial (ISO/IEC 17021-1). The auditor may assess whether proposed corrections and corrective actions are adequate, but must not design or recommend specific solutions. Doing so would be consultancy and create a conflict of interest. The auditor can say a proposed corrective action does not appear to address the root cause. The auditor cannot say "you should implement tool X."

Exam Tips: Answering Questions on Correction Versus Corrective Action

Tip 1: Learn the definitions word for word.

• Correction: action to eliminate a detected nonconformity.
• Corrective action: action to eliminate the cause of a nonconformity and to prevent recurrence.

Many multiple-choice questions turn on the words "detected nonconformity" versus "cause" and "recurrence."

Tip 2: Look for keywords in the scenario.

• Words such as immediately, fixed, removed, disabled, replaced, re-done, quarantined usually point to correction.
• Words such as root cause, procedure updated, process redesigned, prevent recurrence, systemic, analysed why point to corrective action.

Tip 3: Ask yourself, does this action stop it happening again?
If the answer is no, it is a correction. If yes, because the underlying cause has been addressed, it is a corrective action.

Tip 4: Remember that correction during the audit does not cancel the nonconformity.
A frequent trick question: "The auditee fixed the issue while the auditor was present. What should the auditor do?" The correct answer is to still record the nonconformity, noting that a correction was made. Corrective action is still required.

Tip 5: Know Clause 10.2 thoroughly.
Be able to list its required elements:

1. react and correct,
2. evaluate the need for action on causes,
3. implement,
4. review effectiveness,
5. change the ISMS if necessary,
6. retain documented information.

Questions may ask which element is missing from an auditee's response.

Tip 6: Do not confuse corrective action with preventive action.
Corrective action responds to a nonconformity that has occurred. Preventive action is about potential nonconformities and is now covered by risk-based thinking (Clause 6.1). If an answer option mentions preventive action as a separate ISO/IEC 27001:2022 clause requirement, it is probably wrong.

Tip 7: Know the major versus minor follow-up expectations.

• Major: evidence of correction and corrective action, and often verification, is needed before certification is granted.
• Minor: an acceptable plan is usually sufficient, with verification at the next audit.

Tip 8: Spot weak root cause analysis.
In essay or scenario questions, criticise responses where:

• the root cause is simply "human error,"
• the problem is merely restated, or
• retraining is offered as a universal solution without explaining why the system failed.

Tip 9: Respect auditor impartiality.
If a question asks what the auditor should do when the auditee requests advice on corrective action, the right answer is that the auditor may clarify the requirement and the nonconformity but must not provide consultancy or prescribe solutions.

Tip 10: Structure written answers clearly.
For long-answer or case-study questions, use this structure:

1. Define both terms.
2. Identify which actions in the scenario are corrections and which are corrective actions.
3. Evaluate whether the root cause analysis is adequate.
4. State whether the response meets Clause 10.2.
5. Recommend what the auditor should do next, such as accept, request further information, or plan a follow-up.

Tip 11: Practise classifying examples.
Write down ten audit findings and, for each, draft one correction and one corrective action. This builds the reflex the exam tests.

Tip 12: Watch for the word "effectiveness."
Effectiveness review applies to corrective action. If a question asks how an auditor verifies a corrective action, the answer involves evidence that the cause was eliminated and the nonconformity has not recurred, not just evidence that a task was completed.

Worked Exam Example
Scenario: During a stage 2 audit, the auditor finds that three laptops in the finance department do not have full-disk encryption, contrary to the organisation's cryptography policy. The IT manager immediately encrypts the three laptops and says the issue is closed.

Question: Evaluate the IT manager's response.

Model answer:

• What was done. Encrypting the three laptops is a correction. It removes the detected nonconformity.
• Why it is not enough. No root cause analysis has been done, so no corrective action has been taken.
• What remains to be found out. The organisation needs to know why the laptops were unencrypted. Possible causes include:
  • a gap in the device provisioning procedure,
  • no automated compliance check in endpoint management, or
  • a missing step in the build standard.
• Extent check. The organisation should also check whether other departments have unencrypted devices.
• What the auditor should do.
  • Record the nonconformity even though the correction was made.
  • Grade it appropriately. It may be minor if isolated, or major if it shows a systemic failure of the control.
  • Request a corrective action plan with evidence of root cause analysis and an effectiveness review, as required by Clause 10.2.

Conclusion
Correction fixes what is broken. Corrective action fixes why it broke. ISO/IEC 27001 requires both: the correction limits immediate risk, and the corrective action makes sure the ISMS learns and improves. For the Lead Auditor exam, remember the definitions, link them to Clause 10.2, recognise weak root cause analysis, and remember that an on-the-spot correction never cancels a nonconformity.