The day global shipping lost its digital memory: Maersk, NotPetya and operational accountability

Summary

• NotPetya entered Maersk through software used for Ukrainian tax filing and made applications and data unavailable across a globally connected environment. The company shut down additional systems as a precaution, while the malware's credential theft and multiple propagation methods made patching alone an incomplete defense.
• Maersk maintained control of its vessels, but its container businesses suffered significant interruption. Booking, terminal-gate and cargo-information functions failed; APM Terminals reported that gate services were still being expanded at several ports three days after the attack. Physical assets remained present while the digital authority to coordinate them disappeared.
• The company put extensive manual workarounds in place and rebuilt infrastructure at exceptional speed. Maersk's chair later described reinstalling 4,000 servers, 45,000 computers and 2,500 applications in ten days. A detailed journalistic reconstruction says a disconnected domain controller in Ghana supplied the identity data needed to restart core services; that account is important but is not an official forensic report.
• Maersk ultimately reported a USD 250-300 million effect on profitability, mostly from temporarily lost business in July and August, along with restoration and extraordinary operating costs. That figure measures the company's recognized impact, not the complete losses of truckers, freight forwarders, cargo owners, public agencies or small firms downstream.
• Accountability is layered. The Russian military actors later attributed and charged in connection with NotPetya bear responsibility for the destructive attack. Maersk remained responsible for the resilience of systems under its control, for the continuity claims made to customers, and for demonstrating that remediation addressed the paths by which one regional software dependency became a global operational failure.
• The durable lesson is not merely to keep backups. A critical operator must be able to recover identity, configuration, operational data and communications into a clean environment; run bounded manual processes without losing safety or cargo integrity; and give public bodies and smaller customers enough timely, portable information to activate their own continuity plans.

A global operator lost the ability to say what should move next

On Tuesday, June 27, 2017, A.P. Moller - Maersk was one of many organizations struck by malware that looked like ransomware but behaved as a destructive instrument. The immediate images were familiar from an office cyber incident: screens went dark, applications stopped, employees lost access. The consequence was not confined to offices. Maersk connected ocean carriage, port terminals and freight forwarding across jurisdictions and time zones. When shared applications and identity services became unavailable, the interruption reached the points where a truck enters a terminal, a booking becomes a cargo movement, and an electronic manifest tells an operator what is inside a vessel.

The company's Q2 2017 investor presentation supplies the firmest concise account. Maersk said the malware entered through software used to file tax in Ukraine, made applications and data unavailable, and mainly affected its container-related businesses: Maersk Line, APM Terminals and Damco. It said that several systems were shut down as a precaution, that many manual workarounds were introduced, and that full control of vessels was maintained. It also said there had been significant interruption affecting employees and customers, while reporting no third-party data breach or data loss.

Those statements establish an essential boundary. This was not publicly reported as a loss of navigation or propulsion, and an analysis should not turn a severe commercial and terminal interruption into a fictional vessel-control emergency. Yet the survival of vessel control did not mean the shipping service survived intact. A vessel can be safely navigable while the network around it cannot accept its next load, read the files needed to work its cargo, release containers to truckers, or provide reliable status to customers. Operational resilience has several layers, and the safe state of one layer does not confer continuity on the others.

The incident moved quickly from local software exposure to enterprise interruption. Microsoft's contemporaneous technical account of the Petya outbreak observed an initial supply-chain path through the M.E.Doc updater and described lateral movement using credential theft and impersonation as well as exploitation of the SMB vulnerability addressed by MS17-010. A later Microsoft network analysis characterized the propagation as sophisticated and well tested. The practical point is not that one missing patch explains Maersk. Public evidence does not support that neat conclusion. NotPetya could use more than one route, including legitimate credentials, so exposure depended on identity privilege, network reachability, segmentation, software trust and the speed of containment as well as vulnerability status.

