Introduction
I am going to show you what ISO 27001 Annex A 5.27 Learning From Information Security Incidents is, what’s new, give you ISO 27001 templates, an ISO 27001 toolkit, show you examples, do a walkthrough and show you how to implement it.
I am Stuart Barker the ISO 27001 Ninja and using over 30 years experience on hundreds of ISO 27001 audits and ISO 27001 certifications I show you exactly what changed in the ISO 27001 update and exactly what you need to do for ISO 27001 certification.
Table of contents
- Introduction
- ISO 27001 Learning From Information Security Incidents
- Key Takeaways
- How to implement ISO 27001 Learning From Information Security Incidents
- Implementation Checklist
- Audit Checklist
- Root Cause Analysis Explained
- Watch the tutorial
- ISO 27001 Templates
- How to comply
- How to pass the audit
- What the auditor will check
- Top 3 Mistakes People Make
- Frequently Asked Questions about ISO 27001 Learning From Information Security Incidents
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 controls and attribute values
ISO 27001 Learning From Information Security Incidents
ISO 27001 Annex A is list of 93 controls that have been known to mitigate risks. ISO 27001 Annex A 5.27 specifically is an ISO 27001 control that requires an organisation to learn from information security events to improve.
ISO 27001 is the international standard for an information security management system and a key part of the standard is the management of information security incident. “Learning from information security incidents” is a specific control that mandates a proactive approach to improving your security posture based on past events.
Definition
ISO 27001 defines ISO 27001 Learning From Information Security Incidents as:
Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.
ISO 27001:2022 Annex A 5.27 Learning from information security incidents
Purpose
ISO 27001 Annex A 5.27 is a preventive control and it’s purpose is to ensures the reduction in the likelihood or consequences of future incidents. By analysing and understanding what went wrong and why, organisations can prevent similar incidents from happening in the future or reduce their impact. This is continual improvement and a core principle of the ISO 27001 standard.
Key Takeaways
- The control is called ISO 27001:2022 Annex A 5.27 Learning From Information Security Incidents
- It is part of the overall incident management process
- The implementation guidance is given in ISO 27002:2022 Control A 5.27 Learning From Information Security Incidents
- It relies on root cause analysis
How to implement ISO 27001 Learning From Information Security Incidents
An information security incident is an event that could potentially have a negative impact on the confidentiality, integrity, or availability of information. The consequences of an incident can vary depending on the nature of the incident, the systems and data affected, and the organisations response.
As part of your incident management you are going to implement a step that looks at learning from incidents. You will consider this documented process and how you will analyse incidents, identify the root cause and then make decisions on corrective actions as required.
1. Conduct a root cause analysis
Once an incident has occurred and been corrected you would then do a root cause analysis (RCA) to investigate why it happened and the underlying cause. The purpose of determining the cause is to ensure that it does not happen again.
2. Decision on next steps
Once the root cause has been identified, and there may be more than one, a decision will be made on what actions to take. The decision will be based on risk management and is a risk based decision that will be approved and overseen by the management review team. If the decision is to accept the risk and take no action, then this would be recorded in the risk register and if the decision is to take action to mitigate the risk, then this would be added to the corrective actions log and managed as a continuous improvement.
3. Keep records of lessons learnt
The root cause and the decisions made on next steps should be formally documented and retained. This is a valuable resource for future enhancements as well as for audit purposes.
4. Monitor effectiveness
Lessons learned and the improvements that have been made should be monitored to ensure that they are effective. This is usually done via the process of independent internal audit.
Implementation Checklist
ISO 27001 Learning From Information Security Incidents Implementation Checklist
1. Establish a clear incident review process
Challenge
Lack of defined steps for post-incident analysis, leading to inconsistent or missed learning opportunities.
Solution
Develop and document a formal procedure outlining roles, responsibilities, and specific stages for reviewing all information security incidents, from minor events to major breaches. This should include data collection, analysis, and reporting.
2. Implement a robust incident logging and reporting system
Challenge
Inadequate tools or a manual system making it difficult to capture comprehensive incident details and trends.
Solution
Utilise an incident management system (e.g., a ticketing system, dedicated GRC software) to centrally log all incidents, including timestamps, affected assets, impact, remediation steps, and root causes. Ensure clear categorisation and tagging for easier analysis.
3. Conduct thorough root cause analysis (RCA) for all significant incidents
Challenge
Tendency to focus on immediate fixes rather than identifying underlying vulnerabilities or process failures.
Solution
Train staff on RCA methodologies (e.g., 5 Whys, Fishbone diagrams) and mandate their use for all incidents beyond simple anomalies. Encourage a culture of inquiry rather than blame.
4. Document lessons learned from each incident
Challenge
Information gleaned from incidents is not systematically recorded or made accessible for future reference.
Solution
For every incident review, create a “lessons learned” document that summarises the incident, its root cause, the effectiveness of the response, and recommended improvements. Store these centrally in a searchable repository.
5. Communicate lessons learned to relevant stakeholders
Challenge
Siloed knowledge, where valuable insights from incidents are not shared across the organisation, leading to repeated mistakes.
Solution
Establish regular communication channels (e.g., security newsletters, team meetings, dedicated training sessions) to disseminate lessons learned to all relevant employees, including IT, management, and general staff, tailoring the message to their roles.
6. Update risk assessments and treatment plans based on incident findings
Challenge
Incident data is not integrated into the ongoing risk management process, leading to outdated or ineffective controls.
Solution
Periodically review incident trends and specific incidents to identify new or evolving risks. Adjust existing risk assessments, update risk treatment plans, and introduce new controls as necessary to mitigate identified vulnerabilities.
7. Review and improve information security policies and procedures
Challenge
Policies and procedures remain static despite evidence from incidents that they are insufficient or unclear.
Solution
Establish a formal process for reviewing and updating policies and procedures in light of incident findings. This could involve an annual review cycle, or immediate updates triggered by critical incidents.
8. Integrate incident learning into security awareness training
Challenge
Security awareness training is generic and doesn’t reflect the organisation’s specific threat landscape or past incidents.
Solution
Use anonymised examples of real incidents (e.g., phishing attempts, social engineering) in security awareness training to make it more relevant and impactful. Highlight common attack vectors and the importance of employee vigilance.
9. Monitor the effectiveness of implemented improvements
Challenge
Changes are made based on incident reviews, but their actual impact on security posture is not verified.
Solution
Implement metrics and key performance indicators (KPIs) to track the effectiveness of corrective actions. For example, monitor a reduction in specific incident types, faster response times, or improved detection rates.
10. Periodically review the incident management process itself
Challenge
The incident management process becomes stagnant and doesn’t adapt to new threats or organisational changes.
Solution
Conduct regular (e.g., annual) reviews of the entire incident management process, including its effectiveness in identifying, responding to, and learning from incidents. Solicit feedback from incident responders and other stakeholders to identify areas for improvement.
Audit Checklist
ISO 27001 Learning From Information Security Incidents Audit Checklist
1. Review the existence and effectiveness of a “lessons learned” process
Confirm that the organisation has a formal, documented process for reviewing information security incidents to identify their causes, the effectiveness of the response, and areas for improvement.
Challenges:
The process might exist on paper but not be consistently applied, or staff may not fully understand its importance. There might be a culture of blame rather than learning.
Audit Techniques:
- Document Review: Examine the “lessons learned” policy, procedure, or framework.
- Interviewing: Speak to incident response team members and management about their understanding and application of the process.
- Sample Testing: Select a sample of past incidents and trace whether a lessons learned review was conducted for each.
2. Assess the documentation of post-incident reviews
Verify that formal records of post-incident reviews (PIRs) or post-mortem analyses are maintained for significant incidents, detailing findings, root causes, and recommendations.
Challenges:
Reviews might be informal or incomplete, with insufficient detail to drive meaningful improvements. Key information might be missing.
Audit Techniques:
- Document Review: Examine PIR reports or incident review meeting minutes. Look for evidence of root cause analysis and identified improvement opportunities.
- Observation: If possible, observe a post-incident review meeting in progress.
3. Verify the identification of root causes
Confirm that the organisation actively seeks to identify the underlying reasons for incidents, rather than just addressing the symptoms.
Challenges:
Lack of expertise in root cause analysis, or a tendency to stop at the most obvious cause without digging deeper.
Audit Techniques:
- Interviewing: Question incident responders on their root cause analysis techniques (e.g., “5 Whys,” Fishbone diagrams).
- Case Study Review: Select specific incidents and review the associated documentation to assess the depth and rigour of the root cause analysis performed.
4. Examine the process for tracking and implementing corrective actions
Ensure that identified improvement opportunities and corrective actions from PIRs are formally documented, assigned ownership, have target dates, and are tracked through to completion.
Challenges:
Actions might be identified but not implemented, or there’s no clear ownership, leading to recurring issues.
Audit Techniques:
- Document Review: Review action logs, project plans, or incident management system entries related to corrective actions.
- Follow-up Verification: Select a sample of completed actions and verify their implementation through evidence (e.g., system configurations, updated policies, training records).
5. Assess the integration of lessons learned into the ISMS
Determine if the insights gained from incidents lead to updates in risk assessments, policies, procedures, security controls, or training programmes.
Challenges:
Lessons learned might remain isolated within the incident response team and not be integrated into broader security management.
Audit Techniques:
- Document Review: Trace changes in risk assessments, policies (e.g., access control, patching), or training materials back to specific incident findings.
- Interviewing: Ask the ISMS Manager or risk owner how incident lessons inform their activities.
6. Evaluate communication and awareness of lessons learned
Confirm that relevant lessons learned are effectively communicated to appropriate stakeholders (e.g., incident response team, IT staff, all employees) to prevent recurrence.
Challenges:
Information silos, poor internal communication channels, or a lack of emphasis on sharing knowledge.
Audit Techniques:
- Interviewing: Ask staff if they are aware of past incident learnings and how this knowledge is disseminated.
- Document Review: Look for evidence of awareness campaigns, internal newsletters, or training sessions that incorporate incident lessons.
7. Review the frequency and quality of post-incident review meetings
Ascertain that reviews are conducted regularly (for all significant incidents) and that the meetings are productive, with appropriate attendees.
Challenges:
Reviews might be sporadic, rushed, or lack the right attendees to make effective decisions.
Audit Techniques:
- Document Review: Examine meeting schedules and attendance records for PIRs.
- Interviewing: Discuss with participants the effectiveness and regularity of these meetings.
8. Assess the resourcing and capabilities for post-incident analysis
Confirm that the organisation has sufficient skilled personnel and appropriate tools to conduct thorough incident analysis and derive meaningful lessons.
Challenges:
Insufficient budget, lack of training for staff, or outdated tools preventing in-depth analysis.
Audit Techniques:
- Interviewing: Discuss resource allocation and training programmes for incident responders and analysts.
- Observation: If possible, observe the use of incident analysis tools.
- Document Review: Review training records and budget allocations related to incident response capabilities.
9. Verify the measurement and reporting of incident trends
Ensure that the organisation collects and analyses data on incident types, frequencies, and impacts to identify trends and inform strategic security improvements.
Challenges:
Data might be collected but not analysed, or the analysis isn’t translated into actionable insights.
Audit Techniques:
- Document Review: Examine management review minutes, security dashboards, or incident reports that highlight trends.
- Interviewing: Ask management how incident trend data influences their decision-making.
10. Confirm continuous improvement of the incident management process itself
Determine if the process for managing incidents is itself subject to review and improvement based on lessons learned from both successful and challenging incident responses.
Challenges:
Complacency, or a focus solely on the technical aspects of incidents rather than the efficiency of the response process.
Audit Techniques:
- Document Review: Look for evidence of reviews or updates to the incident response policy and procedures based on past experiences.
- Interviewing: Ask the incident manager or ISMS Manager how they improve the incident management process over time.
Root Cause Analysis Explained
What is root cause analysis?
It is technique that looks to see what the actual cause of an incident was. It is not about identifying the symptoms but what actually caused them and the incident to occur. Consider, I have put on weight. Root cause does not look at the fact your clothes do not fit any more but on why. Through analysis you would likely discover the root cause is you eat too much and don’t exercise enough.
How to do root cause analysis
A good way to is to use the technique of the Five Why’s. By asking the question why five times in a row you can often get to the root of the problem.
For example, if you were looking at the root cause of why you have put on weight.
The incident would be – I have put on weight.
You can then ask the 5 why’s:
- Why? Because I am bigger than before
- Why? Because I eat too much
- Why? Because I am unhappy
- Why? Because I work too hard
- Why? Because I need money.
Root cause of all evil = money.
It can actually be a very effective technique.
What to do with the result
Once we know what the root cause of an information security incident is we can now start to make decision as to what to do. It may be that
- This requires no further action
- This requires corrective action
- This requires continual improvement
- This is a risk and needs to be managed via risk management
Root Cause Conclusion
This guide provides a framework for identifying the root cause, lessons learnt and improvements of an information security incident. The guide should be used in conjunction with your information security incident management plan.
The standard that relates to information security management for further reading if required is ISO/IEC 27035
Watch the tutorial
ISO 27001 Templates
You can save months of effort with these templates that take 25 years of experience and distill it in a pack of prewritten best practice awesomeness. We have included guides on how to respond to incidents and resources to help your implementation.
How to comply
To comply with ISO 27001 Annex A 5.27 Learning From Information Security you are going to implement the ‘how’ to the ‘what’ the control is expecting. You are going to:
- Manage information security incidents to resolution
- Perform root cause analysis to identify what caused it
- Make a decision on what to do next
- Record information security lessons learnt.
How to pass the audit
To pass an audit of ISO 27001 Annex A 5.27 Learning From Information Security Incidents you are going to make sure that you have followed the steps above in how to comply. In addition that you:
- Have a documented process for root cause analysis and lessons learnt.
- Implement the lessons learnt process
- Monitor the effectiveness of the lessons learnt process
- Review and update the lessons learnt process as needed.
What the auditor will check
The audit is going to check a number of areas for compliance with ISO 27001 Annex A 5.27. Lets go through them:
1. That you have documented your root cause and lessons learnt process
The audit will check the documentation, that you have reviewed it and signed and it off and that it represents what you actually do not what you think they want to hear.
2. That you can demonstrate the process working
They are going to ask you for evidence to the lessons learnt process and take one example. For this example you are going to show them and walk them through the process and prove that you followed it and that the process worked.
3. That you can learn your lesson
Documenting your lessons learnt and following this through to continual improvements or incident and corrective actions will be checked. They want to see that not only did you respond but that you learnt from it and did something to improve that reduced or eliminated the possibility of it happening again.
Top 3 Mistakes People Make
The top 3 Mistakes People Make For ISO 27001 Annex A 5.27 are
1. Not having a documented information security incident management plan
This is the most common mistake made by organisations. A documented information security incident management plan is essential for effective incident response. It should include the following a process for root cause analysis and lessons learnt.
2. Not implementing the information security incident management plan
Even if you have a documented information security incident management plan, it is not enough to simply have the plan. The plan must be implemented in order to be effective. This means assigning responsibility for implementing the plan, providing training on the plan, and testing the plan.
3. Not monitoring the effectiveness of the information security incident management lessons learnt
Once the information security incident management lessons learnt is implemented, it is important to monitor its effectiveness. This means reviewing reports of information lessons learnt, root cause analysis, risk registers, corrective action logs and actual corrective actions implemented as needed.
By avoiding these mistakes, you can ensure that you have an effective information security incident management plan in place.
Frequently Asked Questions about ISO 27001 Learning From Information Security Incidents
It is important because it provides guidance on how we learn and continually improve as a result of incidents. Information security incidents can have a significant impact on an organisation, so it is important to have a plan in place for how to reduce them in future.
The main benefits of having an effective information security incident lessons learnt process are:
It can help to reduce the impact of information security incidents.
It can help to protect the organisations reputation.
It can help to comply with legal and regulatory requirements.
It can help to improve the organisations overall information security posture.
The implementation guidance for Learning form Information Security Incidents is in ISO 27002:2022 Learning from Information Security Incidents. It can help you to develop and implement an effective information security incident lessons learnt plan.
ISO 27001 Annex A 5.27 is a control that requires organisations to learn from, and improve as a result of, information security incidents. It is one of the 93 information security controls provide in the ISO 27001 standard that are known to mitigate information security risks and is part of the overall incident management process.
Perform root cause analysis
Make a decision based on the root cause
Document the process and results
The most common types of information security incidents are
1. Accidental Incidents
2. Malicious Incidents
3. Natural Disaster / Environmental Incidents
Typically they are:
Incident Manager: Managing and coordinating the incident
Incident Response Team: the people responding to the incident
The Legal Team: providing legal advice
The Information Security Team: maintaining the confidentiality, integrity and availability of data.
Communications Team: keeping interested parties appropriately informed
Typical questions that are asked are: What was the incident? What happened? What was the impact? What was the root cause? How effective was our response? What went well? What would we do differently? What improvements are needed so it does not happen again?
A ‘lessons learned report’ is created that includes the key findings, root cause and actions. It is stored in the information security management system as a record of continuous improvement for audit purposes and future reference.
Yes, it is required for ISO 27001.
ISO 27001 templates that support Annex A 5.27 Learning from information security incidents are located in the ISO 27001 Toolkit.
ISO 27001 Annex A 5.27 is not hard.
ISO 27001 Annex A 5.27 will take approximately 1 week to complete if you are starting from nothing and doing it yourself.
Related ISO 27001 Controls
ISO 27001 Annex A 5.24 Information security incident management planning and preparation
ISO 27001 Annex A 5.25 Assessment and decision on information security events
ISO 27001 Annex A 5.26 Response to information security incidents
ISO 27001 Annex A 5.28 Collection of evidence
ISO 27001 Information Security During Disruption: Annex A 5.29
ISO 27001 Nonconformity and Corrective Action: Clause 10.2
Further Reading
ISO 27001 Incident and Corrective Action Log Template
Business Continuity Incident Action Log Template
ISO 27001 controls and attribute values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
| Preventive | Confidentiality | Identify | Information Security Event Management | Defence |
| Integrity | Protect | |||
| Availability |
