A Cyber Incident Doesn’t Always Start with a Hacker

Manchester Airports Group: information exposed while operations continued

In its August 2026 statement, Manchester Airports Group (MAG) confirmed that an unauthorised third party had obtained customer information linked to airport bookings and Wi-Fi registrations. It included email addresses, phone numbers, vehicle registrations, and postcodes. Bank and payment details were not held in the affected system, and airport operations were unaffected. Read MAG’s statement.

Security researcher Scott Helme’s investigation, published on 7 September 2026, identified credentials exposed in publicly delivered website code. He assessed an overpowered connection to a marketing platform as the likely route to the stolen records. As of 6 October 2026, MAG’s statement does not confirm that explanation; it remains an independent researcher’s assessment. Read Helme’s investigation.

The distinction matters. Misusing exposed credentials can still be a deliberate attack, even when it does not require defeating a system’s defences. For management, the question is whether a routine business function has been given access far beyond its purpose.

NATS: service disrupted by a software defect

The UK air traffic control outage on 8 September 2026 illustrates a different failure. NATS’s preliminary report, issued on 16 September, identified a previously unknown software defect that corrupted flight data under a specific combination of processing events. It found no evidence at that stage of malicious actors or cyber-related activity. This was a software reliability incident, not a reported data breach or confirmed cyberattack. Read NATS’s preliminary investigation.

Controllers used practised fallback procedures and reduced traffic capacity to maintain safety. NATS reported that safety was maintained, but more than 2,000 flights were delayed, cancelled, or diverted. Recovery required restarting systems and reconciling flight data between them. The findings were preliminary, with the full investigation ongoing when the report was issued. The Guardian’s coverage, 18 September 2026.

These cases have different causes and consequences. Together, they show why leaders need to ask whether information is protected from unauthorised access, whether it remains trustworthy, and whether it is available when the business needs it. Cybersecurity and operational resilience meet at those questions, even when an outage has no malicious cause.

Check what a working connection is allowed to do

Start with access. A feature can pass its functional checks while carrying permissions that nobody intended it to have. A newsletter sign-up, for example, might successfully record a new subscriber while its connection can also read a much larger customer dataset. The successful sign-up proves the feature works; it does not prove the access is proportionate.

An API key is a credential that lets one system interact with another. What matters to the business is its authority: can it record an action, read records, or change them? A powerful credential intended for a protected system should not be distributed to website visitors. Have qualified staff check the deployed connection, including what it can actually reach.

Follow the information beyond your main booking or sales system. Copies in marketing, reporting, and customer-support tools create their own exposure. Each should have a clear purpose, appropriate access, and a retention period. Connecting services can save time, but the benefit should justify the information shared and the permissions granted.

Plan for recovery when information cannot be trusted

Limiting access addresses only part of the risk. Your organisation may also need to operate when a system stops or its information becomes unreliable. A fallback plan should specify which services can continue, at what capacity, and for how long. Test those limits before customers and staff have to depend on them.

Recovery also needs an agreed standard for returning to normal. A restarted system may be available while its records remain incomplete or inconsistent. Decide how information will be checked, who can authorise resumption, and how affected teams will be told what they can rely on.

Assign a business owner who understands the service and its consequences, and a technical owner who can explain its dependencies and test the safeguards. Where a supplier operates the connection, make responsibilities for changes, incident evidence, and recovery explicit. Those decisions should be settled before an incident forces them.

Keep customer harm separate from service disruption

A service outage is visible. Information exposure may be less obvious, particularly when orders and bookings continue normally. Contact details linked to a recognisable transaction could make a fraudulent message more convincing. That is a risk to assess, rather than a prediction that every affected customer will suffer fraud.

The ICO’s definition of a personal data breach includes accidental loss, alteration, disclosure, and unauthorised access. An attacker is not required: a misdirected document or an inappropriate sharing permission can also trigger a response. Equally, a software outage should not automatically be described as a personal data breach; assess what happened to personal information. See the ICO’s breach guidance.

Under the guidance reviewed on 6 October 2026, a notifiable UK GDPR breach must be reported without undue delay and within 72 hours of awareness, where feasible. Notification to the ICO is not required where risk to individuals’ rights and freedoms is unlikely. Affected individuals must be informed without undue delay where the risk is high. All personal data breaches must be documented, including the reasoning behind notification decisions.

Assess those obligations alongside containment and recovery. Management and the privacy lead need enough evidence to judge harm and communications, rather than waiting for the technical investigation to finish. Specific obligations depend on the circumstances and should be checked with the appropriate advisers.

Review one important business connection this month

Choose a connection that carries sensitive information or supports a service your organisation depends on. Ask its business and technical owners to produce a short record, supported by evidence:

1. Define its purpose. Record the business task, the minimum information needed, and why any copies must be retained.
2. Demonstrate its access. Establish what it can read, change, or export. Check that powerful credentials remain protected and permissions match the task.
3. Map the consequences. Identify who would be affected by exposure, unreliable records, or an interruption. Include services that depend on the connection.
4. Locate the evidence. Confirm which activity records are available, who can obtain them, and how they would help establish the extent of an incident.
5. Test containment and recovery. Agree who can disable access, what fallback service can be sustained, and how information will be validated before normal operations resume. Test within authorised scope.

Give each gap an owner and a completion date. Repeat the review when the connection’s purpose, permissions, or dependencies change. A security assessment can test access assumptions, while response preparation can test the decisions needed when those assumptions fail.

To review how your organisation protects information and prepares for disruption, speak with CyberSolace.