A target can appear commercially attractive while carrying security weaknesses that materially change the value of the deal. A ransomware event, an undisclosed regulatory exposure, or a dependency on unsupported systems can turn a post-close integration plan into an expensive recovery program. This M&A cyber diligence checklist example is designed to help buyers move from broad concern to evidence-based decisions before signing or closing.
The objective is not to produce a generic maturity score. It is to identify the cyber issues that could affect valuation, deal terms, regulatory approvals, operational continuity, and the realistic cost of integration. The scope should be proportionate to the transaction, but the questions should remain disciplined.
What cyber diligence must establish
Cyber due diligence should establish three things: the target's current exposure, the credibility of its security operating model, and the likely cost and time required to remediate material gaps. These are related but not interchangeable.
A company may have no known breach and still present significant risk because its detection capability is weak. It may hold an ISO 27001 certification while relying on a small number of individuals with no documented incident response process. Conversely, a target with visible control gaps may be a manageable acquisition if those gaps are understood, bounded, and priced into the deal.
For the buyer, the central question is practical: what could go wrong after control changes hands, and what must be done to prevent that outcome? The answer should feed directly into the investment committee paper, transaction documents, Day 1 planning, and the post-merger integration roadmap.
M&A cyber diligence checklist example
The following checklist is a practical starting point for a buy-side assessment. It should be tailored for the target's industry, geography, data profile, technology estate, and regulatory obligations. A financial services transaction subject to DORA, for example, requires more depth on digital operational resilience and third-party arrangements than a small software acquisition with limited regulated data.
1. Governance, accountability, and risk ownership
Begin with whether cyber risk has an accountable owner and a functioning decision process. Request the security strategy, risk register, recent board or executive reporting, policies, and evidence of management review. Determine whether security is managed as an operational discipline or handled reactively by IT staff alongside other priorities.
Assess whether material risks are recorded, assigned, funded, and tracked to closure. Look for a clear escalation path, defined risk acceptance authority, and evidence that leadership understands the most consequential exposures. Absence of formal documentation does not automatically make a deal unattractive, particularly in founder-led businesses. It does, however, increase key-person risk and the probability that remediation work will be more extensive than initially expected.
2. Incident history and resilience
Ask for a complete history of security incidents, ransomware events, material outages, fraud events, insurance claims, regulator correspondence, and customer notifications. Compare management's narrative with available evidence, including incident reports, service desk records, cyber insurance disclosures, and legal correspondence where appropriate.
Examine how the target detects, contains, investigates, and recovers from an incident. Test whether an incident response plan exists, when it was last exercised, and whether roles are understood beyond the security team. Backup arrangements deserve particular scrutiny: immutability, restore testing, recovery objectives, and coverage of critical systems matter more than a statement that backups are performed.
The diligence team should also establish whether an active compromise may be present. This may require targeted technical validation, such as endpoint telemetry review, identity analysis, external attack surface assessment, or a focused compromise assessment. The appropriate level of testing depends on access, timing, and deal sensitivity, but relying solely on questionnaires is rarely sufficient for a material transaction.
3. Identity, access, and privileged control
Identity is often the fastest route to material compromise. Review how users, administrators, contractors, and service accounts are provisioned and removed. Determine whether multifactor authentication covers remote access, cloud administration, email, privileged accounts, and critical business applications.
Focus on privileged access because it amplifies every other weakness. The assessment should establish whether privileged accounts are separately managed, monitored, and reviewed; whether shared administrator credentials exist; and whether third-party support teams retain persistent access. Dormant accounts, excessive permissions, and incomplete offboarding are common findings with immediate operational relevance.
4. Technology estate and security architecture
Develop a credible view of the target's environment: on-premises infrastructure, cloud services, endpoints, networks, business-critical applications, and operational technology where relevant. Asset inventories do not need to be perfect to be useful, but the target should be able to identify systems that support revenue, sensitive data, and core operations.
Review vulnerability management, patching performance, endpoint protection, logging, network segmentation, encryption, and configuration management. Pay close attention to unsupported operating systems, internet-facing services, exposed remote administration tools, and unmanaged cloud accounts. These findings should be tied to a realistic remediation plan rather than presented as a technical catalog.
Architecture should also be assessed against the buyer's integration strategy. A standalone business may tolerate controls that would be unacceptable once connected to the acquirer's network, identity platform, data environment, or shared services. This is where cyber diligence and integration planning must work together.
5. Data, privacy, and regulatory obligations
Identify what sensitive data the target holds, where it resides, how it is transferred, and who can access it. Relevant categories may include customer information, payment data, health data, employee records, intellectual property, source code, and confidential commercial information.
Review data retention, deletion, encryption, cross-border transfer arrangements, and privacy incident handling. Determine whether the target has contractual, legal, or regulatory obligations that could be triggered by a breach or a change in ownership. For regulated organizations, assess the maturity of the relevant compliance program rather than assuming a policy set demonstrates operational compliance.
The key output is not a broad statement that privacy risk exists. It is a clear view of potential exposure: regulatory notification obligations, contractual penalties, litigation risk, remediation cost, and constraints on integration or data migration.
6. Third parties, software, and concentration risk
A target's security posture is shaped by its suppliers. Review material cloud providers, managed service providers, payment processors, software vendors, outsourced development partners, and data processors. Establish whether the target maintains a current supplier inventory, performs risk assessments, and includes security, audit, notification, and termination provisions in its contracts.
Concentration risk matters as much as control language. A critical service operated by a single provider, a founder's personal account, or an unsupported specialist vendor can create a serious continuity issue. Review software licensing, open-source use, code repositories, secrets management, and dependency management where the target develops software. A buyer should understand not only whether software is secure, but whether it can legally and operationally be maintained after close.
7. People, culture, and operating capability
Security capability depends on people who can operate it. Assess the size, skills, retention risk, and location of the technology and security teams. Identify critical individuals whose departure would materially affect access, incident response, architecture knowledge, or regulatory compliance.
Training metrics and phishing results can provide useful context, but they should not dominate the assessment. More telling evidence includes how teams handle access reviews, change control, security exceptions, and incident escalation under pressure. Culture is difficult to measure in a short diligence window, yet it often determines whether remediation plans survive beyond the first few months.
Turning findings into deal decisions
A useful diligence report distinguishes between observations, control gaps, and deal-relevant risks. Each material finding should describe the affected business service, plausible threat scenario, likely impact, current control position, required remediation, accountable owner, estimated cost, and expected timeframe.
Prioritize findings through the transaction lens. A critical exposure may justify a condition to closing, a specific indemnity, a purchase price adjustment, or a dedicated remediation budget. A moderate gap may be better managed through a time-bound post-close plan. Not every weakness should delay a transaction, but no material weakness should be allowed to disappear into a generic integration workstream.
The final output should give executives no surprises: a concise risk position, a list of decisions required before close, and a Day 1 to Day 100 plan that assigns ownership and funding. Independent cyber diligence is most valuable when it converts technical evidence into choices the deal team can act on.
A well-run assessment does not promise that the target is breach-proof. It gives the buyer a defensible view of what is known, what remains uncertain, and what must happen next to protect the value of the acquisition.