Clause 10: Improvement

Overview

Clause 10 closes the Plan-Do-Check-Act loop. It requires you to react to nonconformities (things that go wrong), take corrective action to address the root causes, and continually improve the suitability, adequacy, and effectiveness of your ISMS. An ISMS that does not improve over time will inevitably become ineffective as threats evolve and the business changes.

10.1 Nonconformity and Corrective Action

When a nonconformity occurs — whether identified through an audit, incident, complaint, or routine monitoring — the organisation must:

1. React to the nonconformity by taking action to control and correct it, and deal with the consequences.
2. Evaluate the need for corrective action — determine whether action is needed to eliminate the root cause so the nonconformity does not recur or occur elsewhere.
3. Implement corrective action — put changes in place to address the root cause.
4. Review the effectiveness — verify that the corrective action was effective.
5. Update the ISMS if necessary — make changes to the management system to reflect lessons learned.

Corrective actions must be proportionate to the effects of the nonconformities encountered. You must retain documented information as evidence of the nature of nonconformities, actions taken, and the results of corrective actions.

10.2 Continual Improvement

The organisation must continually improve the suitability, adequacy, and effectiveness of the ISMS. Continual improvement is not just about fixing problems — it is about proactively seeking ways to make the ISMS work better. Sources of improvement include:

• Results from internal and external audits.
• Analysis of security incidents and near-misses.
• Changes in the threat landscape or regulatory environment.
• Feedback from management reviews and interested parties.
• Benchmarking against industry peers and best practices.
• Technology improvements that enable better controls.

Root Cause Analysis

Effective corrective action requires understanding the root cause, not just the symptoms. Common root cause analysis techniques include the “5 Whys” method, fishbone (Ishikawa) diagrams, and fault tree analysis. For security incidents, root cause analysis should consider whether the issue was caused by a process gap, a technology failure, a people issue (lack of training or awareness), or an external factor.

How Standardise Helps

• Incidents module — track security incidents from detection through to resolution with severity levels, root cause analysis, and corrective actions. Incidents flagged as notifiable trigger NDB deadline tracking with countdown badges.
• Audit findings — the Audits module tracks findings with severity ratings and corrective action status, directly supporting the nonconformity workflow required by 10.1.
• Immutable audit trail — every change within Standardise is logged, providing the documented information required for corrective action records.
• Dashboard compliance ring — the compliance readiness metric on the dashboard tracks your overall progress over time, making it easy to demonstrate continual improvement to auditors.