Back to blog
Audit

Correction vs corrective action: closing findings so they stay closed

Fixing the instance an auditor found is a correction. Fixing why it happened is corrective action. Confusing the two is why the same finding returns every cycle - and why auditors check.
GRC Copilot Team
Correction vs corrective action: closing findings so they stay closed

An auditor finds that one leaver's account was not disabled. You disable it. That is a correction. Nothing about why it was missed has changed, so it will happen again - and the auditor knows that, which is why they will ask what you did beyond fixing the instance.

The three terms

  • Correction - action to eliminate the detected nonconformity itself. Disable the account. Necessary, immediate, insufficient.
  • Corrective action - action to eliminate the cause so it does not recur. Fix the offboarding trigger, add the reconciliation, close the handover gap.
  • Preventive action - addressing potential nonconformities before they occur. In current ISO management standards this is largely absorbed into risk-based thinking rather than being a separate clause.

ISO 27001 requires both correction and, where appropriate, evaluation of the need for corrective action to eliminate causes. "Where appropriate" is not an escape hatch - it means you must decide and record the decision.

Finding the actual cause

Root cause analysis fails when it stops at the first plausible answer, which is almost always "human error". People are the mechanism, rarely the cause.

Five whys, done properly

The leaver's account was still active.
Why? IT was not told they had left.
Why? The manager did not raise an offboarding ticket.
Why? Offboarding is a manual step outside the HR system.
Why? The HR system and the identity provider are not integrated.
Why? Nobody owns the joiner-mover-leaver process end to end.

The correction is disabling one account. The corrective action is assigning ownership and integrating the trigger. Stopping at "the manager forgot" produces a reminder email and a repeat finding.

A useful test: if your root cause is a person, keep going. If your corrective action is "remind staff to be careful", you have not found the cause.

Track findings to verified closure

GRC Copilot records findings against the controls they affect, tracks corrective actions and owners, and holds the evidence that closure was verified.

The full sequence

  1. React. Take correction and deal with the consequences.
  2. Evaluate whether corrective action is needed - review the nonconformity, determine causes, and check whether similar issues exist elsewhere.
  3. Check for recurrence elsewhere. This step is routinely skipped. If offboarding failed for one system, test the others before the auditor does.
  4. Implement the corrective action.
  5. Review effectiveness - did it work? This requires waiting and re-testing, not just confirming the change was made.
  6. Update the risk assessment and the ISMS if needed.
  7. Retain records of the nonconformity, actions taken and results.

Evidence of effectiveness is the step that gets missed

Marking a finding closed because the fix was deployed is not evidence it worked. For a periodic control, effectiveness evidence means the next occurrence happened correctly. For an integration, it means testing that a subsequent leaver was actually deprovisioned.

External auditors specifically look at last cycle's findings and ask what evidence shows they stayed fixed. A finding that recurs after being closed is treated far more seriously than a new one.

Common failures

  • Correction recorded as corrective action. The most frequent one.
  • Root cause stated as human error, producing training as the only action.
  • No check for the same issue elsewhere.
  • Closure without effectiveness evidence.
  • Unrealistic due dates set to look responsive, then missed - which becomes its own finding.
  • Only auditor-raised findings tracked. Self-identified issues should flow through the same process; doing so demonstrates a working management system.

Self-identified findings are an asset

Organisations sometimes hide problems they found themselves, fearing they look bad. The opposite is true: a register containing self-identified nonconformities, properly analysed and closed, is strong evidence that your ISMS detects and corrects. A register containing only external findings suggests nothing internal is looking.

Frequently asked questions

Does every nonconformity need root cause analysis?

You must evaluate whether corrective action is needed and record that evaluation. Minor isolated issues may justify correction alone - but the decision must be documented, not implied.

How long should closure take?

Set dates by severity and meet them. Major nonconformities from a certification audit usually carry a defined window set by the registrar.

What if the corrective action does not work?

Reopen it and analyse again - the cause was misidentified. Recording that honestly is better than closing something that has not changed.

Which RCA technique should we use?

Five whys is sufficient for most compliance findings. Fishbone diagrams help where causes are multi-factorial. The technique matters less than not stopping at the first answer.

Key takeaways

  • Correction fixes the instance; corrective action fixes the cause.
  • If your root cause is a person, keep asking why.
  • Check whether the same issue exists elsewhere before closing.
  • Closure requires evidence of effectiveness, not just evidence of change.
#corrective-action #root-cause #nonconformity #capa #continual-improvement