Who should be accountable for aviation cyber risk across IT and operations?

Why This Matters for Security Teams

Aviation cyber risk crosses enterprise IT, operational technology, safety engineering, and third-party maintenance. That makes vague accountability dangerous: when everyone is “aware,” no one is clearly answerable for a failed control. Security teams need named owners for identity, monitoring, segmentation, patching, and recovery, because regulators and auditors will look for traceable decision rights, not committee minutes. The NIST Cybersecurity Framework 2.0 is useful here because it turns governance into auditable outcomes across the organisation.

The practical issue is not whether aviation needs coordination. It does. The issue is that shared responsibility often becomes shared ambiguity. If IT assumes operations will validate uptime risk, and operations assumes IT will harden remote access, attackers exploit the gap. This is especially important where aircraft support systems, maintenance networks, and cloud-managed services intersect with safety-critical environments. In practice, many security teams encounter accountability failures only after a control has already been bypassed, rather than through intentional governance design.

How It Works in Practice

Effective accountability starts by assigning control ownership at the level of the system state, not the department label. Engineering should own technical architecture decisions such as segmentation, remote access design, and resilience patterns. Security should own detection, identity governance, logging, and alert triage. Operations should own enforcement of lifecycle controls, including approved change windows, patch timing, and maintenance access discipline. Leadership then ties those owners to risk acceptance and remediation deadlines.

Aviation teams usually need a control-to-owner model that can be reviewed alongside threat intelligence and regulatory obligations. That means documenting who owns preventive, detective, and recovery controls for each critical service, then validating that ownership during change reviews and incident exercises. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it maps responsibilities to specific control families, while CISA cyber threat advisories help teams align ownership with current attacker behaviour.

• Define one accountable owner per control, even where execution is shared.
• Separate architecture ownership from operational enforcement and detection ownership.
• Link each critical asset to an incident response and recovery owner.
• Review third-party maintenance, identity, and privileged access as part of the same accountability map.

Where AI-assisted detection or maintenance tooling is in use, ownership should also extend to model governance, input validation, and tool authorization. That intersection matters because autonomy can obscure who approved a decision path, especially when human operators assume the system has already checked itself. These controls tend to break down when aviation environments rely on distributed vendors, legacy OT, and inconsistent logging because no single team can prove what changed, when, and under whose authority.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clarity against operational speed. That tradeoff becomes sharper in aviation because safety, uptime, and regulatory reporting can pull ownership in different directions. Current guidance suggests that the answer is not to centralise every decision, but to create a clear RACI-style model with named control owners and escalation paths.

One common edge case is the shared boundary between corporate IT and aircraft or maintenance systems. Another is outsourced operations, where a managed service provider executes changes but the airline still retains risk ownership. In those cases, accountability should remain with the enterprise that accepts the risk, while execution may sit elsewhere under contract. If autonomous tooling is involved, the question becomes who owns the guardrails around the agent, not just who deploys the software. For that reason, practitioners should also track AI-assisted workflows against MITRE ATLAS adversarial AI threat matrix where relevant, and use Anthropic — first AI-orchestrated cyber espionage campaign report as a reminder that agentic abuse is now an operational concern, not a future scenario.

Best practice is evolving, but one principle is stable: if a control failure can affect flight operations, maintenance integrity, or recovery timing, the accountable owner must be identifiable before the incident, not reconstructed afterward.

Related resources from NHI Mgmt Group

• How should organisations govern stablecoin risk across multiple jurisdictions?
• Who is accountable when security risk is presented as a business metric?
• Who is accountable when digital asset controls fail across multiple providers?
• Why do non-human identities create more audit risk than human accounts?