Cybersecurity Incidents: 10 Financial Reporting and ICFR Controls for Controllers

A ransomware event, compromised supplier account or prolonged ERP outage can become a financial-reporting problem long before the final forensic report is available. Revenue may be delayed, customer credits may be promised, emergency suppliers engaged, data restored from backups and legal claims threatened. At the same time, the incident may affect the reliability of the very systems used to close the books.

The controller does not lead the technical response. But finance must help establish the financial facts, preserve evidence, assess accounting and disclosure consequences, and demonstrate that critical controls continued to operate. A practical response plan connects the incident-response team with the close calendar, general ledger, treasury, legal, investor relations and external auditors.

Why cybersecurity incidents belong on the controller’s risk agenda

Cyber incidents can affect more than the cost of forensic specialists or a ransom demand. They can disrupt order processing, payroll, billing, collections, manufacturing, vendor payments and financial reporting. Longer-term effects may include customer attrition, contract disputes, regulatory scrutiny, higher insurance costs and impairment of technology assets.

For public companies, the disclosure question is separate from the accounting question. The SEC’s cybersecurity rules, adopted on July 26, 2023, require domestic registrants to report a material cybersecurity incident under Item 1.05 of Form 8-K, generally within four business days after determining that the incident is material. The SEC’s current Form 8-K interpretations page was updated on October 21, 2026. Canadian reporting issuers have a different material-change framework under National Instrument 51-102. Neither timetable should be confused with the accounting recognition analysis.

10 controls financial controllers should put in place

1. Establish a formal incident-to-finance escalation process

Require the security, IT operations, privacy, business continuity and legal teams to notify the controller when an event could affect financial systems, customer data, payments, operations or contractual obligations. Define escalation triggers for ransomware, data exfiltration, ERP or payroll outages, compromised bank instructions, vendor incidents and repeated related attacks.

Maintain one incident register with the discovery time, affected entities and systems, response owner, known facts, severity changes, key decisions and next review date. The purpose is not to make Finance the incident commander; it is to ensure that Finance receives reliable information early enough to act. NIST SP 800-61 Revision 3, finalized in April 2025, describes incident response as part of broader cybersecurity risk management and continuous improvement.

2. Build a complete financial-impact inventory

Assign an owner and evidence source to each potential impact. At a minimum, assess:

Incremental forensic, legal, recovery, overtime and temporary-system costs;
Lost, delayed or deferred sales, production and customer deliveries;
Customer credits, refunds, service-level penalties and contract claims;
Supplier disruption, emergency procurement and payment diversion;
Ransom payments, deductibles and other out-of-pocket amounts;
Potential litigation, privacy claims, regulatory penalties and insurance recoveries; and
Possible impairment or abandonment of hardware, software, data or projects.

Separate amounts already incurred from estimates, cash payments from non-cash effects, and lost activity from activity merely shifted into a later period. This prevents a delayed shipment from being treated automatically as lost revenue and reduces double counting between business units.

3. Preserve accounting evidence and protect ledger integrity

Coordinate with IT and the incident-response lead to preserve relevant logs, backups, system snapshots, approvals, invoices, contracts, bank records and communications. Record when evidence was collected, by whom and where it is stored. Restrict access to sensitive forensic material while retaining a controlled finance evidence repository.

If credentials or payment workflows may have been compromised, suspend affected access and use approved manual procedures. Do not rely on spreadsheets or exported reports from a system until their completeness and integrity have been assessed. Finance should retain pre-incident trial balances and reconciliations where available, but must not interfere with forensic preservation or restoration procedures.

4. Evaluate obligations under the correct accounting framework

Identify obligations that existed at the reporting date: customer claims, litigation, regulatory matters, contractual penalties, employee claims or other exposures. For US GAAP reporters, perform the analysis under the applicable FASB Codification guidance, including ASC 450 where loss contingencies are involved. The FASB identifies its Accounting Standards Codification as the authoritative source of nongovernmental US GAAP.

For IFRS reporters, IAS 37 governs provisions and contingent liabilities. A provision is recognised when the applicable criteria are met, including a probable outflow; a contingent liability is generally disclosed unless the possibility of outflow is remote. Do not create a broad reserve simply because management expects to spend money on future security improvements. Distinguish an existing obligation from future operating expenditure.

Canadian private enterprises applying ASPE should assess the relevant ASPE requirements rather than importing IFRS or US GAAP conclusions. The accounting framework used for the financial statements is not necessarily the same question as the securities disclosure regime applicable to an issuer.

5. Assess insurance recoveries separately from the loss

Obtain the policy, endorsements, limits, retention, exclusions, waiting periods, notification requirements and any insurer consent provisions. Track claim submission dates, requested evidence, adjuster correspondence, approved amounts and disputed coverage. Ask the broker or coverage counsel to explain restrictions before management assumes a recovery will be received.

Do not automatically net an expected insurance recovery against incident costs or recognise a receivable merely because a policy exists. Assess recognition and presentation separately under the applicable accounting framework. Under IAS 37, a contingent asset is not recognised until the inflow is virtually certain, although disclosure may be required when an inflow is more likely than not. Importantly, the SEC has clarified that reimbursement of a ransomware payment does not, by itself, make an incident immaterial for Item 1.05 purposes.

