How We Built an M&A Security Playbook: From Due Diligence to Penetration Testing

Nobody announces an acquisition and then waits for security to finish. The timeline is what it is. Access is limited, information is incomplete, and the business has already decided the deal is happening. Your job is to work out what they're actually buying before they own it.

In practice, that means starting before you have full access, building a methodology that doesn't collapse when the scope turns out to be wrong, and staying in the room through integration when everyone else has moved on to the next transaction.

This is the framework we've built for doing that. Three phases, a testing approach that works from day zero, and the parts that don't show up in textbooks - what integration actually does to your attack surface, where credential exposure keeps appearing, and why the asset inventory you were handed is never the full picture.

Why security must be embedded in M&A due diligence

Security is crucial. Breaches and vulnerabilities make headlines daily, but one overlooked area is what happens inside an M&A process.

Acquisitions happen across every sector - medtech, consulting, retail, and financial services and in every case, the core dynamic is the same: you're adding a new piece to an organisation that comes with its own culture, processes, and security history. Whether that history is good or bad is rarely the deciding factor. The business has already determined that this company is a valuable asset - one that will grow headcount, expand capability, and improve profitability. The deal is happening because of these realities: security needs to show up early.

The typical starting point is a questionnaire, and questionnaires are a reasonable starting point - they tell you how an organisation understands and describes its own security posture. The problem is that they can't tell you whether that description is accurate. Controls that are "in place" on paper may not be enforced in practice. Existing policies may not be followed. Assets that aren't known can't be disclosed.

This is where a hands-on security assessment earns its place. Even when time is limited, an experienced and mature team can extract significant value from a constrained engagement - knowing where to look, what questions to ask, and how to quickly interpret weak signals. Time-boxed does not mean low quality. It means focused effort by the right people, directed at the highest-risk areas first.

The goal is not to create leverage for renegotiating the deal price - that framing poisons the relationship and misses the point entirely. The value is that it tells the truth that both sides need to hear. For the target company, it surfaces critical issues they may not have known about - problems they can begin addressing immediately. For the acquirer, it creates a clear picture of what's coming: how much remediation work to expect, which internal teams will need to get involved, and where the inherited risk actually sits.

Good assessments are not adversarial. They give both parties visibility, allow informed decisions, and prevent post-signing surprises.

What security due diligence is - and isn't

Security due diligence in M&A is not a full review. You will not get complete access. You will not have time for exhaustive testing. You get a short window to collect the right signals - enough to assess the risk and make informed decisions.

At minimum, that means:

• An honest review of the external-facing attack surface
• OSINT to identify leaked credentials and sensitive information - these are quick wins that reveal real exposure without requiring any internal access
• Evidence of key controls: MFA enforcement, logging practices, patch cadence
• A high-level view of the identity and access model
• Critical vendor and third-party dependencies
• Any known incidents or regulatory findings from the past 24 months

This is not a penetration test. It is structured risk discovery - information to guide the deal, but not enough for full confidence. The goal is to know what you're buying before you own it.

The M&A constraints you can’t ignore

Accept that information may be incomplete - often unintentionally. People describe their environment as they see it, and this understanding is usually partial. This doesn't mean distrusting them, but it does mean treating every detail as a signal to verify, not a fact. Stay alert.

Access will be limited - sometimes severely

From day one, expect restricted visibility. In some cases, you'll have no access at all and will need to find your own way in through legitimate reconnaissance that's not a failure of the process - it's the process. Build your methodology around it.

Business pressure is constant

The M&A security assessment timeline is compressed. You'll feel pressure to move faster, ask fewer questions, and keep findings quiet until after closing. That pressure is real and persistent. Acknowledge it, work within your timeline, and don't let it compromise your report.

Shadow IT is the main technical challenge

