Ransomware Executive Briefing for Boards

A ransomware attack is a business continuity event that arrives with a legal decision attached, and boards are usually asked to make that decision within hours, with incomplete facts. This briefing is for directors, chief executives, general counsel and CISOs who need to understand ransomware in business terms: what the organisation could lose, how long recovery really takes, when paying is unlawful or pointless, what insurance does and does not do, and how to tell whether management's assurances are credible. It deliberately stays at board level. The technical controls are covered in the Ransomware Prevention Guide and the incident mechanics in the Ransomware Response and Recovery Guide.

The risk in one paragraph

Ransomware crews usually get in with a stolen login, an unpatched internet-facing system or a convincing call to the help desk, then spend days or weeks taking control of the accounts that run the business: domain administrators, backup consoles, virtualisation platforms and cloud tenants. Only then do they steal data and encrypt systems, often deleting backups first so that recovery is impossible without them. The organisation then faces two losses at once: operations that stop, and data that may be published unless a ransom is paid. The size of the damage is set less by the malware than by how much of the business one compromised account can reach, and by whether a clean copy of the business can be restored without the attacker's help.

Why this is a board-level issue now

Outages are measured in weeks, not hours. Jaguar Land Rover proactively shut down its systems from 31 August 2025 and only began a phased restart of production on 8 October 2025, more than five weeks later, with knock-on effects across its UK supply chain. See the Jaguar Land Rover cyberattack analysis.
The entry point is often a person or a supplier, not a firewall. At Marks and Spencer in 2025 attackers impersonated a third-party user to gain access, and the company estimated a reduction of about £300 million in profit before recoveries. See the Marks and Spencer cyberattack analysis.
Payment is increasingly regulated. US sanctions can make a payment unlawful on a strict liability basis, the UK Home Office has consulted on and responded to proposals to ban payments by public bodies and critical national infrastructure, and several countries now require payments or incidents to be reported within fixed deadlines.
Disclosure clocks run from the boardroom. US listed companies must file a Form 8-K under Item 1.05 generally within four business days of determining that a cyber incident is material, and must describe the board's oversight of cyber risk in the annual report (Regulation S-K Item 106).
Governance codes now name the board. The UK NCSC's Cyber Security Toolkit for Boards is structured around the Cyber Governance Code of Practice, with a dedicated principle on incident planning, response and recovery.

Exposure: what the business stands to lose

Boards should ask for exposure in business units and money, not in numbers of vulnerabilities. A useful framing is the table below, completed by management for the organisation's top five business services.

Loss type	What drives it	Question to put to management
Lost revenue and operations	Which services depend on systems that can be encrypted, and whether manual workarounds exist	How many days can each critical service run without IT, and what does each day cost?
Recovery cost	Rebuilding identity, servers and endpoints, external forensics, overtime, replacement hardware	What is our realistic rebuild time for the whole estate, as tested, not as planned?
Data exposure	Volume and sensitivity of data that could be stolen before encryption	Which data, if published, triggers regulator notification or customer harm?
Regulatory and legal	Breach notification rules, sector regulators, sanctions, securities disclosure, contracts	Which notification deadlines start in the first 72 hours and who owns each?
Supply chain and customers	Customers and partners who depend on our output, or whose access we hold	Who stops if we stop, and what do our contracts say about it?
Reputation and trust	Public visibility of the outage, leak site listing, handling of communications	Who speaks for us, and what will we say if data appears on a leak site?

A business impact analysis is the standard way to produce these numbers. See the Business Impact Analysis Template.

The payment decision: sanctions, law and ethics

Whether to pay is a board decision that must be prepared before an incident, because the facts needed to make it lawfully take days to establish. The main constraints are:

Sanctions are strict liability: the US Treasury's Office of Foreign Assets Control (OFAC) updated ransomware advisory of 21 September 2021 states that OFAC may impose civil penalties based on strict liability, so a firm can be liable even if it did not know the recipient was sanctioned. Licence applications to pay sanctioned parties are reviewed case by case with a presumption of denial.
Reporting and cooperation earn mitigation: the same advisory treats a prompt, complete report to law enforcement or CISA, and full cooperation, as significant mitigating factors, and recognises offline backups, incident response plans and training as relevant too. It names cyber insurers, incident response firms and financial institutions as parties that facilitate payments and should account for sanctions risk.
Governments discourage payment: OFAC states that the US government strongly discourages paying ransom or extortion demands. Paying does not guarantee working decryption, does not guarantee stolen data is deleted, and funds the next attack.
Some payments may become illegal outright: in the UK, the Home Office ran a consultation from 13 January to 8 April 2025 and published its response on 22 July 2025, proposing legislation that includes a targeted ban on payments by public sector bodies and regulated critical national infrastructure. Check the current status before relying on it: see the Ransomware Payments and Sanctions Guide.

