Start with the business being acquired
Cybersecurity due diligence should explain the operating risks a buyer is taking on. A questionnaire can start the conversation, but the review needs evidence about the systems, people and suppliers that keep the target running. It also needs to show where the available information is incomplete.
Begin with the acquisition rationale. A software company, an industrial operator and a services business will have different dependencies. Identify the services that generate revenue, the information customers entrust to the company and the systems whose loss would interrupt delivery. Use those priorities to decide where deeper investigation is justified.
1. Agree the review boundary and evidence access
Specify which entities, locations, cloud accounts, products and shared services are included. A carve-out needs particular attention to systems that remain with the seller. Establish who can supply evidence, how sensitive material will be handled and which technical checks are authorized. Record exclusions before they become assumptions.
Request a compact initial evidence set. Ask for dates and scope on every item so the team can distinguish a current operating record from an old policy. NIST’s supplier due-diligence guide emphasizes validating findings against multiple sources where possible. It concerns ICT suppliers; that evidence discipline is also useful when reviewing acquisition dependencies. [1]
- Critical-service map, asset inventory and network or cloud diagrams.
- Privileged-access records and identity-control configuration.
- Recent incident summaries and remediation records.
- Vulnerability findings with evidence of closure or accepted exceptions.
- Recovery-test results and critical supplier information.
2. Examine who can reach critical systems
Trace administrative access across identity systems, cloud environments, endpoints, source-code repositories and backup platforms. Include service accounts and outsourced support. Review how access is granted, strengthened with multifactor authentication, periodically checked and removed. Sample actual configuration and recent access changes rather than relying entirely on the written process.
NIST’s zero-trust guidance rejects implicit trust based solely on network location or asset ownership. [2] Apply that principle to the review: an internal account or a trusted supplier connection still needs a clear purpose and appropriate authorization. Unclear ownership of powerful accounts deserves a specific finding and a remediation owner.
3. Understand incident history and recovery evidence
Ask what was detected, how the scope was established and which corrective actions were completed. Compare incident summaries with available investigation and remediation records. A statement that there have been no incidents is difficult to interpret without understanding monitoring coverage and retained evidence. Missing records should be recorded as uncertainty, without assuming either compromise or a clean history.
Request the most recent restoration exercise for a critical service, including elapsed time, dependencies and unresolved failures. CISA recommends protecting backups and regularly testing their availability and integrity. [3] Check whether the business actually restored a usable service, who validated it and what has changed since the exercise.
4. Separate enterprise security from product security
If the target develops software, review how it protects the products delivered to customers as well as its own office systems. CISA’s Secure by Demand guide explicitly distinguishes these areas. [4] Ask how vulnerabilities are reported, investigated and fixed; how releases are protected; and what security support customers receive. Inspect a recent example of the process with sensitive details appropriately limited.
Map critical hosting, identity, support and software dependencies. Identify who controls them and what evidence supports their reliability. NIST’s supplier guide includes provenance, resilience and supply-chain tiers among its assessment areas. [1] For the transaction, turn that into a practical question: which dependencies must continue working while ownership and operations change?
5. Review the planned integration before connecting
An acquisition changes access relationships. Review proposed identity federation, remote administration, network connections and data transfers before enabling them. Identify which connections are essential on the first day and which can wait for further verification. Shared ownership alone does not establish that a connection is safe; this follows the access principles in NIST’s zero-trust guidance. [2]
For each necessary connection, name its owner, permitted use, monitoring and removal procedure. Check who handles an incident during the transition. Where a service remains with the seller, document the operational dependency and the evidence required before moving it. Treat integration as a sequence of controlled changes.
6. Make each finding useful to the deal team
Describe the affected service, the observed weakness and the plausible operating consequence. Attach the supporting evidence and state its age and limitations. Then specify what needs to change, who can do it and what will demonstrate completion. Keep confirmed weaknesses separate from questions that require more access or information.
NIST’s Current and Target Profiles provide a way to compare an organization’s present cybersecurity position with its intended outcomes. [5] Use that structure to prioritize the work. An unsupported system supporting a critical service may need a different treatment from a documentation gap in a well-controlled area. Record the reasoning behind that distinction.
7. Leave the meeting with decisions and owners
Prepare a short decision brief alongside the detailed findings. State what needs clarification before the transaction decision, what must be addressed before systems connect and what can enter an agreed improvement plan. Put unresolved evidence requests in the brief as well; silence should not be mistaken for assurance.
Use a concrete entry such as: privileged access to the backup environment has not been verified; obtain the account inventory and review the access configuration before granting shared administrative access. That connects the missing evidence to an operational decision without pretending to quantify its effect on the purchase price.
The buyer should finish with an accountable owner for each action, a realistic sequence and a verification method. Refresh material findings if the target changes systems or experiences an incident before completion. This keeps the review connected to the business that will actually be acquired, rather than the snapshot first presented in the data room.
