ISO 27001 Clause 10.2: Nonconformity and corrective action

Clause 10.2 requires organisations to have a clear and structured way of managing problems with their information security management system (ISMS).

In simple terms, when an issue arises or requirements are not met, the organisation must:

• Fix the issue
• Understand why it occurred
• Prevent it from happening again
• Provide evidence that the fix is effective.

This Clause is important because auditors often use it to judge the maturity of the ISMS.  When organisations repeatedly fail to meet the requirements of Clause 10.2, it often leads to major nonconformities.  Clause 10.2 also supports continual improvement, which is a key principle of ISO 27001.

An organisation may have strong, well-documented controls, but without an equally strong corrective action process, the ISMS is weak and not sufficiently resilient.

A nonconformity occurs when a required condition is not fulfilled.  This requirement can originate from various sources, such as:

• ISO 27001 requirements
• The organisation’s own ISMS policies or procedures
• Applicable legal, regulatory, or contractual obligations.

Having nonconformities is normal and auditors do not expect organisations to be perfect.  What really matters, though, is how the organisation responds when a problem is identified.

Not all nonconformities are the same.  Auditors usually classify them as minor or major, based on the impact and how widespread the issue is.

Minor nonconformity

A minor nonconformity usually means there is a discrete or isolated problem, but the ISMS still functions overall.

Examples of minor nonconformities include:

• A policy exists and is approved, but one department is using an outdated version
• Staff understand policies, but one person does not know where to find them
• Access reviews are conducted quarterly, but evidence for a particular system is missing
• Policies exist but are not implemented in real operations.

These issues should still be fixed, but they do not indicate a complete system failure.

Major nonconformity

A major nonconformity exists when there is a total absence of a required process or control, a systemic failure in the ISMS, repeated minor nonconformities (suggesting loss of control), or a situation that seriously impacts information security objectives.

Examples of major nonconformities include:

• No corrective action process exists at all
• An information security risk assessment has not been performed
• Management reviews are not being carried out.

Major nonconformities can be raised against management system clauses only and can delay ISO 27001 certification, require follow-up audits, and often indicate problems with leadership or governance.  Major nonconformities should not be raised against individual Annex A controls since the controls are not mandatory (although Clause 6.1.3c does require the Annex A controls to be considered for risk treatment).  However, repeated minor observations against related controls may suggest a systemic failure against a clause, indicating that the clause has not been properly implemented and resulting in a major nonconformity being raised.

React to the nonconformity

First, you must react to the issue by:

• Correcting the problem
• Managing any immediate consequences.

For example, if unauthorised system access is discovered, that unauthorised access must be removed immediately.  Typically, detection and reaction to an operational nonconformity such as this would be evidenced through incident management, whereby initial detection through monitoring systems would be routed into incident management.  It is important to evidence the detection, its analysis and its promotion into incident management to provide an audit trail to the source of the nonconformity.

Of course, nonconformities can also stem from other sources, such as internal and external audits.  The audit trail for such nonconformities is easier to establish, but can sometimes command less management attention given that they have not followed the incident management route.  They can therefore sometimes fall by the wayside, remaining open for extended periods while operational issues are addressed.  As such, it is important to conduct frequent reviews of outstanding nonconformities to ensure all are kept ‘alive’ and are addressed in a timely manner, regardless of how they have been identified.

Evaluate the need for corrective action

Not every issue needs a complex solution.  Your organisation should consider:

• How likely the issue is to happen again
• What the impact would be if it happens again.

This helps ensure corrective actions are reasonable and risk-based.  As discussed above, many nonconformities can be routed through incident management.  A well-constructed incident management process will provide for evaluation of the incident and the required corrective actions.  

However, those nonconformities that do not arise through incident management require an equal measure of evaluation, evidence of which needs to be well documented.  This is often contained within the nonconformity register, but there will need to be evidence that evaluation has garnered suitable management attention, such as review of proposed corrective actions.

Evidence could be an email trail of conversations related to the proposed corrective actions or records of incident management discussions (meetings or calls).  Where a decision is made not to implement a corrective action, it is perhaps even more important to document the reasoning for not doing so including management approvals for the decision.  If the decision is made to not address the nonconformity and accept the associated risk, it is also important that a risk is raised in the risk register, which is subject to the appropriate approvals through the risk management process.  A link to the associated risk should be recorded in the nonconformity register.

Identify the root cause

This is one of the most difficult aspects of Clause 10.2.  A true root cause is not something superficial such as ‘Human error’ or ‘Someone forgot’; instead, it must explain why the system allowed the issue to occur.  Examples include:

• No clear ownership
• No reminder or tracking process
• Poor or missing training
• Outdated or unclear procedures.

