UCSF’s ransom decision was shaped long before the attack

The week

On June 1, 2020, the University of California, San Francisco, one of the country’s leading academic medical centers, detected a security incident in a limited part of the IT environment of its School of Medicine. It disclosed the incident publicly on June 3. It was a ransomware attack.

Ransomware is criminal software that scrambles an organization’s files so they cannot be opened. The scrambling is called encryption: the same mathematics that protects your online banking, turned against you. Only the attackers hold the key that unscrambles the files, and they offer to sell it. It is like a burglar who leaves your filing cabinets where they are, fits them all with new locks and leaves a note with a price for the keys.

In UCSF’s case the attackers did two things. They encrypted a limited number of School of Medicine servers, and they obtained data, meaning they copied files out before locking them up. UCSF later described that data as taken “as proof of their action,” to support the ransom demand. Press reports attributed the attack to the NetWalker ransomware group, though UCSF did not name the malware.

What UCSF said, and when

The university was careful about the scope. It said it had quarantined several School of Medicine systems and isolated the incident from the core UCSF network. It said the incident did not affect patient care delivery, its overall campus network or its COVID-19 research. That mattered a great deal: the attack came in the middle of the pandemic, and a hospital system that could not treat patients or a research program that stalled would have been a very different story.

In an update dated June 26, the university said it had paid approximately $1.14 million, which it described as a portion of the amount demanded, in exchange for a tool to unlock the encrypted data and the return of the data the attackers had obtained. It explained that the encrypted data was important to academic work it pursued in the public interest. It said it did not currently believe patient medical records had been exposed. It described the attack as opportunistic, with no particular area targeted, and said it was cooperating with law enforcement and working with outside cybersecurity experts.

The negotiation, as reported

Press reports later described the negotiation with the attackers in some detail. At the end of June the BBC published screenshots of what it said was the chat between the two sides. According to that reporting, the attackers opened at $3 million. The university’s side countered at $780,000, citing the financial damage the pandemic had done to the institution. The two sides settled at 116.4 bitcoin, roughly $1.14 million. UCSF cautioned that the published exchanges should not be assumed accurate.

That alone was striking for a non-specialist audience. It showed that ransom amounts are haggled over, much like any other commercial deal, even when the counterparty is a criminal group. It also showed that attackers research their victims’ finances and price their demands accordingly.

Part of a wider wave

UCSF was not an isolated target. In the same few weeks, reports attributed NetWalker attacks to Michigan State University, hit around the Memorial Day weekend, and Columbia College Chicago, hit in early June. Michigan State said publicly that it would not pay. NetWalker listed victims on a site it ran on the dark web, with samples of stolen files and a deadline, to pressure them into paying.

NetWalker worked as what the security industry calls ransomware-as-a-service. A core group maintained the encryption software, the payment process and the leak site. “Affiliates” broke into victims and deployed it, and the two sides split the proceeds. The model let the group run many attacks at once against many sectors.

A few weeks later, on July 28, the FBI issued a flash alert on NetWalker. It reported attacks on government bodies and on healthcare and education organizations. It said the group had used COVID-19-themed phishing emails and, from April 2020, had also gained entry through unpatched virtual private network (VPN) appliances, weak web application components and weak passwords on Remote Desktop connections. Those were precisely the remote-access routes that universities and hospitals had widened in a hurry that spring, when staff and students were sent home.

The headline was the payment. The more useful story for leaders is what had already been decided, long before June 1, that shaped the options in front of UCSF that week.

A ransom decision looks like a single choice made in a crisis. Most of its inputs, though, were fixed months or years before, by what the organization bought, contracted for and tested. Four inputs matter most. The first is how quickly the organization can recover without the attacker’s key. The second is how much harmful data the attacker could publish. The third is who pays for the response, and on what terms. The fourth is whether the legal and reporting process is ready.

Each was visible in the UCSF case. The encrypted servers held academic work that was hard to recreate, the attackers threatened publication, the amount was negotiated, and the payment had to be lawful. Health systems and academic medical centers face the same four. So, for that matter, do banks, insurers, city governments and school districts.

