The corrective action report is the ISMS record written most often and hollowed out most easily. One per internal audit finding, one per incident, one per audit nonconformity. By the tenth or twentieth, filling in the form becomes the objective, and the same two phrases appear everywhere: "Cause: staff awareness," "Action: reminder issued."
The problem with those phrases is not that auditors object. It is that the same nonconformity returns next year. As long as the cause is awareness and the control is a reminder, staff turnover and fading memory guarantee recurrence.
Corrective action is fundamentally about moving the question from "that person got it wrong" to "that structure produces this outcome every time." Organisations that manage this see their corrective action count fall year on year; those that do not repeat the same count indefinitely.
This article covers correction versus corrective action, root cause analysis, verification of effectiveness, converting audit findings into corrective action, and the structure of a worked report. See Clause 10: Improvement, Running an Internal Audit and What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: General information only. The standard and the publications of accreditation and certification bodies are authoritative; deadlines and forms for closing nonconformities vary by certification body. Follow your certification body's instructions.
Why This Is Where People Get Stuck
Stopping at the correction
Misdirected email → asked the recipient to delete it → done. That is a correction, not corrective action. You cleaned up the event and reduced the chance of recurrence by nothing at all. Clean-up appears in the "corrective action" field remarkably often.
Causes that terminate in a person
"Insufficient checking," "poor understanding of the procedure," "low awareness." These are not causes; they are restatements of the event. The cause is that the design allowed the check to be skipped, or that the procedure was written in a form nobody absorbs.
Five whys that stop at three
"Why the misdirected send? The address wasn't checked. Why not? They were rushing. Why? Workload." — and out comes "optimise workload," which nobody can execute. The problem is that the questioning ran in one direction only.
Effectiveness "verified" by confirming the action happened
Confirming the action was taken and confirming it worked are different things. The standard asks for the latter; most reports record "training delivered on such a date."
Transcribing the auditor's wording
Pasting the finding text into "description of nonconformity" and writing something shallow underneath. What the certification body is looking for is whether you re-framed the finding as your own problem — transcription works against you.
What You Decide
Correction versus corrective action
The standard requires you first to react to the nonconformity and deal with its consequences (correction), then to evaluate whether action is needed to eliminate the cause and act if so (corrective action). They differ in purpose and timescale.
| Correction | Corrective action | |
|---|---|---|
| Purpose | Contain the event and stop its effects | Remove the cause and prevent recurrence |
| Target | The event itself | The structure that produced it |
| Timescale | Immediate to days | Weeks to months |
| Example | Ask the recipient to delete; disable the rogue account; add the missing record | Introduce a pre-send confirmation; change the access granting procedure; make the field mandatory in the system |
| Always required? | Yes, wherever there are consequences | A judgement after evaluation. If not taken, record why |
Corrective action is not unconditionally mandatory, which matters in practice. The standard requires that the need for it be evaluated. Declining it for a minor, one-off event on cost-benefit grounds is legitimate — provided the reasoning is recorded. "Evaluated; corrective action judged unnecessary because X" is far stronger than a blank field.
Note also that the 2022 edition contains no separate "preventive action" requirement; that function is carried by Clause 6's actions to address risks and opportunities. Horizontal deployment — "could this happen elsewhere?" — is therefore handled inside corrective action.
Fields the report needs
| Field | What goes in it | Common failure |
|---|---|---|
| Reference, date raised, raised by | Start of the trail | — |
| Source | Internal audit / certification audit / incident / customer finding / operations / exercise | — |
| Description (facts) | When, where, what, and against which requirement | Mixing in judgement or speculation |
| Requirement concerned | Clause or control, internal policy article, contract, law | Left blank |
| Impact assessment | Effect on information, spread to other units or customers, reporting obligations | Omitted |
| Correction | What was done to contain it, when, by whom | Corrective action written here |
| Root cause analysis | Why the structure produced this | Ends at "awareness" |
| Need for corrective action | Needed / not needed, and why | Field absent entirely |
| Corrective action | What, by whom, by when | Ends at "we will be thorough" |
| Horizontal deployment | Whether the same exists in other units, systems, customers | Not considered |
| Implementation result | Date, content, evidence references | — |
| Verification of effectiveness | When, and on what basis it will be judged effective; the result | "Action completed" |
| Document revision | Whether procedures change, and to which version | Not considered |
| Closure approval | Approver and date | — |
The two fields most organisations lack are "need for corrective action" and "horizontal deployment." Adding them visibly changes report quality.
The Practice
1. Establish the facts
Write facts without judgement.
- Weak: "Supplier management was sloppy and reviews were not performed"
- Strong: "As of March 2026, five of the twelve Tier 1 suppliers in the register had no FY2025 annual review record. Article 7 of the Supplier Management Policy requires annual review of Tier 1 suppliers"
Identify the requirement breached — clause, internal policy, or contract. Ambiguity here makes the remediation goal ambiguous too.
2. Take the correction
Stop the effects and clean up. Above, that means promptly reviewing the five suppliers. The cause is still untouched.
Where information has leaked or external parties are affected, route it through the incident response procedure first, because external notification decisions are involved.
3. Analyse the cause
Five whys works, but not alone. Three refinements change the quality of the analysis.
Refinement 1: ask in two directions
Ask not only "why did it happen" but "why was it not detected."
| Direction | Question | Analysis in the example |
|---|---|---|
| Occurrence | Why was the review not performed? | The policy did not fix a timing; each owner decided. It was deferred during a busy period and forgotten |
| Detection | Why was the omission not noticed during the year? | The register has a "last reviewed" field but nothing flags overdue entries, and the secretariat never checked mid-year |
Splitting the direction yields two kinds of control — occurrence (fix the timing in policy, put it in the annual plan) and detection (surface overdue entries, check quarterly). Either alone will fail eventually.
Refinement 2: drop through three layers
| Layer | Question | Example |
|---|---|---|
| Technical | Could a mechanism have prevented it? | The register is a spreadsheet with no deadline alerting |
| Operational | Was the procedure or rule deficient? | No timing specified; left to individuals |
| Managerial | Was oversight or accountability deficient? | No routine review of review status; omissions invisible |
All three layers often contain a cause. A report naming only one is usually either shallow or selecting the layer that is easiest to fix.
Refinement 3: when the answer is a person, change the question
When the whys land on "the owner forgot," do not stop — switch:
- Can it be designed so forgetting does not matter?
- Can it be designed so someone notices quickly?
- Does a human need to remember this at all?
Without the switch, the control is always "reminder" or "retraining." Training is an effective control only when the cause is "did not know." Applied to something people knew but did not do, it does nothing.
Refinement 4: look for the change point
When a long-stable process suddenly fails, ask what changed just before — a handover, a system update, a workload increase, a reorganisation, a new supplier. Identifying it turns the control into something concrete: a verification step attached to that kind of change.
4. Decide whether corrective action is needed, and what it is
| Consideration | Points toward acting | Points toward not acting |
|---|---|---|
| Likelihood of recurrence | Structurally repeatable | One-off, needing an unusual coincidence |
| Magnitude | Could lead to disclosure or loss of availability | Limited and recoverable |
| Horizontal spread | The same structure exists elsewhere | Specific to this instance |
| Cost-effectiveness | Structurally preventable at reasonable cost | Cost far exceeds the impact |
Actions need what, who, by when to be trackable — and should prefer structural prevention.
| Strength | Type | Example |
|---|---|---|
| Strong | Make it structurally impossible | Do not grant the privilege; remove the function; do not hold the data |
| Medium-strong | Enforce in the system | Mandatory fields, embedded approval flow, automated alerts, overdue visibility |
| Medium | Change the procedure | Fix timing in policy, add a checklist, introduce a second check |
| Weak | Rely on attention | Training, reminders, announcements |
Closing a corrective action on weak measures alone should be reconsidered as a rule. Where cost or technical constraints rule out strong measures, pair the weak measure with a detection mechanism (training plus periodic verification of practice).
5. Verify effectiveness
This is the weakest field in most reports. The standard asks you to review the effectiveness of the action taken — not that it was taken.
Write when and on what basis at the time the action is decided, not afterwards.
| Corrective action | How effectiveness is verified | When |
|---|---|---|
| Overdue visibility added to the supplier register; quarterly secretariat check | Zero overdue entries at the next quarterly check; any overdue detected within the period | 3 months after |
| Pre-send confirmation dialog for external email | Misdirected-send reports over six months lower than the same period before | 6 months after |
| Manager approval made mandatory for access grants | Zero grants without an approval record at the next recertification | Next recertification |
| Case-based exercises added to security training | Comprehension test scores and incidents of the same type after training | 6 months after |
If verification shows it did not work, record that and return to analysis. "Verified, found insufficient; analysis revisited and further action taken" is evidence of a working ISMS. Closing it as successful is far worse.
Verification results feed Management Review.
6. Update documents and records
If the cause was a deficient procedure, revise the procedure. Reports saying "the procedure will be revised" while the procedure stays at the old version are common. Record the version and date in the report.
The Structure of a Worked Report
The point below is not the wording but the level of detail in each field.
| Field | Example entry |
|---|---|
| Reference | CA-2026-014 |
| Raised | 18 Mar 2026 / ISMS secretariat |
| Source | Internal audit (FY2026 round 1, IT department) |
| Description (facts) | Of six administrator privileges granted on production since the October 2025 recertification, three had no record of the manager approval required by policy. All grants were operationally necessary; no unnecessary privilege was identified |
| Requirement | Access Control Policy Art. 12 (granting privileged access) / ISO/IEC 27001 Annex A technological control on privileged access rights |
| Impact | All grants were within operational need; audit logs show no trace of disclosure or alteration. Effect on customer hospitals and any statutory reporting obligation were considered and found not applicable (ISMS lead, 19 Mar 2026) |
| Correction | Retrospective manager approval obtained for the three grants after review (completed 20 Mar 2026). All fifteen current administrator privileges re-validated; one unnecessary privilege removed (22 Mar 2026) |
| Root cause | (1) Occurrence: grants are handled on internal tickets, but the ticket had no approver field and approval was given verbally or by chat; the procedure did not state that a record was required. (2) Detection: no in-period check of grant records existed, so omissions surfaced only at six-monthly recertification. (3) By layer: technical — no approver field; operational — approval method unspecified; managerial — no in-period check designed |
| Need for corrective action | Needed. The omission is structurally repeatable, and the same ticket practice is used for other systems, requiring horizontal deployment |
| Corrective action | (1) Add mandatory "approver" and "approval date" fields to the ticket form (IT, by 30 Apr 2026) (2) Amend Access Control Policy Art. 12 to state that approval is recorded on the ticket (secretariat, by 30 Apr 2026) (3) Add a monthly check of grant approval records (IT, from 1 May 2026) |
| Horizontal deployment | Grants for internal systems and development environments using the same ticket practice were checked and brought into the same action (completed 10 Apr 2026; two omissions approved retrospectively) |
| Implementation | (1) Ticket form revised 24 Apr 2026 (2) Policy v3.2 issued 28 Apr 2026 (3) Monthly check started May 2026; May completed |
| Verification of effectiveness | Method: at the October 2026 half-year recertification, zero approval omissions among privileges granted since May 2026; and any omission found in a monthly check remediated within the same month. Planned date: 31 Oct 2026. Result: (pending) |
| Document revision | Access Control Policy v3.2 (28 Apr 2026); Access Granting Procedure v2.1 (24 Apr 2026) |
| Closure approval | (entered after verification) |
Three things to note:
- The description records what was not found (no trace of disclosure). Evidence of absence is also evidence of a judgement made
- The cause is written in three layers, and there are three actions because there are three causes
- Verification is set at a future date and the report is not yet closed. A corrective action report is not finished when the action is implemented
Closing reports at "implemented" is the single largest reason effectiveness verification becomes theatre. Putting closure approval after verification prevents it structurally.
Where It Goes Wrong
Not translating the audit finding into your own terms
The certification body's wording records what the auditor saw. You must re-analyse which of your structures produced it. A plan that transcribes the finding into the cause field is sometimes returned.
Responding to an audit finding generally follows this sequence. Deadlines and forms differ by certification body — follow their instructions.
| Stage | Content |
|---|---|
| 1. Receive the finding | The report states the nonconformity, including its classification |
| 2. Correct | Take immediate action on the event |
| 3. Submit the corrective action plan | Cause analysis, actions, deadlines, submitted by the stated date |
| 4. Implement | Carry out the plan and assemble evidence |
| 5. Submit evidence | Revised documents, records of implementation |
| 6. Verification by the body | Document review, or on-site verification depending on classification |
| 7. Closure | The body confirms effectiveness and closes the finding |
Major nonconformities bear directly on issuing or maintaining certification. See Common Nonconformities, What Stage 2 Audits Look At and Preparing for Surveillance Audits.
Too many corrective actions to process
Thirty findings from one internal audit, each needing a report, consuming six months. That is partly an audit design problem. Distinguish observations from nonconformities and reserve the latter for clear failures against a requirement.
Deadlines missed and cases abandoned
Items raised and untouched for six months accumulate. Manage them on one list and surface overdue items monthly. Where an action cannot be completed, obtain approval to extend and record the reason — silently lapsing and formally extending look entirely different in the record.
The same cause recurring every year
Clear evidence that corrective action is not working. Classify past reports by cause once a year and extract the repeats; the analysis becomes the argument for resources at management review.
Incidents and nonconformities managed separately
Two registers with no cross-reference. Since incident prevention is corrective action, link them by reference number and manage as one.
No record kept
The standard requires documented information on the nature of nonconformities, the actions taken, and the results. A case handled verbally counts as not handled.
Healthcare Examples
A healthcare SaaS provider
The distinctive issue is corrective action that touches customer hospitals. If remediating an access design flaw requires customers to change settings, or changes behaviour, the plan must include customer communication and a transition period — and a step verifying customers actually completed it.
The second is nonconformities around production data access. Missing request and approval records from incident investigation are the classic case, and the strong control is a mechanism — time-bounded privileges, mandatory reason capture, no access without a request — not training. See Shared Responsibility in AI EMR Security Design.
A PHR operator
Consent scope nonconformities trace back into the product development process. If the cause is that feature planning has no consent-scope review step, the corrective action is to add that review to the development process. Closing it inside operations guarantees recurrence. See ISMS for PHR Operators.
A clinical trial systems company
For record integrity nonconformities, even the correction is constrained: a late entry must be unambiguously identifiable as such in the audit trail. A correction that quietly makes the records consistent is a graver problem than the original. Design the correction to satisfy the integrity requirement.
A SaMD developer
ISMS corrective action runs alongside QMS (ISO 13485) CAPA. Where one event falls under both, decide which record is authoritative and how the other references it rather than writing two reports. Starting without that rule creates a new nonconformity: inconsistent records. See SaMD, ISMS and ISO 13485.
Relationship to the three-ministry guidelines
Gaps found in a customer hospital's audit or in guideline checklist work are best handled as ISMS corrective actions, keeping management in one place. See Three-Ministry Guidelines Compliance Checklist, Integrating ISMS Documents with the Three-Ministry Guidelines and Learning from the Structure of Incidents.
Conclusion
- Correction and corrective action are different things. Clean-up is not corrective action. Evaluate the need, and record the reasoning even when you decline
- Analyse in two directions — occurrence and detection — and three layers — technical, operational, managerial. When the answer is a person, change the question
- Prefer controls that prevent structurally. Training is effective only where the cause was "did not know"
- Fix the timing and basis of effectiveness verification when the action is decided, and put closure approval after verification
- Translate audit findings into your own terms before analysing; transcription gets plans returned
- Classify past reports by cause once a year to find what keeps recurring
Corrective action status and effectiveness results feed Management Review, where resources are allocated. Findings originate in Internal Audit and Incident Response, and exercise findings in Business Continuity and the ISMS. Gaps found in supplier reviews are handled per Supplier Security Management.
Pottech supports ISMS certification and operation with a focus on healthcare. Turning an audit finding into remediation that does not recur is a matter of cause-analysis design, not form-filling. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee (JISC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Information-technology Promotion Agency, Japan (IPA)
Note: interpretation of requirements, the handling of accreditation and certification, and the deadlines and forms for closing nonconformities are governed by the standard and by the certification body's publications and instructions, and may change with revisions.