Cloud, cybersecurity and digital risk

In late April 2025, Marks and Spencer, one of Britain's best-known retailers, stopped taking online orders after a cyberattack. Customers could still shop in its stores, but contactless payments and click-and-collect services were disrupted for days, some store shelves ran short because stock systems were affected, and online ordering stayed suspended for 46 days. The company later estimated that the incident would reduce its operating profit for the year by about 300 million pounds before insurance and other mitigations. Reports indicated that the attackers had gained access by tricking staff at a third-party help desk into resetting credentials, rather than by exploiting some exotic technical flaw. Within weeks, other British retailers reported attacks of their own.

Dr. Marchetti shows the case at the start of the eighth session because it captures three points that every executive needs to understand. Digital operations are now the business: when the systems stop, the stores, warehouses and website stop with them. Most serious attacks exploit ordinary weaknesses in identity, process and third parties rather than brilliant hacking. And the cost of an incident lies mainly in disruption and lost sales, not in the technical recovery. This lesson covers the management decisions behind cloud computing and cybersecurity: how to choose where systems run, how to think about the economics, how to organize defense and how boards should oversee digital risk. It stays at the level of management and governance; the technical work belongs to specialists.

Cloud computing and its models

Cloud computing means renting computing resources, such as servers, storage, databases and software, over the internet from a provider who runs them in large data centers, rather than owning and operating them in-house. Three service models are usually distinguished. Infrastructure as a service provides basic computing, storage and networking that the customer configures and manages, as with virtual servers from the largest providers. Platform as a service provides managed tools, such as databases, analytics engines and application platforms, so that the customer manages only its applications and data. Software as a service provides complete applications, such as email, human resources, customer relationship management and e-commerce systems, used through a browser and run entirely by the vendor.

The appeal is partly financial and partly about speed. A firm avoids buying hardware for peak loads it rarely reaches, scales up quickly when demand rises, as an online retailer must around holiday sales, and gains access to services, such as machine learning platforms, that would be costly to build. Software as a service also shifts upgrades and much of the security work to the vendor. The costs are real too. Cloud bills can grow quickly and unpredictably if usage is not managed, and many firms have created practices called FinOps, short for financial operations, to make engineering teams responsible for cloud spending. Moving data out of a provider can be expensive, and dependence on a provider's proprietary services creates lock-in. A few firms with very large, stable workloads have moved some systems back from the public cloud to their own facilities to save money.

Cedarline must decide where to run the order and inventory system that will support its single view of inventory. Its current system runs on servers in a rented room near the main warehouse and is due for a hardware refresh. The cohort compares three options over five years: refresh and keep running it on premises, move it to cloud infrastructure, or replace it with a software-as-a-service product from a retail systems vendor.

# 1. Five-year cost of running Cedarline's order and inventory system (thousands of dollars)
years = 5; rate = 0.09
def pv(flows): return sum(f / (1 + rate) ** t for t, f in enumerate(flows))
on_premises = [1_400] + [310 + 260 + 180] * (years - 1)   # hardware refresh now; support, staff and server room space
on_premises[3] += 450                                      # storage expansion in year 3
cloud = [600] + [520 + 160] * (years - 1)                  # migration now; subscription and cloud operations staff
saas = [350] + [790] * (years - 1)                         # vendor-run software: configuration now, fees after
for name, flows in (("on premises", on_premises), ("cloud hosting", cloud), ("software as a service", saas)):
    print(f"{name:22s} total {sum(flows):6,.0f}  present value {pv(flows):6,.0f}")

# 2. Expected annual loss from ransomware, before and after a security program
incident_cost = 9_500          # recovery, lost sales during an outage, response, notification
likelihood_now = 0.12          # chance of a disruptive incident in a year
controls = {"multi-factor sign-in everywhere": 0.45, "tested offline backups": 0.30,
            "endpoint detection and response": 0.35, "staff phishing training": 0.15}
likelihood = likelihood_now
for name, cut in controls.items():
    likelihood *= (1 - cut)                               # assume each control cuts the remaining risk
impact_after = incident_cost * 0.55                        # faster recovery from tested backups and a rehearsed plan
ale_before, ale_after = likelihood_now * incident_cost, likelihood * impact_after
program_cost = 620
print(f"expected annual loss before {ale_before:,.0f}, after {ale_after:,.0f}; reduction {ale_before - ale_after:,.0f} vs program cost {program_cost}")

on premises            total  4,850  present value  4,177
cloud hosting          total  3,320  present value  2,803
software as a service  total  3,510  present value  2,909
expected annual loss before 1,140, after 133; reduction 1,007 vs program cost 620

On these estimates, keeping the system on premises costs about 4.2 million dollars in present value over five years, against about 2.8 million for cloud hosting and 2.9 million for software as a service. The two cloud options are close, and the choice between them turns on things the numbers do not capture. Software as a service would give Cedarline a modern system with regular upgrades and built-in features for ship-from-store and pickup, but would limit customization and make Cedarline dependent on the vendor's roadmap. Hosting its existing system in the cloud would preserve its customizations but would not fix the system's age or its overnight stock updates. The cohort recommends evaluating retail software vendors seriously, because the strategy needs capabilities the old system lacks, and because Cedarline's advantage does not lie in running inventory software.

The shared responsibility model

Moving to the cloud does not move all responsibility for security to the provider. Cloud providers describe a shared responsibility model. The provider secures the physical data centers, hardware and the underlying infrastructure. The customer remains responsible for what it puts on that infrastructure: its data, who can access it, how its applications and accounts are configured and how users sign in. With software as a service, the vendor takes on more of the stack, but the customer is still responsible for its data, its users' access and the configuration of the service. Many cloud breaches result not from provider failures but from customer mistakes, such as storage left open to the internet or accounts protected only by passwords.