The analysis below runs in three steps. It first describes how an attack of this kind unfolds, because each input only makes sense against that sequence. It then takes the four inputs in turn: recoverability, data exposure, financing and legal readiness. Finally, it turns them into governance: why the decision belongs above the IT department, the habits of organizations that handle it well, and the questions a board can ask before any ransom note arrives.

What a ransomware attack actually looks like

The sequence is usually similar. An attacker first gets a foothold, often through a stolen password, a phishing email that tricks someone into running malicious software, or an internet-facing system that was not patched. From there, they move unnoticed from computer to computer, looking for valuable data and for the backups the organization would use to recover. This can take days or weeks.

When they are ready, they do two things. They copy data out, and then they trigger the encryption, often at night or on a weekend when fewer staff are watching. Staff arrive to find files they cannot open and a ransom note explaining how to pay, usually in cryptocurrency, and how to contact the attackers.

The note typically carries two threats. Pay, and you get a decryptor, a piece of software that unlocks the files. Pay, and the attackers promise not to publish the data they stole. Security people call this “double extortion.” It means that even an organization with perfect backups still faces the second threat.

The business model behind the note

By 2020 the largest ransomware operations ran like franchises. A core group wrote and maintained the encryption software, ran the payment and negotiation portal, and hosted the leak site. Affiliates, often several independent crews, did the breaking in. Each side took a share of every payment. NetWalker was described in exactly these terms by researchers and, later, by prosecutors.

The franchise model has consequences for defenders. The people inside your network are not necessarily the people who wrote the malware, so their skill and patience vary. The negotiation is often run by the core group, which wants a reputation for honoring deals, because that reputation drives future payments. The leak site is a marketing tool aimed at the next victim as much as the current one. And because affiliates can move between programs, disrupting one brand does not remove the people who carry out the intrusions.

How the foothold is usually gained

The FBI’s July 2020 alert on NetWalker listed the entry routes that defenders saw most often that year. Phishing emails with malicious attachments, some of them dressed up as COVID-19 information. Virtual private network appliances that had not been patched against known flaws. Remote Desktop services exposed to the internet and protected only by weak passwords. Each one maps to a specific control: email filtering and attachment controls, a patching deadline for internet-facing devices measured in days, and multi-factor authentication on every remote-access route.

The spring of 2020 made all three worse. Universities and hospitals had expanded remote access in days, not months, so that staff and students could work from home. Some of that access was stood up by departments rather than central IT. Some of it bypassed the usual review. Attackers who scanned the internet for exposed services found more of them than a year earlier.

Why academic medicine is a rich target

An academic medical center is a particularly rich target. It holds patient records, which are sensitive and regulated. It holds unpublished research, which may represent years of work and millions in grant funding. It is also unusually decentralized: individual departments and research groups often run their own computers, set up for their own needs. That decentralization is a strength for science and a weakness for security.

There is a further complication. An academic medical center is several legal entities and regulatory regimes at once. The hospital is a HIPAA covered entity. Many universities designate themselves “hybrid entities” under HIPAA, so that only their health care components are covered and research or teaching units fall outside. Research data may instead be governed by data use agreements, institutional review board protocols, sponsor contracts and, for some defense-funded work, federal contract clauses. Student records fall under FERPA. A single encrypted server can touch several of these at once, and each has its own owner and its own obligations.

Recoverability: the cost of restoring without the key

The most important factor is whether the organization can restore without the attacker’s decryptor, and how long that would take. That depends on backups attackers cannot reach or delete, recovery procedures tested at realistic scale, and a clear view of which systems matter most. Departmental and research servers are often outside central backup programs. A department sets them up for its own needs, funds them from its own budget and runs them with its own staff.

Recoverability is bought in advance. Immutable or offline backups, periodic full-restore tests and an inventory that includes departmental systems are the core purchases. An “immutable” backup is one that cannot be changed or deleted for a set period, even by someone with administrator passwords. An “offline” backup is physically or logically disconnected from the network. Either way, the aim is that an attacker who has taken over your systems cannot destroy your way back.

Backup spending should be weighed against weeks of lost research, grant deadlines missed and the pressure to pay that follows, rather than against a ransom amount. A restore test that measures hours to recover a representative research server gives leaders a number they can use in a crisis. Without that number, leaders in the middle of an attack are guessing at their own recovery time while the attackers set a deadline.

What attackers do to backups first

