A company can look excellent in a financial model and still come with an unsupported business application, untransferable software licenses, a flat network, weak identity controls, untested backups, or years of deferred technology work.
Those are not merely IT problems. They can affect the price of the deal, the integration timeline, regulatory obligations, customer commitments, and the buyer’s ability to operate the business safely on Day 1.
Yet IT and cybersecurity are still too often brought into a merger or acquisition after the important decisions have already been made. The assumption is that the technical teams will simply connect everything, migrate the users, and clean up the rest after closing.
They probably can figure out much of it. The more important question is: How much will it cost, how long will it take, and what risk will the buyer accept in the meantime?
You Are Buying More Than Revenue, Contracts, and People
Every modern business depends on technology. When one company acquires another, the buyer also acquires or inherits a collection of:
- Identities, accounts, and privileged access
- Endpoints, servers, networks, and cloud environments
- Business applications and custom software
- Data, retention obligations, and privacy requirements
- Vendor contracts and software licenses
- Technical debt and unsupported systems
- Security controls and monitoring gaps
- Previous incidents, known vulnerabilities, and unresolved findings
- Dependencies on employees, contractors, and service providers
Some of these assets create value. Others create immediate cost or liability. Until they are examined, the buyer does not know which is which.
That uncertainty is exactly what due diligence is meant to reduce.
The Dangerous Assumption: “IT Will Handle It After Close”
Post-close integration is necessary, but it is not a substitute for pre-close diligence.
Before the transaction becomes final, the buyer still has options. A material technology or security finding can influence valuation, deal structure, contractual protections, required remediation, transition services, integration funding, or the decision to proceed at all.
After close, many of those options narrow. The same finding becomes an urgent operational project funded by the new owner.
Consider a few examples:
| What diligence finds | What it may mean for the business | Possible deal impact |
|---|---|---|
| A core application is no longer supported | Failure or migration could disrupt operations | Additional capital and a longer integration timeline |
| Critical licenses cannot transfer to the buyer | The buyer may have to repurchase or replace software | Added transaction cost and vendor negotiations |
| The target shares systems with the seller or another business | Clean separation may not be possible at closing | A transition services agreement and defined exit plan |
| MFA is inconsistent and privileged access is poorly controlled | Account compromise risk may carry into the buyer’s environment | Day 1 isolation and accelerated remediation |
| Security logging is limited or absent | The buyer may not be able to verify past activity or investigate an incident | Greater uncertainty and stronger monitoring requirements |
| Backups exist but have not been tested | Recovery capability may be assumed rather than proven | Immediate validation and business continuity work |
| Compliance claims are not supported by evidence | Customer, legal, or regulatory commitments may be at risk | Additional legal review, remediation, or changes to deal terms |
These are business issues expressed through technology. Treating them as cleanup tasks hides their true cost until the buyer owns them.
Where IT and Cybersecurity Belong in the M&A Process
IT and security do not need to dominate the first conversation with a target. They do need a defined role early enough to inform the transaction.
Initial Discussions and the NDA
The earliest phase is about mutual interest and high-level fit. Once an NDA allows confidential information to be shared, the buyer can begin identifying which technology and cyber questions could materially affect the deal.
At this point, the goal is not an invasive assessment. It is to establish a secure way to exchange information, identify obvious dependencies, and make sure the diligence plan includes qualified IT and cybersecurity reviewers.
Initial Information Package
Alongside financial statements, customer information, major contracts, and the organization chart, the buyer should request a useful high-level view of the technology environment. That may include:
- Major business applications and infrastructure
- Cloud and hosting providers
- Key technology and security vendors
- Approximate user, endpoint, and site counts
- Critical data types and regulated activities
- Recent audits, assessments, or penetration test reports
- Known incidents or significant outages
- High-level security architecture and control coverage
This first pass helps determine whether the deal deserves deeper review and where specialists should focus their time.
Letter of Intent
The letter of intent usually addresses purchase price, deal structure, exclusivity, timeline, and major assumptions. Although much of an LOI is commonly non-binding, it is an important opportunity to surface technology assumptions before they harden into expectations.
Will the target operate independently for a period? Are systems shared with the seller? Is a transition services agreement likely? Does the proposed timeline assume a fast identity, email, application, or data migration? Is the integration budget based on evidence or optimism?
The LOI does not need a complete technical plan, but it should not be built on an imaginary one.
Formal Due Diligence
During formal diligence, financial, legal, HR, operational, technology, and cybersecurity workstreams run in parallel. They should also share findings with one another.
A security control can affect a customer contract. A software license can affect valuation. A data-retention practice can create legal obligations. A key engineer may be the only person who understands a critical system, creating both technical and retention risk.
Technology and cybersecurity diligence should answer six practical questions:
- What technology is required to keep the acquired business operating?
- What will the buyer own, inherit, license, replace, or need to separate?
- What material cyber risks exist today?
- What legal, regulatory, contractual, and insurance requirements apply to the environment and its data?
- Can the target be integrated without introducing unacceptable risk to either company?
- What will it realistically cost to remediate, operate, and integrate the environment?
Management Presentations and Q&A
Documents rarely tell the entire story. Conversations with the CIO, CISO, engineering leaders, operations teams, and key service providers help validate what is written and reveal where processes depend on institutional knowledge.
The strongest questions are often simple:
- Which system worries you the most?
- What would be hardest to separate or migrate?
- Which security improvement has been repeatedly deferred?
- Who has administrative access, and how is it reviewed?
- When was the last successful recovery test?
- What technology depends on one person or one vendor?
- What would you fix first if budget were available?
The purpose is not to catch people giving a wrong answer. It is to understand how the environment actually operates.
Risk Assessment, Agreement, and Closing
Findings should be translated into business terms before the purchase agreement is finalized. Executives need to understand severity, likelihood, operational effect, estimated cost, timing, and any uncertainty caused by missing evidence.
Depending on the issue and advice from the deal’s legal and financial teams, a finding may affect price, representations and warranties, indemnification, escrow, closing conditions, transition support, or required pre-close remediation.
By closing, the buyer should also have a practical Day 1 security plan. Ownership may transfer in a moment. Safe integration does not.
What Cybersecurity Diligence Should Examine
The scope should reflect the target’s size, industry, data, technology, and risk. A practical review commonly covers:
- Security governance, policies, ownership, and staffing
- Network, application, and cloud architecture
- Identity lifecycle, privileged access, and MFA
- Endpoint protection and vulnerability management
- Logging, monitoring, and incident response
- Backup, recovery, and disaster recovery capabilities
- Data location, classification, retention, and protection
- Third-party and supply-chain risk
- Secure software development and software dependencies, when applicable
- Relevant frameworks and obligations such as SOC 2, ISO 27001, HIPAA, or PCI DSS
- Open findings from audits, assessments, and penetration tests
- Material incidents, insurance claims, and unresolved remediation
The review may also include external attack-surface analysis, DNS review, passive open-source intelligence, cloud-exposure review, code review, or software composition analysis.
Production penetration testing is less common during diligence because active testing can disrupt the target and requires careful authorization. In many deals, it is more appropriate to review recent independent test reports, validate remediation, and conduct passive or narrowly scoped assessments. If active testing is necessary, the scope and permission should be explicit.
A Security Questionnaire Is Not Enough
Questionnaires are useful for organizing information, but they are not evidence.
A target may answer that MFA, backups, logging, vulnerability management, and incident response are in place. Diligence should still determine where those controls apply, how consistently they operate, who reviews them, and whether the target can demonstrate that they work.
There is a meaningful difference between:
- Having MFA available and enforcing it for all critical access
- Running backups and proving that systems can be restored
- Purchasing a security tool and monitoring its alerts
- Writing an incident response plan and exercising it
- Completing an audit and closing the findings
Good diligence tests the difference between documented intention and operating reality.
Turn Technical Findings Into Deal Decisions
A list of vulnerabilities is not an executive deliverable. The final report should help decision-makers act.
For a larger acquisition, the diligence team will often produce:
- An executive summary and overall risk rating
- Material findings ranked by business impact
- The evidence reviewed and important information gaps
- Estimated remediation and integration costs
- Dependencies, separation issues, and transition-service needs
- The potential impact on valuation, terms, timing, or closing
- Recommended Day 1, 30-day, 90-day, and 180-day actions
Cost estimates should include more than new products. Licensing, consulting, internal labor, user disruption, data migration, contract termination, training, temporary services, and ongoing headcount can all change the total.
The report should also separate confirmed findings from assumptions. Missing logs, incomplete inventories, or unavailable evidence do not prove that a problem exists, but they do increase uncertainty. That uncertainty is itself relevant to the deal.
Pre-Close Diligence and Post-Close Integration Are Different Jobs
The two phases support each other, but they have different purposes.
Pre-close diligence helps the buyer understand what it is buying, identify material risk, estimate costs, challenge assumptions, and make informed transaction decisions.
Post-close integration turns that information into action. Typical activities include identity consolidation, email and data migration, endpoint deployment, network connectivity, security-tool onboarding, logging integration, policy alignment, user training, and remediation of known weaknesses.
A useful integration roadmap may look like this:
- Day 1: Establish incident escalation, protect privileged access, confirm endpoint and email visibility, validate backups, and tightly control connectivity between environments.
- First 30 days: Complete asset and account inventories, close critical exposures, stabilize monitoring, and validate recovery procedures.
- First 90 days: Consolidate core controls, address high-risk technical debt, align policies, and begin planned migrations.
- First 180 days: Complete longer-term integration, retire duplicate or unsupported systems, resolve remaining findings, and establish consistent governance.
The plan will vary by transaction. The principle does not: connect deliberately, based on known risk, rather than joining two environments first and investigating later.
Know What You Are Buying Before You Own It
IT and cybersecurity diligence is not a request for technical perfection. Every company has legacy systems, open findings, budget constraints, and work still to do.
The goal is informed consent.
Leadership should know the material technology dependencies, cyber risks, compliance concerns, integration challenges, and likely costs before the deal becomes final. With that information, the buyer can proceed confidently, negotiate appropriate terms, fund the work, require changes, or walk away.
Without it, the organization is not avoiding the cost. It is accepting an unknown cost at the moment its leverage is disappearing.
Need an Independent Technology and Cybersecurity Review?
MN Risk & Cybersecurity Advisory helps organizations translate technical findings into practical business and risk decisions. If you are evaluating an acquisition, preparing for integration, or need an independent view of a target’s security posture, let’s talk before the assumptions become obligations.