Ransomware at a 38-Person Bookkeeping Firm
Halcyon Bookkeeping is a 38-person firm that keeps the ledgers and payroll for about 600 small businesses. A partner opens an invoice attachment that appears to come from a long-standing client; three days later, files on the shared drive are renamed with an unfamiliar extension. The firm has a nightly backup to a NAS that stays permanently mounted on the network, and a cyber insurance policy with a €250,000 limit. The risk register lists 'ransomware' once, with likelihood Medium and impact High, no owner and no treatment noted. The firm's risk appetite statement says it has 'no tolerance for regulatory breach' but says nothing about downtime. Two of the 600 clients are in a sector whose regulator requires breach notification within 72 hours. The managing partner asks whether the firm should simply rely on the insurance and the backup.
1. What is missing from the risk register entry 'ransomware - likelihood Medium, impact High' before it can support a decision?
Read the worked answer
A risk needs a subject. Ransomware is a threat; the register does not say which asset is exposed (client ledgers, payroll data, the shared drive, the backup) or which vulnerabilities make it possible (invoice attachments, flat network, permanently mounted backup, no MFA). Without those, 'Medium/High' cannot be verified or treated.
The scales are undefined. If 'High' means 'regulator notified and 600 clients affected' in one person's head and 'a day of lost work' in another's, scores are not comparable across the register. Define likelihood and impact scales in the policy with examples.
Impact is not expressed in business terms. Management needs figures: billable hours lost per day of downtime, cost of notification and credit monitoring, contractual penalties, reputational damage with 600 SME clients.
No owner, no treatment, no residual risk, no review date. A risk without an owner is not managed. The entry should record the chosen treatment (mitigate, transfer, avoid, accept), the controls, the residual rating after controls, and when it will be reviewed.
2. The managing partner proposes to accept the risk because there is insurance and a backup. Evaluate this proposal and name appropriate treatment for two specific weaknesses.
Read the worked answer
Insurance transfers financial loss; it does not reduce likelihood or restore anything. Cover of €250,000 may not match the cost of rebuilding 600 client ledgers, lost billing during recovery, regulatory penalties or the clients who leave. Many policies also require demonstrable controls, and reputational and regulatory consequences cannot be transferred.
The backup is not a control as configured. A NAS that stays mounted on the network is reachable by the same ransomware that encrypted the shared drive, so it will probably be encrypted too. Its value depends on being offline or immutable, on separate credentials, and on tested restores.
Treatments, by weakness:
- Permanently mounted backup - mitigate: 3-2-1 backups, at least one offline or immutable copy, separate admin credentials, quarterly restore tests.
- Invoice attachment entry point and flat access - mitigate: attachment sandboxing or macro blocking, MFA, least-privilege share permissions, endpoint detection and response, segmentation.
- For the 72-hour notification clients, detection speed matters, so monitoring is part of the treatment, not an extra.
Acceptance may be defensible only for the residual risk after these controls, documented with an owner and a review date.
3. How should the risk appetite statement influence the decision, and what is wrong with it as written?
Read the worked answer
What is wrong: it addresses only regulatory breach ('no tolerance') and is silent on downtime, data loss and client harm. That silence matters here: the largest plausible impact of this ransomware is operational - the firm cannot produce ledgers or payroll for days - yet the statement gives no threshold to judge it against. A risk appetite needs defined tolerances, for example maximum tolerable downtime per service, maximum records lost, and whether ransom payment would ever be considered.
How it should influence the decision: the statement is the criterion against which treatment options are chosen. If downtime beyond, say, 24 hours is unacceptable, then the nightly-backup architecture and untested recovery are outside appetite and must be mitigated regardless of insurance. Conversely, if a short outage is tolerable, accepting some residual risk is legitimate.
Practical point: an appetite statement is not a control and does not by itself reduce risk. It must be approved by management, translated into thresholds that staff can apply, and revisited after this incident.