Every organisation has it. Acquired companies, especially those that have grown quickly or gone through their own acquisitions, tend to have layers of it. The systems nobody owns, the tools that outlived the team that bought them, the cloud accounts provisioned on a personal card three years ago. You need a well-established, automated approach to asset enumeration that starts delivering results from day zero - so your team has something to work with immediately and can plan the next move rather than wait for inventory to materialise.

Vendor and third-party boundaries add unquantifiable risk. Third parties affect risk in ways you may not see

Check specifically: how does the organisation control access to third-party systems? SSO or individual accounts? If the answer is surprising, you're not alone - recent public examples show why it matters. Whatever the answer, it defines what you must check.

Resistance can come from both sides

Sometimes the target pushes back; sometimes the pressure is internal. Keep doing what you must and follow the plan. If blockers prevent certain checks, that's fine - some things may be skipped - but list every blocker in the report. Skipped checks are not closed risks.

The repeatable framework: M&A Security Assessment Playbook (3-phase model)

No two acquisitions are identical, but the security challenges that come with them are surprisingly consistent. Compressed timelines, incomplete information, limited access, inherited technical debt. What changes is the degree. A repeatable, phased framework lets you adapt to those variables without rebuilding your approach from scratch every time a deal comes through.

The model has three phases: Preboarding, Onboarding, and Ongoing.

Phase 1: Preboarding (pre-close / limited access)

This phase happens before the deal closes. Access is limited, confidentiality constraints are tight, and you won't get inside the environment. That's fine. There's more you can do from the outside than most people expect, and the work done here directly shapes how Phase 2 is scoped and prioritised.

Start with passive subdomain enumeration across every domain you've been given. Passive only at this stage - no active probing, no direct requests to the target's infrastructure. Tools like subfinder and bbot pull from threat intelligence platforms, certificate transparency logs, DNS aggregators, and passive DNS databases simultaneously. The output is rarely complete, but it's a meaningful first map of the external footprint and surfaces assets that won't appear in any inventory you're handed.

Certificate transparency deserves a dedicated pass. CT logs are public, searching them touches nothing on the target side, and they consistently return infrastructure that passive TI platforms miss - subdomains registered under subsidiaries, domains tied to old product lines, certificates issued for internal tooling that ended up internet-accessible. Note domains that appear in certificate SANs beyond the submitted scope. They're candidates for Phase 2 enumeration.

At this stage, skip dictionary-based subdomain brute forcing. It's not passive, the timing is wrong, and you don't yet have enough company-specific context to build a useful keyword list. Flag it as a Phase 2 activity and move on.

Resolve what you've found, but don't discard what doesn't resolve. Unresolved subdomains pointing at deprovisioned cloud infrastructure or third-party services are worth keeping on a separate list for subdomain takeover review once you have more time.

OSINT for credential and information exposure is often the highest-signal work in this entire phase. Breach datasets and paste sites give you a sense of exposure volume and how recent it is. GitHub is consistently productive - search not just the organisation's own repositories but employee accounts, forks, and gists for API keys, internal hostnames, connection strings, infrastructure details, sometimes credentials that are still valid. A company that's grown fast or gone through its own acquisitions tends to have a long tail of this. What you find here - the kinds of secrets exposed, how old they are, whether they've been rotated - tells you more about security culture than most questionnaire responses will.

Check for exposed cloud assets from the outside: company-branded S3 bucket naming patterns, public Azure blobs, GCP buckets. These can be identified without internal access and occasionally turn up sensitive data or configuration files that inform the rest of the engagement.

What you produce at this stage isn't a pentest report. It's a risk memo: what you found, what assumptions you're carrying, confidence level, and a prioritised list of what needs active validation the moment internal access opens up. The unresolved subdomains flagged for takeover review, the additional domains identified through certificate SANs, the credentials found in breach data that haven't been tested against live systems yet - all of it goes into that list. Some of what you found will turn out to be decommissioned. Some won't.

Phase 2: Onboarding (post-close / first 30 days)

