Incident Forensics vs. Disclosure Timelines: The Manufacturing Double Bind

By Roger Hill

OT incident investigation takes weeks or months. The SEC wants a materiality determination “without undue delay.” Welcome to the hardest operational problem in cybersecurity disclosure.

You Cannot Image a Running PLC

Let me describe something that happens in IT incident response so routinely that nobody thinks about it anymore.

An analyst detects anomalous activity on a server. Within hours, the IR team creates a forensic image of the affected system. They pull logs from the SIEM, correlate network traffic data, and begin mapping the scope of the compromise. Within days, sometimes hours, they have a reasonable picture of what happened, what was accessed, and what the blast radius looks like.

That picture may not be complete, but it is sufficient for a materiality determination. The disclosure committee can assess whether the incident is likely to have a material impact on the company. If it is, they file a Form 8-K within four business days of that determination. If additional facts emerge later, they amend the filing.

Now let me describe what happens when the incident is on the plant floor.

An operator notices unexpected behavior in a batch process. A reactor temperature is climbing faster than the recipe profile allows. The process alarm triggers. The operator manually intervenes and brings the process to a safe state. Production on that line stops.

The investigation begins. And immediately, everything that works smoothly in IT forensics breaks down.

The PLC controlling the batch process does not have forensic imaging capability. You cannot take a snapshot of its memory state in the way you image a server hard drive. The PLC may be running proprietary firmware from a vendor who does not provide forensic tools. The program logic on the controller may have been modified by the attacker, but comparing the current program to the last known good version requires engineering tools specific to that vendor’s platform, and someone who knows how to use them.

The PLC’s logging capability is minimal. Industrial controllers were designed to control physical processes reliably and quickly, not to generate audit trails for cybersecurity investigations. You may have timestamps for alarm events, but you are unlikely to have a record of when the program was modified, from which workstation, or by what user account.

The historian, if one exists, captured process data showing the temperature deviation. But the historian records process variables, not cybersecurity events. You know the temperature went wrong. You do not know why from the historian data alone.

The network monitoring on the OT side, if it exists, may show traffic patterns. But many manufacturing networks still lack the visibility tools that are standard in IT environments. And even where OT network monitoring is deployed, interpreting the data requires expertise that sits at the intersection of control systems engineering and cybersecurity, a combination of skills that is genuinely rare.

Meanwhile, the most critical question remains unanswered: was this a cyberattack, or was this a malfunction? A PLC program error, a sensor failure, a power quality issue, and a deliberate cyber manipulation can all produce similar symptoms. Distinguishing between them requires a level of investigation that takes weeks, not days.

And while your OT investigation team is trying to answer that fundamental question, your disclosure committee is asking: “Do we need to file?”

The Double Bind

This is the manufacturing double bind. The SEC requires materiality determinations to be made “without undue delay.” The Commission has made clear that companies cannot deliberately slow-walk a materiality assessment to avoid the four-day filing clock. But the forensic realities of OT environments mean that you genuinely may not know what happened, or even whether a cybersecurity incident occurred, within any timeframe that the SEC’s framework contemplates.

In IT, the forensic timeline and the disclosure timeline are mismatched but manageable. You know you had a breach within hours. You may not know the full scope for weeks, but you know enough to assess materiality.

In OT, the forensic timeline and the disclosure timeline can be fundamentally incompatible. The initial symptoms of a cyber event may be indistinguishable from an operational malfunction. Confirming that a cybersecurity incident occurred, much less assessing its scope and impact, may take longer than the SEC’s framework assumes is reasonable.

This creates three scenarios, all of them bad:

Scenario 1: Premature disclosure. You file a Form 8-K based on incomplete information, disclosing a potential cybersecurity incident that may turn out to be a process malfunction. You have alarmed investors, depressed your stock price, and triggered media coverage for an event that may not have been a cyberattack at all. If it turns out to be a false alarm, you have undermined your credibility with the market. If it turns out to be worse than initially assessed, you face accusations of inadequate initial disclosure.

