How to Detect Incidents and Vulnerabilities Under EASA Part-IS (IS.I.OR.220)

In my previous article, we clarified the distinction between vulnerabilities and incidents under EASA Part-IS. One represents a weakness that exists within your environment. The other reflects a breach that has already materialised.

What enables you to manage either is detection.

Detection, however, does not begin at the point where something is clearly wrong. It begins much earlier, at the level of information security events. The collection and subsequent analysis of these events is what allows an organisation to identify abnormal activity that may indicate an incident, or to recognise signals that directly point to the presence of a vulnerability.

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

A Practical Scenario

Consider an aircraft Original Equipment Manufacturer (OEM) responsible for the design of structural components. Within its ISMS scope sits a digital engineering platform used to develop and store design data for load-bearing parts.

These designs are not simply intellectual property. Their integrity directly affects the safety of the aircraft. If a design is altered without authorisation or corrupted without detection, the consequence is not limited to data loss. It becomes a safety risk.

Across this platform, activity is constant. Engineers access files, modify models, exchange data with suppliers, and manage design baselines. Each of these actions generates observable occurrences within the system. These are events.

Individually, they are routine. Collectively, they form the only reliable picture of what is actually happening within the environment.

The challenge is not generating events. It is ensuring that the right ones are collected, understood, and made visible to the organisation.

Information Security Events as the Foundation of Detection

An information security event is any observable occurrence within a system, process, or activity that may be relevant to information security.

It does not need to indicate a breach. It simply reflects that something has happened which may warrant attention.

A modification to a design file, a sequence of failed login attempts on the system, a configuration change within a system, or an alert generated by a monitoring tool are all examples of events. Most will be benign, but in some cases, a small number will not be.

This distinction is important. Detection is not about treating every event as an incident. It is about ensuring that events are collected so that they can be assessed in context.

Every incident begins as an event. Many vulnerabilities are first identified through one. Without event collection, neither can be reliably detected.

Mechanisms for Event Collection

Under IS.I.OR.220, detection emerges from the structured collection of information security events. This is not achieved through a single control or tool, but through a set of complementary mechanisms that together provide coverage across technical, human, and external domains.

Event Monitoring

Event monitoring provides the primary layer of visibility. It ensures that activity across systems supporting aviation safety is captured and logged in a way that allows meaningful observation. In the OEM example, this includes the design platform, its access controls, and its interfaces with suppliers. Monitoring is not about capturing everything indiscriminately, but about focusing on areas where a failure would have safety implications. When a design file is modified outside expected workflows, or when user access behaviour deviates from normal patterns, these become events that require attention.

Internal Reporting (IS.I.OR.215)

However, not all relevant events are generated by systems. Some are observed by people interacting with those systems. This is where internal reporting, required under IS.I.OR.215, becomes essential.

An engineer may identify inconsistencies within a design that are not flagged by monitoring systems. A supplier may notice unusual behaviour when interfacing with shared data. A contractor may experience system responses that do not align with expected operation. These observations represent events that would otherwise remain invisible. The internal reporting scheme provides the mechanism through which they are captured, ensuring that human observations are integrated into the detection capability alongside system-generated data.

External Information Sources

Detection also depends on recognising that not all relevant events originate within the organisation. External information sources continuously produce signals that may directly indicate vulnerabilities affecting systems within the ISMS scope - vulnerabilities which have the potential to be exploited and result in an incident.

An OEM relying on specific software components within its design environment may be affected by newly disclosed vulnerabilities published through the Common Vulnerabilities and Exposures (CVE) program or catalogued within the National Vulnerability Database (NVD). Vendor advisories, such as Service Bulletins (SBs), may highlight flaws in data handling or system behaviour. Regulatory publications, such as Airworthiness Directives (ADs), including those addressing safety concerns in digital systems, may carry implications beyond maintenance and into information security.

These are not abstract pieces of information, buy they are events that signal the potential presence of vulnerabilities within the organisation’s environment. Treating them as part of the event landscape ensures they are assessed alongside internally generated signals.

Auditing

Auditing introduces a further dimension to detection by deliberately creating conditions under which events can be revealed. Penetration testing explores the existence of vulnerabilities that were previously unknown. Vulnerability scanning identifies known weaknesses within systems. Internal audits assess whether controls are operating as intended and whether processes align with documented expectations.

Findings from these activities are events in their own right. They do not confirm incidents, but they provide structured evidence of conditions that may have led, or will lead to one.

Bringing these Elements Together

Returning to the OEM scenario, detection becomes tangible when these mechanisms operate together.

Think of this example involving the OEM's digital engineering platform: event monitoring highlights that a critical design file has been modified outside normal working hours, accompanied by repeated failed user login attempts, eventually followed by a successful login and access. At the same time, an engineer reports that the updated design does not align with expected parameters. Shortly thereafter, an external disclosure by the platform’s supplier identifies a vulnerability which would allow a threat actor to bypass two-factor authentication, enabling them to gain unauthorised access to the platform by simply guessing a user’s password.

Viewed in isolation, each of these events may appear inconclusive. Together, they form a pattern that warrants further assessment.

This is the essence of detection. It is not the immediate identification of an incident or the confirmation of a vulnerability. It is the ability to collect, centralise, and analyse events in a way that allows abnormal activity to be recognised and understood.

Without this capability, events remain fragmented. With it, the organisation gains visibility over conditions that may impact information security, and as a result, aviation safety.

An Implementation Perspective

In practice, organisations often approach detection with a strong focus on technology. Logging capabilities are enhanced, monitoring tools are configured, and alert thresholds are defined. These are necessary components, but they do not, on their own, constitute effective detection.

Detection becomes meaningful when the different channels of event collection are connected and aligned with the organisation’s risk landscape.

• Monitoring must be focused on safety-critical assets.

• Reporting channels must be encouraged, accessible, trusted, and actively used by both internal and external stakeholders.

• External sources must be reviewed systematically, with clear ownership and follow-up actions.

• Auditing must go beyond compliance and actively challenge the effectiveness of controls.

The gap is rarely the absence of data. It is the absence of structure in how that data is collected and brought together for analysis.

Key Takeaway

Detection under IS.I.OR.220 is not a single activity. It is a capability built on the consistent collection and analysis of information security events.

These events are the earliest indicators of both potential or active risk materialisation. Some will point to abnormal activity that may evolve into an incident. Others will directly reveal the presence of vulnerabilities that require attention.

If events are not collected, they cannot be analysed. If they are not analysed, they cannot be understood. And if they are not understood, they cannot be managed.

Detection, therefore, is only the first step. It is the foundation upon which incident and vulnerability management is built. It enables your organisation to respond to situations which may potentially threaten, or are actively threatening, the safety of your operations.

 

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.