The ASOS data breach is not a card skimming incident. That distinction sounds pedantic until you start spending money on the wrong control. ASOS’s own account of what happened describes an unauthorised party getting into an employee account and reaching a third-party communication platform that held customer contact details. No injected JavaScript. No skimmer on the payment page. Contact details sitting in a supplier’s database are a different asset from card data read out of a payment form, reached by a different route, and defended with different work.
What follows is written for the people who have to answer the internal question that lands the morning after a headline like this: could that have been us, and what do we fix first. There is also a short section for shoppers, because the honest answer to “are my card details at risk”is not the one most coverage gives.
What is confirmed about the ASOS data breach, and what is still a claim
Work only from the retailer’s own statement and from named reporting that quotes it. As of the time of writing, the confirmed line is narrow: an unauthorised third party obtained access to an employee account by impersonating a trusted contact, and that access reached a third-party platform used for customer communications, holding names and contact details. Read plainly, that is social engineering against an identity process, followed by access to data at rest in a supplier system.
Scope then widened in later statements to more detailed customer profile information. This is normal, and it is the part worth internalising if you are planning your own incident comms. First statements are written from the first forensic picture, and the first forensic picture is almost always the smallest one. Access logs get pulled, a second platform turns out to have been in reach, and the scope grows. Plan your customer notification wording so that growth does not make you look as though you concealed something.
Separately, claims have circulated through app notifications and social posts: named cloud suppliers, a ransomware label, specific volumes. Treat attacker messaging as marketing. Pressure on the victim and inflation of the story are the point of it, and a crew that has just stolen a contact list has every reason to describe it as something larger. Do not repeat unconfirmed attribution in your own customer emails, your board update or your supplier questionnaires. If you cannot source a claim to the official statement or to reporting that quotes it, leave it out.
Personal data or card data: why the difference decides your response
A browser-side skimmer takes a specific set of fields: the primary account number, expiry date, CVV and cardholder name, read out of the form as the shopper types them. It happens in the shopper’s browser, in the seconds before the payment is authorised, and the payment still succeeds. Card details stolen at the moment of payment never touch your database, which is precisely why database security does nothing about them.
Contact details, order history, addresses and account identifiers are a different class. They sit at rest, in your platform and in the dozen supplier platforms that hold a copy. Nobody needs to execute code in a browser to get at them. They need an account.
The two land differently everywhere that matters. A confirmed card compromise pulls in your acquirer, your payment provider and card-brand notification routes, and it will put your PCI DSS compliance position under immediate scrutiny. A personal data breach with no card element is primarily a UK GDPR matter: risk assessment, Information Commissioner’s Office notification where the threshold is met, and notification of individuals where the risk to them is high. Customer harm is real in both cases. It is just a different harm.
Here is the mistake the ASOS incident exposes most clearly. A Content Security Policy and Subresource Integrity hashes would have changed nothing about an impersonation call that ended in access to an employee account on a communication platform. The data was at rest. It was never passing through a shopper’s browser, so there was no browser control to catch it. The reflex after a headline breach is to buy the control that was in the news. Buy the control that fits your own weakest route instead.
The route in: impersonation of a trusted contact, and its skimming equivalents
The identity route is unglamorous and extremely effective. Someone rings or messages a support desk, an IT team or a colleague, presents as a supplier contact or an internal name, and asks for a password reset or an MFA re-enrolment. The authenticator is moved to a device the attacker controls. Every technical control downstream now sees a legitimate, authenticated user. Help desk verification is the weak joint in most UK retail organisations, and it is cheap to harden.
Card skimming has a structurally identical route, where the weak point sits in a third party rather than in your own code. Ticketmaster UK, June 2018: skimming code reached the payment flow through a supplier chat widget loaded onto the page. The retailer’s own code was intact. Someone else’s code, running with the same privileges, was not.
The British Airways incident in August and September 2018 shows the opposite case. Modified first-party JavaScript on the payment flow, meaning the code you own and deploy yourself is also a route in. The ICO issued a £20 million penalty over that breach in October 2020, after proposing a far larger figure. First-party code is not safe code; it is just code you are responsible for.
Then there is the platform route, where no phone call is required at all. Over a single weekend in September 2020, the security firm Sansec reported roughly two thousand Magento 1 stores compromised through unpatched platform software. Nobody was socially engineered. The software was simply out of support and reachable.
Which is the argument for route-based thinking over group-based thinking. “Magecart”is a label for a method, not a gang, used by many unconnected crews, and knowing which crew hit someone else tells you almost nothing about your own exposure. Knowing which of the routes behind the best-documented incidents is open on your estate tells you everything.
What stolen profile data enables next: better phishing, not cloned cards
The realistic follow-on harm from a profile breach is a more convincing email. That is not a consolation. A refund message quoting a real order number, a real delivery address and the correct last-ordered item is extremely hard for a shopper to dismiss, and the “reconfirm your payment details”page it links to collects a full card record in one step.
So the weeks after a breach announcement are when fake payment forms convert best. The shopper has been told to expect contact about a security incident, then receives contact about a security incident. The page looks right. The payment appears to fail and is then “retried”successfully on the real site, which removes the one signal a shopper might have noticed.
Two practical consequences for merchants. Make your own communications verifiable: a single named page on your own domain that customers can reach by typing the address themselves, no payment or card fields anywhere in your breach comms, and a clear statement that you will never ask for card details by phone or email. And treat outside signals as detection data. Issuer and acquirer fraud reports, chargeback clusters that cling to one date range, and customer reports of odd payment prompts often arrive before any internal alert does. If a cluster points at a specific window, that is the point at which checking whether your checkout has been skimmed stops being theoretical.
For shoppers, the short guidance is blunt. Card details are not usually what is taken in this class of breach, so there is no need to cancel a card on principle. Check statements for small unfamiliar amounts, never give card details or one-time codes to an inbound caller or an emailed link, change any password reused elsewhere, and treat any message that creates urgency about a refund as suspect until you have logged in by typing the address yourself.
The supplier and script audit UK merchants should run this week
Most merchants keep one inventory. You need two, and they contain different companies.
The first lists every party that stores your customer data: email service provider, support desk and ticketing, analytics, loyalty, CRM, reviews, returns portal, warehouse and delivery partners. For each, record what data they hold, who at your end can administer the account, and whether access requires single sign-on with phishing-resistant MFA.
The second lists every party whose code executes on your payment page. A chat widget, a tag manager container, a personalisation script and a session replay tool all belong on this list even though none of them touches your database. PCI DSS v4.0 requirement 6.4.3 expects each script loaded in the consumer browser to be authorised, to have its integrity assured, and to appear in an inventory with a written business justification. Requirement 11.6.1 expects change and tamper detection on the payment page and its HTTP headers, with alerts to personnel. Both became mandatory on 31 March 2025, after the PCI Security Standards Council’s future-dated phase ended. The detail of what those two requirements actually ask for is worth reading properly before an assessor asks.
One warning about 11.6.1. Tamper detection only helps if someone owns the alerts. Plenty of merchants switch it on, point it at a shared inbox, and let the reports accumulate unread, so an injected script change ends up sitting in a log nobody opened. Decide the alert threshold, the destination inbox and the named owner on the day you deploy it, not later.
For the browser side, start a Content Security Policy in report-only mode and leave it there long enough to learn what your checkout genuinely loads. Blocking first and discovering second is how you take your own payment page down on a Friday. Subresource Integrity hash-pinning is the companion control, with a real operational cost: when a supplier ships an update, the hash stops matching and the script stops loading until someone updates it. Budget for that work rather than being surprised by it.
The configuration-level fix most merchants underuse is moving card entry into a payment provider’s iframe or hosted payment fields. Card inputs then sit outside the reach of scripts on your page, and it can support SAQ A eligibility. Note that the Council’s revised SAQ A, published in January 2025, took 6.4.3 and 11.6.1 off that questionnaire while adding an eligibility condition about the site not being susceptible to script attacks affecting the payment page, so check the current wording rather than assuming. And be clear about the limit: hosted fields protect the card number. Names, delivery addresses, order history, account credentials and admin sessions remain in your platform and your suppliers’ platforms. That is exactly the data class the ASOS incident involved.
If it happens to you: notification, evidence and the first week
Assess the risk to individuals first, then notify. Under UK GDPR, a personal data breach that meets the risk threshold must be reported to the ICO within 72 hours of becoming aware of it, and affected individuals must be told where the risk to them is high. Tell them in plain language, say what you do not yet know, and do not promise that no further data was involved before your logs support that.
Preserve evidence before anyone starts cleaning up. Server and admin logs, deployed script versions and build artefacts, third-party platform access and audit logs (request them early, retention windows on SaaS platforms are often short), and a frozen copy of the payment page exactly as it was served to a shopper. Remediation destroys the record, and the record is what tells you the date range your acquirer will ask about.
Beyond the ICO: your acquirer and payment provider if card data is anywhere in scope, the supplier whose platform was involved, and your own support and social teams, who will be answering the calls long before the forensic report lands. Give them a script and a verified page to point at.
Then close the identity route, which is the one that actually failed here. Define a verification step for credential and MFA resets that cannot be satisfied by knowing internal names. Review least privilege on supplier and staff accounts, particularly on communication and marketing platforms that hold exports nobody remembers creating. Remove dormant integrations and old API keys. The supplier breach checklist for checkout covers the sequencing in more detail.
The short version
The ASOS data breach, on the evidence available, was an identity and supplier-access incident: an impersonated contact, an employee account, customer data at rest in a third-party platform. It was not a browser-side skimmer, and browser-side controls would not have stopped it. Build both inventories, one for who holds your data and one for whose code runs on your payment page. Satisfy 6.4.3 and 11.6.1 properly, with a named owner for the alerts. Harden help desk verification, because that is where this class of breach begins. Then expect the phishing, because detailed profile data is what makes the next fake payment page believable.
Frequently Asked Questions
Were card details stolen in the ASOS data breach?
ASOS has not reported card data as being involved. The data described in its statement is customer profile information held in a third-party communication platform, which is a different asset from the card number, expiry and CVV that a checkout skimmer captures. Shoppers do not need to cancel cards on that basis, though statement checks remain sensible. Scope can widen in later statements, so read the current official notification.
What customer data was involved, and how did the attackers get in?
The confirmed route is an unauthorised party obtaining access to an employee account by impersonating a trusted contact, which gave reach into a third-party platform holding names and contact details. Later statements extended the scope to more detailed customer profile data. Claims circulating in app notifications and on social media, including named cloud suppliers and ransomware labels, remain unconfirmed and should be treated as attacker messaging rather than evidence.
Is the ASOS data breach a Magecart or card skimming attack?
No. Magecart-style attacks inject JavaScript into a payment page so card details are copied in the browser as the shopper types them. Nothing in the ASOS account describes code on a checkout page. The common structural link is third-party dependence: Ticketmaster UK in June 2018 was compromised through a supplier chat widget, and the ASOS data breach through a supplier communications platform. Same dependency, different data and different controls.
What should ASOS customers do now?
Change the password and change it anywhere it was reused. Check card statements for small unfamiliar transactions. Treat any inbound call, text or email about refunds, failed deliveries or reconfirming payment details as suspect, and reach your account by typing the website address yourself rather than following a link. Nobody legitimate will ask for your full card number or a one-time code.
How can a retailer stop a similar supplier or employee account breach?
Start with help desk verification for credential and MFA resets, since impersonation is the route that worked. Add phishing-resistant MFA and single sign-on across supplier platforms, review least privilege on every account that can export customer data, and remove dormant integrations and unused API keys. Keep a live inventory of which suppliers hold customer data, separately from your payment-page script inventory, and review supplier access logs on a schedule rather than only after an incident.
Further reading on the regulatory side: the ICO’s guidance on personal data breaches and the PCI Security Standards Council for the current text of PCI DSS v4.0.