Cybersecurity Due Diligence for Technology Company Acquisitions

Cybersecurity due diligence decides whether a technology acquisition is buying a product or buying a breach. A target can show impressive engineering, growing recurring revenue and a clean profit and loss account while carrying unpatched infrastructure, shared administrator credentials, undisclosed incidents and customer contracts promising security standards it does not meet.

This guide sets out a practical twelve-point review for buyers of Vietnamese and regional technology companies: what to inspect, what evidence to demand instead of accepting policy documents, which cybersecurity due diligence findings are deal breakers, and how to convert the rest into conditions precedent, specific indemnities and price adjustments before signing.

Cybersecurity failures can destroy the value of a technology acquisition through outages, data loss, customer claims and regulatory action. A target may present modern products while relying on weak access controls, unsupported systems or unresolved vulnerabilities.

This guide explains how buyers should conduct cybersecurity due diligence for a technology company acquisition in Vietnam and connect cybersecurity due diligence findings to valuation, closing conditions and post-closing integration. It complements personal data protection diligence.

Why cybersecurity due diligence matters in technology M&A

Technical weaknesses may remain hidden until integration or a major incident. The buyer must understand not only whether a breach has occurred, but whether the target can prevent, detect, contain and recover from future events.

1. Map critical systems and data

Identify products, source-code repositories, cloud services, networks, endpoints, databases, APIs and third-party platforms. Classify them by operational importance and data sensitivity.

Cybersecurity due diligence starts with an inventory, not an opinion. Ask for a current asset register covering production applications, databases, internet-facing endpoints, third-party integrations and administrative tooling, then a data flow map showing where personal data, payment data and source code are held, who can reach them and which of those locations sit outside Vietnam. Where the register is incomplete or maintained manually in a spreadsheet, treat that as a finding in itself: an organisation that cannot list its own internet-facing assets cannot credibly warrant that they are patched, monitored or contractually permitted to hold the data they contain.

2. Review cybersecurity governance

Examine policies, responsible personnel, reporting lines, risk assessments, budgets and management oversight. Confirm whether security decisions are documented and tracked to completion.

Governance determines whether controls survive after closing. Establish who owns security, whether that person reports independently of the engineering delivery function, what budget they control, and whether the board receives regular reporting on risk and incidents. Ask for the last two board packs and the risk register rather than the policy library. Cybersecurity due diligence should also test whether policies are lived: sample joiner, mover and leaver records, security training completion, and evidence that exceptions to policy are logged and approved rather than granted informally by whoever is available.

3. Assess identity and access management

Review privileged accounts, multi-factor authentication, password controls, joiner-mover-leaver procedures and periodic access reviews. Test whether former employees, contractors or shared accounts retain access.

Access control is where most findings cluster. Obtain a full list of privileged accounts across cloud consoles, production databases, source repositories and payment systems, and reconcile it against current headcount. Look for shared administrator credentials, service accounts with static keys, contractors retaining access after engagement end, and multi-factor authentication that is available but not enforced. Orphaned administrator accounts belonging to departed staff are a common and serious result of cybersecurity due diligence, and revoking them is usually the clearest candidate for a pre-closing condition because the remedy is cheap, immediate and verifiable.

4. Examine cloud and infrastructure security

Review architecture, segmentation, configuration management, encryption, key management, logging and administrative access. Identify public storage, exposed services and dependence on individual cloud accounts.

Request the cloud account structure, network segmentation design and the output of the provider security posture tooling rather than a narrative description. Publicly readable storage buckets, databases exposed to the open internet, absent encryption at rest, over-broad identity roles and unrestricted outbound traffic are all objectively verifiable. Cybersecurity due diligence should also confirm who holds the root or owner credentials for each cloud tenancy, because a target whose infrastructure sits inside a founder personal account creates both a security exposure and a transfer problem that has to be resolved before closing.

5. Review secure software development

Assess coding standards, peer review, testing, secrets management, deployment approvals and separation of development and production. Confirm how vulnerabilities are prioritised and fixed.

Examine how code reaches production. Look for mandatory peer review, branch protection on the main branch, separation between development and production environments, secrets held in a managed vault rather than in the repository, and automated static analysis in the build pipeline. Ask whether any developer can deploy to production unilaterally. In a technology acquisition, cybersecurity due diligence findings here predict future incidents better than any policy document, because weak release controls reintroduce vulnerabilities faster than a remediation programme can close them.

6. Analyse open-source and supply-chain risk

Identify software components, versions, known vulnerabilities and update processes. Review vendors with network or production access and determine whether their controls are monitored.

Obtain a software bill of materials and review it for unsupported components, packages with known critical vulnerabilities, and dependencies maintained by a single unaffiliated individual. Separately, list the third parties that hold target data or connect into its systems, and check what security terms and audit rights the contracts actually contain. Supply-chain exposure is frequently the least documented area in cybersecurity due diligence, and it is the area where the buyer inherits obligations it cannot renegotiate quickly after closing.