The deal has closed. Now you get access, and the picture usually shifts.

The first thing to do is validate the asset inventory against what you found in preboarding. In almost every engagement there's a gap. Sometimes minor - a few forgotten subdomains. Sometimes it's a separate AWS organisation provisioned two acquisitions ago that nobody fully mapped. That delta between what was disclosed and what actually exists tells you a lot about organisational maturity before you've run a single test.

Asset discovery before anything else. Whatever scope was handed to you, treat it as a starting point. Begin subdomain enumeration across every submitted domain using passive collection from threat intelligence platforms - subfinder, bbot, and similar tools pull from dozens of sources simultaneously and will surface assets that never made it into any internal inventory. Layer certificate transparency over that: querying CT logs against the primary domains often returns subdomains and related domains that passive tools miss, including infrastructure registered under subsidiaries or for specific projects.

After passive collection, run a dictionary-based search. It takes longer, and the temptation is to use a generic wordlist and move on. Don't. Build custom keyword lists for this company - product names, internal terminology, office locations, anything that shows up in their public presence - and don't stop at second-level subdomains. Go deeper, and run reverse lookups to catch patterns that forward enumeration misses.

Resolve everything. Work only with alive hosts going forward, but before you discard the unresolved subdomains, review them separately. Dangling DNS records pointing at deprovisioned infrastructure are a consistent source of subdomain takeover opportunities, and they're easy to miss if your workflow automatically drops anything that doesn't resolve.

The submitted domains are also not the full picture. Organisations buy domains for testing, campaigns, acquisitions, and then forget about them. Look for additional domains in the links of identified subdomains, in certificate SANs, in archived social media posts, through reverse WHOIS lookups. Any domain you find gets run through the same enumeration process as the originals.

Cloud deserves its own thread running in parallel. Use whatever internal access you have to enumerate cloud presence across providers, but also approach it from outside using keyword-based searches - company-branded S3 bucket naming patterns, Azure tenant discovery, GCP project enumeration. Acquired companies, especially those that grew fast or went through their own deals, tend to have cloud assets that predate any central governance. Some are dormant but retain data or hold permissions that remain valid. Archives, pastebins, and services that store historical snapshots of web assets are also worth sweeping - they surface endpoints and credentials that are no longer live but reveal infrastructure history and sometimes still-valid secrets.

Scanning. Once you have a working asset list, enumerate the perimeter properly. Port scan across the full range, not just common ports - identify services, grab banners, take screenshots of web-facing applications. The goal at this stage is a coherent picture of what's running and what technology stack you're dealing with, because that shapes what you look for next.

Run a vulnerability scanner across the identified surface - nuclei works well here given the breadth of its template library. The output from automated scanning is not findings to report; it's a prioritisation input. Go through it manually and identify what warrants deeper work, what looks like a likely entry point, and what is noise. Scanners are good at finding known patterns. They miss logic issues, misconfigured authorisation, and vulnerabilities that require context to identify. The manual work that follows automated scanning is where the more impactful findings tend to appear - research the services themselves, understand what they do and how they're exposed, and look for risks that don't fit a template signature.

Credential stuffing. Take the credentials and breach data collected during OSINT and test them against the login pages identified during enumeration. This is consistently underestimated as an activity. Organisations focus on their primary SSO portal but have legacy applications sitting on subdomains that authenticate independently. Those are the portals worth targeting. A valid credential on an internal project management tool or an old admin panel is often a better entry point than anything a scanner will surface.

Build the environment map as you go - what's in production, what's not, how identity is managed across systems, what monitoring is in place. Testing without that context means findings land without the information needed to assess their real-world impact.

Leave this phase with critical findings that have owners and deadlines attached, and a trend summary showing where weaknesses concentrate. The trend summary is what gets cut when time is short. It shouldn't be. It's what Phase 3 is built on.

Phase 3: Ongoing Testing + Integration Risk (post-close, ongoing)