The board's job is not to negotiate. It is to agree in advance who may authorise a payment, the conditions under which the organisation would even consider one (for example, risk to life or no viable recovery), the legal and sanctions checks that must be completed, and how the decision is recorded. Negotiation mechanics are covered in the Ransomware Negotiation Guide.

Decision factor	Points against paying	What the board needs to see
Recovery capability	Clean, tested backups exist and can restore critical services in an acceptable time	Evidence of a recent full restore test, not a backup success report
Sanctions exposure	Any link between the group or wallet and a sanctioned person or jurisdiction	Written legal and sanctions screening advice
Data extortion	Payment cannot prove deletion of stolen data	Assessment of what was taken and the notification duties that apply either way
Safety and life	Rarely a reason not to pay; often the strongest reason to consider it	A clear statement of harm to people if services stay down
Regulatory position	Bans, pre-payment notification or reporting deadlines in the relevant country	A jurisdiction map maintained by legal, updated when rules change

Recovery time and the backup reality

Recovery is where most ransomware losses are made or avoided. The CISA, FBI, NSA and MS-ISAC #StopRansomware Guide (September 2023) recommends maintaining offline, encrypted backups of critical data, regularly testing their availability and integrity, keeping "golden images" of critical systems, and maintaining and exercising an incident response plan. It also recommends that the plan is approved in writing by the chief executive or equivalent: a point boards can check directly.

Backups are a target: attackers deliberately delete or encrypt backups and snapshots before launching encryption, so a backup that the same administrators can delete is not a recovery plan. See the Backup Security and Immutable Backup Guide.
Identity comes first: nothing can be restored safely until the directory and privileged accounts are trusted again, which is often the longest step. See Recovering IAM and PAM After Ransomware or Domain Compromise.
Order matters: management should hold an agreed restore order based on business priority, not on which system is easiest to bring back.
Tested time beats planned time: a recovery time objective that has never been tested end to end is an aspiration. Ask for the date and result of the last full restore of a critical service.

Cyber insurance: what it does and does not do

Insurance transfers part of the financial loss. It does not restore systems, it does not remove legal duties, and it does not make an unlawful payment lawful: OFAC explicitly lists cyber insurers among the parties that must account for sanctions risk. Boards should understand:

Cover conditions: policies and renewals increasingly depend on attested controls such as multi-factor authentication for remote and privileged access, offline backups and endpoint detection. An inaccurate attestation can put a claim at risk. See the Identity Controls for Cyber Insurance Questionnaires Guide.
Panel firms: many policies require the use of the insurer's approved incident response, legal and negotiation firms. Know who they are and have their contact details offline before an incident.
Limits versus exposure: compare the policy limit with the exposure figures above. A multi-week outage can exceed typical limits by a wide margin.
Notification: policies usually require prompt notice to the insurer; failing to notify early can affect cover.

See the Cyber Insurance Guide for policy structure and exclusions.

Five questions for the board to ask

If we were encrypted tonight, which services would stop, and how many days until each is back? A credible answer cites a tested restore, a named restore order and a cost per day.
Could an attacker who controls our administrator accounts also delete our backups? The right answer is no, because backups are immutable or offline and administered through separate identities with phishing-resistant MFA.
Who decides whether we pay, on what criteria, and what legal checks happen first? There should be a written decision process with named roles, sanctions screening and a decision record.
When did we last rehearse a ransomware scenario with the executive team, and what did we change afterwards? Look for an exercise in the last 12 months and a list of closed actions.
What are the three most likely ways in, and what has been done about each this year? Expect specifics: remote access without MFA, unpatched internet-facing systems, help desk resets, supplier access. See the Top 10 Ransomware Initial Access Vectors.

Red flags in management answers

