The short answer: in June 2025, attackers got into servers run by a third-party supplier to CGI, one of Glasgow City Council's IT providers. The council isolated those servers to protect the rest of its network, and that decision took a number of online services offline for weeks. Independent investigators later found no evidence that council or customer data had been encrypted or stolen. The lesson for any organization is that a supplier's systems are part of your attack surface, and that a recovery plan has to allow for switching services off on purpose.
This post summarizes what the council and the UK technology press reported, with sources linked in each section, and what businesses can take from it.
What happened at Glasgow City Council?
Early on Thursday 19 June 2025, CGI found malicious activity on servers managed by one of its own suppliers. Those servers ran services for Glasgow City Council. The council took the affected servers offline and brought in Police Scotland, the Scottish Cyber Coordination Centre and the National Cyber Security Centre.
Online services that depended on those servers went down with them. Reported examples included planning applications, parking fine payments, reporting school absences and ordering certificates. The council said none of its financial systems were affected and no bank or card details were compromised.
At first the council could not confirm what data had been touched, so it worked on the presumption that customer data might have been taken. It also warned residents to be wary of anyone contacting them and claiming to be from the council or to hold their data.
Sources: UKTN, "Glasgow council cyber attack", June 26, 2025; PublicTechnology, "No evidence of data theft in recent Glasgow cyberattack", July 22, 2025.
What did the investigation find?
In July 2025 the council reported that independent specialists had examined the affected servers and found no evidence that council or customer data had been encrypted or exfiltrated. There were attempts to download data, and the council said all of them were denied. Investigators had high confidence the incident was contained.
The council described it as an opportunistic attack on a third-party supplier rather than on the council itself. Access came through the supplier's network, not through a council system or a council user account.
The council also said that much of the disruption came from its own decision to isolate the servers. It expected all but a handful of applications, the ones that depended on outside support, to be back online by mid-August 2025.
Source: FutureScot, "Cyberattack on Glasgow City Council did not lead to data theft or encryption, new report finds", July 24, 2025.
Why does a supplier breach matter to a private business?
Glasgow's own systems were not the way in, yet residents still could not pay a parking fine or submit a planning application for weeks. Most businesses depend on outside providers in the same way: hosted line-of-business software, payroll, cloud backup, websites and IT support. If one of those providers is breached, your service can go down even though nothing in your office was touched.
The Glasgow case also shows that containment has a cost. Pulling servers off the network was the right call, and it was also the main cause of the outage. A business that has never decided which systems it can live without will make that call in a hurry, in the middle of an incident.
What should IT teams take from the Glasgow incident?
- List the suppliers that hold your data or run your services. Include the systems they host for you, who to call at any hour and what each contract says about breach notification. Ask key suppliers which subcontractors are involved.
- Decide in advance what you can switch off. For each important system, write down who can approve isolating it, what stops working when it is offline and how staff will work around it.
- Assume data may be lost until you can show it was not. Glasgow treated customer data as possibly taken until forensics said otherwise. That only works if you already know what data each system holds.
- Warn customers about follow-on scams. Criminals use news of a breach to send convincing fake messages. Tell customers how you will and will not contact them.
- Separate supplier-managed systems on the network. Isolating one segment is only possible if it is not tangled up with everything else.
- Require MFA and logging for supplier remote access. Every vendor account should be named, protected with multi-factor authentication and reviewed regularly.
- Keep backups the attacker cannot reach. Restoring services onto clean servers is far quicker with offline or immutable backups that have been test-restored.
How do you build a response plan that covers suppliers?
An incident response plan does not need to be long. It needs to answer these questions before anything goes wrong:
- Detection and triage. Who decides that an alert is an incident, including at night and on weekends?
- Containment. Which systems can be isolated, who approves it and what the business impact of each one is.
- Notification. When to contact police, regulators, your cyber insurer, customers and the supplier involved.
- Recovery. The order systems come back in, where clean servers will come from and how long each step takes.
- Review. What changes afterward, with an owner and a date for each.
Walk through the plan once a year as a tabletop exercise, with leadership in the room and at least one scenario where the problem starts at a supplier.
How Velocity helps Arizona businesses plan for this
Velocity Technologies helps Phoenix and East Valley businesses map the vendors and systems they depend on, segment their networks and test that backups restore. See cybersecurity services and backup and disaster recovery for how that work is done. To find out where your own gaps are, start with a free network assessment.