Nonconformity and corrective action
Plain English Translation
Clause 10.2 mandates that when something goes wrong (a nonconformity), the organization cannot simply fix the immediate issue and move on. You must react to control the situation (correction) and then perform a root cause analysis to understand why it happened. Based on this analysis, you must implement a 'corrective action' to modify the system or process so the error does not reoccur, and finally, verify that this new measure was effective.
Technical Implementation
Use the tabs below to select your organization size.
Required Actions (startup)
- Log nonconformities in a simple spreadsheet or the 'Security' section of the bug tracker
- Perform '5 Whys' root cause analysis for major issues
- Review open actions monthly
Required Actions (scaleup)
- Formalize the Corrective Action Procedure with defined SLAs for closure
- Link corrective actions directly to Engineering tickets (e.g., Jira)
- Track 'recurrence rate' as a key metric
Required Actions (enterprise)
- Automate nonconformity workflows within a GRC platform
- Conduct statistical analysis on root causes to identify systemic weaknesses
- Integrate corrective actions with automated regression testing
A nonconformity is the non-fulfillment of a requirement. This could be a failure to follow your own internal policies, a failure to meet a specific ISO 27001 clause, or a breach of a legal/contractual requirement.
A Major Nonconformity describes a total breakdown of a system or process (e.g., no risk assessment performed). A Minor Nonconformity is a single lapse or isolated incident (e.g., one employee missed training) where the system is otherwise functioning.
You must: 1) React to control/correct it; 2) Evaluate the need for action to eliminate the root cause; 3) Implement the action; 4) Review the effectiveness; and 5) Make changes to the ISMS if necessary.
Correction is the immediate fix to the specific problem (e.g., patching a server). Corrective Action is the deeper change to the process to prevent it from happening again (e.g., implementing an automated patch management system).
Examples include: Access rights not revoked upon termination, lack of evidence for a management review, failure to test backups, or a policy document that hasn't been reviewed in years.
Common methods include the '5 Whys' technique (asking why until the fundamental cause is found) or Fishbone diagrams. The goal is to move beyond 'human error' to find process or system flaws.
It should include a description of the nonconformity, the immediate containment actions, the root cause analysis, the planned long-term corrective action, the owner, the due date, and the method for verifying effectiveness.
Verification involves checking, after a suitable period, that the action was implemented and that the nonconformity has not recurred. This can be done via a follow-up audit, spot check, or reviewing metrics.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-18 | WatchDog Security GRC Team | Initial publication |