By June 30, the operational picture was improving but still uneven. An APM Terminals update said it was expanding gate services at a list of ports that included Los Angeles. A public update of that kind is valuable because it exposes the actual unit of recovery: not “IT is back,” but a particular gate or terminal service in a particular place. Global restoration was a portfolio of local states. Some sites could work cargo, others could offer limited gates, and customer-facing systems recovered on their own timetable.

The company's later financial reporting confirms that this was more than a short technical inconvenience. Its Q3 2017 interim report placed the effect on profitability at USD 250-300 million, with the vast majority related to Maersk Line in the third quarter. It said transported volumes were down 2.5 percent from the comparable quarter and negatively affected by the attack, and described most of the financial impact as temporarily lost business in July and August. Working capital was also affected, while APM Terminals and Damco recorded attack-related effects.

That accounting period matters. The most visible outage unfolded over days, but commercial consequences persisted after applications began returning. Containers and schedules do not instantly return to their prior positions when a server starts. Bookings forgone during uncertainty are not restored by rebooting a portal. A customer that diverts cargo, a trucker that loses a turn, or a manufacturer that pays for another route creates a consequence that lives beyond technical restoration. Recovery time therefore has to be measured separately for infrastructure, applications, sites, transaction backlogs and customers.

The attack was destructive, not an ordinary ransom negotiation

Calling the event ransomware can obscure the decisions that defenders and executives faced. NotPetya displayed a payment demand, but its design and subsequent official attribution support treating it as destructive malware. The United Kingdom's 2018 attribution statement judged the Russian government, specifically the Russian military, responsible and said the attack masqueraded as a criminal enterprise while its principal purpose was disruption. In 2020, the United States Department of Justice charged six Russian GRU officers in connection with a campaign that included NotPetya. Those charges are accusations, not convictions, but they are a formal accountability action and the department explicitly described the malware as destructive.

This distinction changes recovery strategy. In an ordinary extortion scenario, leaders may still debate whether a decryptor exists, whether data was stolen and whether payment could alter the outcome. With a destructive event, preservation and clean reconstruction become central. Restoring an apparently functioning machine is not enough if privileged credentials, software distribution paths or trusted images may be compromised. The organization must establish a clean control plane from which it can rebuild, reset trust and decide which data is safe to reintroduce.

It also changes the fairness of the accountability analysis. Maersk did not choose to be attacked, and the entity that releases a destructive worm is responsible for the foreseeable and reckless damage it causes beyond an intended target. Victim accountability is not a substitute for attacker accountability. The two coexist because different actors controlled different parts of the causal chain. State actors controlled the decision to deploy destructive code. The software supplier controlled its update environment. Maersk controlled how a Ukrainian business dependency connected to its global estate, how privileged identity and network boundaries were protected, and how recoverable its critical services were.

The public record is not a complete forensic assessment of those controls. Maersk's filings identify the entry route and effects but do not publish a device-by-device propagation path, patch inventory, privilege graph or independent finding on which safeguards failed. Later reporting has supplied important detail, but an accountability argument should not fill the remaining gaps with confident guesses. It is fair to ask why one infected endpoint could contribute to enterprise-wide loss. It is not fair to assert, without the internal record, that a named employee, one unpatched machine or one product setting was the sole cause.

The better governance question is about failure domains. A multinational must sometimes run locally required software, including tax and customs tools that would never be selected as a global technology standard. Local necessity does not justify global trust. Systems with narrow regional purposes should be placed in an architecture that assumes their update channels can fail: restricted privileges, controlled egress, limited reachability, monitored execution, separate administrative credentials and rapid isolation. If the business cannot remove the exposure, it can reduce the authority that exposure has over everything else.

Physical capacity and digital authority were separated

Container logistics makes the difference between assets and authority unusually visible. Ships, cranes, containers, chassis, gates and warehouses are physical. Their efficient operation depends on digital records that answer basic but consequential questions: Which box is this? Is it cleared? Where should it go? Is it safe to lift? Which customer has authority to collect it? Which vessel and voyage should receive it? What hazardous, refrigerated or time-sensitive conditions apply?