Scenario 2: Delayed determination. You take the time needed to properly investigate the OT event before making a materiality determination. The investigation takes three weeks. The SEC later questions whether you made the determination “without undue delay.” Your argument that OT forensics inherently require more time may or may not satisfy regulators who built their framework around IT incident timelines.

Scenario 3: Parallel track chaos. You try to run the forensic investigation and the materiality assessment simultaneously. Your OT investigators are providing preliminary findings to the disclosure committee while the investigation is still active. The materiality assessment keeps shifting as new information emerges. The disclosure committee cannot make a definitive determination because the facts keep changing. You end up filing an 8-K that is vague enough to be almost meaningless, then amending it repeatedly as the investigation progresses.

I have watched all three of these scenarios play out in various forms at manufacturers dealing with OT events. None of them end well. But the third one is the most common, and it is the most dangerous, because it creates a paper trail of evolving materiality assessments that plaintiffs’ attorneys will later use to argue that the company knew the incident was material earlier than it admitted.

Why OT Forensics Are Fundamentally Different

Let me be specific about the forensic challenges, because this is where the disconnect between the SEC’s framework and manufacturing reality is sharpest.

Evidence Volatility

In IT, evidence can be preserved. You image the drive. You export the logs. You capture the network traffic. The evidence exists independently of the running system.

In OT, much of the evidence is volatile and exists only in the running state of the controller. PLC memory can be overwritten by normal operations. Process data in controller buffers has limited retention. If you need to restart a process (which you may need to do for safety or production reasons), you may destroy evidence in the process. The act of making the plant safe can eliminate the forensic data you need to investigate the event.

Investigation vs. Operation Conflict

In IT, you can take a compromised system offline for investigation without shutting down the entire business. In OT, the compromised system may be the only thing standing between a safe process state and a dangerous one. You cannot pull a PLC out of a running chemical process for forensic examination. You may need to keep the potentially compromised system running while you investigate it, which limits your forensic options and extends the investigation timeline.

Expertise Scarcity

IT forensic investigators are a well-established profession with certifications, tools, and methodologies. OT forensic investigators barely exist as a category. The work requires someone who understands both control systems engineering and cybersecurity forensics. The global pool of people with this combined expertise is measured in hundreds, not thousands. When you need one during an active incident, they may not be available. And if you do not already have a relationship with an OT forensic specialist, you are not going to find one in the middle of a crisis.

Vendor Dependencies

OT forensics often require cooperation from the control system vendor. Analyzing PLC program modifications may require vendor-specific engineering software. Understanding whether a firmware anomaly is an attack or a bug may require vendor engineering support. Those vendor relationships operate on their own timelines. A vendor may take days to respond to a support request, and weeks to provide the kind of deep analysis needed for forensic conclusions.

Multi-System Complexity

A modern manufacturing process involves dozens or hundreds of controllers, multiple communication protocols, and layers of supervisory systems. An attacker who compromises one PLC may have moved laterally through the control network. Scoping the full extent of the compromise requires examining every controller in the affected network segment. That is not a four-day exercise. It is a multi-week campaign.

What Smart Manufacturers Are Doing Differently

The manufacturers who are ahead of this problem are not waiting for an incident to figure out their forensic-to-disclosure pipeline. They are building it now, and they are designing it around the unique realities of OT.

Pre-Incident Baselining

The single most valuable forensic preparation you can make in an OT environment is establishing baselines before an incident. Capture the known-good program state of every PLC. Document the normal process variable ranges. Record the baseline network traffic patterns. When an event occurs, having a baseline to compare against compresses the investigation timeline dramatically. Without a baseline, your investigators are starting from zero every time.

Tiered Determination Protocols

Rather than a single materiality determination process, build a tiered protocol that accounts for OT uncertainty. Tier 1: within 24 hours, assess whether the event could be cyber-related (based on initial indicators). Tier 2: within 72 hours, assess whether the event is confirmed or likely cyber-related (based on preliminary forensic findings). Tier 3: within 7 to 14 days, conduct the full materiality determination based on confirmed scope and impact.

