Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.27 — Learning from Information Security Incidents

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.27 ISO 27001ISO 27002BSI DER.2.1

The same phishing variant succeeds three times in six months. Each time the incident team responds, resolves and closes the ticket. Nobody analyses the pattern, nobody updates the training, nobody adjusts the email filter rules. A.5.27 closes this feedback loop by requiring organisations to systematically learn from incidents and feed improvements back into the ISMS.

Responding to incidents (A.5.26) handles the immediate damage. Learning from them ensures that the same type of incident becomes progressively less likely or less impactful over time. This is where the ISMS improvement cycle meets operational reality.

What does the standard require?

  • Analyse incidents systematically. Every confirmed incident undergoes a structured review to identify root causes, contributing factors and control gaps.
  • Document lessons learned. Findings are recorded in a form that enables trend analysis and feeds into risk assessment updates.
  • Track incident types and costs. The organisation maintains statistics on incident frequency, categories and financial or operational impact to identify patterns.
  • Update controls and procedures. Lessons learned translate into concrete corrective actions — updated playbooks, adjusted configurations, additional training, new or modified controls.
  • Share knowledge appropriately. Relevant lessons are communicated to those who can benefit, including awareness training for the broader workforce where applicable.

In practice

Conduct blameless post-incident reviews. The goal is to understand what happened and why — the focus lies on systemic causes (missing controls, unclear procedures, insufficient tooling) rather than individual mistakes. A blame culture discourages reporting and hides the very information the organisation needs to improve.

Maintain an incident database with categorisation. Tag incidents by type (phishing, malware, misconfiguration, insider, physical), affected assets and root cause. Over time this database reveals which categories are growing and where investment has the greatest effect.

Feed findings into the risk assessment. If an incident reveals a threat or vulnerability that was not previously considered, update the risk register. If it demonstrates that a risk was underestimated, adjust the likelihood or impact rating. This keeps the risk assessment grounded in operational experience.

Close the loop with measurable actions. Every corrective action from a post-incident review gets an owner, a deadline and a verification step. Track completion in the same system you use for other ISMS improvement actions.

Typical audit evidence

Auditors typically expect the following evidence for A.5.27:

  • Post-incident review reports — structured analyses of root causes and lessons learned
  • Incident statistics — aggregated data on incident types, frequency and trends over time
  • Corrective action tracker — evidence that lessons learned translated into concrete actions with owners and deadlines
  • Updated procedures or controls — before/after comparison showing changes triggered by incident reviews
  • Awareness materials — training content or communications derived from lessons learned

KPI

% of IS incidents with completed post-incident review and documented lessons learned

This KPI measures whether the organisation consistently closes the learning loop. Target: 100% for incidents classified as high or critical severity, at least 80% for medium severity. Track also the average time from incident closure to completed review.

Supplementary KPIs:

  • Number of corrective actions implemented as a result of post-incident reviews
  • Reduction in recurrence rate for previously observed incident types
  • Average time from incident closure to completed post-incident review

BSI IT-Grundschutz

A.5.27 maps to the BSI requirements for incident evaluation and improvement:

  • DER.2.1.A17 (Handling of security incidents) — includes the requirement for post-incident analysis.
  • DER.2.1.A18 (Post-processing of security incidents) — explicitly requires documentation of lessons learned and derivation of improvement measures.
  • DER.2.1.A22 (Advanced post-processing) — recommends trend analysis across multiple incidents and integration with the overall ISMS improvement process.

A.5.27 is the improvement step in the incident management chain:

Sources

Frequently asked questions

When should a post-incident review take place?

As soon as the incident has been resolved and immediate pressure has subsided -- typically within two to four weeks. Waiting longer risks losing details and context. The review should involve all key responders while their memory is fresh.

What belongs in a lessons-learned report?

Root cause, timeline of events, what worked well, what failed, control gaps identified, and specific corrective actions with owners and deadlines. The report should be concise enough that management actually reads it.

Should near-misses also be analysed?

Yes. Near-misses often reveal the same control weaknesses as actual incidents, with the advantage that no real damage occurred. Analysing them provides improvement opportunities at lower cost. Include near-misses in your incident statistics and review process.