A later WIRED reconstruction of NotPetya and Maersk's recovery reported that 17 of APM Terminals' 76 terminals were affected, that gates and some crane operations stopped, and that the central booking site was unavailable. It described terminals losing access to electronic files identifying vessel contents, truck queues at Elizabeth, New Jersey, and customers struggling to locate or reroute cargo. This is deeply reported narrative evidence based on interviews, not a regulator's forensic report. Its specific internal claims should be attributed accordingly, while its broad account is consistent with Maersk's disclosures of significant customer interruption and lost volumes.

The failure reveals why “the port stayed open” is an inadequate continuity measure. A landlord port authority, customs service, terminal operator, shipping line, rail operator and trucker can all be technically available while a cargo movement remains impossible. The transaction requires several permissions and records to agree. If one participant controls the authoritative cargo state and that state is unavailable, spare physical capacity elsewhere may not help.

Conversely, digital availability without trustworthy state can be dangerous. A terminal should not move a container merely because a crane can reach it. Manual handling has to preserve weight, dangerous-goods, customs, reefer, ownership and stowage constraints. The pressure to “keep freight moving” cannot override the information required for safe and lawful movement. A resilient manual mode is therefore not a blanket instruction to use paper. It is a deliberately restricted service with defined transactions, independently available reference data, dual checks, reconciliation identifiers and clear stop conditions.

Maersk reported that it introduced a large number of manual workarounds. The WIRED account describes personal email, messaging, spreadsheets and paper attached to containers. Such improvisation can be a rational bridge during an unprecedented emergency, and it speaks to employee ingenuity. It also creates integrity, privacy, authorization and reconciliation risks. A message received on an emergency account may be authentic, mistaken or malicious. A spreadsheet can preserve a booking but omit a hazardous-cargo field. A paper release can enable movement while creating duplicate or unbilled transactions later.

The accountability lesson is not to ban improvisation. It is to turn the best emergency practices into controlled capability before the next incident. A minimum viable terminal service should specify which cargo classes can move, what independent data must be present, who may approve an exception, how every manual action gets a unique record, how public authorities are contacted and how records will be reconciled once systems return. Capacity should be tested in trucks or containers per hour, not described only as “manual fallback available.”

The recovery depended on reconstructing trust

The most memorable part of the Maersk story concerns Active Directory. In the WIRED reconstruction, approximately 150 domain controllers had synchronized with one another and were wiped, while no separately usable backup of that identity layer could initially be found. One domain controller in Ghana had been disconnected during a power outage and survived. Limited bandwidth made remote transfer impractical, so employees reportedly relayed a drive through Nigeria to the recovery center in England.

This account has often been reduced to an anecdote about good luck. Its deeper significance is that identity was a prerequisite for everything above it. An enterprise can possess backups of application data and still be unable to restore operations if it cannot recreate trusted users, machines, permissions, service accounts and administrative authority. The identity system is not just another application. It is part of the machinery that declares which restored components are allowed to communicate and act.

The story also distinguishes replication from backup. Multiple synchronized domain controllers improve availability against ordinary hardware failure. They do not create independent recovery if destructive state can reach all replicas. Redundancy answers “can another live node serve?” Backup answers “can the organization return to a known-good prior state after all live nodes become untrustworthy?” A copy that shares the same administrative plane, connectivity and destructive path may be redundant but not recoverable.

Modern guidance makes that independence explicit. The UK's National Cyber Security Centre recommends offline or segregated backups, multiple copies, tested restoration and clean recovery. NIST's contingency-planning guidance treats recovery as a coordinated combination of plans, procedures and technical measures, including alternate equipment, manual processing and alternate locations. Neither document proves what Maersk had in 2017. They provide a disciplined way to evaluate what the event showed.

For a global logistics operator, the recoverable set has at least four parts. First is identity and the administrative control plane. Second is infrastructure configuration: network, security, cloud, endpoint and platform definitions that can be rebuilt without trusting the damaged estate. Third is operational state: bookings, manifests, container location, customs status, dangerous-goods attributes, equipment assignments and customer instructions. Fourth is the external relationship map: verified contacts and channels for ports, authorities, vendors, customers, banks and emergency partners.

