Cybersecurity / Source date:

Marriott's 2018 Starwood breach and revised estimates

Marriott's initial 2018 estimate was later revised to an upper limit of 383 million guest records, not unique people. Later disclosures also revised the stated protection method.

Illustration of retained hospitality records in an unbranded hotel back office, not Marriott premises.

Historical and retrospective context. The original 4 December 2018 date is retained. Marriott's initial November 2018 disclosure estimated up to 500 million guests before deduplication. Its 4 January 2019 update reduced the upper limit to 383 million guest records, not 383 million unique people. Later evidence is retrospective.

Marriott disclosed on Friday that the Starwood guest reservation database had been accessed without authorisation since 2014, and that up to around 500 million guest records were involved. The Marriott data breach 2018 is the largest disclosure of its kind since Yahoo, and the number everyone is repeating is the least interesting thing about it. The interesting figures are four and eighty-three. Four years of undetected access. Eighty-three days between the alert that started the investigation and the public statement. Everything a board should take from this sits inside those two intervals.

What the company has said

An internal security tool flagged an attempt to access the Starwood reservation database on 8 September. The investigation that followed established that there had been unauthorised access since 2014, and in the second half of November that an unauthorised party had copied and encrypted information and taken steps to remove it. In the initial November 2018 estimate, later revised, for roughly 327 million of the then-estimated affected guests, the company says the exposed data included some combination of name, postal address, phone number, email address, passport number, Starwood loyalty account information, date of birth, gender, arrival and departure details, reservation date and communication preferences. For a smaller group, payment card numbers and expiry dates were present. That initial protection description was later revised. In January 2019 Marriott said it had no evidence that the components needed for decryption were accessed. Its 17 April 2024 update said payment card numbers and some passport numbers previously described as AES-128 encrypted had instead been protected with SHA-1. Do not present the initial encryption account or key uncertainty as the final finding. The Starwood system was already on the way out. Marriott acquired Starwood in 2016 and has been consolidating reservations onto its own platform, with the legacy environment due to be retired. The breach ran its full course inside a system that was scheduled for deletion.

Four years is the actual story

The acquisition-diligence lesson here is real and it is also the obvious one: an acquirer inherits the target's history along with its assets, and a compromise that predates the deal becomes the buyer's problem on completion. That argument has been made, including in these pages, and it is not the most useful thing to take from this week. The more uncomfortable point is what happens after the deal closes. A legacy platform in a multi-year decommissioning programme is the worst-monitored asset class in any large organisation. It is in run mode, nobody is investing in it, the people who understood it have moved on or left, the monitoring was configured for the operational profile it had five years ago, and every proposal to improve it is met with a reasonable objection that the system is being switched off anyway. That objection is correct about the roadmap and wrong about the risk, because the data stays live until the day the system goes dark. Four years of undetected access in a reservation database is not primarily an attacker sophistication story. It is a detection story. A reservation platform serves an enormous volume of legitimate queries from hotels, agents, aggregators and call centres around the clock. Illegitimate access looks like legitimate access unless someone has defined what abnormal means and is watching for it. Most organisations have logs. Fewer have baselines. Almost none have alerting on bulk read volumes, which is the single control most likely to have shortened this timeline. The eighty-three days from alert to announcement are more defensible than they will sound in the coverage. Establishing what was taken from a system with four years of attacker presence is genuinely slow work, and the alternative, announcing early with wrong numbers, has its own costs. What organisations should take from it is planning arithmetic: the notification clock in the new European regime runs from awareness of a personal data breach, not from the completion of forensics, and the gap between those two moments is where the hard judgements live.

Passport numbers change the harm profile

Most breach commentary defaults to payment cards because the remediation is familiar. Cards get reissued, liability frameworks exist, and the consumer harm is bounded and short. Passport numbers are not like that. They cannot be reissued on request without cost and inconvenience, they persist for years, and they are used as an identity anchor for account opening, border processes, visa applications and know-your-customer checks. Combined with name, date of birth, address and a travel history showing exactly where somebody was on specific dates, they support a far more durable class of fraud and, for certain individuals, a personal safety exposure that no reissued credit card comes close to. This is the part of the disclosure that regulators are most likely to weigh heavily, and it should reframe how hospitality, travel, healthcare and financial organisations think about their own identity-document holdings. The question is not whether you take passport copies. It is how long you keep them, whether they sit in the transactional system or in an attachment store nobody inventories, and whether anyone would notice a bulk export.

Reduce identity-record exposureA qualitative control sequence from the article, not incident evidence or legal advice. No breach counts or notification deadlines are charted.
  1. Locate the records

    Inventory identity documents in attachments, shared files and email as well as databases.

  2. Review retention

    Establish the applicable retention position and delete records no longer required.

  3. Watch bulk access

    Baseline reads and exports, including systems scheduled for retirement.

  4. Prepare the response

    Check key custody, awareness decisions, entity responsibilities and notification content.

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