This is where most programs lose momentum. It's also where some of the more significant risks appear, because the act of merging two organisations creates attack surface that didn't exist before.

Retesting comes first. Every critical and high finding from Phases 1 and 2 needs a return visit - not a checkbox, an actual verification that the issue is gone. The findings worth prioritising for retest aren't just the highest-severity ones in isolation. They're the ones that connect. A dangling DNS record that looked like a low-effort subdomain takeover in Phase 2 may now point at infrastructure that's been brought into a shared network. An authentication bypass on a legacy application that previously sat in an isolated environment may now have a trust path into the main identity provider. Integration changes the blast radius of findings that looked containable at close. Go back through the Phase 2 findings with that lens before assuming severity ratings still hold.

For credential exposure found during OSINT: retest any breach credentials that weren't fully validated in Phase 2, particularly against applications that have since been connected to the main environment. A credential that didn't work against an isolated login portal might now open something more significant.

Cloud is where the ongoing work gets most complex. Acquired companies, especially those that grew fast or went through their own deals, tend to have cloud sprawl that no single person fully understands at close. Multiple AWS accounts in various states of management, Azure tenants provisioned for specific projects and never consolidated, GCP environments maintained by teams that have since been reorganised. Start with a full enumeration across providers. Use the internal access you now have, but also keep running external keyword-based searches - new assets get provisioned during integration and don't always make it into the central inventory immediately.

Check IAM configurations carefully. Over-permissioned roles, stale access keys, and service accounts with broader access than their function requires are common in environments that scaled fast without strong governance. Pay particular attention to cross-account trust relationships and any federation that was set up during integration. These are frequently configured under time pressure and often grant more access than intended.

Shadow IT in this context isn't just unsanctioned SaaS. It's entire infrastructure segments. A team that spun up a production environment in a personal AWS account because procurement was slow. A subsidiary running its own Active Directory that was never federated. An application built on a cloud account that got orphaned when the engineer who provisioned it left. You find these through continued DNS enumeration, certificate transparency, cloud provider OSINT cross-referenced against the internal inventory, and targeted conversations with engineering leads during the integration process.

Running parallel to all of this is a compliance gap review against your own organisation's policies - and this is where acquired companies consistently generate findings that pure security testing won't catch. The target company made its own infrastructure decisions independently, with no knowledge of what your procurement, legal, or security teams had approved. By the time you're in Phase 3, you have enough visibility to start mapping what they're running against what you allow.

The most common categories worth checking explicitly: hosting providers and cloud regions not on the approved vendor list, commercial VPN services running on company assets or used for corporate traffic, domain registrars and DNS providers outside the approved set, and SSL certificate authorities that don't meet internal policy. External VPNs in particular are worth dedicated attention. They're frequently installed by developers or IT staff at acquired companies as a workaround for something - geo-restrictions, remote access, privacy - and they create outbound traffic paths that bypass your monitoring entirely. Finding them isn't always straightforward. Look for the characteristic ports and protocols during network-level scanning, check endpoint software inventories where you have access, and watch for the hostnames and IP ranges associated with common commercial VPN providers in DNS logs.

Unapproved hosting is a similar pattern. A service running on a provider your organisation hasn't vetted, contracted, or assessed carries risk that has nothing to do with how the service itself is configured. Data residency, incident response obligations, subprocessor agreements - none of that was negotiated with your requirements in mind. Document every instance, map it against what the service does and what data it handles, and prioritise remediation by data sensitivity rather than just the number of non-compliant assets.

These findings don't always sit comfortably in a pentest report alongside CVEs and authentication bypasses. They belong in the integration risk register alongside the security findings, flagged for the teams that own vendor management and procurement. Security surfaces them. Someone else closes them.

Track coverage, time-to-remediate, retest pass rate, and the count of assets still outside central inventory and controls. That last metric is the one leadership rarely asks for. It's a direct measure of how much of the environment remains unknown, and in an M&A context, that number should be falling consistently from Phase 2 onward. If it isn't, something in the integration process isn't working.