7. Evaluate vulnerability management

Request penetration tests, scans, remediation logs and exception approvals. Verify whether critical cybersecurity due diligence findings were fixed and whether testing covered internet-facing and production environments.

Ask for the last two external penetration test reports, the internal vulnerability scan output, and the remediation tracker showing what was fixed and when. The useful metric is not the number of findings but the time taken to close critical items and whether the same finding recurs across successive tests. A target that commissions tests but does not remediate has documented its own exposure, and that documentation will be available to a regulator or a claimant later.

8. Review incident history

Examine ransomware, phishing, data leakage, fraud, outages and suspected intrusions. Review forensic reports, notifications, root-cause analysis and remediation. Compare incident logs with insurance and customer disclosures.

Request a complete incident log for at least three years, including ransomware, business email compromise, credential stuffing, insider misuse and data loss, together with any notifications made to authorities, customers or affected individuals. Cybersecurity due diligence should test the log against external evidence: cyber insurance claims history, legal fees, credit monitoring costs and unusual entries in the general ledger. An incident that was contained and properly notified is a manageable finding; an incident that was concealed changes the buyer view of management as much as it changes the risk assessment.

9. Assess monitoring and detection

Review logging coverage, alerting, security operations, endpoint detection and escalation. Determine whether logs are protected, retained and actively reviewed.

Determine whether the target would know it had been compromised. Check that logs from cloud, identity, endpoint and application layers are centrally collected, retained for a defined period, and actually alerted on, and ask who responds outside business hours. Confirm whether there is a tested incident response plan naming decision-makers, external forensic and legal support, and notification timelines. Detection capability is what separates a contained incident from a breach that runs undetected for months.

Ask specifically how long logs are retained. If retention is thirty days and an intrusion is discovered in month three, the buyer will never establish what was taken, which converts a quantifiable incident into an open-ended exposure that no seller will indemnify on acceptable terms.

10. Test backup and recovery

Understand backup scope, isolation, encryption, retention and restoration tests. Compare recovery objectives with contractual service levels and operational needs.

Backups are only as good as the last successful restore. Ask for evidence of restore testing, the recovery time and recovery point objectives the business actually commits to customers, and confirmation that backups are immutable or otherwise isolated from the production identity plane. Cybersecurity due diligence routinely finds backups that exist but are reachable using the same administrator credentials as production, which means a ransomware operator would encrypt both. Where the target commits to availability service levels, reconcile those commitments against tested recovery capability.

11. Review customer and regulatory commitments

Examine security clauses, audit rights, certifications, incident-notification duties and representations made in tenders. Identify gaps between promised and actual controls.

Read the security schedules in the material customer contracts, not just the commercial terms. Enterprise customers frequently impose certification requirements, audit rights, breach notification windows measured in hours, data residency restrictions and uncapped liability for data incidents. Cybersecurity due diligence must then check compliance against Vietnamese requirements, principally Decree 13/2023/ND-CP on personal data protection together with the Law on Cybersecurity 2018 and the Law on Network Information Security 2015, and confirm which regime applies to the specific data and sector at the signing date, since the framework has been tightening.

12. Plan integration risk

Connecting networks and sharing credentials can transmit vulnerabilities to the buyer. Define pre-connection testing, account controls, segmentation and a staged integration plan.

Connecting a weakly secured target to the buyer network transfers the risk rather than containing it. Agree an integration sequence that keeps the environments separate until agreed remediation is complete, defines which identity systems are merged and when, and assigns budget and ownership for the work. Cybersecurity due diligence findings should feed directly into the first hundred days plan, with named owners and dates, because remediation commitments that are not funded and scheduled before closing are rarely delivered afterwards.

Worked example: converting a cybersecurity finding into deal protection

Consider a hypothetical SaaS target where cybersecurity due diligence reveals that the company’s incident log shows a customer database was briefly exposed to unauthenticated access roughly eight months before the transaction, due to a cloud storage misconfiguration. The company remediated the misconfiguration within days of discovery but never formally assessed whether the exposure met the threshold for a notifiable data breach, and no notification was made to affected customers or regulators.

In this hypothetical, buyer’s counsel would typically commission an independent forensic review to determine the scope of data actually accessed, then negotiate a specific indemnity for any resulting regulatory exposure or third-party claims, combined with a pre-closing requirement that the seller complete a proper breach assessment and, if required, make a corrective notification before closing. This mirrors the risk-quantification and remediation-covenant approach used across other technical diligence areas: the finding is converted into a bounded, priced risk rather than left as an open-ended unknown. This structure is illustrative only; the appropriate remedy depends on what the forensic review actually finds.

