Cyber due diligence before an acquisition: evidence for the investment decision

TRUST-IT · Content reviewed 6 October 2026

Start with the investment thesis and the transaction boundary

A buyer acquiring a software platform needs different evidence from an investor taking a minority position in an industrial business. Identify what gives the target its value: proprietary code, customer data, availability of a service, regulated operations or trusted distribution relationships. Map the systems, entities and suppliers that support that value. The assessment should follow those dependencies instead of producing an undifferentiated list of vulnerabilities.

Agree the permitted methods, access, reviewers and escalation route before collecting material. A data-room invitation does not authorise active testing of production or third-party infrastructure. For a carve-out, distinguish assets that transfer from services retained by the seller. Record what cannot be examined and the decision that missing evidence prevents.

Build a claim-to-evidence register

Ask the target to connect each material assertion to a dated record: asset coverage, privileged access, incident handling, restoration, software release or supplier oversight. Record the owner, system, relevant period, collection method and any exclusions. Classify each assertion as evidenced within scope, partly evidenced, contradicted or unverified. An unanswered question remains a gap; it should not silently become either a clean result or a confirmed incident.

A certificate or penetration-test summary is useful context, but check its scope, exclusions, date, tested environment and treatment of unresolved findings. A screenshot of a dashboard may establish a displayed setting at one point in time. An export covering the defined population, together with sampled operational evidence, supports a different level of confidence.

Related primary guidance: NIST Cybersecurity Framework

Test the dependencies that could interrupt the investment

Examine the identity system, administrator recovery, domain and DNS ownership, cloud tenancy, code repositories, release pipeline, signing keys and critical providers. Ask whether a departed founder, seller or outsourced administrator retains a dependency that the buyer cannot independently operate. Evidence should distinguish ownership, billing, technical control and authority to transfer.

Availability requires more than a backup-success percentage. Inspect a relevant restoration exercise: what was restored, where, by whom, with which credentials and measured outcome. Compare the exercise to the actual critical service. A restored database without application secrets, configuration or identity dependencies does not establish recovery of the complete service.

Assess software and data boundaries where they matter

For a software target, select a release and trace a change from repository review to built artefact and deployment. Check which identities may alter the build, dependencies or production configuration, and what happens when an emergency change bypasses the normal path. Request inventories and provenance appropriate to the product rather than treating possession of a software bill of materials as proof that risk is controlled.

Review data flows, tenant separation, privileged support access, retention and third-party processing with the relevant specialists. Use synthetic data for any authorised boundary test. Separate observed technical behaviour from questions of contractual rights, regulatory applicability and intellectual-property ownership, which require the transaction’s legal advisers.

Related primary guidance: NIST SP 800-161 Rev. 1

Review incident history and unresolved uncertainty

Ask for a defined reporting period, the incident register, material investigation summaries, open remediation and relevant provider notifications. Cross-check a sample against operational records where access permits. The purpose is to understand exposure, response capability and residual risk, not to infer that every unexplained log entry indicates a breach.

If material is unavailable, explain why it matters and which alternative source might reduce uncertainty. Retention gaps, a recently replaced platform or restricted access can limit conclusions. “No evidence observed in the reviewed sources” is not equivalent to proving that no incident occurred. Keep that distinction visible in the investment-committee brief.

Separate pre-completion decisions from the integration plan

Classify findings by the decision they support. Some require further evidence before the buyer can make a decision; some need containment or an agreed owner before integration; others belong in the post-completion improvement plan. For each item, describe the affected dependency, credible business consequence, evidence strength, proposed action and verification method.

Security specialists can explain technical scenarios and remediation effort. Commercial terms, valuation, warranties, indemnities and conditions are decisions for the deal team and its advisers. Estimates should identify assumptions, supplier lead times and dependencies. Avoid combining speculative maximum losses into an apparently precise total risk figure.

Plan Day 1 access without creating a new exposure

Connecting two identity environments or granting administrators broad cross-company access can change the risk before remediation starts. Define the minimum connectivity needed at completion, with named owners, rollback arrangements and a staged integration plan. Establish who can revoke seller access and how essential services will continue while accounts and contracts transfer.

A transitional-services arrangement needs explicit technical boundaries, logging, access review, incident coordination and an exit test. Record the evidence that demonstrates independence from the seller. Revisit inherited permissions after migrations; an account disabled in the primary directory may leave active tokens, service identities or external guest access elsewhere.

Specify a report that the investment committee can use

Request a concise decision brief, a dependency map, the claim-to-evidence register, prioritised findings, limitations and an implementation backlog. Each finding should point to evidence and identify the person responsible for accepting or reducing the risk. Restrict sensitive technical detail to the people who need it.

Agree a follow-up checkpoint for unresolved evidence and a method to verify the highest-priority actions. The objective is a defensible decision within the assessed scope, followed by accountable integration work. A due-diligence review is neither a guarantee of future security nor a substitute for ongoing operational control.

Further reading

• NIST — Cybersecurity Framework
• NIST SP 800-161 Rev. 1 — Cybersecurity supply chain risk management

Put the guidance to work

Connect risk management, GDPR, NIS2, DORA, and ISO 27001 preparation with practical CISO and DPO support.