"Our backups are fine": without a date and scope for the last full restore test, this is not evidence.
"We have MFA": ask whether it covers every remote access path, every administrator and every service account that can log in interactively, and whether the help desk can bypass it.
"Insurance covers it": insurance pays some costs later; it does not run the business during the outage.
"We would never pay": a policy stance is useful, but the board should test whether it holds if lives or the company's survival were at stake, and document the exceptions.
"IT owns the plan": ransomware response needs legal, communications, operations, finance and the board. A plan owned only by IT will fail on the first day.
Exercises with no consequences: a tabletop that produced no actions, or actions that were never closed, has not tested anything.

What good looks like

Area	Good practice
Governance	A named executive owner, ransomware on the risk register with quantified exposure, and board review at least annually
Prevention	Phishing-resistant MFA on remote and privileged access, internet-facing systems patched against known exploited vulnerabilities, controlled supplier access
Privileged access	Few standing administrators; separate admin identities; service accounts inventoried with owners
Recovery	Immutable or offline backups under separate identities; full restore of critical services tested on a schedule
Response	An incident response plan signed off by the chief executive, with offline contacts, retained experts and a payment decision process
Assurance	Independent testing, exercise results reported to the board, and insurer attestations checked for accuracy

The Ransomware Readiness Maturity Model turns this table into five levels for self-assessment.

Where to invest first

Recoverability: immutable or offline backups with a separate administrative path, and a tested restore of the most critical service. This limits the worst outcome regardless of how the attacker got in.
Privileged and remote access: phishing-resistant MFA, fewer standing administrators and hardened help desk identity checks. Most ransomware runs on stolen or abused accounts. See the Phishing-Resistant MFA Guide.
Exposure reduction: patching or removing internet-facing systems listed in the CISA Known Exploited Vulnerabilities catalogue, starting with remote access and file transfer products.
Detection and response: monitoring that can see identity misuse and backup tampering, with a retainer for expert help. See the Incident Response Retainer Buyer's Guide.
Decision readiness: a rehearsed executive playbook, including the payment decision process and communications. See the Ransomware Playbook Template.

Metrics to track

Tested recovery time for the top five critical services, against the agreed objective.
Date and outcome of the last full restore test and the last executive ransomware exercise.
Percentage of remote and privileged access covered by phishing-resistant MFA.
Number of standing domain and cloud administrator accounts, and the trend.
Days to remediate known exploited vulnerabilities on internet-facing systems.
Percentage of exercise and audit actions closed on time.

A 90-day plan

Days 1 to 30: confirm the executive owner; ask management to complete the exposure table for the top five services; verify that backups for those services are immutable or offline and administered separately; confirm offline copies of the incident response plan and key contacts, including insurer panel firms.
Days 31 to 60: agree the payment decision process with legal, including sanctions screening and the jurisdictions where bans or reporting apply; close the most serious gaps in MFA coverage for remote and administrator access; run a restore test of one critical service end to end.
Days 61 to 90: run an executive tabletop exercise based on a realistic scenario, including a leak site threat and a regulator deadline; report results and actions to the board; baseline maturity with the Ransomware Readiness Maturity Model and set a 12-month target.

Common failure patterns

Backups in the blast radius: backup consoles joined to the same domain and run by the same administrators as production, so the attacker deletes them first.
Supplier and help desk paths ignored: strong perimeter controls undermined by a reset granted over the phone or a trusted third party's access, as the Marks and Spencer incident illustrates.
Payment decided in the moment: no prior criteria, no sanctions advice lined up, and directors under pressure to decide in hours.
Plans that assume IT is available: contact lists, playbooks and collaboration tools stored on the systems that have just been encrypted.
Recovery time never tested at scale: restores proven for single files but never for a whole service, so a planned two-day recovery becomes five weeks.

Practitioner checklist

Brief the board annually on ransomware exposure in money and days of outage for the top five services.
Keep the incident response plan signed by the chief executive, with offline copies held by named executives.
Maintain a written payment decision process: authority, criteria, sanctions and legal checks, decision record.
Maintain a jurisdiction map of payment bans, payment reporting and incident reporting deadlines, owned by legal.
Prove backup immutability and separation, and run a full restore of a critical service at least annually.
Reconcile cyber insurance attestations with actual control coverage before each renewal.
Run an executive ransomware exercise every year and report closed actions to the board.
Report the six metrics above to the risk or audit committee each quarter.

Standards and references

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments, board briefings and programme initiation support, with a focus on the privileged and machine accounts that ransomware operators abuse. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.

Ransomware Executive Briefing: What Boards Need to Know and Ask