Learning from information security incidents
What the organization learns from its information security incidents is to be fed back to strengthen and improve its security controls.
What the requirement asks
What the organization learns from its information security incidents is to be fed back to strengthen and improve its security controls. Purpose: make future incidents less likely or less damaging. Guidance: set up procedures to measure and track the kinds, numbers and costs of incidents. Use what incident evaluation reveals to improve the incident management plan with its scenarios and procedures (5.24); to spot incidents that recur or are serious, and their causes, so the risk assessment is updated and additional controls are chosen and implemented to cut the likelihood or impact of similar events, supported by gathering and tracking data on incident types, volumes and costs; and to enrich user awareness and training (6.3) using real cases that show the possible harm, the right reaction and ways to stop a recurrence. ISO/IEC 27035 carries more on this. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Learning is the point of the incident record. The guidance asks for the cause, the lessons, the change to controls and the evidence that the change was made.
Status of the guidance. The guidance lens for 5.27 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A procedure for quantifying and monitoring incident types, volumes and costs, with the resulting metrics or dashboards and one live sample together.
Evidence an assessor asks for
- Lessons learnedA procedure for quantifying and monitoring incident types, volumes and costs, with the resulting metrics or dashboards
- Lessons learnedPost-incident review reports identifying causes and recommended improvements
- Lessons learnedUpdates to the risk assessment and risk treatment plan traced to specific incidents
- Lessons learnedRecords of new or strengthened controls implemented after recurring or serious incidents
- Lessons learnedRevisions to the incident management plan and scenarios informed by incidents
- Lessons learnedAwareness and training material that uses real incident examples
The question an assessor will ask
An assessor will ask for A procedure for quantifying and monitoring incident types, volumes and costs, with the resulting metrics or dashboards, then trace it to the system it protects. For A.5.27 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- Incident costs are never captured, so trends and business impact are unknown
- Lessons are written up but the resulting actions are not tracked to completion
- The risk assessment is not revisited after significant incidents
- Recurring incident types are handled individually without any cause analysis
Before the next audit
Before the next audit, check one live sample for this gap: incident costs are never captured, so trends and business impact are unknown.