Recovering from Information Security Incidents Under EASA Part-IS (IS.I.OR.220)

In a previous article, Responding to Information Security Incidents Under EASA Part-IS (IS.I.OR.220), we looked at what response is designed to achieve: engaging the right people, prioritising by aviation safety, and containing a confirmed incident before it spreads further.

Recovery sits later in the same timeline. The incident has happened, been confirmed, and been contained. The spread is stopped, but the affected systems are not yet safe to return to service. Recovery is the work of getting them there: eradicating the cause, restoring systems to a state that is both safe and secure, and verifying that state before anything returns to service.

If you're implementing Part-IS and unsure you're on the right track - that's a common challenge. I've helped aviation organisations build compliant ISMSs that are audit-ready, aligned with safety, and work in practice.

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

An Operator and a Navigation Database Update

Consider an air operator holding an AOC. Before each cycle, its aircraft receive a navigation database update — the dataset that feeds the flight management system with waypoints, procedures, and routing information. Prepared by a third-party navigation supplier, each update passes the integrity checks built into the distribution process.

One update behaves differently. During pre-flight preparation, a discrepancy in the database is noticed, and the aircraft does not depart because of it. Investigation later establishes that the update had been deliberately manipulated at the supplier, and that it had still passed every integrity check before being loaded. The aircraft is removed from service while the situation is understood. What remains is more demanding than containment: removing the manipulated data completely, understanding how it passed undetected, and returning the aircraft to a safe and secure state.

What Recovery Is Actually About

Once an incident is contained, recovery has a twofold purpose: to eradicate the cause, and to restore the affected systems to their nominal, safe, and secure states.

Those two words carry the weight of the phase. A safe state carries no unacceptable safety risk and stays within the acceptable level of safety defined by the operator. A secure state is free of active compromise and residual malicious artefacts. A manipulated database may still let the aircraft appear to function normally, and that is exactly where the hazard lies.

Restoring system availability alone is not recovery.

Recovery is also bounded by time. Recovery time objectives set how quickly each asset should be restored, based on its criticality. Where restoration within that window is not achievable, the asset is held in a fail-safe or fail-secure state instead. In this case the grounded aircraft, which cannot carry a corrupted database into the air.

Find the Cause Before Removing the File

Recovery does not begin with a fix, but with understanding.

Eradicating the manipulated file is only reliable once the organisation knows how it arrived and why the existing checks did not catch it. Remove it without those answers, and the same data can return on the next cycle.

To reach it, a structured root cause method is used — the 5 Whys, drawn from safety management practice. Each question moves from the visible failure toward the underlying one. The file was loaded: why? It passed the integrity checks: why did those checks not detect the manipulation? The process continues until it reaches the real cause rather than its symptom, with every answer supported by evidence.

Only then does eradication follow: removing the manipulated dataset from every affected system and confirming no trace remains. Because the failure originated upstream, at the supplier, eradication also has to reach the process that let it through. A purely technical clean-up on the aircraft would still leave the pathway open.

Verify, Then Return to Service

Removing the file is not the end. Eradication must be verified before restoration begins, and restoration before the aircraft flies. The navigation data is rebuilt from a clean, trusted source and checked against known-good baselines.

For a certified aviation system, this verification is not always an internal-only exercise. If the incident affects, or raises questions about, the integrity of certified avionics or their approved configuration, coordination with the applicable Design Approval Holder (DAH) may be necessary. The DAH can provide the approved technical guidance needed to verify that restoration preserves the system's original safety and security requirements, and supports confirmation that the aircraft remains airworthy before it returns to service. Returning it too early would undermine the recovery effort.

Key Principles

• Safe and secure, not merely available: A system that functions again is not necessarily recovered. Only once the asset is free of compromise and within acceptable safety limits may it be considered as 'recovered'.

• Understand before eradicating: Removing the visible artefact without knowing how it arrived invites its return. Root cause analysis comes first.

• Eradication reaches the pathway, not just the file: Where a cause originates upstream, technical clean-up alone is insufficient. The process that allowed the incident must be addressed too.

• Verification precedes return to service: Eradication is verified before restoration, and restoration before operational use. Assumption has no place in the sequence.

• Certified systems require DAH coordination: For regulated systems, restoration must align with the design approval holder's requirements before the asset returns to service.

Approaching Recovery in Practice

Recovery works best when its structure is decided before it is needed, not improvised during an incident. Recovery time objectives set in advance, and clear agreement on who confirms an asset is safe to return, both take pressure out of the moment. That judgement is never the maintenance team’s function alone. It involves the information security manager, the safety manager, the third-party supplier, and for a certified system, the design approval holder — because recovery is where information security, safety, and airworthiness have to act as one.

A Quick Summary

Recovery under IS.I.OR.220 turns a contained incident back into safe operation. It eradicates the cause rather than the symptom, restores affected systems to a state that is both safe and secure, and verifies that state before anything returns to service.

In the navigation database scenario, that discipline is the difference between grounding an aircraft briefly and allowing manipulated data back into the air - potentially across multiple aircraft.

Recovery closes the operational response to an incident, but it does not close the matter. Once systems are safe and secure again, the organisation needs to ask what the incident revealed about its defences and what should change as a result. These are the lessons learned.

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.