Corrective Action & Continual Improvement Procedure

​

Purpose

​

What raises a corrective action

• An internal audit finding (see Internal Audit Procedure).
• An external audit finding (SOC 2 / ISO certification / customer audit).
• A security or privacy incident (see Incident Response Policy) or AI incident.
• A failed control test (e.g., a Vanta test in NEEDS_ATTENTION) that indicates a process gap rather than a one-off.
• A management-review decision or a missed objective (see ISMS Management Review).
• A risk-treatment action that is overdue or ineffective.
• A complaint, whistleblower report, or customer-reported issue indicating a systemic gap.

​

Corrective action workflow

1. Record the nonconformity in the corrective-action register (Linear #compliance/#security), including: source, description, the criterion or requirement not met, severity, date raised, and owner.
2. Contain — take immediate action to control and correct the nonconformity and deal with its consequences (e.g., revoke access, patch, notify).
3. Analyze root cause — determine why the nonconformity occurred, and whether similar nonconformities exist or could occur elsewhere. Use a structured method (5 Whys / fishbone) proportionate to severity.
4. Plan corrective action — define the action(s) needed to eliminate the root cause so the nonconformity does not recur, with an owner and due date. Distinguish correction (fix the instance) from corrective action (fix the cause).
5. Implement the action.
6. Verify effectiveness — confirm the action eliminated the cause (e.g., re-test the control, re-audit the area). A CA is not closed until effectiveness is verified.
7. Update the management system — where the root cause is a policy/procedure/control gap, update the affected document (via PR through the appropriate CODEOWNERS), the risk register, the Controls Inventory, and the relevant Statement of Applicability as needed.

​

Severity and timelines

​

Continual improvement

• Tracking information-security and AI objectives (see the ISMS Management-System Register) and acting on those not on track.
• Maintaining an improvement backlog of OFIs from audits, reviews, incidents, and risk assessments.
• Reviewing CA trends at each ISMS Management Review — recurring causes drive structural change, not just point fixes.

​

Records

• Corrective-action register (per CA: source, root cause, action, owner, dates, verification).
• Retained for 6 years. See the Records Retention Schedule.

​

Cross-references

• Internal Audit Procedure — primary source of nonconformities.
• ISMS Management Review Procedure — reviews CA status and trends.
• Incident Response Policy — incident-driven corrective action.
• Risk Management Policy — risk-treatment linkage.
• ISMS Management-System Register — objectives.

​

Version history