Experienced ransomware crews look for backups before they encrypt anything. The steps are predictable. They delete the local snapshots that Windows keeps of recent file versions. They look for the backup software’s management console and try the administrator credentials they have already stolen. They target backup servers joined to the same directory as everything else, because one compromised domain administrator account then opens them too. Where backups are written to network storage, they encrypt that storage along with the servers.

Each step has a matching design choice. Backup administration should use separate accounts, ideally in a separate identity domain, with their own multi-factor authentication. At least one copy should be immutable or offline, so that even a full administrator cannot delete it inside the retention window. Retention should be long enough to reach back past the likely dwell time, so that the restore point predates the attacker’s arrival. And backup alerts, such as a sudden mass deletion, should go to a monitored queue rather than an unread mailbox.

Recovery order and realistic timelines

Restoring files is the last step, not the first. Before any server can be safely restored, the organization needs a trusted identity system, usually Active Directory, because every other system depends on it for logins. If the attacker controlled the directory, it may need to be rebuilt from a known-good state. Then come the network, the security tools, the core clinical and business systems and, finally, departmental servers.

Two numbers drive the plan. The recovery time objective is how long a system can be down before the harm becomes unacceptable. The recovery point objective is how much recent data the organization can afford to lose. A research server with weekly backups has a recovery point of up to a week, whatever its owners assume. Writing both numbers down for each important system, and comparing them with what the last restore test achieved, shows exactly where the gap is.

Even good backups do not make recovery fast. Forensic teams usually want to preserve evidence before systems are wiped. Every restored server has to be checked for the attacker’s tools, or the organization risks reinfection. That is why some victims with usable backups still paid: the decryptor promised a shorter path, even if it often proved slow and buggy itself. A recovery plan should assume weeks for a large environment and say which services will run on manual workarounds in the meantime.

Two labs, one attack

Suppose a university has a genetics lab that runs its own server. The lab backs it up to a drive plugged into the same network. When ransomware strikes, the backup drive is encrypted along with everything else. A second lab at the same university uses the central backup service, with copies that cannot be altered for thirty days, and IT restored a sample server in a test last spring in eleven hours. When both labs are hit, the second lab’s leaders have a real choice. The first lab’s leaders have no usable backup and a grant deadline approaching.

Central IT cannot impose this on departments overnight. A workable model offers departments a funded central backup service, sets a minimum standard for any server holding sensitive or irreplaceable data, and gives the chief information security officer authority to enforce it. Exceptions should be recorded and approved by the dean or department chair who owns the risk. That last step matters: it moves the decision from a technical footnote to a named leader’s signature.

How recoverability differs by institution

The same principle plays out differently by type of organization. A large academic medical center has scale and central staff but a long tail of departmental systems. Its hardest problem is coverage. A community hospital usually has fewer systems, mostly run by a vendor or a small central team. Its hardest problem is depth: one or two people may hold all the knowledge of how to rebuild the electronic health record environment. An ambulatory network or physician group often depends on hosted systems. Its recoverability rests largely on its vendors’ contracts and their own backup practices, which it should ask to see evidence of.

Outside health care the pattern holds. A regional bank’s core banking platform is often hosted by a processor, so its recovery question is partly contractual. A county government may run its own systems on thin staffing, with backups on the same network as everything else. The question in each case is identical: how many hours to restore what matters, without the attacker’s help, and when was that last proven.

Data exposure: the cost of publication

By 2020, many ransomware groups combined encryption with data theft and threatened to publish what they took. Good backups do not remove that pressure. An organization might still face release of unpublished research, personnel files or patient information. Paying for deletion gives no reliable assurance, because the victim cannot verify that data was destroyed or that no copies remain. You are, in effect, taking a criminal’s word for it.

Incident responders said so publicly within months. In its report on the third quarter of 2020, the response firm Coveware said trust in data deletion was eroding. It named several groups, NetWalker among them, that had published data or demanded a second payment after a victim paid to suppress it. The decryptor can be tested; the promise to delete cannot.

Where the data lives

The advance decision here is data placement. Knowing where sensitive data is stored, limiting copies and restricting what any single environment can reach all reduce what an attacker can take. Research groups that keep identifiable patient data on departmental servers create exactly the exposure that makes extortion effective. “Identifiable” means the data can be linked to a real person, by name, medical record number or other details.

