Your Customers Heard About the Breach From the Hacker

On the morning of October 6, millions of Asos customers got a push notification on their phones. It was titled “ASOS HACKED.” It was addressed not to the customers but to the company’s data protection officer and IT team, and it said the attackers had “fully compromised” the company’s Snowflake data platform and would leak data unless Asos engaged with them.

Asos did not send that message. The attackers did. Asos confirmed the notification was unauthorized, and its shares fell almost 15% in London at the low point that day, ending the afternoon still down nearly 10%.

Read that again. The first public disclosure of the incident was written by the criminals, delivered through the company’s own app, and timed for maximum market impact.

What we know, and what we don’t

Asos has said the activity involved third-party platforms it uses to communicate with customers. It restricted access to those platforms and is working with outside specialists and authorities. It said names and contact details may have been accessed, and that it does not believe payment card information or account passwords were affected.

Much of the rest is unproven. The attackers claimed to have compromised a Snowflake environment. They published no samples or other evidence, and Asos has not confirmed that a Snowflake environment was involved. Snowflake has said it found no compromise of its own platform. The group, calling itself Xuanye Group, was unknown to researchers before this week.

An executive reading this should resist the urge to decide who is at fault. The more useful question is structural: how did a message from an attacker end up on customers’ phones, and what does that tell us about how much of our business runs through systems we don’t directly control?

The breach was a business event before it was a technical one

In Cyber Risk Is Business Risk, I argue that the board’s job is not to understand firewalls. It is to understand consequences. This incident is a clean example. Whatever the forensic investigation eventually finds, the business consequence arrived within hours: a double-digit swing in market value, a brand-trust problem with roughly 17 million active customers, and a regulatory clock that starts ticking the moment personal data may be involved.

No one needed a technical briefing to see that. Directors read a stock price.

The vendor you forgot is part of your company

Customer messaging, marketing, and analytics platforms rarely feel like “critical infrastructure.” They are not in the data center. They are subscriptions bought by a business unit. But they hold customer contact data and, as this week showed, they hold something more dangerous: the authority to speak to your customers in your name.

This is the first of the Three Questions I encourage every board to ask: What are we protecting? Most companies answer with their crown-jewel databases. Few include the megaphone. If a third party can push a message to every customer you have, that capability is an asset, and it needs an owner.

Compliance is not the same as security

Many companies can show a vendor-risk questionnaire, a signed contract, and a SOC 2 report for every supplier. That is compliance. It proves that someone asked the right questions at some point in the past.

Security is whether the control works today. Is multi-factor authentication actually enforced on every administrative and API login at the vendor? Are old accounts and shared credentials removed? Can you cut a vendor off in minutes? A questionnaire cannot tell you. Only evidence can.

For perspective, in 2024 a criminal campaign used stolen credentials to get into customer accounts on Snowflake that lacked multi-factor authentication; roughly 165 organizations were notified. The lesson then was that the platform wasn’t breached, but the customers’ configuration and access controls were. Whether that pattern applies here is not yet known. It is the right question to ask regardless.

The communications gap

Notice what Asos was forced to do: respond to a story the attacker had already told. Companies that rehearse only the technical response, and not the moment their own channels are turned against them, lose the first news cycle by default.

Ask whether your incident plan answers these questions: Who can authorize a message to customers? Who can shut the channel off? How quickly can we tell customers the truth in our own words, and does the plan assume our normal channels are still trustworthy?

What to ask your CISO this week

1. List every third-party platform that can send messages to our customers or employees. Who owns each one, and who has administrative access?
2. Show me evidence that multi-factor authentication is enforced on those platforms, including for service accounts and API keys, not just a policy that says it should be.
3. How fast can we revoke a vendor’s access? Have we ever tested it?
4. If an attacker used our own app to announce a breach, what is our first hour? Who decides what we say, and to whom?
5. Which of our vendors would we not want to be the subject of this headline? Let’s review those first.

The bottom line

Boards are held accountable for what they chose to oversee. When an attacker can reach your customers through a supplier, “it was the vendor’s system” is an explanation, not a defense. The companies that come through these moments well are the ones whose directors asked the uncomfortable questions before the notification went out.