EASA Part-IS: How to Tell the Difference Between a Vulnerability and an Incident (And Why You Must)

Previously, we looked at how organisations can reduce information security risk under Part-IS. That process assumes something important: that you have identified your risks and treated them as best you can.

But, no risk treatment is perfect. Technology evolves. Threat actors adapt. Systems that were secure last year may carry weaknesses today that did not exist when the assessment was first conducted. That reality does not make risk management pointless - it makes continuous monitoring essential.

This article focuses on IS.I.OR.220, the Part-IS requirement that addresses information security events. Specifically, it explains the difference between a vulnerability and an incident, why that distinction matters operationally, and what the regulation expects you to do about each.

If you're implementing Part-IS and unsure you're on the right track - that's a common challenge. I help aviation organisations build 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).

A Practical Scenario

Consider a CAMO using a continuing airworthiness management system. Maintenance records, airworthiness directives, and work packages are all stored and accessed through it. The system is central to the organisation’s safety-critical processes, ensuring aircraft remain airworthy.

One afternoon, the IT team notices that a software component used by the CAMO system has a known flaw: The current software version allows threat actors to gain remote access to the system via a backdoor (a hidden way to sneak into the system), letting them take full control over it. No one has exploited it. Nothing has gone wrong. But the weakness is there, and it is now known.

A week later, a different alert: an unusual amount of activity at unexpected times suggests that an unauthorised, external party may have accessed the CAMO system. Records may have been viewed, and possibly altered.

Two types of situations - very different in nature, but both relevant under Part-IS. Understanding the difference between them is the key to determine your response.

Vulnerabilities vs. Incidents - What’s the Difference?

A Vulnerability Is a Weakness

A vulnerability is a condition that increases the likelihood of a harmful event occurring. It creates the potential for an unacceptable risk to materialise. Nothing bad has happened yet - but the door is open. The software component containing the backdoor in the scenario above is a vulnerability. It represents a gap in your defences that, if discovered and exploited, could lead to a breach.

Think of it like a padlock left unlocked on a cabinet. The cabinet is not broken into and the information inside is still intact. But the protection that should be there is missing.

Identifying vulnerabilities is a proactive activity. You are looking for weaknesses before they are exploited, which gives you the opportunity to close them before harm occurs.

An Incident Is a Breach

An incident is different. It means something has already happened - specifically, a breach of the confidentiality, integrity, or availability of safety-relevant information. Such an incident may result in the materialisation of an unacceptable risk. In the scenario above, the suspicious and unexpected activity points to an incident. Someone may have accessed information they were not authorised to access, and the integrity of maintenance records may be in question.

Where vulnerability detection is proactive, incident management is reactive since the risk has materialised. The question is no longer “how do we prevent this?”, but “how do we contain it, recover from it, and ensure it does not happen again?”

Why the Distinction Matters

Both vulnerabilities and incidents are addressed under IS.I.OR.220, but they require fundamentally different responses. Treating a vulnerability like an incident, or failing to recognise an incident for what it is, leads to poor decision-making and delayed action.

Getting this right is essential to operating a mature ISMS.

What IS.I.OR.220 Requires

Part-IS does not just ask you to be aware of vulnerabilities and incidents. It requires a structured capability to detect, respond to, and recover from them – and to learn from what happens.

Detection

Detection is the foundation. Without it, neither vulnerabilities nor incidents can be managed. Under Part-IS, this means continuously monitoring information security events across the information assets within your scope - looking for signals that something is wrong, whether that’s a weakness that has emerged or a breach that has occurred.

The distinction between the two shapes how detection is approached. Vulnerability detection tends to be systematic and scheduled, such as through scanning, monitoring, and reviewing. Incident detection however is often triggered by anomalies or alerts that suggest something has already gone wrong.

Both vulnerabilities and incidents can also be detected through the organisation’s internal reporting scheme.

Response

When an incident is confirmed, the immediate priority is containment. The goal is to stop the spread of the impact, prevent further compromise of safety-relevant information, and ensure that any resulting failures occur in a controlled way - not in a manner that degrades the safety of operations.

Response is not about fixing the root cause immediately, but about limiting the impact on aviation safety first.

Recovery

Once the immediate situation is under control, the focus shifts to recovery. This means restoring affected information assets to a safe and trustworthy state, removing or constraining the incident root cause, and doing so within a timeframe that the organisation has defined based on safety impact. The goal is a return to a known, safe operating condition.

Lessons Learned

This step is often underestimated. Once an incident is resolved, the experience should feed back into your risk management process. What did the incident reveal about your existing controls? What changed? What should be treated differently going forward? This loop is how information security under Part-IS improves over time - not through compliance alone, but through operational learning.

Key Principles to Keep in Mind

• Separate concepts, separate responses: Vulnerabilities and incidents are not interchangeable. Each requires its own management approach.

• Both matter: Proactive and reactive management must coexist. You need both vulnerability detection and incident response - one does not replace the other.

• Safety is the filter: Safety relevance is the anchor. Not every IT event requires a formal Part-IS response. The question is always whether safety-relevant information is affected.

• Improvement is the goal: Learning closes the loop. Incidents that are resolved but not analysed and learned from leave organisations vulnerable to the same event occurring again.

An Implementation Perspective

Organisations often ask whether they need separate processes for vulnerabilities and incidents. The answer is yes - at least at the response level. The detection activity can be unified (monitoring information security events), but what happens next depends entirely on what has been detected.

A vulnerability that is identified and remediated before exploitation is a success. It means the monitoring is working and the organisation is staying ahead of the threat. An incident, on the other hand, triggers a different chain of decisions: response, recovery, and review.

From a practical standpoint, organisations should ensure that the people responsible for managing these situations understand the difference - and that escalation paths are clear. When an event is detected, there should be no ambiguity about whether it is being treated as a vulnerability or an incident. That clarity drives the right actions, in the right order, at the right time.

A Quick Summary

No ISMS eliminates risk entirely. The work done in risk assessment and treatment creates a solid baseline. But the baseline will always have gaps, and the threat environment will continue to evolve.

IS.I.OR.220 exists because of that reality. It acknowledges that weaknesses will emerge and that breaches will sometimes occur. What matters is whether the organisation is equipped to detect them, respond appropriately, and recover in a way that protects aviation safety.

The distinction between a vulnerability and an incident is not a technicality. It shapes everything that follows: how quickly you act, who gets involved, what decisions are made, and how you improve. Understanding it clearly is one of the more practical steps an organisation can take toward achieving compliance - and genuine safety.

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.