Moving such data to managed research environments, with access logging, cuts both the likelihood and the impact. A managed research environment is a centrally run, secured computing space where researchers can work with sensitive data without taking copies onto their own machines. Access logging records who opened what and when, which helps both to deter misuse and to establish quickly what an attacker could have reached.

The trade-off is real. Researchers value control over their own computing, and a managed environment can be slower to set up, more restrictive about software and less flexible for large data transfers. A program that ignores those costs will be routed around. The ones that work tend to offer something researchers want, such as faster provisioning, shared storage or help with data use agreement compliance, in exchange for the controls.

Seeing data leave

Large-scale theft takes time and bandwidth. Attackers commonly compress files and send them to cloud storage services or their own servers before triggering encryption. Monitoring outbound traffic for unusual volumes, and restricting which servers can reach the internet at all, gives defenders a chance to notice the theft before the ransom note. Many research servers have no business sending gigabytes to an unfamiliar destination at 3 a.m. Few organizations in 2020 were watching for it.

What the regulators presume

Notification duties under HIPAA and state breach laws apply if protected information is affected, whether or not a ransom is paid. HIPAA is the federal law that governs the privacy and security of health information. Payment does not remove the regulatory work, and it does not shorten the forensic review needed to scope it. Forensic review is the investigation that reconstructs what the attacker did, which systems they touched and what they took. Regulators and affected individuals will want those answers regardless of any deal with the attacker.

HHS had already set the default in a 2016 fact sheet on ransomware. When ransomware encrypts electronic protected health information, HHS treats that as a breach under the HIPAA rules. A covered entity or business associate can rebut the presumption only by documenting a risk assessment that shows a low probability that the information was compromised. That assessment weighs the nature of the data, who obtained it, whether it was actually acquired or viewed, and how far the risk was mitigated.

The practical effect is that good logging becomes evidence. An organization that can show which files were touched and which left the network can scope its notices precisely. One that cannot may have to notify everyone whose data was on an affected server. For breaches affecting 500 or more people, the HIPAA rule also requires notice to HHS and, in many cases, to prominent media outlets, on a 60-day outer limit from discovery. State laws add their own definitions and clocks, and organizations should check with counsel which apply to which data.

Financing: who pays and on what terms

Cyber insurance often shapes the response. Policies may cover incident response, negotiators, ransom payments and business interruption, and they usually come with panels of approved firms. Business interruption cover pays for income lost while systems are down. A panel is the insurer’s list of forensic firms, lawyers and negotiators whose fees it will pay.

Policy terms decide what help arrives and how quickly. Exclusions and conditions, such as requirements for multi-factor authentication or tested backups, decide whether a claim is paid at all. Multi-factor authentication is the familiar second step after a password, such as a code sent to a phone, which makes stolen passwords far less useful to an attacker. If the policy requires it and you did not have it switched on everywhere you said you did, the insurer may decline to pay.

How a policy shapes the first 48 hours

The first call in many incidents goes to the insurer’s hotline, not to a forensic firm. The insurer then assigns or approves breach counsel, who engages forensic investigators and, where needed, a negotiator. Most policies require the insurer’s consent before a ransom is paid and before significant costs are incurred. A policy may also carry a separate, lower limit for ransomware or extortion losses, and a retention, the insurance equivalent of a deductible, that the organization pays first.

None of those terms is visible during a crisis unless someone read them beforehand. The application matters too. Insurers price and accept risk based on the answers given about controls. An answer that overstated multi-factor coverage or backup practice can become grounds for dispute when a claim arrives.

Procurement decisions made in advance

These are procurement decisions. Before an incident, an organization should know which forensic firm, negotiator and outside counsel it will call, and whether the insurer has approved them. It should know what the policy covers and excludes, and whether its own controls meet the policy’s conditions. Engagement letters signed in advance save days. An engagement letter is the contract that lets a firm start work immediately; negotiating one at 2 a.m. during an attack is a poor use of the first critical hours.

There is a trade-off between the insurer’s panel and the organization’s own preferred firms. A panel firm is pre-approved and its rates are agreed, but it may not know your environment. A firm you already use knows your systems, but its fees may not be covered unless the insurer accepts it in advance. Many organizations negotiate to add their preferred firms to the panel at renewal. That conversation is easy in a calm month and impossible during an attack.

