Cyber security due diligence in mergers and acquisitions is one of the most consistently underdone disciplines in Australian corporate IT. Legal and financial teams run exhaustive checks. Technology infrastructure gets a cursory look. But the security posture of the target organisation, its exposure to active threats, the state of its logging, its third-party access footprint, and its patch history, often receives a fraction of the scrutiny it deserves. By the time the deal closes, the acquirer has absorbed not just the target's assets but every unpatched vulnerability, every lingering access credential, and every shadow IT tool the target's staff were quietly using.
That gap is where attackers operate. Threat actors have long understood that M&A activity creates windows of disruption: network boundaries shift, IT teams are stretched, identity management is in flux, and nobody has a complete picture of what's connected to what. Australian organisations have paid a real price for this, with post-acquisition breaches tracing back to infrastructure the acquirer didn't know it had inherited.
Why the due diligence window is never long enough
In a typical Australian M&A transaction, the security review happens inside a compressed data room exercise. A vendor's security questionnaire goes out. Responses come back. A consultant skims them. The deal continues. What rarely happens is a genuine technical assessment of the target's environment: active scanning, log analysis, identity auditing, or a review of the target's asset inventory to check whether the organisation itself knows what it owns.
The reasons are structural. Sellers resist intrusive technical access before a deal closes. Timelines are tight. The acquirer's IT team is often told about the transaction late. And security is still treated, in too many deal teams, as an IT problem rather than a commercial risk.
The practical result: acquirers discover the real security posture of the target after integration begins, not before. That's when the skeletons appear. Servers running unsupported operating systems. Service accounts with admin rights that haven't been reviewed in years. Vendor access that was provisioned for a project in 2021 and never revoked.
What a proper pre-close security review should cover
A thorough cyber security assessment of an acquisition target covers five areas that questionnaire-based reviews almost always miss.
Active threat presence. Before anything else, check whether the target is already compromised. Endpoint detection data, DNS query logs, and firewall traffic can reveal indicators of compromise that the target's own team may not have noticed. A two-week review of outbound DNS traffic alone can surface command-and-control activity that no security questionnaire will capture.
Identity and access state. Pull a full export of privileged accounts, service accounts, and external vendor access. Count the accounts that haven't been used in 90 days. Count the admin accounts without multi-factor authentication. In most target environments, both numbers will be higher than the acquirer expects. This connects directly to the broader challenge of identity-based attacks, where stale credentials become reliable entry points.
Patch and vulnerability posture. Run an authenticated vulnerability scan across the target's externally accessible assets and internal network. Pay particular attention to systems that haven't been patched in more than 60 days. In regulated sectors, also check whether the target's patch management has been documented and tested, or whether it exists only on paper.
Third-party access footprint. Ask for a list of every third-party tool, vendor connection, and SaaS integration with access to the target's data. Expect the list the vendor provides to be incomplete. Cross-reference it against DNS records, firewall rules, and OAuth grants visible in identity provider logs. The gap between the official list and the real one is where supply chain risk lives.
Data classification and residency. Establish where sensitive data sits, how it's classified, and whether it's subject to obligations under the Privacy Act, sector-specific regulation, or contractual obligations to the target's own customers. Acquiring a company that holds health records or government data without understanding the residency and handling requirements creates immediate compliance exposure.
The 100-day integration window and why it's the highest-risk period
Security risk doesn't peak at close. It peaks during the integration sprint. Networks get joined before segmentation policies are updated. Active Directory domains get merged before access rights are reviewed. Employees from both organisations gain access to systems they shouldn't while provisioning catches up. Legacy systems that were planned for decommissioning stay running longer than expected because migration timelines slip.
Effective acquirers treat the first 100 days post-close as a formal security program, not an IT project. That means a dedicated integration security lead with authority to pause connectivity decisions if risk thresholds are breached. It means a hardened perimeter between the two networks until the internal assessment is complete, rather than an immediate full merger of environments. And it means daily review of access provisioning logs, not monthly.
Network segmentation is the single most effective technical control during this period. Keeping acquired infrastructure in a logically separate zone, with monitored and explicitly approved connections to the acquirer's core environment, limits the blast radius of anything the assessment missed. The principle is simple: don't trust, verify, then connect.
What most Australian IT teams skip in the post-close review
Two failure modes appear repeatedly in Australian acquisitions. The first is skipping the post-close security assessment entirely because a pre-close questionnaire was completed. The second is completing the post-close assessment but not acting on the findings quickly enough, because remediation is deprioritised behind feature delivery or business integration tasks.
A third, less obvious failure: the acquirer's own incident response capability isn't updated to include the acquired environment. When a security event occurs in the first year post-acquisition, responders often discover that the acquired systems aren't in the SIEM, aren't covered by the existing EDR deployment, and don't have documented escalation paths. Incident post-mortem disciplines that most teams already find difficult become even harder when half the environment is new. Reviewing what effective post-mortems require before integration begins gives teams a better starting baseline.
Logging gaps are a specific and persistent problem. Systems inherited from the target frequently aren't configured to ship logs to the acquirer's SIEM. If an attacker who was already present in the target environment pivots into the acquirer's network during integration, the detection window is precisely as wide as the logging coverage. Often that means no detection at all.
Practical steps for Australian IT teams managing an acquisition
Get involved before the deal closes. Security teams that engage during due diligence, even with limited access, produce better integration plans than those handed a completed transaction and told to make it work. Push for at least a read-only technical review of the target's identity infrastructure and external attack surface, even if full access isn't available.
Build a security-specific integration checklist that runs in parallel with the broader IT integration program. Include: SIEM onboarding for acquired assets, EDR deployment, privileged access review, third-party access audit, and a vulnerability remediation schedule with actual deadlines, not aspirational timelines.
Set a network integration gate: no full connectivity between environments until the post-close security assessment findings are reviewed and critical issues remediated. This is a harder conversation to have with business stakeholders who want integration to happen yesterday, but the risk of skipping it is concrete and well-documented.
Finally, test the combined incident response capability before you need it. Run a tabletop exercise that includes the acquired environment within 90 days of close. If the exercise reveals that nobody knows who owns incident response for the acquired systems, that's important information to have in a rehearsal rather than a real event.