Closing an Incident Is Not the Same as Learning from It (IS.I.OR.220)

In my previous article, Recovering from Information Security Incidents Under EASA Part-IS (IS.I.OR.220), we followed an incident to the point where its cause was eradicated, the affected systems were restored, and that safe and secure state verified before anything returned to service. Whilst recovery closes the operational response, it does not close the matter entirely.

Once systems are safe and secure again, another important phase must begin. Your organisation has to ask what the incident revealed, and what should change because of it. Under IS.I.OR.220, this is where lessons learned from an incident belong, a step which aims to improve the Information Security Management System (ISMS). In this article, I share what this step involves, and why it matters beyond closing an incident report.

Subscribe to the Aviation Cybersecurity Brief for practical insights + my Free Part-IS Starter Checklist (covering what most organisations miss early on), or reach out if you'd like to take a clear and proven approach to Part-IS.

Flight Operations and a Hidden Automation

Consider an example scenario involving an air operator’s flight operations department. Before every departure, dispatch prepares the briefing package the flight crew rely on, bringing together the operational flight plan, fuel figures, and mass and balance information. The accuracy of that information is essential, as it feeds into the performance calculations made before take-off. The data itself is safety-critical.

To save time on a repetitive task, a member of the dispatch team builds a small automation using a workflow tool available to them. What it does is simple: it picks up figures from one system, adjusts them, and places them into the briefing package on its own, without human interaction. It works, it saves time, and it becomes part of how the department operates. Nobody outside the team knows it exists, because it was never assessed, approved, or recorded as a change to a safety-critical process.

Some time later, this automation workflow is altered by someone inside the organisation who has access to it. The change is small, but intentional: the figures it places into the briefing package no longer match the figures it collected. The package is produced on time, and it looks exactly as it always does. Nothing appears broken.

The discrepancy is found by a pilot. During pre-flight checks, the crew cross-check the briefing package against the source data, and notice that the figures do not match. They report it to dispatch and put their departure on hold. When the report reaches the department, the person who built the automation recognises that it handles exactly the data in question, and says so.

That admission was important, because it turned an unexpected data discrepancy into a traceable information security incident. Knowing this, the automation is disabled to identify the intentionally altered logic, and the briefing information verified from source before operations continue. As a result of the flight crew’s actions, no aircraft departs with incorrect figures. The incident is contained and eventually recovered from, but what follows now, is learning from it.

More Than Closing an Incident Report

Lessons learned is, unfortunately, treated as a formality (such as a minuted meeting that is held because the procedure asks for one, eventually being filed, and forgotten). Under Part-IS, it is meant to give your organisation true value: to capture what the incident exposed and feed it back into the ISMS, so you are better prepared than you were before.

This phase is meant to be practical. In the flight operations scenario, the altered figures were caught because a crew cross-checked them and reported what they found. The same alteration, left undetected across further flights, could have sent aircraft into the air with performance calculations built on information that was never correct, resulting in potentially serious safety consequences. Learning from the smaller events helps keep the larger ones from happening, or at least, improves the way they are dealt with to minimise the impact on safety.

Reconstructing What Actually Happened

The review of the lessons learned needs to involve the right people: those who detected, contained, and recovered from the incident, the owners of the affected systems, and those who understand its safety consequences. For a safety-critical flight operations process, that means information security, IT, flight operations, and safety management reviewing the incident together.

Before discussing what should change, the group reconstructs the incident from evidence. This includes logs, records, root causes, and the decisions taken during the response and recovery. With the timeline clear, the review looks to assess how well the response performed: whether detection was quick enough, whether containment and recovery held, and whether it stayed aligned with procedures and reporting obligations. It’s all about gaining clarity through retrospection, helping understand what was good, and what went wrong.

Turning A Review into Change

A truly honest review highlights both the gaps and the things that worked. In the flight operations scenario, the crew cross-check and the quick reporting performed deserve reinforcing. Then come the harder questions: How did an automation come to sit inside a safety-critical process without being assessed, approved, or recorded? Who was able to alter it, and why was that possible? Did monitoring flag the altered figures at all, or did a pilot notice them first?

The answers point in a consistent direction. Automations that touch safety-critical information need to be known, owned, and controlled like any other part of the operation. This means bringing them into change management so they are assessed and approved before they go live, rather than discovered afterwards. Additionally, extending monitoring to cover them once they are running, and making sure that anyone who might build one understands that a small time-saving tool placed inside a safety-critical process is a change to that process. Training carries the same weight here as any technical control/barrier, because this automation was not built with bad intent. It was built by someone solving a problem, unaware of what it touched, and how exposed to manipulation it was.

Each gap points to an improvement, but an improvement only counts once it is actually implemented. A lesson that stays on paper changes nothing, so corrective actions must be defined in detailed, actionable steps. They must be owned by a named person, given a timeline, and defined by what successful implementation looks like. Finally, the outcomes must also land in the ISMS as a revised risk assessment, procedure, detection approach, or training programme.

This is where lessons learned connects to, and feeds continuous improvement directly. Handled this way, your organisation does not only recover from altered, safety-critical information, but it tightens, or even closes, the pathway that allowed it, while improving how it would detect, respond to, and recover from the next one.

Key Principles

• Learning is part of incident management: IS.I.OR.220 treats lessons learned as the closing phase of incident handling. An incident is not fully managed until it has been learned from.

  
  

• Reconstruct from evidence: A reliable review rests on the actual timeline of detection, response, and recovery, drawn from records rather than recollection. Document everything.

  
  

• Involve the right people together: Information security, flight operations, IT and safety functions review together as one. For a safety-critical system, the technical cause of an incident matters as much as the safety consequence, because the former impacts the latter.

  
  

• Capture what worked, not only what failed: Reinforcing a detection or a check that worked is as valuable as fixing a weakness. Both make the next response stronger.

  
  

• A lesson is only learned once it changes something: Corrective actions need an owner, a timeline, and a place in the ISMS. Anything less is a record on paper, nothing more.

Approaching Lessons Learned in Practice

The organisations that get the most from the lessons learned phase decide how it will run before they need it, almost as a reflex. They agree who triggers it, how quickly it happens (while details are fresh), and how actions are tracked to completion.

It also helps to treat the safety consequence as the anchor. In the flight operations scenario, the question was never only how data was altered, but what it meant for the calculations made before take-off, and the crew relying on them. This is where the point of Part-IS becomes clear: information security exists to protect aviation safety, and lessons learned is where such protection compounds over time to ensure adaptability and continuous improvement.

Quick Summary

Lessons learned under IS.I.OR.220 ensures that a handled incident becomes a better ISMS. It reconstructs what happened from evidence, evaluates how the response performed, and closes the gaps by turning them into specific, owned improvements that feed continuous improvement.

In the flight operations scenario, this approach is what makes the difference between filing a report on one altered briefing package, and making sure the same weaknesses cannot return in situations where the outcomes may be far worse for safety.

Every incident teaches something. The only question worth asking afterwards is whether the organisation was listening, or simply taking meeting minutes.

Navigating Part-IS? Let's Make It Work.

Achieving Part-IS compliance goes far beyond ticking boxes. It's about building something that actually works - under audit, under pressure, and alongside your existing SMS.

I've led aviation organisations through their Part-IS journey, achieving successful compliance with ISMS implementations that are practical, audit-ready, and aligned with safety.

If you're currently navigating Part-IS, or unsure whether your approach will stand up to oversight, it's worth having a conversation.

Reach out if you'd like to discuss how to approach Part-IS in a clear, structured way.