On Tuesday 6th October 2026, ASOS customers received a push notification saying the company had been hacked. It is the message every cybersecurity and data protection professional dreads, and the clock starts the moment it lands.
I have used it as a tabletop scenario: if this happened to your organisation tomorrow, what would you do in the first hours? Below is how I would approach it, from a risk and compliance seat rather than a deeply technical one, along with the UK regulatory deadlines that apply. The ASOS details come from the company’s public notifications and what I have picked up since, so treat them as an illustration rather than a full account.
1. Tell your insurer early
This may not be everyone’s first thought, but it can decide whether a later claim succeeds. Most cyber insurance policies require you to notify the insurer within a set timeframe and can also provide specialist technical support, so check your policy wording.
2. Form your incident response team
Things move quickly in these situations, so start by following the plan you already have. Most organisations have an incident response plan that names the groups involved (for example, Gold, Silver and Bronze teams), the decision makers, the update cadence and the approvals. In my experience, senior management should lead while the technical teams investigate.
Most importantly, everyone needs to be on the same page. Your cyber team, legal, data protection, customer and internal comms, and investor relations all need one place to share information and respond to updates as they arrive.
3. Establish legitimacy
The first technical question is whether someone has actually compromised your systems. App notification platforms are typically third-party systems, so it is possible that only the third party has been breached. That creates noise without putting your key data assets at risk.
Until you have ruled that in or out, treat the incident as a compromise. In ASOS’s case, their public notifications indicated a potentially broader compromise of key systems, which meant the attacker could reach more than the push notification platform. The claim was legitimate.
4. Contain the incident
Once the attack is confirmed, the objective is to get the attackers out of the network, prevent further issues and recover. This is where your technical team steps up, potentially with outside help.
From what I have picked up, the ASOS incident looks like an extortion attempt: a copy of key personal data was taken and the attacker threatened to release it. That suggests the attacker was found and handled without downtime, although we do not know whether any money was paid.
5. Preserve the evidence
Once the issue is contained, dig out and keep the evidence of the attack. It builds a picture of what happened, informs your mitigating actions and helps in future cases. It is also relevant to any legal action or insurance claim, so it must be preserved. I would look for logs showing:
- The point of entry
- Movement within the network
- Any alarms from security technology that were missed
- Access to systems
- Evidence of data exfiltration
- Date and time stamps
6. Communications and reporting
As evidence comes in, your communications to key stakeholders become better informed. That matters most for external communications.
ASOS is a UK PLC, so it is obliged to submit a Regulatory News Service (RNS) announcement to the market. The stock market is an external stakeholder that needs informing, and major shareholders may need to be contacted too. The share price moved on the day of the notification, but that should never affect your decision to notify the market when you are required to.
And please do not sell shares in the company before the market has been told. That is insider trading, and it is serious.
Conclusion
No two incidents play out the same way, but the first hours tend to follow a familiar pattern: tell your insurer, get the right people together, work out whether the claim is real, contain it, keep the evidence, and communicate carefully. Most of that is decided long before the notification lands, in the plan you have written, the roles you have agreed and the contacts you have to hand.
That is why I would encourage you to run this scenario with your own team. Walk through it with a clock running, and note where roles, decisions or contacts are unclear. It is far easier to find those gaps in a meeting room than in the middle of a live incident.
If you would like help running a tabletop exercise or reviewing your incident response plan, contact the TEC+ team.
References:
About the author
Joe Gaunt is Director of TEC+ Consulting, a UK consultancy specialising in data protection, responsible AI and governance, risk and compliance.