Each part needs its own recovery-point and recovery-time objective. A three-day-old server backup may be acceptable for a static reference service and unacceptable for container events that change by the minute. A clean identity backup may restore access but not tell a terminal which transactions occurred manually during the outage. A customer contact list stored behind the failed identity provider may be complete yet useless. “Backups succeeded” is therefore a poor board metric. The useful evidence is whether representative services have been reconstructed from protected inputs inside a clean environment, at scale, within the period the operating network and its customers can tolerate.

Ten days was an achievement, not a complete resilience verdict

At the World Economic Forum in January 2018, Maersk chair Jim Hagemann Snabe described a remarkable effort: rebuilding 4,000 servers, 45,000 personal computers and 2,500 applications in ten days. The scale is widely cited because it captures the labor and urgency of the response. The later WIRED account says some recovery work continued much longer, which is compatible with a distinction between rebuilding the core estate and completing every application or user restoration.

Maersk's own 2017 annual report called the recovery fast and reported USD 250-300 million in losses covering revenue, IT restoration and extraordinary operating costs. It said immediate and long-term initiatives had been implemented or planned to secure the digital business, strengthen the infrastructure platform, enhance IT service continuity and recovery, and reinforce business continuity plans. The company also purchased cyber insurance.

That is a credible management response, but it does not make recovery speed a sufficient verdict on pre-incident resilience or post-incident assurance. Heroic recovery and designed resilience are different qualities. Heroic recovery draws on exceptional people, emergency purchasing, broad executive authority, vendor support and sustained effort. Designed resilience makes critical outcomes less dependent on exceptional conditions. It narrows the blast radius, preserves trusted recovery material, pre-arranges capacity, and provides practiced decisions before fatigue and uncertainty take hold.

The distinction matters for employee accountability. Praise for extraordinary work can quietly normalize an operating model that requires extraordinary work. Boards should ask how many people worked unsafe hours, which roles had no trained alternate, which recovery steps depended on personal knowledge, and whether emergency authority was documented after the fact. A resilience program should preserve the improvisational knowledge revealed by a crisis while reducing the need to repeat the physical and psychological burden.

It matters for financial accountability too. The USD 250-300 million estimate is not a global damage total. Maersk described what the attack cost its own profitability. It does not capture every uncompensated truck turn, warehouse booking, missed production slot, spoiled item, delayed public purchase or working-capital strain experienced by customers and service providers. The WIRED report cites truckers and logistics businesses who said they carried substantial losses, but no audited dataset supports adding those anecdotes into one economy-wide number.

Insurance similarly transfers only specified financial consequences. It does not restore a medicine shipment, preserve a small importer's customer, or give a port authority real-time cargo visibility. A board that reports insurance limits without reporting operational recovery evidence is measuring balance-sheet protection rather than service resilience. Both matter, but they are not substitutes.

Responsibility follows control, not proximity to the malware

The phrase “Maersk was a victim” is true and incomplete. So is “Maersk should have been prepared.” A useful allocation of accountability identifies the decisions each actor could make before, during and after the event.

Actor	Control before disruption	Duty during disruption	Evidence owed afterward
Malicious state actors	Decision whether to develop and release destructive malware	Stop harmful activity and avoid indiscriminate propagation	Criminal, diplomatic and state-accountability processes; preservation of evidence
Software supplier	Security of build, update and administrative environments	Rapid warning, isolation, indicators and cooperation	Independent incident findings and supply-chain remediation
Maersk group leadership	Risk appetite, investment, architecture, recovery objectives and executive incentives	Resource incident command, protect life and safety, communicate material service states	Causal account, customer impact, remediation ownership and verified resilience outcomes
Technology and business owners	Segmentation, identity, patching, backup, service mapping and manual procedures	Contain, preserve evidence, rebuild cleanly and maintain bounded operations	Test results for the actual failure paths and unresolved exceptions
Terminal and port partners	Local continuity, safe cargo rules, public-agency coordination and alternate channels	Control gates, queues, cargo safety and local status	Site-specific capacity, reconciliation and joint-exercise findings
Public authorities	Continuity requirements, priority-cargo policy, cross-operator coordination and public information	Maintain safety, customs and emergency decisions through independent channels	After-action findings, dependency remediation and proportionate oversight
Customers and logistics intermediaries	Critical-lane mapping, inventory, data exports, alternate contacts and contracts	Protect cargo, prioritize orders, document loss and communicate downstream	Updated continuity plans and tested provider-failure scenarios

