Responding to Information Security Incidents Under EASA Part-IS (IS.I.OR.220)

In my previous article, How to Detect Incidents and Vulnerabilities Under EASA Part-IS, we looked at how information security events are collected and analysed to identify potential incidents and vulnerabilities. This article builds on that foundation and focuses on incident response — what IS.I.OR.220 requires when a confirmed incident is on your hands, and what response is actually designed to achieve.

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).

When an Incident Is Confirmed

When an event is assessed and confirmed as an information security incident — an unwanted occurrence that has already had an adverse effect on the confidentiality, integrity, or availability of information assets — the response phase begins.

At that moment, the objective is not to fix what went wrong. Response is not about fixing the root cause immediately, but about limiting the impact on aviation safety first. The goal is control: bring the right people together, stop the threat from doing further harm, and create the conditions for a proper resolution.

An Airline Operations Scenario

Consider an AOC holder operating scheduled commercial services. Within its ISMS scope sits a flight dispatch and crew briefing system — the platform through which crews receive performance data, operational notices, and route briefings before each departure. If the data it delivers is tampered with or corrupted, the consequences reach into the cockpit.

One morning, the operations team notices that briefing packages for several upcoming departures contain figures that do not match the flight planning outputs generated minutes earlier. A subsequent check reveals that records within the system have been modified without any corresponding audit trail entry. Something has interfered with the integrity of the data. This is an incident — and the clock is running.

Bringing the Right People In

Upon incident confirmation, the responsible person under Part-IS must engage the right people and coordinate. This includes people that need to be involved when an incident impacts a safety-relevant information asset within your ISMS scope.

Aviation incidents rarely respect departmental boundaries. The individuals who understand the technical dimension of the compromise are seldom the same people who understand its operational and safety consequences.

In this scenario, that means bringing together an Incident Response Team (IRT), including the information security lead, the IT team responsible for the dispatch platform, the safety manager, and the nominated person for flight operations. The safety manager will determine whether the Safety Action Group (SAG) needs to be activated, ensuring accountability for operational safety is present in the response and aligned with the organisation’s safety management practices.

Suppliers are not exempt. If the system involved is supported by an external provider, they should form part of the response.

Assessing Safety Impact & Setting Priorities

Once the IRT is activated, the first task is not investigation. It is impact assessment and prioritisation.

Under IS.I.OR.220, response priorities are led by aviation safety. An incident with actual or potential safety implications takes precedence over everything else. In this scenario, the safety manager’s first question is whether any affected briefing packages have already reached flight crews — and whether aircraft have departed using compromised data. That assessment shapes the urgency of every subsequent decision. Higher safety impact equals higher priority.

Where multiple issues surface concurrently, the same principle applies under Part-IS: safety first, business operations second.

Knowing What Acceptable Looks Like

Effective prioritisation depends on more than reading the current situation. For response to be calibrated rather than improvised, the organisation must already know — before any incident occurs — what level of impact on safety and information security is acceptable for each asset within scope, specifically in the context of that asset failing due to a threat scenario.

In the AOC scenario, that means establishing in advance what constitutes acceptable degradation of the flight dispatch and crew briefing system. Can operations continue if the system is partially available? Is any compromise of data integrity tolerable, even temporarily, if manual crosschecks are in place? These are not questions to answer in the middle of an incident. Pre-defined answers are what make prioritisation credible and consistent — not judgement under pressure.

Response time is directly tied to this picture. IS.I.OR.220 requires that the time within which an organisation responds is commensurate with the impact level pre-assessed for the affected asset. An asset whose failure could immediately affect flight safety demands a faster, more structured response than one supporting administrative functions. Those differences must be formalised so that the response is measured against a standard rather than estimated in the moment.

Containment

With the right people engaged and priorities clear, containment begins. The objective is to limit the scope and impact of the incident — stopping further spread, protecting unaffected systems, and preserving the evidence needed to understand what happened.

In our scenario, that might mean working with the IT team to temporarily suspend the affected briefing system while data integrity is verified — coordinating that decision with operational leadership so the safety consequences of the suspension are weighed against those of leaving it running.

