Corrective Actions and Root Cause Analysis for ISMS Findings

Every internal audit produces findings. That is the point of an audit. The problem is not the finding itself. The problem is what happens next. Most teams log a corrective action, do something quick, and mark it closed. Then the same issue reappears twelve months later, and the auditor notices.

This post is about closing findings so they stay closed. That means treating the finding as a symptom, not the disease.

What a finding actually tells you

A finding is a gap between what your ISMS says and what you actually do. It is evidence that a control did not operate as designed, or was never designed well enough to begin with.

There are two mistakes teams make when they read a finding.

The first is treating it as a personal failure. Someone forgot to review access, so the fix is to remind that person. This fixes nothing. People forget. Reminders decay.

The second is treating every finding as a crisis. Not every finding needs a formal root cause investigation. A single mistyped date in one record is a correction, not a systemic problem. Spending two hours on a fishbone diagram for that wastes everyone's time and trains people to hate the process.

The skill is telling the difference. Ask one question: if I do nothing about the underlying cause, how likely is this to happen again? If the answer is "very likely" or "I genuinely do not know," you have a corrective action. If the answer is "this was a genuine one-off," you have a correction and you move on.

Correction versus corrective action

These two terms get used interchangeably. They are not the same, and auditors care about the distinction.

• A correction fixes the immediate instance. An offboarded user still had access, so you revoke it. Done.
• A corrective action addresses why the instance happened, so it does not recur. You find out why the offboarding process missed that account, and you change the process.

Almost every finding needs a correction. Only some need a corrective action. But when a corrective action is warranted, skipping it is the single most common reason findings reopen.

A useful test: if your only response to a finding is to fix the specific record and nothing about your process changes, ask yourself honestly whether the next audit will find another instance. If it will, you did a correction and called it a corrective action.

Getting to a real root cause

Root cause analysis has a reputation for being heavyweight. It does not have to be. For most SaaS and fintech ISMS findings, a disciplined conversation is enough.

The "five whys" method works well when used honestly. The trick is to keep going past the first satisfying answer.

Take a real example. Finding: a departing engineer kept production database access for three weeks.

• Why? Their access was not revoked at offboarding.
• Why? Offboarding covered the identity provider but not the database, which uses separate credentials.
• Why? The offboarding checklist was written before that database was added to the stack.
• Why? No one owns keeping the checklist current as infrastructure changes.
• Why? Infrastructure changes and access governance are handled by different people who do not talk.

The first "why" would have led you to revoke one account. The fifth reveals a structural gap between how you change infrastructure and how you govern access. That is the real corrective action: a step in your change process that flags new systems for inclusion in joiner-mover-leaver procedures.

Two cautions. Do not force exactly five whys. Sometimes you reach the root in three. Sometimes you need seven. Stop when the next "why" moves outside your ability to act. And do not let the chain drift into blame. "Why did the engineer not remind us" is the wrong direction. The system should not depend on the departing person remembering to remove their own access.

Writing corrective actions that hold

A weak corrective action reads like an intention. A strong one reads like a change to how work happens.

Compare these:

• Weak: "Team will be more careful with offboarding going forward."
• Strong: "Add a database access revocation step to the offboarding runbook, owned by the platform lead, triggered automatically when HR marks a leaver. First run to be verified by the ISMS owner within 30 days."

The strong version has four things the weak one lacks: a specific change, a named owner, a trigger that does not rely on memory, and a verification date. Every corrective action you write should have all four.

Give each corrective action a realistic target date. A date three days out that everyone knows is fiction is worse than an honest date six weeks out. Auditors read overdue actions as a sign your ISMS is not being managed. A small number of open actions with credible dates reads as a system that is working.

Closing the loop and proving it

A corrective action is not closed when the change is made. It is closed when you have verified the change works and the original problem cannot recur in the same way.

Verification is the step teams skip most. Build it in explicitly.

• Confirm the action was implemented. The runbook step exists. The automation fires.
• Confirm it is effective. Test one real leaver after the change and check the database access is gone without manual intervention.
• Record the evidence. A dated note, a screenshot, a ticket link. Something an auditor can see without asking you to explain.

Then watch for recurrence over the following cycle. If the same finding appears again after you closed it, that is not a new finding. It is proof the root cause was never addressed, and it is a far worse conversation with your certification auditor than the original issue would have been.

Keep your corrective action log simple and current: the finding, the correction, the root cause, the corrective action, the owner, the target date, the verification evidence, and the closure date. That single table is often the most convincing artefact in an internal audit, because it shows a system that notices problems and actually resolves them.

Bottom line

Findings are healthy. A management system that never surfaces anything is not mature, it is asleep. What matters is whether your corrective actions change how work happens or just document good intentions. Get the root cause right, name an owner, remove the dependency on memory, and verify before you close.

If you are not sure whether your corrective actions would survive scrutiny, or your action log has a quiet pile of overdue items, a Kellwick readiness review can pressure-test your process before an external auditor does it for you.