An Acquisition Is Not Complete Until You Know What You Have Acquired
Executive Summary
A merger or acquisition changes more than the ownership of a business. It introduces a new technology estate, identity environment, supplier ecosystem and security risk profile. Without early visibility, the acquiring organisation can inherit unknown infrastructure, undocumented applications, unmanaged cloud tenants, excessive privileges and security obligations that were never properly assessed. The acquiring security team must be involved from the beginning, supported by a standardised M&A security operating model applied to every transaction. Asset discovery, IAM, security architecture, third-party risk, SOC operations and reputation management must work together to ensure that the combined enterprise is understood, accountable and secure.
The Deal Is Closed. But Do We Know What We Acquired?
Imagine an organisation completing the acquisition of another company. The business teams are celebrating, employees are being onboarded and technology teams have started connecting systems.
A few weeks later, the security team discovers an internet-facing server that was never declared during due diligence. An application is running on an undocumented virtual machine. A cloud tenant appears outside the known corporate environment. Several privileged accounts have permissions that nobody has reviewed, and a third-party service provider still has remote access to critical systems.
These are not necessarily signs of deliberate concealment. Technology environments evolve over years. Business units create their own applications, development teams provision temporary infrastructure, cloud subscriptions are opened for specific projects and systems remain operational long after their original purpose has disappeared.
The acquiring organisation may have received an inventory, but that does not mean it has received an accurate picture of the technology estate.
This is where an acquisition can quietly become a security problem.
The acquiring organisation is not just taking over employees, customers and business operations. It is also assuming responsibility for the digital environment that supports them.
The security team should not discover what the organisation acquired several months after the transaction. It should understand what is entering the enterprise before integration begins.
Security Must Have a Seat at the Table Before Day One
Cybersecurity should not be introduced after the acquisition agreement is signed and the integration programme is already underway.
The acquiring organisation’s security team must participate in the initial due-diligence process. Its role is to understand the target company’s technology landscape, assess its security maturity, identify material exposures and establish what needs further investigation.
A declaration that the target operates 500 servers does not establish that only 500 servers exist. A list of business applications does not prove that every application has been documented. A cloud subscription register does not guarantee that every tenant, account and project has been identified.
The difference between a declared inventory and the actual environment can be significant.
Security teams should validate available information using technical discovery, configuration records, endpoint management platforms, vulnerability assessment tools, cloud management interfaces, network discovery and application records.
The findings should influence the acquisition’s integration strategy. Significant security gaps, unsupported technology, unresolved incidents and inadequate controls should be visible to the decision-makers before the business commits to a transition plan.
This is not about making every acquisition slower. It is about preventing the organisation from discovering expensive and potentially serious problems after it has already assumed responsibility for them.
Start With the Technology Estate, Not Just the Asset Register
An asset inventory is a useful starting point, but it does not provide the complete picture by itself.
The acquiring organisation needs to understand the relationship between infrastructure, applications, identities, cloud services and external connections.
Physical servers, virtual machines, endpoints, network devices, databases, storage platforms and operating systems must be identified. Business applications and internally developed software must be mapped to their hosting environments, technical owners and business functions.
Cloud discovery needs particular attention. The target may have multiple tenants, subscriptions, accounts and projects, some of which were created independently by business units or development teams. These environments may not appear in the central IT inventory.
External-facing assets also matter. Domains, public IP addresses, remote access gateways, internet-accessible applications and externally hosted services can expose the organisation to risks that remain invisible in traditional infrastructure records.
The objective is to establish a reliable picture of what is actually operating, where it resides, what it supports and who is responsible for it.
An application should not be considered accounted for simply because its name appears in a spreadsheet. The organisation needs to know where it runs, what information it processes, which systems it communicates with and who maintains it.
Without that understanding, the acquiring organisation may have multiple inventories but still lack meaningful visibility.
IAM: Rebuilding Trust Across Two Identity Environments
Identity integration deserves particular attention because an acquisition brings together people, privileges and authentication systems that were previously governed independently.
The acquired company may operate its own Active Directory forests, cloud identity tenants, authentication platforms, privileged access systems and application-specific accounts. Its access policies and administrative practices may differ significantly from those of the acquiring organisation.
Simply connecting the two identity environments can create unintended trust relationships.
Existing administrative privileges may no longer be appropriate. Former employees’ accounts may remain active. Contractors may retain access beyond their original engagement. Service accounts, application registrations and API credentials may have permissions that nobody has reviewed.
The IAM workstream must establish a complete identity baseline before consolidation.
It should identify the directories and authentication systems in use, review privileged and service accounts, examine external identities and assess federation arrangements between environments. MFA coverage, conditional access, role assignments and access review practices should also be evaluated.
The acquiring organisation must then determine which identities should be migrated, which should be retired and what access is justified in the combined enterprise.
The principle is straightforward: an identity should not inherit privileges merely because the organisation that created it has been acquired.
Security Architecture: Integration Must Follow Design
Two organisations rarely have identical technology architectures.
The acquired company may use different network segmentation models, security gateways, endpoint protection products, cloud architectures, encryption standards and remote access solutions.
Connecting these environments without architectural assessment can introduce weaknesses into the acquiring organisation’s existing security design.
The security architecture team must establish how the environments will coexist and what needs to change before integration.
Network connectivity should be reviewed for segmentation, routing, trust boundaries and remote access. Cloud architecture should be examined for tenant isolation, identity federation and workload exposure. Application architecture needs attention to authentication mechanisms, data flows, integrations and external dependencies.
The team should also identify unsupported platforms, duplicated security technologies and architectural components that could complicate long-term operations.
This does not mean replacing every technology immediately. That could be expensive, disruptive and unnecessary.
Instead, the organisation needs a defined target architecture, with clear integration requirements, security controls and transition priorities. Systems that do not meet the required security conditions should not receive unrestricted access to the enterprise simply to meet an integration deadline.
TPSRM: The Supplier Ecosystem Comes With the Business
An acquisition also brings external relationships that may not have been assessed under the acquiring organisation’s Third-Party Security Risk Management (TPSRM) programme.
The acquired company may rely on cloud providers, managed service providers, software vendors, outsourced development teams, payment processors and infrastructure support companies.
Some suppliers may process sensitive information. Others may operate critical business services or maintain privileged access to the target’s technology environment.
The acquiring organisation needs to understand these relationships before allowing them to continue unchanged.
The TPSRM workstream should establish which suppliers have access to systems or data, what services they provide, whether subcontractors are involved and whether existing contractual and security requirements are adequate.
Remote support arrangements deserve particular scrutiny. A supplier account that was acceptable within the target organisation should not automatically receive access to the acquiring enterprise.
The organisation must decide whether each supplier can continue under the existing arrangement, requires reassessment, needs stronger controls or should be replaced.
This decision must consider both security and business continuity. Removing a critical supplier without a transition plan can disrupt operations, while retaining an inadequately assessed provider can introduce unnecessary exposure.
The acquired supplier ecosystem must eventually operate under the acquiring organisation’s established third-party governance requirements.
SOC: Visibility Must Extend to the Newly Acquired Environment
Knowing that an asset exists is not enough. The security organisation must also be able to detect suspicious activity involving it.
The target company may have its own SOC, SIEM platform, managed detection service or endpoint security tools. It may also have limited monitoring capabilities or depend on manual incident reporting.
The acquiring organisation must establish what is being monitored, what security telemetry is available and whether incidents can be investigated effectively across the combined environment.
Critical infrastructure, endpoints, cloud workloads, identity platforms, applications and network devices should be assessed for logging and detection coverage.
Existing alerts, detection rules and incident response procedures may need to be adapted to the new environment. Previous breaches, unresolved investigations and known compromises should also be communicated to the SOC so that analysts have the necessary context.
The integration should establish clear incident escalation responsibilities, including how incidents involving both organisations will be handled.
A server may appear in the CMDB and still be invisible to the SOC. A cloud tenant may be identified but have no centralised audit logging. An endpoint may be enrolled in asset management without sending security telemetry.
These gaps must be addressed as part of integration acceptance, not left for a future security review.
Reputation Management: What Is the Organisation Inheriting Beyond Technology?
An acquisition can introduce reputational exposure that the acquiring organisation did not previously have.
The target company may have experienced a data breach, ransomware incident, regulatory investigation, privacy complaint or public controversy. Some matters may already be known, while others may remain unresolved.
These issues can affect customer confidence, business relationships, regulatory obligations and the reputation of the combined organisation.
Security, legal, privacy, compliance and corporate communications teams should establish a coordinated view of the target company’s known security history and outstanding obligations.
This includes examining previous security incidents, regulatory actions, customer notifications, contractual disputes and unresolved investigations. The organisation should also establish who has authority to communicate if a security incident involving the acquired business becomes public.
A technical incident can quickly become a business reputation issue when customers, regulators, employees and partners receive inconsistent information or discover that the organisation was unprepared.
Reputation management therefore needs to be part of acquisition readiness, not an activity introduced only after a public issue emerges.
One Operating Model for Every Acquisition
These functions should not operate as independent teams performing disconnected assessments. They need to work within one established M&A security operating model.
The operating model should be designed and approved well in advance, with defined responsibilities, mandatory assessment requirements, decision gates, evidence expectations and measurable completion criteria.
Every acquisition should follow the same fundamental security process. The scale of the target may influence the depth of assessment, but it should not change the core requirements.
The model should cover five stages.
1. Pre-acquisition due diligence
Security participates in the transaction assessment. The technology estate, application landscape, cloud footprint, IAM maturity, security architecture, supplier exposure and known security incidents are examined.
2. Technical discovery and validation
Declared information is reconciled with technical discovery results. Undocumented infrastructure, applications, cloud environments, identities and external connections are investigated.
3. Risk assessment and integration planning
Vulnerabilities, architectural weaknesses, excessive privileges, supplier risks and monitoring gaps are prioritised. Remediation requirements, isolation measures and integration conditions are agreed.
4. Controlled security onboarding
Validated assets are incorporated into enterprise management processes. IAM controls are aligned, architecture requirements are implemented, suppliers are assessed and SOC monitoring is extended.
5. Post-integration assurance
The security team verifies that the combined environment is represented accurately in enterprise inventories and governance systems. Outstanding exceptions have accountable owners, remediation dates and formal risk acceptance where required.
Each stage should have an accountable owner and documented sign-off. The organisation must also define which security conditions prevent unrestricted connectivity or formal integration acceptance.
A repeatable operating model removes uncertainty about who must do what, when it must happen and what evidence is required.
The Final Acceptance Criteria: No Unaccounted Active Assets
A completed acquisition should leave the organisation with a technology estate that it can identify, manage and defend.
Every active asset should have a recognised identity, a business or technical owner, a known operational purpose, an appropriate classification and the required security coverage.
The same accountability must extend to applications, cloud tenants, privileged identities and third-party relationships.
An asset that is no longer required should be formally decommissioned. Its historical record may remain for audit and traceability, but it must not continue to appear as an active operational asset.
The organisation should establish clear acceptance criteria:
- No unidentified active infrastructure.
- No undocumented applications supporting business operations.
- No unknown cloud tenants, accounts or subscriptions.
- No orphaned privileged or service accounts.
- No active assets without accountable ownership.
- No critical operational systems outside approved security monitoring.
- No unmanaged supplier access to enterprise systems.
- No unresolved inventory discrepancies without an accountable owner and closure plan.
A zero-unknown-active-asset target is a meaningful integration objective. It must be supported by continuous discovery and reconciliation because technology environments continue to change even after the acquisition project formally closes.
Historical records of retired assets can remain. What must disappear is uncertainty about what is currently alive and operating.
Security Integration Is an Enterprise Responsibility
The security team can define requirements, coordinate assessments and validate the security position, but it cannot independently maintain every part of the acquired technology estate.
Infrastructure teams must account for the systems they operate. Application owners must maintain their applications. Cloud teams must establish visibility across tenants and subscriptions. IAM teams must govern identities and privileges. Architecture teams must ensure that integration follows the approved design.
TPSRM must assess external providers, while the SOC must establish monitoring and incident response coverage. Legal, privacy, compliance and corporate communications teams must address regulatory obligations and reputational exposure.
Each function has a defined responsibility, but the acquisition programme needs one accountable governance structure to bring these activities together.
Without that coordination, individual teams may complete their assessments while important gaps remain between them.
An Acquisition Should Expand the Business, Not Its Unknowns
A merger or acquisition changes the enterprise’s technology landscape, identity boundary, supplier ecosystem and security responsibilities.
The acquiring organisation should not wait for a vulnerability assessment to reveal an undocumented server, an audit to identify an unknown cloud tenant or a security incident to expose an unattended application.
Nor should it discover during a breach that a supplier retained excessive access, a privileged identity was never reviewed or critical cloud logs were never reaching the SOC.
These are matters that should have been addressed through the acquisition process itself.
A standardised M&A security operating model provides the discipline to do that. It brings asset discovery, IAM, architecture, TPSRM, SOC and reputation management into one coordinated programme, beginning before the transaction closes and continuing until the combined environment meets defined security requirements.
The success of security integration should not be measured by how quickly two organisations connect their systems. It should be measured by how confidently the combined enterprise understands, governs and protects everything it has acquired.
The acquisition may be signed off by the business. But from a security perspective, it is not complete until every active asset is known, every identity is governed, every external relationship is understood and the entire environment is visible to the security organisation.