This allocation avoids making the nearest administrator the moral center of a systemic event. If a local employee was required to use Ukrainian tax software, that person did not decide the global trust architecture. If a terminal employee used a personal channel to rescue a shipment, that action should be reviewed for risk and learned from, not isolated from the conditions that made it necessary. Senior accountability begins where authority over architecture, budget, risk acceptance and service promises sits.

It also avoids excusing downstream organizations. A public agency or small importer cannot redesign a carrier's identity system. It can decide whether its own continuity plan assumes that the carrier's portal, account team and terminal will all remain available together. It can keep shipment identifiers and essential documents outside the provider portal, agree emergency contacts, classify which goods justify alternate routing, and understand how long its inventory or service commitment can absorb a delay.

Accountability should remain proportionate. A small firm cannot economically maintain duplicate bookings on every lane or reserve air freight for ordinary cargo. A municipal buyer cannot command a global carrier's recovery sequence. The standard is not infinite redundancy. It is conscious selection of continuity measures based on consequence, time sensitivity, substitutability and available resources.

Ports make private failure a public continuity problem

Ports are institutional ecosystems. Public port authorities, customs and border agencies, police, health and agricultural inspectors, privately operated terminals, carriers, railways, truckers and freight forwarders share the same physical and informational space. A failure originating in one company's enterprise network can therefore create public tasks even when no government system is compromised.

The U.S. Government Accountability Office's 2025 review of maritime cybersecurity uses NotPetya as a prominent example, reporting that Maersk computers shut down, port operations including U.S. operations halted, and ships were left idle at sea. The report also found broader gaps in the Coast Guard's incident-list process, strategic planning and cyber workforce practices. The significance is institutional: the public sector cannot discharge maritime-security and continuity responsibilities solely by assuming each private operator has managed its own dependencies.

The international policy baseline was already moving when NotPetya struck. Ten days before the attack, the International Maritime Organization adopted Resolution MSC.428(98), encouraging cyber risk to be addressed in safety management systems by the first annual verification after January 1, 2021. The associated 2017 maritime cyber-risk guidelines organized action around identifying, protecting, detecting, responding and recovering, with senior management involvement and continuity of shipping operations.

Those instruments should not be misapplied. They are high-level maritime safety guidance, not a retrospective finding that Maersk violated a specific terminal-IT rule in June 2017. Their timing does show that cyber risk to shipping was not invented by NotPetya. The incident accelerated an accountability question the sector was already confronting: how to connect cyber governance to the safety and continuity systems that maritime leaders already understand.

Later guidance has become more operational. The European Union Agency for Cybersecurity's port cyber-risk guidelines map risk practices to port security processes and emphasize an adaptable assessment cycle. UN Trade and Development's port resilience guidebook treats carriers, customs, freight forwarders, cargo owners and inland logistics operators as collaborating stakeholders. It notes that containerized goods account for a much larger share of maritime trade by value than by volume and that ports can become single points of failure.

Public continuity planning should translate those principles into operational questions. Which minimum cargo data can customs and a terminal use if the carrier platform is unavailable? Can a port authenticate emergency instructions through a channel independent of the affected operator's identity system? Who manages truck queues when appointment and gate systems fail? How are refrigerated, dangerous, medical, food and public-service cargo prioritized without allowing self-declared priority to overwhelm the process? When will storage, demurrage or access rules be suspended, and who can announce that decision?

