Acquisition Strategy
Program: Security Foundations, Governance and Risk Module: Personnel and Third-Party Security Submodule: Acquisition Strategy
Every acquisition — of software, hardware, a service, or a whole company — introduces cybersecurity risk. Software may ship with a backdoor. Hardware may hide implants in silicon you cannot inspect. An acquired company may bring disgruntled employees, weaker controls, and networks whose security posture is far behind your own — and the moment the networks connect, their weaknesses become yours.
Acquisition strategy is the discipline of integrating cybersecurity and risk-management considerations into every kind of purchase, contract, and merger — early enough to shape the deal, not so late that the deal shapes the security posture.
By the end of this submodule you will be able to speak to acquisition-strategy best practices from a cybersecurity and risk-management standpoint, and integrate those considerations into common deal shapes.
1. The Shapes of an Acquisition
"Acquisition" covers more ground than corporate M&A. Common categories, each with distinct risk profiles:
| Shape | Example | Primary risk theme |
|---|---|---|
| Hardware purchase | New fleet of delivery trucks with connected telematics; new office network gear | Firmware, supply-chain provenance, physical implants |
| Software purchase | New accounting package; new EMR system | Vulnerabilities, backdoors, insecure defaults, SDL maturity |
| Business function outsourcing | Moving customer service to another company or country | Data-residency, personnel security across borders, insider risk |
| Supplier relationships | New raw-materials supplier | Physical + logistical + supply-chain provenance |
| Third-party contracting | Engaging a firm to run pen tests, IR, or infra ops | See 03 · Vendor Risk Management |
| Merger and acquisition (M&A) | Buying or merging with another company | All of the above simultaneously, plus network merging, cultural fit, entitlement carry-over |
The rest of this submodule focuses on the highest-complexity case — M&A — because it composes every other risk theme. Individual categories are covered in the previous submodules.
2. Why M&A Is a Cybersecurity Event
Consider the typical trajectory of a growing company:
At the end of this diagram, security teams face:
- Multiple corporate networks interconnected.
- Multiple data centers owned or contracted.
- Multiple cloud tenants with different IAM, key management, and logging.
- Multiple third-party firms (customer service, ops) with tunnels into both sides.
- Sometimes multiple identity providers, MDM tools, EDR vendors, SIEMs.
The security question is no longer "is our data safe?" — it is "across how many trust boundaries is our data now traversing, and who owns each one?"
2.1 A cautionary case study
One financial-industry client had become genuinely hard to hack. Annual red-team engagements produced a shrinking list of findings, all of which were fixed. They ran proactive vulnerability scans, risk assessments, and adversarial simulations.
Then they acquired a small organization and merged the networks. The small company was orders of magnitude more vulnerable — and once the networks were joined, the red team's easiest path became: compromise the small company; use its authenticated trust into the client's network to pivot straight to the crown jewels.
Two lessons the case teaches:
- Post-merger security posture is a
min()operation across the two organizations, not an average. - Preserving the acquired entity as a separate network segment is not just an integration decision — it is a risk control.
The complete-separation alternative has its own costs, which we turn to next.
3. Complete Separation vs Full Integration
There is a spectrum, and both endpoints have failure modes.
| Approach | Advantages | Failure modes |
|---|---|---|
| Full integration — one domain, one IdP, merged networks | Cost synergies; unified culture; single view for the SOC | Weaker partner drags posture down; entitlement carry-over; unclear ownership during transition |
| Complete separation — networks and identities remain distinct | Weaker partner's compromise cannot pivot to strong partner | Duplicated controls; hard to enforce consistent security standards; monitoring gaps between the two SOCs; collaboration friction |
Most organizations land in the middle — connect at controlled interfaces (federated SSO, defined API gateways, network segments with explicit east-west rules) while keeping data planes separate until both sides meet a defined security baseline.
The specific questions to answer:
- How do we efficiently ensure the business on both sides is collaborating?
- How do we ensure two separate technology stacks are secured to similar standards?
- How do we verify that server-side security controls are being followed through on both sides of the house?
4. Minimum Cybersecurity Requirements
Before any deal closes, define a baseline that any acquired or merged entity must meet — and that any vendor must meet to remain in the extended enterprise. A working checklist:
- Access control — what are the minimum access-control requirements? Who gets access to which systems, how often is that access reviewed, and who approves it?
- Password policy — minimum length, complexity, breach-list checks, MFA where.
- Change-management criteria — process for introducing new hardware or software into the environment.
- Regulatory compliance — which legal or regulatory frameworks apply and are being met?
- Logging and monitoring — what is logged, retained where, and monitored by whom?
- Incident response — is there a documented IR plan and a way to invoke it?
- Backup and recovery — RPO/RTO documented and tested.
These are the acquisition-side counterpart to the vendor minimum-requirements in the previous submodule.
5. Pre-Deal Due Diligence
5.1 On-site assessments
The strongest evidence comes from on-site assessments — physical security and network security both — rather than self-assessment questionnaires. On-site work is usually written into the LOI / term-sheet and executed under NDA before the deal closes.
The same is a good idea for vendors and suppliers. In cybersecurity, default to "trust and verify", not "trust because we like them".
5.2 Document exchange
Structured document exchange between both parties helps neither side be surprised after the deal. Commonly requested:
- Security policies and standards.
- Latest penetration-test reports.
- Latest internal- and external-audit reports (SOC 2 Type II, ISO/IEC 27001 surveillance, PCI DSS AoC, HIPAA-related assessments).
- Vulnerability-scan summaries (external and internal).
- Incident registers for the past 12-24 months.
- IR runbooks.
- BCP and DR plans, with last-test evidence.
- Risk register with accepted risks.
- List of key vendors and their SOC 2 reports.
5.3 Policy and process review
Some organizations do not have basic policies documented. Confirm that they do, and then read them. Look for:
- What are their minimal cybersecurity requirements?
- How do they monitor compliance with those requirements?
- Which risks have they accepted, and does that acceptance match your appetite?
- Their business-continuity and disaster-recovery plans — what do they consider business-critical and how do they plan to safeguard it? Is it the same as what you would consider business-critical about them?
If the answer to any of these is "we don't have that", price the gap into the deal — either as a purchase-price reduction, a required investment before close, or a walk-away.
6. Software as an Acquisition — a Deep Dive
Software is the most common form of acquisition, and worth its own checklist. Key themes:
- Secure SDL adoption — is the entity using a recognized secure-software-development framework? The most common baseline is the OWASP Top 10; more mature programs adopt OWASP ASVS or Microsoft SDL.
- Adoption vs training — do engineers use the framework, or just complete an annual training on it?
- Periodic testing — do they run SAST, DAST, SCA, and penetration tests, and act on the findings?
- Data-security compliance — do they meet the data-security regimes you rely on? Notably:
- HIPAA if you are a US healthcare company or one of its business associates.
- PCI DSS if you handle payment cards.
- GDPR if you acquire an entity in the EU (or serve EU residents).
- PIPEDA / CCPA / LGPD / others for the appropriate jurisdictions.
- New legal and contractual obligations — an acquired company may bring new regulators into scope. Acquiring a European entity now puts GDPR on your ledger; a US hospital brings HIPAA.
- Vendor lock-in and technical debt — see next section.
7. Vendor Lock-In and Technical Debt
Two of the most-underestimated acquisition risks:
- Vendor lock-in — how difficult would it be to move off the acquired vendor or technology if it becomes necessary?
- Technical debt — long-lived unpatched systems that cannot easily be upgraded.
Hospitals in particular are known to run decades-old medical software or hardware because the original vendor is defunct and migration is prohibitively expensive. It is not unusual for an assessment to uncover systems still running end-of-life operating systems whose migration cost runs into the millions — more than the organization can afford — so they continue to run legacy, formally accepting the associated risk.
The correct questions to ask any prospective vendor or acquisition:
- What is your future product roadmap and expected end-of-life for the current major version?
- What data-export formats do you support if the customer chooses to migrate?
- Are there open-source or standards-based alternatives to your proprietary interfaces?
- What long-term-support commitments are made contractually?
Answers to these questions determine whether the "acquisition" ends in a healthy migration path in five to ten years — or in a non-negotiable dependency that outlasts the vendor's own solvency.
8. Making the Go / No-Go Decision
The output of pre-deal cybersecurity due diligence should feed directly into the risk-management framework covered in Module 2 · Risk Management. The four possible outcomes are the same four risk responses:
- Mitigate — proceed with the deal, but require the acquired entity to close specific gaps before or shortly after close.
- Transfer — insure the residual risk, or push it back onto the seller through reps and warranties and escrow.
- Accept — the residual risk is within appetite; document and proceed.
- Avoid / walk away — the risk is beyond redemption. This is a valid answer and one that many acquirers under-use.
The role of the cybersecurity team in the deal is not to say "yes" or "no" — it is to give the deal team the information they need to make an informed decision, and to make the risk of that decision concrete.
9. Post-Close Integration — a Rapid Checklist
Once a deal closes and integration begins, security work in the first 90 days typically includes:
- Immediate: inventory the acquired networks and cloud tenants; onboard them into the SIEM (read-only initially); block the known-bad indicators of compromise across the combined estate.
- First 30 days: rotate shared credentials and admin passwords; enforce MFA on all admin accounts; disable dormant accounts.
- First 90 days: harmonize identity — federate the acquired IdP or migrate users to the primary IdP; deploy the primary EDR/MDM; enroll the acquired estate in vulnerability management and patching.
- Ongoing: reconcile access reviews on the combined estate; retire duplicate SaaS licenses (a source of shadow IT); merge IR runbooks and rehearse.
Segregation until parity is a healthy default. Do not merge networks or identity until the acquired entity has reached your minimum security baseline.
10. Key Takeaways
- Acquisition covers many shapes — hardware, software, services, suppliers, and M&A. Cybersecurity risk enters at every one, but M&A composes them all.
- Post-merger security posture is a
min()operation across the two organizations. Networks and identities should stay separated until parity is reached. - Define minimum cybersecurity requirements that any acquired entity, merger partner, or vendor must meet.
- Base go / no-go decisions on on-site assessments and structured document exchange, not on trust.
- For software acquisitions specifically, verify secure SDL adoption, periodic testing, and regulatory-regime overlap.
- Vendor lock-in and technical debt are the two most-underestimated acquisition risks. Ask about roadmap, end-of-life, data-export formats, and LTS commitments before signing.
- The cybersecurity team's role in the deal is to inform the four risk responses (mitigate / transfer / accept / walk away), not to gatekeep.
11. Glossary
- Acquisition strategy — the discipline of integrating cybersecurity and risk-management considerations into every form of purchase, contract, and merger.
- M&A (Mergers and Acquisitions) — corporate transactions in which one entity buys or merges with another; the highest-risk cybersecurity event in the acquisition category.
- Pre-deal due diligence — assessment of a target's security posture before the deal closes, feeding the go / no-go decision.
- Reps and warranties — contractual promises about the state of the target; breaches expose the seller to indemnification claims and are one of the primary risk-transfer tools in M&A.
- Vendor lock-in — condition where migrating away from a vendor is prohibitively expensive, restricting future options.
- Technical debt — accumulated legacy code, infrastructure, or dependencies whose eventual remediation is deferred and grows more expensive over time.
- Post-close integration — the operational programme of merging identities, networks, tools, and processes after a deal closes.
- Minimum cybersecurity requirements — the baseline any acquired entity, merger partner, or vendor must meet to be part of the extended enterprise.
12. What's Next
This closes Module 3. Continue with Module 2 · Risk Management or return to the Program 1 index.
Cross-refs:
- 03 · Vendor Risk Management — the ongoing counterpart to acquisition-time due diligence.
- Program 3 · Module 1 · OWASP Top 10 — the technical grounding for software-security due diligence.
- Module 2 · Risk Management — the four risk-response options every acquisition decision ultimately chooses among.