Public institutions and self-insurance

University systems should also confirm whether coverage sits with the campus, the system office or a self-insurance program, since that determines who must approve spending during an attack. The same applies to any organization with a parent company, a holding structure or a shared-services center. If nobody knows who can authorize a seven-figure payment on a Sunday, the organization will find out under the worst conditions.

Public bodies face an extra layer. A county or a public university may buy cover through a state program or a municipal risk pool, with its own panel and approval rules. Paying anyone in cryptocurrency may sit awkwardly with public procurement rules and require a specialist intermediary. A credit union or community bank, by contrast, usually buys a commercial policy and must also think about its regulator’s expectations for incident notification. Each structure is workable. Each needs a named person who knows how it works before it is needed.

Legal readiness: the process for deciding and reporting

Any payment raises sanctions, law enforcement and regulatory questions. Sanctions laws prohibit payments to certain people, groups and countries; paying a ransom to the wrong recipient can itself be a violation. Counsel needs a defined process for checking the recipient before money moves, and the procurement point is simply that the process and the advisers should exist before they are needed.

That risk was already concrete by June 2020. The Treasury’s Office of Foreign Assets Control had added two Iranian individuals linked to the SamSam ransomware, along with bitcoin addresses, to its sanctions list in November 2018. In December 2019 it designated the Russia-based group known as Evil Corp. A victim negotiating with an anonymous group cannot always know who is on the other side, which is why the checks, and the record of having made them, matter.

Separate clocks

Reporting obligations run on separate clocks. An academic medical center may owe notices to a hospital regulator, research sponsors, a university system office and affected individuals at once. Each may have its own deadline, its own format and its own definition of what counts as a reportable event. A short matrix of those obligations, agreed with counsel in advance, saves time and keeps one notice from contradicting another. Inconsistent public statements are a reputational risk in their own right: they invite the question of what else the organization got wrong.

The matrix differs by type of organization. A university doing defense-funded research may be bound by a Defense Department contract clause requiring rapid reporting of cyber incidents that affect covered defense information. A bank answers to its prudential regulator and to state banking and privacy law. A broker-dealer has its own regulators and recordkeeping duties. A state agency may have to report to a state chief information security officer under state law. Building the matrix forces the question of which of these actually apply, and to which systems.

Privilege and the forensic report

How the forensic firm is engaged matters for litigation. Just as the UCSF attack unfolded, a federal court in Virginia ordered Capital One to hand over a forensic report on its 2019 breach to plaintiffs. The magistrate judge ruled in May 2020 that the report was not protected as attorney work product, and the district judge affirmed in late June. The firm had been on retainer before the breach, and the report was shared widely inside the company and with regulators and auditors.

The ruling is from one court and does not bind others. It still gave counsel a clear checklist: engage investigators through outside counsel under a separate agreement, scope the work to legal advice, and control who receives the report. Those choices are made in the first hours, which is another reason to have the engagement structure agreed before any incident.

A ransom policy before the attack

Boards of health systems and research institutions can bring the four inputs together in a ransom policy agreed before any attack. It should state the circumstances in which payment would be considered, who decides, which advisers are engaged and what evidence is required. That policy will not make the decision easy. It does ensure that leaders arrive at it knowing their recovery time, their data exposure, their coverage and their obligations.

A useful policy also says what will be recorded. A decision log, kept by counsel, notes the options considered, the recovery estimates, the sanctions checks, the insurer’s position and who approved the final choice. If regulators, auditors or plaintiffs later ask why the organization paid or did not pay, the log is the answer.

Above the IT department

Ransomware does not belong under “technology risk,” left to the chief information officer. The UCSF case shows why. Every one of the four inputs is a decision about money, ownership and accountability that sits above the IT department.

Take money first. Backups, restore tests, managed research environments and insurance premiums are all line items that compete with faculty hires, clinical equipment and student services. In a tight year they are easy to defer, because nothing visibly breaks. The cost of deferral shows up later, all at once, as lost work, emergency consultants, regulatory notices and a ransom demand with a deadline attached.