6. Review asset impairment, restoration costs and contracts

Determine whether equipment, software, data-related assets or implementation projects have been damaged, compromised, rendered unusable or abandoned. Review cloud-provider credits, service-level agreements, vendor indemnities, termination rights and customer contracts. Separate repair and maintenance activity from expenditure that may qualify for asset recognition under the entity’s accounting framework; do not capitalize all recovery spending by default.

Where systems are replaced or projects are paused, document the facts supporting any impairment, disposal or useful-life assessment. The analysis should identify the asset, the event that affected it, the date the condition arose, the estimate used and the reviewer who approved the conclusion.

7. Run a documented materiality and disclosure assessment

Set up a cross-functional assessment involving the CFO, controller, legal counsel, security leadership and investor relations. Consider operational interruption, data sensitivity, customer and supplier effects, litigation, regulatory exposure, reputation, financing and the reasonably likely financial impact—not just the amount of a ransom or the invoices received to date.

For US domestic SEC registrants, Item 1.05 of Form 8-K generally requires filing within four business days after the company determines that the incident is material. The clock is tied to the materiality determination, not simply discovery, and the determination must not be unreasonably delayed. The SEC also says related incidents may need to be assessed collectively. For Canadian reporting issuers, NI 51-102 section 7.1 generally requires an immediate news release for a material change and a material change report as soon as practicable, no later than 10 days after the change, subject to the instrument’s exceptions. Cross-listed companies should map both regimes with counsel.

8. Assess the effect on ICFR and compensating controls

Identify which financial-reporting processes and assertions were affected: completeness of revenue, accuracy of payroll, existence of cash, validity of vendors, authorization of journal entries, or completeness of liabilities. Determine whether privileged access, change management, interfaces, automated approvals, bank-file controls or audit logs were disabled or bypassed.

For every temporary manual control, document the owner, frequency, population, evidence, reviewer and end date. A spreadsheet reconciliation may be a reasonable short-term safeguard, but it needs controlled inputs, access restrictions, independent review and evidence of resolution. Evaluate control deficiencies under the entity’s ICFR framework; do not assume every cyber incident automatically creates a material weakness, or that restored system access proves controls are effective again.

9. Validate ERP and close data before resuming normal processing

For SAP S/4HANA or another ERP, agree recovery sign-off criteria with IT before finance resumes normal posting. Validate user access, master-data changes, posting periods, interfaces, bank files, workflow approvals, recurring journals and scheduled jobs. Reconcile opening balances and transactions before and after restoration. Search for missing, duplicated, backdated or unauthorized postings, and confirm that interrupted interfaces have been reprocessed exactly once.

Use controlled extracts and retain the reconciliation between restored data and trusted source records. Reconcile subledgers to the general ledger, bank activity to cash postings, payroll to the payroll register, and billing or shipping records to revenue. The close should not be signed off solely because the ERP is available.

10. Complete an incident accounting memo and post-incident review

Prepare a concise memo that records the timeline, affected entities and systems, known and unknown facts, accounting conclusions, estimates, insurance position, materiality assessment, disclosure decisions, journal entries, control impacts and approvals. Link each conclusion to evidence and identify what remains unresolved.

Keep the matter on the close checklist until legal claims, insurance correspondence, customer credits, asset assessments and control remediation have been revisited. NIST SP 800-61 Rev. 3 emphasizes using lessons from response activities to improve risk management. Finance should convert those lessons into updated close procedures, control owners, vendor requirements and scenario tests.

Illustrative controller scenario

Assume a ransomware event makes an order-management and billing platform unavailable for three days. The company incurs $800,000 of emergency response and restoration costs, grants $250,000 of customer credits, and delays $3 million of shipments. The $3 million is not automatically a $3 million revenue loss: some orders may ship later, while others may be cancelled or become subject to contractual remedies. The controller should reconcile the order population, assess the credits and claims, classify incurred restoration costs, evaluate any asset impairment, and separately assess insurance recovery. The event’s materiality assessment should also consider customer, operational and reputational consequences.

Controller’s readiness checklist

Is Finance included in the incident escalation tree and tabletop exercises?
Can the team produce a reliable incident timeline and financial-impact register?
Are accounting, insurance and legal assessments owned and independently reviewed?
Are SEC and Canadian material-change decision paths documented where relevant?
Can the company demonstrate how ICFR and ERP data integrity were validated after recovery?
Are unresolved estimates, claims and remediation actions tracked through subsequent closes?

Conclusion

A cyber incident is not only an IT disruption; it can affect financial results, disclosures, cash flows and confidence in internal controls. Controllers add value by translating technical facts into traceable financial evidence, coordinating framework-specific accounting and disclosure decisions, and insisting on reconciliations before the close is certified. The best time to establish these controls is before an incident occurs.

Informational only: This article is not legal, cybersecurity, insurance or accounting advice. Apply the requirements relevant to the entity, reporting framework and securities jurisdictions with qualified advisers.

Defined Benefit Pension Plans: 10 Controls for ASC 715, IAS 19 and Canadian ASPE