What a structured pentesting program for acquired companies looks like

The best case is when security is engaged as soon as the deal is approved, before the announcement. This early window allows time to assess and fix critical findings before the news goes public. After the announcement, the deal attracts attention - a breach right after close isn't just a security incident; it's a reputational event. Getting ahead matters.

Scoping model

Scoping is one of the trickiest parts. The more information you receive upfront, the better prepared you'll be and the more accurate your estimates will be, but don't count on it. Have a tested, reliable approach ready for the worst case - one that, even with no input, covers the most critical areas and produces a meaningful picture of the risk posture. Be ready to treat the engagement as a full black box from day zero.

Testing tracks

The more you cover, the better - but be realistic about what you can do in the time you have. Prioritise by criticality and impact, not thoroughness for its own sake. Sometimes, chasing quick wins for immediate access outweighs days spent on an RCE in a public asset. Remember, in most cases, bad actors log in, not break in. Use the same logic - credential exposure, authentication issues, and identity paths matter more than headline vulnerabilities.

Reporting structure

The report is one of the most important outputs of the entire engagement - and one of the most commonly done poorly. Your executive summary exists for one purpose: to clearly communicate impact to people who don't speak CVE. No technical jargon. No acronym soup. A clean, plain-language overview of what was assessed, what was found, and what the business risk is. All technical details belong in the appendices - that's where the engineering and remediation teams will live. Give each audience what they actually need.

Remediation and retesting

Every identified issue needs an owner. Without one, the finding ends up in a shared drive and quietly dies there. Ownership is non-negotiable. Alongside ownership, set deadlines - not as a formality, but as a commitment to come back and verify. Prioritise remediation in the same way you prioritised testing: critical and high findings first, especially anything that can be chained with other issues to amplify impact. Lower priority items can often be folded into the onboarding process - but only if they can't be exploited in combination with something else; that distinction matters.

Common pitfalls (and how to avoid them)

The mistakes that sink M&A security programs aren't usually dramatic. They're quieter - decisions that seem reasonable under pressure and only reveal their cost later.

• Questionnaires as ground truth. They tell you how an organisation describes its posture, not what the posture actually is. Assets that aren't known can't be disclosed. Every engagement turns up infrastructure that wasn't in the scope we were handed.
• Scan-only assessments. Nuclei won't find the legacy application authenticating independently because SSO was never integrated. It won't find the breach credential still working against an admin panel nobody remembers owning. Automated output is a prioritisation input, not a report.
• Skipping asset discovery. The gap between what was disclosed and what enumeration finds doesn't close after the deal signs. It just becomes your problem.
• Findings without owners. A report in a shared drive is a record of risk that still exists, not a remediation. Named owner, deadline, retest date - without all three, the finding is decoration.
• Overpromising coverage. Constrained access, blocked tooling, compressed timelines - say so in the report. Skipped checks are not closed risks and that distinction needs to survive the handover.
• No retesting after close. Integration changes the environment around findings. An authentication bypass that looked contained in an isolated application may now sit inside a network it didn't have access to before. What was fixed in isolation may not have stayed fixed in context.
• Assuming close means done. Unapproved hosting providers, commercial VPNs routing corporate traffic, orphaned cloud accounts - none of it shows up on a risk register until someone goes looking. The deal signing is not the finish line.

Leader–Practitioner partnership model

This is arguably the most important dynamic in the entire program - and it needs to be established from day one. The security team is not there to put pressure on the deal's financials. It's there to provide visibility: to avoid reputational and financial losses, to surface what needs fixing, and to give everyone a realistic picture of the effort required from the teams involved.