This tiered approach allows you to escalate disclosure readiness in parallel with the investigation, rather than waiting for complete forensic conclusions before engaging the disclosure process.

Forensic Retainer Relationships

Do not wait until you need an OT forensic specialist to find one. Establish retainer relationships with firms that have demonstrated OT forensic capability. Define response time SLAs. Conduct annual tabletop exercises that include the forensic team, the OT operations team, and the disclosure committee working together on a realistic OT scenario.

Evidence Preservation Automation

Invest in OT-specific evidence preservation. This means automated PLC program backup systems that capture program states at regular intervals. Network recording capabilities in the OT environment that preserve traffic data for forensic analysis. Historian configurations that retain granular process data for incident investigation timelines. The goal is to reduce evidence volatility so that more data survives the initial response period.

Legal Pre-Authorization

Work with your general counsel now to pre-authorize investigation activities that might otherwise require approval during an incident. In IT, the IR team has standing authority to image systems and pull logs. In OT, investigative actions may require approval from operations, engineering, safety, and legal. Pre-authorizing standard forensic activities (PLC program captures, network recording activation, historian data preservation) eliminates delays that extend the investigation timeline.

The Disclosure Committee’s Homework

If you are on a disclosure committee at a publicly traded manufacturer, here is what you need to understand about OT forensics:

The initial report from an OT event will be ambiguous. Accept this. The first 48 hours of an OT investigation will not produce the kind of definitive findings you are accustomed to receiving from IT incident response. You will be making decisions with incomplete information. Build your process to accommodate that reality.
“We don’t know yet” is a legitimate forensic finding. The SEC’s guidance allows for amended filings. If you determine that an event is likely material but the full scope is not yet known, you can file an initial 8-K with what you do know and amend it later. This is not ideal, but it is far better than either premature certainty or delayed determination.
Document your decision-making process in real time. The SEC will evaluate whether your materiality determination was made “without undue delay” based on the totality of the circumstances. If your records show that you were actively investigating, regularly assessing incoming information, and making determination decisions as facts became available, you are in a defensible position. If your records show a gap between when information was available and when you acted on it, you are not.
The forensic timeline is a risk factor in itself. Your 10-K disclosure should acknowledge that OT incident investigation takes longer than IT incident investigation. Investors deserve to know that in the event of an OT cyber incident, the company’s ability to fully scope the event will be constrained by the inherent forensic limitations of industrial control systems.

What You Can Do Now

Map your OT forensic capability today. Can you capture the current program state of your most critical PLCs within 24 hours of an event? If not, that is your first gap to close.
Build a tiered materiality determination protocol. Define what information triggers each tier, who is responsible at each tier, and what disclosure actions correspond to each tier.
Identify your OT forensic resources before you need them. Internal, external, or both. Establish the relationships now. Test them with tabletop exercises.
Invest in evidence preservation infrastructure. Automated PLC program backup, OT network recording, and historian data retention are not luxuries. They are the foundation of defensible disclosure.
Pre-authorize forensic investigation actions. Work with legal, operations, and safety to establish standing authorization for standard OT forensic activities.

What Comes Next

Next week, we shift from problems to solutions. I will walk through a practical framework for building a board-ready OT materiality framework before you need it. The framework addresses all five impact dimensions (production, safety, environmental, regulatory, and insurance/liability) and gives your disclosure committee a structured process for making OT materiality determinations under pressure.

The manufacturers who build this capability now will be the ones who navigate their first OT disclosure successfully. The ones who wait will discover that you cannot build a forensic-to-disclosure pipeline during an active incident any more than you can build a fire escape while the building is burning.

Thanks for reading! Have you ever tried to investigate an OT cyber event under time pressure? What was the hardest part: the forensics, the decision-making, or the communication between the technical team and the business? We want to hear what breaks first in practice.

This is part 3 in a series, you can catch up here:

https://www.linkedin.com/embeds/publishingEmbed.html?articleId=7190093531490079180