The correct answer is rarely a giant shared spreadsheet waiting for a disaster. A central fallback can become another common failure and a tempting source of sensitive trade data. Better continuity uses agreed minimum datasets, interoperable formats, protected local extracts, clear legal authority, tested communication paths and a federated way to reconcile events. The public sector's role is to convene and test the interfaces that no single company owns.

Port digitization makes this more urgent. The World Bank describes port community systems as collaborative platforms connecting customs, port management, carriers, logistics firms and freight forwarders. Such systems can reduce cost and improve resilience, especially for smaller participants, but their value increases the consequence of failure or bad integration. Efficiency architecture needs degradation architecture: an answer for what each participant can still see and do when the shared platform or one major contributor disappears.

Small firms absorb delay differently

The Maersk disruption reached small businesses in several roles: freight forwarders arranging shipments, trucking companies serving terminals, customs brokers, warehouse operators, exporters, importers and firms waiting for inputs. Some were direct customers; others were economically dependent on terminal throughput without a contract that promised compensation. Their continuity problem differed from Maersk's. They did not need to rebuild thousands of servers. They needed authoritative status, access to cargo, a credible alternative and enough cash to survive the wait.

Small firms are structurally exposed to logistics uncertainty. The OECD's work on SMEs and trade notes that smaller firms have fewer resources to meet cross-border costs and can be disproportionately affected by trade barriers, while trade facilitation and connectivity help support timely delivery. An outage that adds phone calls, storage, duplicate documentation, emergency transport and uncertain release dates therefore imposes more than a time delay. It adds fixed coordination costs that are harder to spread across volume.

Provider concentration has two meanings for an SME. There may be only one commercially sensible carrier or terminal for a lane, and several apparently separate services may depend on the same operator's digital control plane. Buying ocean carriage through a forwarder does not necessarily create an independent route if the booking, terminal and customer-status chain converges on the same carrier. Continuity mapping must follow the actual movement and information path, not the number of invoices or intermediaries.

The practical response begins with data custody. A small importer should retain booking references, bills and commercial documents, container and seal numbers, customs status, dangerous or refrigerated requirements, contacts and promised milestones in a place that does not require the carrier portal to open. This is not an attempt to duplicate the provider's operating database. It is the minimum package needed to identify the shipment, prove authority and ask another party for help.

Next comes triage. Firms should decide in advance which cargo can wait, which can use another sailing, which threatens production or a public commitment, and which might justify expensive air or road substitution. The answer should include a spending authority. During the Maersk event, scarce alternatives and uncertain information forced decisions under pressure. A pre-agreed threshold lets an operations lead act before a founder, finance officer or public client can be reached.

Communication needs the same independence as backup. The UK's National Cyber Security Centre offers a small-business response and recovery guide that emphasizes preparation, roles, contacts, resolution, reporting and learning. For a logistics dependency event, the contact sheet should extend beyond internal cyber responders. It should include the carrier's emergency route, terminal, forwarder, broker, warehouse, insurer, bank, critical customers and relevant public authority. A printed or independently stored copy matters when email or single sign-on is part of the failure.

Finally, the contract should say what operational fairness looks like. Notice channels, data access, fee waivers during inaccessible gates, cargo-preservation responsibilities, documentation for claims and escalation routes are more useful than a broad promise of high availability. Not every small customer can negotiate bespoke terms, which is why port authorities, regulators, trade associations and large logistics providers have a role in standardizing protections. The goal is not guaranteed compensation for every delay. It is a predictable process that does not force the least powerful party to prove an outage the operator already knows occurred.

General preparedness resources remain relevant. Ready Business combines communications, IT recovery, continuity plans, training and exercises rather than treating cyber recovery as an isolated technical plan. CISA's guidance to corporate leaders similarly says to focus resilience investment on critical business functions and test continuity after intrusion. For a small firm, the exercise can be modest: one hour in which the team assumes the carrier portal, account representative and primary terminal are unavailable, then attempts to locate two priority shipments and make a documented rerouting decision.

