OT Cybersecurity Due Diligence for M&A

Direct Answer

OT cybersecurity due diligence should identify conditions that can change valuation, terms, transition-service design, day-one controls, integration funding, or the decision to proceed. It should not end with a generic maturity score or rely only on management representations.

Key Takeaways

The legal deal perimeter may not match the operational technology perimeter.
Unsupported assets and shared services can become hidden integration liabilities.
Verified evidence should be separated from management representation.
Cyber findings should map to terms, funding, conditions, and day-one controls.
Diligence must respect operational and safety validation boundaries.

The Transaction Question Is Not Whether the Target Has Cyber Risk

Every industrial target has cyber risk. The transaction question is whether verified OT conditions change valuation, deal terms, separation design, day-one controls, integration funding, insurance assumptions, or the decision to proceed. A generic maturity rating rarely provides that answer.

Operational technology can create deal risk through unsupported systems, incomplete engineering records, shared identities, supplier-controlled access, transition-service dependencies, fragile recovery, and capital commitments that are not visible in conventional IT diligence. These conditions matter because the buyer inherits the ability—or inability—to operate, separate, integrate, and recover after close.

OT diligence should therefore begin early enough to influence the deal model. Findings discovered after signing often become urgent integration work, unplanned capital, or accepted operational risk when the buyer has less commercial leverage.

Expose technical debt

Assess support status, configuration knowledge, spare strategy, backups, engineering capability, integration complexity, supplier rights, and required outage. Technical debt can convert a low purchase price into a large post-close obligation.

Technical debt should be connected to an outcome: production stability, safe operation, separation timing, support continuity, recovery, or future capital. A list of unsupported devices has limited transaction value until the buyer understands which conditions can alter the deal thesis or post-close plan.

Convert findings into deal decisions

Map each material finding to price or reserve assumptions, representations, conditions precedent, transition services, insurance, integration funding, acceptance tests, and post-close validation. Preserve uncertainty and identify what evidence would change the decision.

A material finding should map to a commercial or operating response: price, condition precedent, representation, indemnity, transition-service obligation, insurance treatment, day-one control, integration budget, or post-close validation.

How OT Findings Should Change Valuation, Terms, and Integration Funding

Not every OT finding should change price, but every material finding should have a defined transaction response. A condition that can be corrected before close may become a deliverable or condition. A dependency that will continue under transition services may require service levels, evidence rights, incident duties, exit tests, and remedies. A structural limitation that the buyer will inherit may require a capital reserve, integration budget, insurance treatment, or explicit risk acceptance.

The transaction team should avoid converting technical uncertainty into a precise financial estimate without evidence. Cost ranges should state the affected cohort, outage assumptions, supplier dependence, engineering effort, validation needs, and contingency. Where the buyer cannot inspect the condition, the model should preserve a range and a post-close validation trigger rather than selecting the most favorable assumption.

Findings can also affect sequencing. A buyer may delay network consolidation until plant dependencies are understood, retain a transition identity service while dedicated administration is built, or prioritize supplier-route control before broader modernization. These choices should be visible in the integration thesis and owned before day one.

The strongest diligence output connects each material condition to one of five decisions: proceed without change, request more evidence, alter terms, design an interim day-one control, or fund structural correction. That decision map is more useful than a long list of observations because it gives the deal team an accountable next action.

Minimum Evidence Requests That Produce Transaction Leverage

Evidence requests should be narrow enough to receive a useful response. High-value requests include current site and process scope, remote-access paths and sponsors, privileged identity dependencies, authoritative configuration and backup sources, lifecycle and support commitments, critical supplier contracts, recent recovery exercises, and material open exceptions. The request should state why the evidence matters to the transaction.

When the seller cannot provide evidence, the absence is itself a decision input. It may justify a broader cost range, a pre-close deliverable, a transition obligation, a day-one control, or post-close validation. Diligence should not silently convert missing evidence into a low-risk conclusion.

The Investment Committee Readout

The final readout should separate verified condition, transaction implication, uncertainty, proposed response, cost or timing range, owner, and next validation. It should highlight the few findings that can change the deal rather than reproduce the complete technical workpaper. This gives the investment committee a defensible basis for terms, funding, or acceptance while preserving the evidence for integration teams.

A Clear Boundary for the Review

The review should state which sites, processes, suppliers, shared services, and evidence periods were included. It should also state which conditions could not be tested because of access, time, seller restrictions, or operating risk. This prevents a focused diligence exercise from being interpreted as assurance over the entire target.

CyberTech Intelligence Perspective

CyberTech Intelligence’s perspective is that OT diligence is a decision discipline at the intersection of corporate development, operations, engineering, security, legal, finance, and integration. The objective is not to certify the target. It is to expose the conditions that can change the transaction and preserve enough evidence for the buyer to act.

The most consequential conditions are often hidden in relationships rather than devices: shared identity, local vendor ownership, unsupported licenses, engineering repositories held by individuals, cloud support dependencies, or recovery procedures that rely on departing personnel. These dependencies should be tested against the deal perimeter and the day-one operating model.

The conversion value is a findings-to-terms and day-one plan. Diligence should leave the transaction team with specific decisions, owners, costs, deadlines, and validation steps—not an abstract cyber score.

CyberTech Intelligence Industrial Cyber Due Diligence Lens

The lens connects OT evidence to the deal thesis, commercial terms, and day-one operating protection.