Then ownership. In a decentralized institution, the dean or department chair who decides to run a local server is making a risk decision on behalf of the whole university. If that decision is not recorded and approved by someone with authority, the institution is carrying risk that nobody has agreed to carry.

Then reputation. Patients want to know their records are safe. Research participants consented to share data on the understanding that it would be protected. Funders want assurance that grant-supported work will not vanish. Staff want to know their personnel files are not about to appear online. How an organization prepares for, and responds to, an attack shapes how all of those groups see it for years.

Finally, regulators and auditors increasingly ask the same questions a board should: whether you tested recovery, where sensitive data lives, and who decided to accept exceptions. An organization that has those answers ready faces a review. One that does not faces an investigation.

The case for leaving it to the crisis team

There is a serious counter-argument. Every attack is different, the argument runs, and a policy written in advance cannot anticipate the facts. Better to trust an experienced crisis team with good advisers to weigh them on the day. A second argument goes the other way: payments fund crime, so the only sound policy is never to pay, and planning for payment legitimizes it.

Both have force, and neither defeats the case for preparation. A policy does not dictate the answer; it sets out who decides and on what evidence, and it ensures the evidence exists. A crisis team without tested recovery numbers is not exercising judgment so much as guessing. A no-payment stance is only credible if the organization can actually recover without paying, which brings the decision straight back to backups, data placement and testing. An organization that declares it will never pay, and then discovers it cannot restore, has made a promise it cannot keep.

What a board report contains

The practical consequence is that a board, or a board committee, should receive a short, regular report that covers all four inputs: hours to recover key systems, the number of sensitive-data locations outside managed environments, the status of insurance conditions and advisers, and the readiness of the ransom and notification policies. Those are numbers a non-technical director can track quarter to quarter, and they reveal whether preparation is improving or drifting.

Each figure needs an owner and a source. Recovery hours come from restore tests run by infrastructure staff, not from vendor brochures. Data locations come from a scan or an inventory that the research office and the security team both accept. Insurance status comes from risk management, checked against the policy text. Policy readiness comes from counsel and the most recent tabletop exercise. A report built that way is hard to dress up.

Habits of the prepared

Organizations that handle ransomware well usually share a few habits. They know, in hours, how long it would take to restore their most important systems, because they have tested it. They know where their sensitive data lives, and they have deliberately reduced the number of places it lives. They have read their insurance policy and checked their controls against its conditions. They have advisers under contract and a matrix of who must be told what, by when. And their board has discussed, calmly and in advance, the circumstances in which it would and would not consider paying.

They also rehearse. A tabletop exercise walks leaders through a realistic scenario, hour by hour: the first alert, the ransom note, the leak-site posting, the insurer’s call, the press inquiry. The most valuable exercises include the people who would actually decide, such as the general counsel, the chief financial officer and a dean or hospital president, alongside the security team. They usually surface gaps that no document review would find, such as a phone tree that depends on the email system the attacker has just encrypted.

The failures mirror those habits:

• Treating backups as a checkbox. Having backups is not the same as being able to restore from them quickly, at scale, after an attacker has had the run of the network.
• Ignoring the edges. Departmental, research and “shadow” systems that sit outside central IT are often where attackers find the least resistance and the most valuable data.
• Assuming payment ends the problem. Payment does not remove notification duties, forensic work or the risk that stolen data appears anyway.
• Discovering insurance terms during the claim. Conditions that were not met can turn an expected payout into a dispute.
• Improvising governance. Deciding who decides, in the middle of an attack, wastes the hours that matter most.
• Planning communications on systems that will be down. Contact lists, playbooks and call bridges held only in the corporate email and file shares vanish with them.

For a hospital or medical school, there is an extra dimension. Patients, research participants, funders and staff all have a stake in how the organization behaves. A decision to pay or not pay will be judged publicly, and the organization will be better placed to explain it if it can show the decision followed a policy agreed beforehand.

Sequencing the work

For an institution starting from a weak position, the order of work matters. The first quarter is usually best spent on the controls that stop the most common entry routes: multi-factor authentication on all remote access and email, and patching of internet-facing devices. The second is an immutable backup copy for the most important systems and a first restore test. The third is the inventory of departmental and research systems holding sensitive data. Insurance review, engagement letters and the ransom policy can run alongside, since they need legal and finance time rather than engineering time.