Safety and operational continuity take precedence over digital evidence preservation — but every reasonable effort must still be made to protect what will be needed for investigation. Containment does not mean discarding forensic rigour; it means ensuring that rigour does not delay decisions that protect safety.

Once the threat is contained and no further spread is confirmed, the organisation can move toward recovery. For now, containment must be verified — not assumed.

Beyond Containment

Containment is the most visible element of a response, but IS.I.OR.220 describes a broader approach. The organisation should have defined, in advance, a containment strategy for each asset category within its ISMS scope — one that accounts for both the potential worst-case effect of an incident on that asset and the mission constraints of operating it. An incident response playbook is a great way to do this.

The briefing system in our scenario has different mission constraints from a crew scheduling platform. The containment approach for one may not suit the other, and those differences should be worked through before an incident, not during it.

The response measures available extend beyond containment alone. Resistance — reinforcing adjacent systems to prevent lateral spread — is one dimension. Controlling the possible ways a system can fail is another: ensuring that a compromised asset degrades in a predictable direction rather than one that generates unexpected, unsafe conditions. Where appropriate, deception may also be used to slow or misdirect a threat actor while the organisation works to address the source. Together, these measures are oriented toward keeping safety degradation within the pre-defined acceptable thresholds while minimising disruption to operations.

The containment strategy should also define observable criteria for when an incident is considered contained — specific evidence that the threat is no longer spreading and the affected asset is no longer in an uncontrolled state. That determination should not be a subjective call made at the end of a long night. Equally, the resources required to execute these measures — personnel, technical capabilities, and external support — should be identified in advance. Discovering mid-response that a critical capability is unavailable is a planning gap, not an operational one.

When the Response Itself Carries Risk

There is a dimension of IS.I.OR.220 that is easy to overlook: the response measure itself may introduce an immediate safety risk. The regulation is clear that both response time and the measures taken must account for the potential immediate negative impact on safety if action is taken before it has been fully verified that the measure will not cause additional, immediate safety impacts.

In the AOC scenario, this is not abstract. Suspending the flight dispatch and crew briefing system removes the source of corrupted data — but if flight crew are mid-briefing, or if the suspension disrupts an operational handoff already underway, the act of containment may itself create a hazard. The question is not only “does this stop the threat?” but “at this moment, in this operational state, does stopping the threat in this way introduce a new immediate risk?”

This is not a reason to hesitate. It is a reason to ensure the response framework includes a verification step before significant measures are executed, and that the safety manager is part of that verification — not informed of it afterwards.

Key Principles

• Safety determines the priority order: Response efforts are ranked first by aviation safety impact, then business operations. This hierarchy is not optional.

• Response is not repair: Containment stops the threat from doing further harm. Root cause analysis and eradication come later, in recovery.

• The right people must be engaged early: Information security, IT, operational, and safety functions need to work together. Waiting until the technical picture is complete before involving safety leadership is a recurring mistake.

• Containment must be verified: Assuming the threat has been stopped is not sufficient. Evidence of containment must be established before moving forward.

• External parties are part of the response: Suppliers, third parties, and platform providers whose systems are involved must be brought in. Containment that stops at the organisational boundary, when there are external dependencies, is incomplete.

What Response Requires in Practice

What separates an effective response from a disorganised one is rarely the quality of the tools. It is the quality of the decisions — and who makes them, and how quickly.

The hardest calls involve whether to take an operationally critical system offline, whether to convene the Safety Action Group, and what to share with external parties at which stage. IS.I.OR.220 requires that incidents are responded to in a manner that protects safety, engages the right people, and creates a traceable record of every action taken.

A Quick Summary

Incident response under IS.I.OR.220 is about control before cure. When a breach has already occurred, the immediate objective is to limit its impact on aviation safety, bring the right people together, and contain the threat before it spreads further.

Stakeholder engagement, prioritisation, and containment form the backbone of this phase. Each depends on the others — containment without the right people is unlikely to address the full scope of the threat.

Once containment is verified, the work shifts to recovery — eradicating the root cause and restoring affected systems to a safe and secure state. The parallel path, for vulnerabilities detected before exploitation, follows a different logic entirely. That is the subject of the next article.

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.