Practical Guidance for a Data Protection Assessment

  • Find your identity documents first. Passport scans, national identity copies, visas and residence permits, wherever they landed. They are usually in attachment tables, file shares and email, not in the fields anyone classified.
  • Set a retention period for them and enforce it. Most organisations hold these copies indefinitely because deletion was never anybody's job. This is the highest-value, lowest-cost reduction in exposure available.
  • Alert on volume, not just on failure. Bulk reads, unusual export sizes and off-hours queries against customer databases. Access control tells you who may read; volume alerting tells you when someone did something strange.
  • Put legacy and decommissioning systems on the monitoring plan explicitly. A system scheduled for retirement holds live data until the day it does not, and the retirement date has slipped before.
  • Check what your encryption actually protects against. If keys or key material sit in the same environment as the data, encryption does not survive a compromise of that environment, and your notification assessment cannot rely on it.
  • Rehearse the awareness decision. Who declares that a personal data breach has occurred, on what evidence, and how a partial picture gets reported to a regulator inside three days without committing to numbers you will have to retract.
  • Know which regulator, for which entity, before you need to. For a group with entities in several jurisdictions this takes days to work out under pressure and an hour to work out now.
  • Prepare the customer notification content in advance. What was taken, what it means, what you are doing, what the customer should do. The organisations that handle this well have drafted the structure before the event, not during it.

The Regional Angle

This one lands directly on a core regional industry. The Gulf runs one of the world's most concentrated hospitality sectors, and it holds guest identity data in a way that is both deeper and more compulsory than in most markets, because hotels here are required to collect and register guest identity details with the authorities. A passport copy at check-in is not an optional loyalty convenience; it is a regulatory step. The consequence is that a mid-sized regional hotel group holds a document set that in many jurisdictions would only exist at a border post, and it usually holds it forever, because the retention question has never been asked. The ownership structure complicates accountability in a way that will matter if something goes wrong. A large share of hotels here are owned by local investors and groups, and operated under an international brand through a management or franchise agreement, with the reservation platform, the loyalty programme and often the property management system provided centrally by the brand. When a breach occurs in that architecture, the questions arrive immediately and the contracts frequently do not answer them: who is the controller for guest data, who notifies whom, who notifies the guest, who pays for the response, and who owns the relationship with the regulator. Hotel management agreements were drafted around revenue share and brand standards, not around data protection roles, and the ones being renegotiated this year are the first to treat it seriously. European reach is not hypothetical for this sector either. Assess a hotel's actual activities under Article 3 establishment, offering and monitoring tests, not travellers' nationality alone. Several regional operators are discovering that their breach notification obligation could run to a European supervisory authority before it runs to anyone local, and that Article 33 has a controller-specific notification duty without undue delay and, where feasible, within 72 hours of awareness, unless risk to individuals is unlikely. Processor escalation and communication to individuals differ. And there is a category of guest data here that deserves separate handling. Pilgrimage travel, medical tourism and government delegations generate guest records whose sensitivity goes well beyond the commercial. A booking history is a movement history, and for some travellers that is the part of the record that matters most.

The objection worth taking seriously

The objection is that nothing changes. Yahoo disclosed three billion accounts and is still in business under a new owner. Equifax lost identity data on most American adults last year, and the practical consequences were a management change and a survivable cost. Breach fatigue is real, consumers do not switch hotel brands over data, and the market reaction this week was a single-digit share price move. Treating each of these disclosures as an inflection point has been wrong every previous time. The harder version is more specific. Four years of undetected access in a high-volume reservation platform is not evidence of unusual negligence; it is close to the industry norm, and the organisations criticising Marriott this week would mostly not have detected it either. Detection at that timescale requires baselining normal data access across a system serving millions of legitimate queries, which is expensive, noisy and unglamorous, and almost nobody funds it before an incident. Blaming the victim here is cheap, and it lets everyone else avoid asking what their own dwell time would be. Both are fair. What defeats them is the change in who is watching. This is the first breach of this magnitude to be disclosed under a regime with turnover-based penalties, a statutory notification clock and supervisory authorities under visible pressure to demonstrate that the regime has teeth. The standard being applied will not be whether an attacker could get in, which they can, but whether the organisation could see a bulk export of a hundred million records leave, and whether its retention of passport data was justifiable at all. Those are questions with cheap answers available in advance, which is what makes them dangerous ones to have deferred.

Common Questions

Was the payment card data actually protected?

The disclosure changed over time. The January 2019 update reported no evidence of access to decryption components; the April 2024 update corrected the stated method for payment card and some passport numbers from AES-128 to SHA-1. Assess the actual protection and breach circumstances; neither an encryption label nor that correction automatically determines notification duties.

How should organisations handle notification when the facts are incomplete?

Notify on awareness with what you know, state clearly what is still being established, and provide updates in phases. The European regime explicitly contemplates information being provided in stages. The instinct to wait for certainty is the most common cause of late notification and the easiest failing for a regulator to establish after the fact.

What should a hotel or travel business do first?

Locate the identity documents, decide how long they need to be kept, delete what is past that, and put volume alerting on whatever remains. That sequence removes more risk per day of effort than any other work available in this sector.

What should we expect over the next twelve months?

Expect a long regulatory investigation with the United Kingdom's authority prominent, and expect the eventual outcome to be one of the defining early tests of how turnover-based penalties are applied to a security failure rather than a consent failure. Expect US state attorneys general and class action litigation to move faster than any regulator. Expect guest identity document retention to become a standard audit question across hospitality, and expect the brand-versus-owner accountability gap to be renegotiated in management agreements. And expect at least one more disclosure of comparable scale from an acquired legacy platform, because the conditions that produced this one are present in a great many integration programmes that are still running.


Data Protection Assessment — we find the identity documents you did not know you were keeping, set a retention position you can defend, and put alerting on the bulk export that nobody is currently watching for.

Continue reading

Talk to OPS

Start with the operating problem.