Key red flags

• No reliable inventory of systems, data or privileged accounts.
• Multi-factor authentication is absent from critical services.
• Unsupported software or unresolved critical vulnerabilities remain in production.
• Source-code or cloud credentials are shared or embedded in repositories.
• Incident logs conflict with customer or insurer disclosures.
• Backups have not been restored in testing.
• Vendors retain broad, unmonitored access.
• Security promises exceed actual capabilities.

Treat the following as escalation points rather than routine findings: administrator accounts without multi-factor authentication, production data copied into development environments, no external penetration test in the last two years, an incident that was never notified despite an apparent obligation, source code held in a repository controlled by a departed founder, and customer contracts promising a certification the target does not hold. Each of these has been the subject of adverse cybersecurity due diligence findings that materially changed deal terms.

Where two or more of these appear together, treat the pattern rather than the individual item as the finding, because it usually indicates that security decisions are being made informally by whoever is closest to the problem. In that situation, extend the scope of cybersecurity due diligence rather than pricing what has been seen so far, since the sample suggests the register is incomplete.

Turning cybersecurity due diligence findings into transaction protection

Critical remediation, credential rotation, incident investigation and vendor changes may be conditions precedent. Quantified costs can support a price adjustment, escrow or specific indemnity. Representations should cover incidents, vulnerabilities, access, backups, compliance and accuracy of security disclosures.

The buyer should coordinate cybersecurity due diligence findings with intellectual property and software diligence and establish a risk-based post-closing security plan.

Map every material finding to a remedy before drafting. Incurable or licence-critical issues become conditions precedent with a long-stop date. Identified incidents and known regulatory exposure become specific indemnities outside the general cap and basket. Systemic weaknesses become warranties on compliance, incident history and customer commitments, with a claim period longer than for general business warranties because breaches surface late. Quantified remediation cost comes off the price. Cybersecurity due diligence delivers value only when each of these mappings appears in the signed agreement.

Conclusion

Effective cybersecurity due diligence combines documents, interviews and technical testing. The buyer should finish with a verified risk register, immediate containment actions, budgeted remediation and safe integration milestones.

Frequently asked questions about cybersecurity due diligence

What does cybersecurity due diligence cover in an acquisition?

It covers the target technical estate and the legal commitments attached to it: critical systems and data flows, security governance and ownership, identity and access management, cloud and network configuration, secure development practice, open-source and supply-chain exposure, vulnerability and patch management, incident history, monitoring and detection, backup and recovery testing, and the security and data protection promises made in customer contracts and regulatory filings.

How is cybersecurity due diligence different from IT due diligence?

IT due diligence asks whether the technology can support the business plan: architecture, scalability, technical debt, licensing cost and engineering capability. Cybersecurity due diligence asks whether the estate is defensible and whether the target has already been compromised or has already breached its obligations. The two overlap but reach different conclusions, and a target can pass one comfortably while failing the other.

What are the main data protection rules to check in Vietnam?

Verify how the target collects, processes, stores and transfers personal data against Vietnam personal data protection framework, principally Decree 13/2023/ND-CP together with the Law on Cybersecurity 2018 and the Law on Network Information Security 2015. Check whether required impact assessment dossiers and cross-border transfer records have actually been prepared and filed, and confirm the position in force at signing, because the regime has been tightening and obligations differ by sector.

Should an undisclosed security incident stop a deal?

Not automatically, but it changes the process. An undisclosed incident raises three questions: whether notification obligations to authorities, customers and data subjects were met, whether the attacker retains access, and what the incident says about management candour. Until a forensic assessment confirms containment, the right response is usually to suspend signing rather than to price the risk, because the exposure cannot be quantified while the compromise may still be live.

How do you protect against cybersecurity risk in the contract?

Use layered protection. Make remediation of critical vulnerabilities and revocation of orphaned administrator accounts a condition precedent, take specific indemnities for identified incidents and for regulatory exposure arising before closing, obtain warranties on compliance, incident history and customer commitments with a longer claim period than general business warranties, and secure the package with escrow or a holdback sized to the realistic cost of notification, remediation and customer compensation.

Next step

Confirm that the corporate approvals for the share transfer, and any change of control consents the target has given to customers, are consistent with the shareholder and board authority rules in the Law on Enterprises 2020 before you commit to a signing date.

IVLF Lawyer advises acquirers of software, platform and data-driven businesses in Vietnam, from scoping the technical and legal review to negotiating the security warranty and indemnity package. If you need a Vietnam M&A lawyer for technology transactions, see our legal services or contact IVLF Lawyer.

Related reading: Technology M&A in Vietnam: software, data and intellectual property, Personal data protection due diligence in Vietnam M&A, and Intellectual property and software due diligence in Vietnam.