A security questionnaire can tell an acquirer what the target believes. Due diligence should also test whether the available evidence supports that belief and identify conditions that could affect valuation, deal terms, integration sequencing, insurance or the first hundred days.

Begin with the transaction thesis

The review should reflect what the buyer is acquiring. A software company raises questions about source code, development access and customer data. A manufacturer adds plant continuity, vendor remote access and aging control systems. A carve-out may depend on shared identity, networks and security services that will disappear after close.

Translate the thesis into a short list of material scenarios. What would interrupt revenue? Which data sets drive regulatory exposure? Which systems must be separated on day one? Where could a past intrusion move into the buyer’s environment?

Ask for evidence behind the answers

Policy documents matter, but operating records show whether the policy is real. Useful evidence can include identity-provider configuration, privileged-account lists, endpoint coverage, external exposure, cloud inventory, vulnerability aging, backup test records, incident tickets and security exceptions. Sampling is often necessary. The sample and its limits should be stated.

Questions worth testing include:

  • Can the target identify every internet-facing service and its owner?
  • Are privileged and remote-access accounts protected by phishing-resistant controls where practical?
  • Which critical systems lack current endpoint or logging coverage?
  • Have backups been restored under realistic conditions?
  • Do past incidents have a documented root cause and verified closure?
  • What security capabilities depend on the seller or a departing provider?
  • Which remediation promises cannot be completed before close?

Separate present exposure from integration risk

A target can be reasonably secure as a standalone business and still create integration risk. Connecting directories, email tenants, remote tools or shared services expands trust. The diligence report should distinguish weaknesses that exist today from weaknesses created by the proposed operating model.

For a carve-out, document transition-service dependencies and their end dates. For a platform acquisition, assess whether the target can meet the buyer’s baseline without interrupting the business. For a distressed transaction, identify the minimum controls required before connectivity or data migration.

Turn findings into deal decisions

A useful report does not stop at high, medium and low. It groups findings by decision: remediate before close, address through a covenant, adjust the integration plan, reserve budget, seek additional representation, limit connectivity or accept with a named owner.

Estimates should show their assumptions. Replacing an unsupported system may require process redesign, validation, downtime and training, not merely a license purchase. A short-term compensating control may reduce exposure while the durable repair is planned.

A defensible pre-close record

  1. Define the business scenarios that matter to the deal.
  2. Record which claims were tested and which were accepted without validation.
  3. Preserve the evidence set and the date it reflects.
  4. State exclusions caused by time, access or seller restrictions.
  5. Assign each material item to a deal or integration decision.
  6. Carry unresolved assumptions into the closing and first-day plan.

The NIST Cybersecurity Framework 2.0 places cybersecurity supply-chain risk within governance and calls for due diligence before formal supplier relationships. NIST SP 1305 provides a concise quick-start guide for that work. Public companies should also consider the SEC’s cybersecurity risk management and incident disclosure rule with securities counsel.

Deal context: Cyber diligence is one part of transaction diligence. The scope, materiality standard and use of findings should be set with deal counsel, the buyer and the relevant technical owners.