Diligence element	Evidence required	Transaction decision
Operational deal perimeter	Entities, sites, processes, assets, suppliers, shared services, licenses, repositories, transition dependencies	Define what the buyer must operate, separate, or integrate.
Deal-thesis impact card	Production, safety, quality, customer, regulatory, capital, and timing consequences	Determine whether the condition changes valuation or willingness to proceed.
Technical-debt register	Support, configurations, spares, interfaces, backups, expertise, outage constraints, modernization commitments	Estimate corrective cost, sequence, and execution risk.
Inherited-trust map	Domains, cloud services, vendor routes, privileged identities, remote sites, shared infrastructure	Identify access and dependency that crosses the transaction boundary.
Supplier-rights matrix	Access, assignment, licensing, notification, lifecycle support, evidence, termination	Determine whether the buyer can control critical third parties after close.
Day-one control plan	Signing, close, day-one, transition, and target-state actions with tests and rollback	Protect the operating mission while structural work is pending.
Findings-to-terms matrix	Evidence, uncertainty, commercial response, owner, deadline, post-close validation	Translate cyber-physical conditions into transaction action.

The lens should preserve uncertainty. Limited access, compressed timelines, and seller constraints may prevent complete validation. The diligence output should state what is known, what remains assumption-based, and which post-close action is required to close the uncertainty.

A finding is material when it can change the economics, timing, operating model, or acceptance boundary of the transaction—not merely because it is technically severe.

Worked Deal Scenario: A Six-Plant Specialty Manufacturer

A buyer evaluates a six-plant manufacturer. Initial diligence finds unsupported HMIs, a shared corporate identity service, OEM routes managed by local vendors, incomplete controller backups, and a planned ERP separation that several plants depend on for production scheduling and quality records.

The operational perimeter review shows that legal separation can occur before technical independence. Shared identity and ERP dependencies will continue under transition services, while supplier routes are governed through local relationships that may not transfer. The buyer also cannot prove that the latest controller projects are available for every plant.

The transaction team converts the findings into decisions. The seller must provide authoritative configuration and supplier-access inventories before close. The transition agreement includes identity and ERP service levels, incident notification, evidence retention, and exit tests. The buyer funds day-one restrictions for the highest-consequence supplier paths, validates recovery for two critical lines, and includes a post-close capital reserve for unsupported systems.

Finding	Deal impact	Pre-close response	Day-one or post-close action
Shared identity across perimeter	Separation and privileged-access dependency	Define transition scope, service level, evidence, and exit condition	Create dedicated administrative paths and test separation.
Local OEM routes	Unclear rights, ownership, and incident accountability	Obtain route, contract, identity, and termination evidence	Restrict highest-consequence routes and recertify sponsors.
Incomplete controller backups	Recovery and integration uncertainty	Require authoritative configuration deliverables and validation access	Run restore and process-acceptance tests.
Unsupported HMIs	Future capital and outage requirement	Estimate cohort, consequence, support, and spares	Sequence modernization around planned outages.

The diligence does not eliminate risk. It changes the terms, funding, and sequence so the buyer does not discover the same conditions after leverage has shifted.

OT Cyber Questions for the Deal Team

Which processes, sites, suppliers, and shared services sit inside the operational deal perimeter?
Which cyber-physical conditions can change valuation, timing, customer commitments, or willingness to proceed?
Are authoritative configurations, backups, licenses, and engineering records available and transferable?
Which identities, routes, cloud services, and supplier platforms cross the legal boundary?
Can critical supplier rights and support obligations be assigned or terminated?
Which actions must occur before signing, before close, on day one, during transition, and in the target state?
What evidence remains unavailable, and how will the buyer validate it after close?
Which finding should change price, terms, transition services, insurance, funding, or risk acceptance?

The checklist should be used to improve the deal decision, not to promise a complete technical assessment under transaction constraints.

Transaction-Timed OT Cyber Workplan

Before signing: Test the deal thesis

Bound the operational perimeter, identify material dependencies, request decisive evidence, and connect findings to valuation, terms, or conditions.

Between signing and close: Design protection

Resolve priority evidence gaps, finalize transition obligations, build day-one controls, and assign integration funding and owners.

First 90 days: Validate and correct

Test inherited access, recovery, configurations, supplier rights, and separation assumptions. Convert provisional conclusions into funded corrective actions.

Common OT Diligence Failures

Starting after the deal model is fixed

Late findings have less ability to influence valuation, terms, and transition design.

Using enterprise IT maturity as a proxy

Plant operations, engineering dependencies, supplier access, and recovery conditions require separate evidence.

Listing technical debt without commercial consequence

The deal team needs cost, timing, dependency, and decision impact—not an unsupported-device count alone.

Assuming legal separation creates technical separation

Shared identity, cloud, repositories, suppliers, licenses, and transition services can preserve inherited trust after close.

Conclusion

OT cyber risk belongs in due diligence when it can change the deal. The buyer needs a defensible view of operating dependencies, technical debt, inherited trust, supplier rights, day-one controls, and unresolved evidence before leverage moves.

The Industrial Cyber Due Diligence Lens turns those conditions into transaction decisions and a post-close validation plan rather than a generic maturity rating.

Pre-Deal OT Cyber Risk Review

CyberTech Intelligence can support a bounded transaction review focused on the industrial conditions most likely to affect valuation, terms, transition, and day-one operation.