Auditors pay close attention to root cause analysis.  As such, it’s important to ensure that root cause analyses are fully documented and subject to management review that can be clearly evidenced.  The root cause can be documented as part of the nonconformity register or in separate documentation, but where it is held separately, it should be referenced from the register.

Implement corrective actions

Corrective actions must:

• Address the root cause
• Be practical and proportionate
• Be implemented and tracked.

Examples of corrective actions include updating procedures, assigning responsibility to a role, improving training, or adding automation.

Where a corrective action will result in an operational change, as with all sources of such change, they must be passed through your change management process, where management approval for the change can be evidenced.  Similarly, where a nonconformity results in process changes, the associated process documentation would need to be updated and approved through your document management process.

Review effectiveness

After corrective actions are implemented, you will need to check whether:

• The action actually fixed the problem
• The issue has reoccurred
• The control is now working as intended.

This review can be done through audits, monitoring, or management reviews.  Of course, any nonconformity that has resulted in a change passing through the change management process will include a post-change evaluation.  However, this alone may not be sufficient, as it will only assess whether the change was implemented correctly, not whether the change actually addressed the nonconformity.  It is possible that the initial evaluation of the nonconformity identified the wrong corrective action, so no matter how well the resulting change was implemented, it may not have addressed the nonconformity.

As such, the nonconformity should be closed only after it can be evidenced that the corrective action has successfully addressed the nonconformity.  If a nonconformity is identified in a process that operates on a periodic basis, the nonconformity should be closed only after at least the next successful iteration of the process.  For example, if the nonconformity relates to failure to produce complete user lists for an access review run on a quarterly basis, the nonconformity should remain open until the next quarterly review can be demonstrated to have included all users that need to be reviewed.

Update the ISMS

If corrective actions change how the ISMS operates, related documentation must be updated.  This may include policies, procedures, risk registers, or controls.  Documentation should always reflect what really happens in practice.

As discussed above, any changes to documentation, especially that related to the ISMS should be implemented in accordance with the organisation’s document management processes, with appropriate approval of the modified documentation.   To learn more about the Standard’s requirements for document management and how to meet them, read our blog on ISO 27001 Clause 7.5: Documented Information Explained.

‍

Implementing ISO 27001 in practice begins with identifying nonconformities, which can be found through internal audits, external audits, incidents, management reviews, or daily operations.  Once identified, each nonconformity needs to be formally logged.  As such, you will need to maintain a register that records:

• Description of the issue
• Date identified
• Source of the issue
• Ownership within the organisation
• Severity (minor or major)
• Details of root cause analysis
• Links to incident and change management as appropriate, and a link to the risk register for related risks
• Documentary evidence that the nonconformity has been addressed prior to closure
• Closure date.

Root cause analysis then needs to be performed, considering what failed, why it failed and what allowed it to fail, and corrective actions defined that fix the root cause, reduce risk and have clear owners and deadlines.

It’s important to include a mechanism to monitor and review corrective actions, with the capability to extend target dates where a corrective cannot be completed in accordance with initial plans and expectations.  The mechanism should form part of the nonconformity and corrective action process and define suitable approvals for the extension of target dates.

Once corrective actions have been defined, they must be implemented and their progress tracked until actions are completed and evidence is available.  You will then need to verify the effectiveness of the actions, confirming that the issue is resolved and has not reoccurred.  The nonconformity should only be closed once evidence exists that it has been addressed, the effectiveness of the action has been reviewed, and any relevant documentation updated if needed.

There are a number of common errors organisations make when addressing Clause 10.2 that you should aim to avoid.  These include reaching premature conclusions or solutions without performing a structured and clear root cause analysis, as well as failing to properly document the nature of nonconformities, any actions taken, and evidence of effectiveness of those actions, i.e., not verifying whether a corrective action has actually resolved the issue.  It is also common for organisations to permit long delays between identifying a nonconformity and taking action, thus exposing the organisation to further recurrences.  In addition, you should avoid simply repeating the same corrective actions for recurring issues rather than identifying systemic problems, as this can result in the insufficient use of time and resources by continually addressing the same issue instead of resolving its underlying cause and preventing future recurrence.  Finally, failing to communicate nonconformities and corrective actions to all relevant stakeholders can undermine their effectiveness, while treating Clause 10.2 only as an audit requirement or box-ticking exercise, rather than an opportunity for improvement, will limit your ability to strengthen your ISMS and reduce future risk.

Clause 10.2 is fundamentally about how an organisation learns from problems, weaknesses, and unexpected events, and how it improves over time.  No organisation is perfect, and ISO 27001 does not expect perfection.  What it does expect is honesty, structure, transparency, and a commitment to continual improvement.  When implemented effectively, Clause 10.2 becomes a practical and powerful enabler of ongoing improvement, helping an organisation strengthen its security posture and mature its ISMS year after year.