Manual continuity must have a design limit

Maersk's manual workarounds are rightly admired because they preserved much of the service while the digital estate was being rebuilt. They also show why manual continuity cannot be described as an unlimited substitute. Human throughput is lower, errors are harder to detect, and the records needed for later reconciliation multiply quickly. The longer the degraded mode lasts, the more its own backlog and control debt become a recovery problem.

A credible manual plan has a maximum scope and duration. It identifies the functions that must continue, those that can pause, and those that must not be attempted without systems. It allocates scarce capacity according to safety and consequence. It establishes how a transaction is authorized, logged and checked. It maintains a single incident clock and sequence even if local teams use different tools. It reserves people for reconciliation, because every temporary record will eventually have to meet the restored system.

The plan must also survive loss of ordinary workplace technology. Emergency forms stored on the same file share, contact lists behind the same identity provider, and conference bridges dependent on the same network are not continuity assets. NCSC technical-response guidance advises organizations to maintain clean backups, spare devices and usable logs; the broader principle is that responders need an independent minimum toolset. For a distributed logistics company, that may include clean laptops, separate communications, pre-approved external identities, protected configuration repositories and regional recovery kits.

Manual operations should be exercised with the parties who receive them. A terminal can produce a paper release, but it has no continuity value if gate staff, customs or a trucker cannot validate it. A carrier can accept a booking by emergency email, but the booking is unsafe if dangerous-goods declarations cannot follow. A public authority can create a priority list, but it will fail if there is no verified way to match that list to containers. Joint exercises discover these interface failures before an incident creates commercial pressure to overlook them.

Capacity metrics should be honest. “Terminals can operate manually” says little. A stronger statement is that a specified site can safely process a defined category of moves at a measured percentage of normal throughput for a certain number of hours, with a known reconciliation burden and clear exclusions. Publishing all details could create security or commercial risk, but boards and relevant authorities should see the evidence.

What a board should ask to see

After NotPetya, Maersk said it strengthened cyber resilience, infrastructure, service continuity, recovery and business continuity. Public reporting does not disclose enough detail to independently verify the current state of each measure, and absence of detail is not evidence that the work was not done. It does mean external readers should distinguish a declared program from tested outcomes.

The first board artifact should be a service map, not an asset count. It should begin with outcomes such as accepting a booking, admitting a truck, reading vessel cargo data, releasing a container, monitoring a reefer and communicating status. For each outcome it should identify identity, network, application, data, facility, vendor and public-agency dependencies. The map should expose when multiple outcomes share one administrative plane or local software trust path.

The second artifact should be destructive-recovery evidence. Can the organization build a clean identity environment without any live enterprise service? Are credentials, keys, device trust, configuration and privileged workstations restored in a controlled order? Are backups inaccessible to compromised administrators, retained long enough, scanned and tested? Has a representative terminal or booking service been rebuilt from protected inputs at operational scale?

The third should be degraded-operation evidence. Which services can run manually, at what capacity and with which safety controls? When does the firm stop accepting new work to protect cargo already in its custody? How will manual records be reconciled? Which communication channels remain if corporate identity and telephony are lost together? When was the plan last exercised with a port, customs actor, large customer and small logistics provider?

The fourth should be third-party consequence data. It should show not only corporate downtime but rejected gate moves, missed bookings, unlocated cargo, refrigerated exceptions, customer-status delays, fee disputes and claims. It should distinguish large customers with dedicated support from smaller customers and indirect operators. A recovery program that restores revenue while leaving customers unable to obtain authoritative status has not completed service recovery.

The fifth should be closure evidence. Every remediation should identify the observed failure path, owner, due date, test, exception and independent reviewer. Controls that reduce likelihood, such as patching and segmentation, should be separated from controls that reduce consequence, such as clean identity recovery and manual terminal modes. Cyber insurance should be reported as financial transfer, not technical remediation.