Before the ransom note arrives

1. If our most important research or clinical server were encrypted tonight, how many hours would it take to restore it without the attacker’s key, and when did we last prove that in a test?
2. Which departmental or research servers sit outside our central backup program, and who has signed off on each exception?
3. What does our cyber insurance cover and exclude, and do our actual controls meet every condition in the policy?
4. Which forensic firm, negotiator and outside counsel would we call, are they approved by our insurer, and are engagement letters already signed?
5. Has the board agreed, in writing, the circumstances in which we would consider paying a ransom, and who would decide?

Asking these questions takes no technical expertise. Answering them takes work done well before any attack.

With hindsight

In October 2020, the Treasury Department’s Office of Foreign Assets Control warned that facilitating ransomware payments to sanctioned parties could violate sanctions regulations. The Financial Crimes Enforcement Network issued a companion advisory the same day on the role of payment facilitators. Together they made the legal readiness described above a formal requirement rather than good practice: organizations, and the firms that help them pay, needed a way to check who was on the other end. OFAC updated its advisory in September 2021, saying that prompt reporting to law enforcement and full cooperation would weigh in a victim’s favor if a payment later turned out to involve a sanctioned party.

In January 2021, the Justice Department announced a coordinated action against NetWalker, including seizure of a dark web site used to publish victims’ data and charges against an affiliate. The dark web is a part of the internet reachable only through special software that hides who runs a site, which is why criminal groups use it to post stolen data. The affiliate, a Canadian national, was later extradited to the United States and, in October 2022, sentenced in federal court in Florida to 20 years in prison. The action showed that law enforcement could disrupt such groups and punish individuals, though not before many victims had already faced the choices UCSF faced.

The Capital One privilege ruling also proved to be a marker rather than an outlier. Over the following years, counsel across sectors restructured how forensic firms were engaged after an incident, separating legal investigations from routine security work. The questions of who commissions a report, and who sees it, became part of incident planning.

Cyber insurance markets tightened sharply in 2021 and 2022. Insurers raised premiums and made multi-factor authentication and tested backups conditions of cover, which turned the advance decisions described here into underwriting questions. Underwriting is how an insurer decides whether to offer cover and at what price. In practice, the controls that make an organization recoverable became the controls that make it insurable, and leaders who had treated them as optional found the market had stopped agreeing. Many policies also introduced lower limits or co-insurance specifically for ransomware losses.

Lawmakers began to act on payment itself. By 2022, North Carolina had barred state agencies and local governments, including public schools, community colleges and universities, from paying ransoms. Florida barred state agencies and local governments that year and required them to report ransomware incidents quickly. For public institutions in those states, the payment question was settled by statute, which made recoverability the only path left. Congress took a different route. The Cyber Incident Reporting for Critical Infrastructure Act of 2022 requires covered entities to report ransom payments to CISA within 24 hours, once CISA’s implementing rule takes effect. CISA proposed that rule in April 2024 but missed the statutory deadline to finalize it, and the final rule was still pending well into 2026.

Health care regulation moved toward the same inputs. A January 2021 amendment to the HITECH Act required HHS to consider whether a regulated entity had adequately used recognized security practices for the prior twelve months when deciding HIPAA penalties and audits. In January 2024, HHS published voluntary cybersecurity performance goals for the health sector. In its December 2024 proposal to update the HIPAA Security Rule, HHS proposed, among other things, written procedures to restore certain systems and data within 72 hours.

Health care remained one of the most targeted sectors. In the 2024 Change Healthcare attack, UnitedHealth Group’s chief executive confirmed to a Senate committee that a ransom was paid, reported at $22 million, and patient data was still exposed. The company later put the number of affected people at roughly 190 million. The case confirmed, at enormous scale, that payment does not guarantee the outcome it is meant to buy.

With that hindsight, the UCSF case reads differently. The question is less “would we pay?” and more “have we arranged things so that we rarely need to ask?” Recovery time, data placement, insurance terms and legal process are all set in calm periods. Every major development since 2020, from sanctions guidance to insurance conditions to state payment bans, has pushed in the same direction: toward organizations that can recover without the key. They are budget and governance decisions, and they deserve a board’s time well before any attacker makes them urgent.