The gap between security and control

Asahi Group Holdings recently flagged a material weakness in its internal controls over financial reporting following a ransomware attack. For those who live in IT security, the instinct is to treat this as an uptime problem or a failure of perimeter defense. It isn't. This was a failure of evidence.

When a firm admits that a cyberattack disrupted its ability to report financials accurately under SOX and GAAP standards, they aren’t just saying their servers were encrypted. They are admitting they cannot prove the integrity of the data used for those reports. In audit terms: you've lost your chain of custody over the numbers.

Most firms treat "security" as a shield—something that keeps people out. But internal control is about visibility—proving exactly what happened inside. Many practitioners confuse these two things, believing that because they have an expensive EDR tool and encrypted backups, their controls are functioning. This is where 'privacy by design' usually becomes a hollow phrase; it’s often used to describe the purchase of software rather than the architecture of proof.

If you're the person responsible for implementing these controls, your focus shouldn't be on how quickly you can restore from backup. It should be on what happens in the gap between the last clean snapshot and the moment of recovery.

The evidence required here isn’t a log showing that a server restarted at 4:02 AM. You need an integrity bridge. This means having pre-defined, automated checksums or reconciliation reports for critical financial tables that can be run immediately upon restoration to verify no data was altered prior to the encryption event. If you cannot prove precisely which transactions were lost and whether any existing records were manipulated before the lockout, your control is broken.

Some will argue that a robust disaster recovery plan (DRP) covers this. It doesn't.

A DRP ensures availability—it gets the lights back on. Internal controls over financial reporting ensure accuracy. If you restore from a backup and find an eight-hour hole in your transaction ledger, you haven’t recovered; you’ve just formalized a data loss event that now makes your balance sheet unreliable. The objection is usually that such granular verification takes too long during an active crisis. That's exactly why the evidence needs to be automated before the attack happens.

The second-order effect here will hit external auditors first. When firms like KPMG or EY step into a post-breach environment, they won’t just check your firewall logs. They'll start demanding "integrity audits" of the restored data against independent sources—bank statements, third-party payment gateways and shipping manifests. If you can't provide that reconciliation quickly, the auditors will have no choice but to qualify their opinion or flag a material weakness themselves.

This effectively turns your cyber insurance policy into an audit liability. Insurers might pay for the forensic cleanup, but they won’t fix a "material weakness" finding in your SEC filing.

The real test is whether you can produce a report today that proves no one has touched your critical reporting tables in the last 30 days without leaving a permanent, immutable trace. Most firms can't actually do this; they just assume their permissions are set correctly.

Watch for how regulators treat "automation bias" here too. The NFRA recently warned against letting AI replace professional judgment in audits. This applies to your controls as well. Relying on an automated dashboard that says 'System Healthy: Green' is not a control if you don’t know exactly what the green light represents or how it handles corrupted data inputs during a system crash.

The question for any practitioner this week is simple: do you have evidence of integrity, or just evidence of uptime?