The sixth should be learning about people. Which decisions were delayed because authority was unclear? Which responders held unique knowledge? Which improvised tools proved useful, and which created unacceptable risk? How will the company preserve emergency competence without assuming hundreds of people can again sustain a round-the-clock rebuild? Operational resilience includes staffing, vendor mobilization, visas, travel, facilities, food, rest and succession, because a clean recovery design still has to be executed by humans.

Regulation is catching up to the operating reality

Maritime cyber governance has become more concrete since 2017. In the United States, the Coast Guard's Cybersecurity in the Marine Transportation System rule took effect on July 16, 2025. It requires covered U.S.-flagged vessels and facilities to report incidents and phases in training, a designated cybersecurity officer, assessment and an approved cybersecurity plan. The rule does not make a repeat of NotPetya impossible. It creates named ownership and auditable planning where reliance on voluntary maturity was no longer considered sufficient.

The GAO's 2025 findings are a reminder that regulation also needs operational capacity. Requirements work only if the authority can understand incidents, maintain a reliable evidence base, coordinate locally and test whether plans address real dependencies. Port cyber resilience is not achieved when each entity separately submits a document. It emerges when plans connect at the shared interfaces where cargo, safety information and public authority cross organizations.

Regulators should also preserve proportionality. A global carrier and a small customs broker cannot carry identical control burdens. Large operators can reasonably be expected to produce independent recovery evidence, maintain clean-room capability and support joint exercises. Small firms need baseline security, usable continuity plans and access to common channels. Public bodies can lower collective cost by defining minimum datasets, common incident terminology, model fee policies and exercise formats.

Transparency has to be calibrated as well. Publishing a complete network or identity architecture would create new risk. Publishing only that “systems are restored” creates too little accountability. Useful disclosure includes affected services and locations, time-bounded recovery states, customer actions, whether cargo safety or data integrity is in question, the categories of root cause and control failure, and how remediation will be independently assured. Specific sensitive details can remain with regulators or auditors.

The final measure is whether dependence became governable

Maersk's response in 2017 demonstrated formidable recovery capacity. Employees maintained vessel control, improvised service channels and reconstructed a vast technology estate under extreme conditions. The company absorbed a large financial impact and subsequently reported investment in cyber resilience and continuity. Those facts deserve weight.

They do not erase the central accountability signal. One locally required software relationship acquired enough practical reach to help interrupt container operations around the world. Replicated identity infrastructure did not necessarily provide independent recoverability. Customers and terminal partners lost not only access to a website but the information needed to coordinate physical commerce. Smaller operators and public institutions had to manage consequences outside Maersk's reported loss.

Operational resilience is often described as the ability to bounce back. The phrase is too passive for infrastructure on which others depend. A critical operator must decide in advance what it will preserve, what it can safely do without its main systems, whose needs will be prioritized, how truth will be communicated and what evidence will prove recovery. Its customers and public partners must decide what they will do when the operator itself is the unavailable dependency.

The enduring value of the Maersk case is therefore not the spectacle of 45,000 computers being reinstalled. It is the exposure of a hidden hierarchy. Identity had to return before applications could trust one another. Cargo data had to return before physical capacity could be used safely. Authoritative status had to return before customers could make rational choices. Reconciliation had to continue after systems were nominally available. Every layer had a different clock.

A mature accountability regime follows those clocks. It does not declare victory at the first restored server, or assign blame to the first infected office, or ask small customers to infer continuity from a corporate financial estimate. It asks whether destructive authority has been bounded, whether recovery trust exists outside the failure domain, whether manual service is safe and measurable, whether public and SME dependencies are visible, and whether remediation has been tested by someone able to challenge it.

NotPetya was an act of destructive aggression. Maersk's duty was not to make such aggression impossible. It was, and remains, to make the company's dependence on digital trust governable: limited before failure, survivable during failure, reconstructable after failure, and legible to the institutions and businesses that have to keep operating when global shipping loses its memory.