Framed correctly, this is a win-win. The target company receives a free security assessment that helps them identify and address unknown security issues previously and improve overall resilience. The acquirer gains essential visibility into scope, effort, timelines, and the specific teams that need involvement, enabling more effective planning and risk reduction. Neither side loses from that outcome. Communicating this clearly from the start to all parties keeps the process collaborative rather than adversarial.

Responsibilities on each side

These engagements run under pressure, and that means the mindset has to be proactive from the start - not reactive, and certainly not passive. Don't wait for information to arrive. It might come, but it can also arrive fragmented, delayed, or framed in ways that don't reflect the full picture. Be ready to act from day zero, including starting the assessment before full access is granted. There's meaningful work you can do just by getting your hands on the external scope and understanding what you're actually dealing with.

Set clear expectations around execution quality - and communicate them to stakeholders so everyone understands what the assessment will and won't cover. As the engagement progresses, flag blockers early and explicitly. Anything that prevents a check from being completed needs to be visible, not quietly skipped. A preliminary checklist of what will be assessed is a simple yet effective tool for aligning expectations across all parties.

And finally - remediation. Results shouldn’t be lost in handover. The goal is to improve risk posture and avoid losses. That work ends only once findings have owners, deadlines, and proof of resolution.

A lightweight starter kit that readers can copy

Preboarding checklist

• Company profile: business area, size, geographical distribution of offices
• Infrastructure model: cloud only, on-premises only, or hybrid
• Third-party and vendor landscape: key dependencies and critical integrations
• External footprint review (passive reconnaissance)
• OSINT: leaked credentials and exposed sensitive information
• Evidence of key controls: MFA, logging, patch cadence
• Known incidents or regulatory findings from the past 24 months

Onboarding checklist

• Full technology stack: what's in use and where
• Operational technology inventory: systems, versions, ownership
• Security policies in place: what exists, what's enforced, what's aspirational
• Asset inventory validation: compare against what was provided in preboarding
• IAM baseline: access provisioning, offboarding, privileged access
• Test entry-point critical controls: external surface, remote access, and authentication weaknesses

Ongoing checklist

• Retest the highest-risk workflows identified across preboarding and onboarding
• Re-examine highest-risk assumptions from earlier phases - validate or close them
• Integration risk review: What new attack surface did the merger create?
• Sweep for uncontrolled assets existing outside central inventory and controls

Minimum deliverables

Every acquisition should produce at a minimum:

1. Asset snapshot - identified asset inventory compared against what was initially provided, giving a clear picture of the gap between what the company believed it had and what actually exists
2. Executive summary - plain-language overview of what was assessed, what was found, and what it means for the business
3. Remediation plan - high-priority findings with assigned owners and deadlines; no finding without an owner
4. Retest plan - scheduled return dates to validate fixes, not just trust them

Metrics

Three metrics worth tracking across every acquisition:

• Asset delta - the difference between assets identified during assessment and assets disclosed upfront. This gap alone tells you a great deal about the acquired organisation's maturity and self-awareness.
• Findings by type and area - the distribution of identified findings across various categories (such as identity, external surface, cloud, third parties, etc.). This breakdown highlights the weakest areas and directs remediation teams to where their efforts are most needed.
• Risk posture indicators by area - which areas carry the highest concentration of risk? This is the metric that matters most to leadership: it translates technical findings into business decisions and helps prioritise where attention and resources should go first.

Closing

M&A timelines are not designed with security in mind. The pressure to move fast, stay out of the deal's way, and avoid findings that complicate the close is real and persistent. Most security teams feel it on every engagement. The ones that handle it well aren't the ones with the most resources or the longest timelines - they're the ones that built a methodology around those constraints rather than waiting for conditions that never arrive.

What we've tried to put together here is a framework that works in the real environment: limited access, incomplete information, compressed timelines, and an integration phase that creates new risk faster than most programs can track it.

None of this requires a large team or a long timeline. It requires the right focus and a methodology that doesn't depend on perfect access to produce useful output.

Co-author: Yekaterina Shevchenko