This part of the standard is concerned with corrective action requirements. You will need to show how you react to nonconformities, take action, correct them and deal with the consequences. You’ll also need to show whether any similar nonconformities exist or could potentially occur and show how you will eliminate the causes of them so they do not occur elsewhere. There is also a requirement to show continual improvement of the ISMS, including demonstrating the suitability and adequacy of it and how effective it is. However, you do this is up to you.
10.1 Nonconformity and corrective action
When a nonconformity occurs, the organization must react to this nonconformity by taking action to control and correct it; and deal with the subsequent consequences. The organization must evaluate the need for action to eliminate the causes of nonconformity, in order that it does not recur or occur elsewhere, by reviewing the nonconformity, determining the causes of the nonconformity, and determining if similar nonconformities exist, or could potentially occur. The organization must implement any action needed. It must review the effectiveness of any corrective action taken and make changes to the information security management system, if necessary. The Corrective actions taken should be appropriate to the effects of the nonconformities encountered. The organization must keep a record of the nature of the nonconformities and any subsequent actions taken, and the results of any corrective action taken.
Outputs from management reviews, internal audits, and compliance and performance evaluation should all be used to form the basis for nonconformities and corrective actions. Once identified, a nonconformity or corrective action should trigger, if considered relevant, proper and systematic responses to mitigate its consequences and eliminate root causes, by updating processes and procedures, to avoid recurrence. The effectiveness of actions taken must be evaluated and documented, along with the originally reported information about the nonconformity / corrective action and the results achieved. ISO 27001 requires an organization to continually improve its ISMS. These improvements come from a number of activities. Corrective action is one mechanism to drive improvements and address weaknesses within the system. Corrective action is required by ISO 27001 when a non-conformance or deficiency is identified. The need for corrective action can arise from a number of ISMS activities. These include:
- Internal audits;
- Management reviews;
- External audits;
- Security incidents;
- Security reviews and testing.
- Corrective Action is required to address any deficiencies as per the agreed procedure
- Your agency specifies its timelines for response
- The only exception is issues raised by the certification bodies
- Operate on very specific time frames for correction of defects
The organization’s response to a need for corrective action is documented in some form of corrective action procedure. This procedure includes the requirement for root cause analysis to ensure that the non-conformance does not re-occur. The timeframe for response and implementation of corrective action is the choice of the organization, except for non-conformances raised by certification bodies. There are defined timeframes for the implementation of corrective action for any non-conformances raised during certification or surveillance audits.
One of the main drivers of improvement is to learn from security incidents, issues identified in audits, performance issues identified from monitoring, complaints from interested parties, and ideas generated at management reviews. For each learning opportunity identified you must maintain a record of:
- what occurred;
- if the event had undesirable consequences, what action was taken to contain and mitigate those;
- the root cause of the event (if determined);
- the action is taken to eliminate the root cause (if needed); and
- an assessment of the effectiveness of any action taken.
Root cause analysis
To identify effective corrective action, it is strongly advisable to complete a root cause analysis of the issue that occurred. If you don’t get to the bottom of why or how it happened, then it is likely that whatever fix you implement will not be fully effective. A simple approach such as “5 Whys” is a good root cause analysis tool:
start with the issue, then ask “Why” enough times to reach the root cause. Usually, 5 times of asking are enough, but for more complex problems you may need to dig deeper.
The organization was infected by the bogus virus
Someone clicked on a link in an email and it downloaded the virus and infected their PC
They had not received any training in clicking on links in emails they are not expecting to receive
The training manager is on maternity leave and the organization has not implemented cover for them
The maternity leave process is not covered in the Change Management Procedure and so a risk assessment was not completed to identify any information security risks.
You may not have sufficient resources to undertake root cause analysis for every event. To prioritize your efforts, you should consider first completing a simple risk assessment of an event and then undertake root cause analysis only for those that are medium or high risk.
10.2 Continual improvement
The organization must continually improve the suitability, adequacy, and effectiveness of the information security management system.
Continual improvement is a key aspect of the ISMS in the effort to achieve and maintain the suitability, adequacy, and effectiveness of the information security as it relates to the organizations’ objectives. Organizations with operational ISMS’ must continually strive to improve their management system. This is fundamental to all management systems and an ISMS is no exception.
Improvements can come from a number of sources. These include:
• Internal audits;
• The output from Management reviews;
• External audits;
• Security incidents;
• Security reviews and testing;
• Suggestions, including those from interested parties.
Suggested improvements should be considered but do not need to be implemented. The organization selects those improvements it feels add value to the ISMS. Suggestions from internal and external auditors also do not need to be implemented but should be considered. Timeframes for implementing agreed improvements are set by the organization.
If you need assistance or have any doubt and need to ask any questions contact me at firstname.lastname@example.org. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.