The call comes midway through fieldwork or just after year-end: the client's systems are encrypted, the accounting file is unreachable, and the controller wants to know whether the audit is still on. A ransomware attack is not only an IT event for the client. It threatens the completeness of the records you are auditing, the client's ability to continue, and, if a payment is contemplated, the client's exposure under sanctions law. This post sets out the response in the order the issues arrive.
First: protect your own side
Before anything else about the audit, protect your firm and its other clients.
- Do not connect to or open files from the client's affected systems or share drives until the client's response team confirms they are safe.
- Pause any automatic sync between client folders and your firm's environment.
- Rotate any credentials the engagement team holds for client systems or portals, and use the client's replacement channels for new ones.
- Tell your firm's security contact. If the attacker is inside the client's email, messages from "the client" may not be from the client.
- Move requests for information to a channel you have confirmed by phone with a known person.
A threatening email to your team is a firm-level incident, and your own written plan applies. The AICPA confidentiality and AI tools guide describes the Safeguards Rule's written incident response requirement that applies to firms preparing tax returns.
Second: understand the attack and who has been told
Ransomware is malicious software designed to block access to a system or data, often by encrypting it, to extort payment in exchange for restoring access. Some attackers also threaten to publish sensitive files. OFAC's advisory notes that attacks are carried out against private and governmental entities of all sizes and in all sectors, and that vulnerable entities are also targeted on the assumption that they have fewer resources to invest in cyber protection.
Ask management, in writing, for:
- the date and time of discovery and the first date of suspected compromise
- systems and data affected, including the general ledger, subledgers, payroll, banking portals and document stores
- whether the attacker exfiltrated data
- whether backups were intact, and which restore point is being used
- who has been notified: law enforcement, insurer, counsel, customers, regulators
- whether a ransom demand has been made, and whether payment is being considered
Insist that management, not you, handles communications with the attackers. If counsel has been engaged, route requests for privileged material through counsel and understand what will and will not be shared.
Third: reporting obligations the client may face
OFAC's advisory strongly encourages all victims and those involved in addressing ransomware attacks to report the incident as soon as possible to CISA, their local FBI field office, the FBI Internet Crime Complaint Center, or their local U.S. Secret Service office, and to contact OFAC if there is any reason to suspect a sanctions nexus with a ransom payment.
The Cyber Incident Reporting for Critical Infrastructure Act of 2022 adds a statutory structure. Under 6 U.S.C. 681b, a covered entity must report a covered cyber incident to CISA not later than 72 hours after it reasonably believes the incident has occurred, and must report a ransom payment not later than 24 hours after it is made. Those reporting paragraphs take effect on the dates prescribed in CISA's final rule, which also determines which entities are covered. CISA had not published the final rule in the Federal Register as of November 2026, so the reporting duties are not yet in force. Ask whether the client operates in a sector the rule could reach.
For public companies, the SEC's Item 1.05 clock applies; see SEC cyber incident disclosure.
Fourth: the ransom payment question
The auditor does not decide whether the client pays. The auditor does need to know what happens, because a payment raises sanctions and accounting questions.
OFAC's updated advisory (September 21, 2021) states that companies that facilitate ransomware payments, including financial institutions, cyber insurance firms and digital forensics and incident response companies, may risk violating OFAC regulations. U.S. persons are generally prohibited from transactions with persons on the SDN List, other blocked persons, and persons covered by comprehensive country or region embargoes. OFAC may impose civil penalties on a strict liability basis: a person subject to U.S. jurisdiction may be liable even if it did not know or have reason to know that the transaction was prohibited. The U.S. government strongly discourages paying ransom or extortion demands, and license applications involving ransomware payments are reviewed case by case with a presumption of denial.
The advisory also describes what OFAC treats as significant mitigating factors in an enforcement response: meaningful steps to improve cybersecurity practices, such as maintaining offline backups, developing incident response plans, instituting cybersecurity training, updating antivirus and anti-malware software and using authentication protocols; a self-initiated and complete report of the attack to law enforcement or relevant agencies as soon as possible after discovery; and full and ongoing cooperation with law enforcement. The advisory says OFAC is more likely to resolve apparent violations with a non-public response when the party took these steps, particularly early reporting.
For the audit, a payment means:
- obtain the decision record, who approved it, and legal advice received
- understand the payment channel and how the amount reached the attacker, since the route determines which parties handled it
- test the accounting for the payment, any insurance recovery receivable, and related costs
- consider whether the payment, or a failure to report it, creates a legal or regulatory exposure that needs evaluation as a contingency
OFAC's own wording applies to payers and facilitators. The audit firm should not arrange or facilitate payment.
Fifth: reliability of the records
This is the core audit question. After a restore, you cannot assume the books are what they were.
- Completeness. Transactions entered between the last backup and the attack may be missing. Compare the restored general ledger to bank activity, subsequent cash receipts and disbursements, payroll registers, and sales and shipping records created outside the affected systems. The audit trail guide explains how to test for gaps.
- Integrity. Look at whether data was altered rather than only encrypted. Unusual entries or master data changes around the compromise date deserve investigation.
- Reconstruction. If records were rebuilt from source documents, the rebuild is information produced by the entity, and you test it as such. Audit evidence under AU-C 500 covers the reliability framework.
- Controls. Revisit your IT general controls conclusions for the period. A compromise may mean access, change management and backup controls did not work as you concluded. See the ITGC guide.
- Cutoff and existence. Systems that were down affect invoicing, receiving and inventory. Plan more testing around the outage window.
If you cannot obtain sufficient appropriate evidence on a material area, you consider the effect on your opinion in the usual way. That is a conclusion you reach after the work, not a position to take on day one.
Sixth: financial reporting consequences
- Loss contingencies. Exposure to customer claims, regulatory action and data breach costs follows the framework in ASC 450.
- Subsequent events. An attack after the balance sheet date and before the report is issued is evaluated as a subsequent event for disclosure or adjustment as the circumstances require. Run the procedure at the date of your report, with a fresh inquiry.
- Impairment indicators. Lost customers, long outages or reputational damage can trigger asset impairment tests.
- Going concern. If the incident affects liquidity, operations or customer retention, evaluate management's plans for the next twelve months from the date financial statements are issued. Obtain evidence of insurance coverage, claim status and cash forecasts.
- Capitalization. Costs of rebuilding systems are not all assets. Test what was capitalized.
Seventh: communication and engagement terms
Communicate with those charged with governance about the incident's effect on the audit, any control deficiencies it revealed and any limitation on evidence. Obtain specific written representations about completeness of incident information. Revisit timing: a late audit is a smaller problem than an unreliable one. The planning memo guide is the place to record the revised plan, and the engagement letter may need a supplement if the scope or fees change.
Frequently asked questions
Should the audit firm pay or negotiate a ransom?
No. The decision belongs to the client, with counsel. OFAC's advisory warns that facilitating payments carries sanctions risk.
Do we have to stop fieldwork?
Pause access to affected systems and channels. Resume against restored or rebuilt records once the client's response team confirms they are safe, and expand testing on reliability.
Does a ransomware attack always require disclosure in the financial statements?
It depends on the effects. Evaluate loss contingencies, subsequent events and going concern against the facts.
Sources
- U.S. Department of the Treasury, OFAC, Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments (September 21, 2021): https://ofac.treasury.gov/media/912981/download
- 6 U.S.C. 681b, Required reporting of certain cyber incidents (Cyber Incident Reporting for Critical Infrastructure Act of 2022): https://www.law.cornell.edu/uscode/text/6/681b
- SEC, Fact Sheet: Public Company Cybersecurity Disclosures; Final Rules: https://www.sec.gov/files/33-11216-fact-sheet.pdf
- 16 CFR 314.4, Elements: https://www.law.cornell.edu/cfr/text/16/314.4
CORAA prepares ready-to-review audit files for US CPA firms from QuickBooks books; you review and sign. See /us.
Part of CORAA University · Engagement and acceptance: related guides, calculators and templates.
AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error