Adam Banks

FACT Banks was Chief Technology and Information Officer of A.P. Møller-Maersk when NotPetya reached the company in late June 2017 [1]. In his account roughly 55,000 devices were infected within seven minutes, about 49,000 laptops lost, 1,200 critical applications made inaccessible and 147 Active Directory instances thought destroyed [1]. The mandate was not to investigate an intrusion but to reconstitute a global company's IT estate from nothing while ships and terminals kept running.

1. Shut down globally — a company-wide shutdown that took roughly seven hours on day one [1].
2. Rebuild rather than restore. After Microsoft confirmed on day two that decryption was not viable: "If you've been hit to the extent that we had, which was 99% infection, why would you restore the thing that had just been destroyed?" [1].
3. Change the crisis model to fit the failure — abandoning Maersk's asset-centric crisis management for "a financial services crisis management model, because financial services normally only ever have global crises" [2].
4. Buy forensics, design the build, and commit to transparency in parallel. Days one to three: Deloitte engaged for forensics; a new Windows build designed before there was anything to install it on; transparency chosen internally and externally [2].
5. Recover identity first. An undamaged Active Directory copy survived in an office that was offline during the attack because of a local power cut, and became the foundation for rebuilding the global network [1].
6. Sequence: identity → build → applications → devices. About 2,000 laptops built on days four to nine; basic business technology restored by day fourteen; full operations at weeks four to six [1][2].
7. Stay on site for 70 days directing recovery [1][2].

Company-reported. Chairman Jim Hagemann Snabe, at Davos in January 2018: "We had to install 4,000 new servers, 45,000 new PCs, 2,500 applications. And that was done in a heroic effort over ten days" [3]. "Ten days" is the figure that travels.

Company-reported. Maersk's August 2017 statement put the expected impact at "USD 200-300m" [4]; it is commonly cited as $250–300 million. Speaker-reported. Banks later put the total near $350 million, including about $30 million of recovery cost [1]. Every count above is likewise from his 2019 conference accounts [1][2].

• The numbers drift between retellings — 45,000 PCs (Snabe) versus 49,000 laptops lost (Banks); 2,500 applications versus 1,200 critical ones. And "ten days" depends on the finish line: Snabe's ten, Banks's fourteen to basic business technology, four to six weeks to full operations. Cite the speaker with the number, and define the finish line before quoting a duration.
• Where the surviving domain controller was. Lagos, Nigeria in [1]; other widely circulated accounts say Ghana. The drift is the caution.
• No independent record. There is no public post-incident review; the account is the responder's own, and a rebuild at this scale involved thousands of people plus Deloitte and Microsoft. No source apportions decisions to an individual.

INTERPRETATION Four design lessons, all upstream of the crisis.

Recovery objectives are written for the wrong asset. Most RTO/RPO tables cover applications. Here the binding constraint was identity: nothing could be rebuilt until a clean Active Directory existed. Ask your recovery time for identity, DNS and the build pipeline before the ERP.

The control that saved Maersk was an accident, and build capability is a recovery asset. A power cut produced the offline copy; the deliberate equivalent — an immutable, isolated copy of identity with a tested restore — is cheap and almost never rehearsed. Likewise, a Windows build had to be designed before anything could be rebuilt: a current gold image and automated provisioning are recovery infrastructure, not housekeeping. HYPOTHESIS Most mid-market firms would find neither has been exercised end-to-end.

Match the crisis model to the failure, and plan for endurance. An asset-centric model assumes bounded loss; a simultaneous global loss needs a different structure, swapped in mid-event. Seventy days on site is a staffing plan nobody wrote — rotation and relief belong in the runbook.

Trait Dial (INTERPRETATION — from the decisions). Decisiveness↔inquiry −2; urgency↔patience −3; centralization↔decentralization −3 during the event; hands-on↔delegation −2. Prevention↔Resilience swings hard to resilience — none of these decisions would have stopped the wiper. Maturity Model: a Capability case, incident command at scale, with one Maturity artifact: the statement that the company was "not unusually weak" when hit [2].

Two-Sentence Test and Risk Corollary. "We're going to do this" is the day-two rebuild call, made against sunk backups. And if ordinary controls do not stop a state-grade wiper, the board conversation moves from prevention spend to priced recovery capability.

1. State your recovery time objective for identity — not applications — and the last date you tested a full restore from an isolated copy.
2. At what infection percentage do you stop restoring and start rebuilding? Write the threshold and who may call it, before you need it.
3. If "not unusually weak" is true of you too, how should that change next year's prevention/recovery split — and how would you argue it to a board that funds prevention because it is legible?