Data location raises legal questions as well. Some organizations must keep certain data in particular countries, and others choose to, out of concern about foreign governments' access. Large providers now offer regions in many countries, including several in Canada and the United States, and contractual commitments about where data are stored. A firm should know where its data live, which laws apply, what its contracts say about access requests and how it would move its systems if it had to.

The cyber threat in management terms

Executives do not need to understand malware in detail, but they do need to understand the main ways organizations are harmed. Ransomware attacks encrypt or steal an organization's data and demand payment; in recent years attackers have increasingly combined encryption with threats to publish stolen data. Phishing and social engineering trick people into revealing credentials, approving sign-in requests or making payments; business email compromise, in which attackers impersonate executives or suppliers to redirect payments, causes large losses at modest technical effort. Third-party and supply chain attacks reach a firm through a vendor, a software update or a service provider, as in the Marks and Spencer case. And insider threats, both malicious and careless, account for a meaningful share of incidents.

For a retailer, the most serious risks are an outage of stores, warehouses or online sales, theft of customer and payment data, and fraud. For a hospital, they include disruption of care, as several hospital ransomware incidents have shown. For a manufacturer like Northfield or an energy company like Prairie Ridge, they include attacks on operational technology, the systems that control machines and industrial processes, where the consequences can be physical. Owen Tremblay notes that Prairie Ridge keeps its control systems separated from its business network, monitors the connections between them closely and has run exercises in which its plants operate manually for several days.

Building a defense: frameworks and controls

The NIST Cybersecurity Framework, first published in 2014 and revised as version 2.0 in February 2024, is the most widely used structure for organizing a security program. Version 2.0 added a govern function to the original five, giving six: govern, which sets strategy, roles, policy and oversight; identify, which understands assets, risks and suppliers; protect, which puts safeguards in place; detect, which finds attacks quickly; respond, which contains and manages incidents; and recover, which restores operations. The framework's value for managers is that it frames security as a continuing management process rather than a product to buy.

A small number of controls prevent or limit most serious incidents, and Dr. Marchetti lists those she would insist on at Cedarline. Multi-factor sign-in for all staff and especially for administrators and remote access, preferably using methods that resist phishing; strict procedures for resetting credentials, including at outsourced help desks; backups of critical systems that are kept offline or immutable and are regularly tested by restoring them; endpoint detection and response software on computers and servers, monitored around the clock by the firm or a provider; prompt patching of internet-facing systems; least-privilege access, so that each account can do only what it needs; segmentation of networks so that an intruder cannot move freely; and security requirements and reviews for key suppliers. The newer principle of zero trust captures the spirit of many of these: no user or device is trusted automatically because it is inside the network, and every access is verified.

Because security spending competes with other investments, it helps to estimate its value. A common approach is annualized loss expectancy: the probability of an incident in a year times its expected cost. The second part of the code estimates Cedarline's exposure to a disruptive ransomware incident. At a 12 percent annual chance and an expected cost of 9.5 million dollars, mostly lost sales during an outage, the expected annual loss is about 1.1 million dollars. A program of the four controls listed, assuming each cuts the remaining likelihood by the stated share and that tested backups and a rehearsed plan cut the impact of any incident that does occur by 45 percent, reduces the expected loss to about 133,000 dollars, a reduction of about one million dollars a year for a program costing 620,000. The inputs are uncertain, and the multiplication assumes the controls work independently, which overstates the combined effect somewhat. But the calculation makes the trade-off visible, and it shows that the largest benefit often comes from reducing the impact through recovery rather than only the likelihood.

Incident response and recovery

Every organization will have incidents, so preparation for them matters as much as prevention. An incident response plan sets out who decides what, how to contain an attack, when to involve outside specialists, law enforcement and insurers, how to communicate with customers, staff and regulators, and how to keep operating manually. The plan is useful only if it has been rehearsed. Tabletop exercises, in which executives work through a realistic scenario, regularly expose gaps: nobody knows who can authorize shutting down the website, the backup systems turn out to depend on the same credentials as the main systems, or the contact list for the insurer is out of date.

Regulatory obligations shape the response. Every US state has a data breach notification law, with differing definitions, timelines and requirements to notify state attorneys general. Since December 2023, public companies have had to disclose a material cybersecurity incident on a Form 8-K within four business days of determining that it is material, and to describe their cybersecurity risk management and governance in their annual reports under rules adopted by the Securities and Exchange Commission. Sector rules apply in health care, financial services and critical infrastructure. Cyber insurance can cover response costs and some losses, but insurers increasingly require controls such as multi-factor sign-in and tested backups before they will offer cover.

Board oversight of digital risk

Boards cannot manage security, but they must oversee it. Dr. Marchetti suggests that a board ask management a few questions at least once a year. What are our most important digital assets and services, and what would an outage of each cost us per day? What are the top risks, and how have they changed? How do we compare with a recognized framework, and what is the plan to close the gaps? Which suppliers could cause us serious harm, and how do we oversee them? When did we last test our backups by restoring them and rehearse our response to a major incident, and what did we learn? And who is accountable? Boards should expect the answers in business terms, such as days of disruption and dollars at risk, rather than counts of blocked attacks, which say little about whether the firm is safe.

Digital risk is broader than cyberattacks. It includes outages caused by faulty software updates, as in July 2024, when a defective update from the security company CrowdStrike crashed millions of Windows computers worldwide and disrupted airlines, hospitals and banks for days; dependence on a few large cloud and software providers; failures of AI systems; and the loss of key technical staff. A resilient organization identifies its critical services, understands which systems and suppliers each depends on, sets a tolerance for how long each can be disrupted and tests whether it can stay within it.