7 IT Due Diligence Checks Before Buying, Merging With, or Taking Over a Business

What IT due diligence should a business run before an acquisition or major vendor transition?

Before buying, merging with, or taking over a business, leadership should verify asset ownership, identity access, cybersecurity controls, vendor contracts, backup recoverability, data obligations, and post-close support capacity. The goal is not a perfect technical audit. The goal is to uncover hidden operational risk before it becomes a post-close outage, breach, invoice surprise, or integration delay.

For Modesto and Central Valley companies, this matters in ordinary transactions: buying a professional services firm, absorbing a medical practice, expanding a manufacturing operation, acquiring a branch office, replacing an incumbent MSP, or consolidating Microsoft 365 tenants after a merger. The legal and financial diligence may look clean while the technical environment is held together by undocumented admin accounts, unsupported firewalls, shared passwords, stale backups, expired warranties, and contracts nobody can exit cleanly.

That is a bad way to inherit risk.

Below is a seven-part IT due diligence checklist business leaders can use before signing, closing, or handing control to a new managed IT provider.

1. Confirm who owns the core technology assets

The first due diligence question is brutally simple: who owns the systems the business runs on?

Do not assume the seller owns its domain, Microsoft 365 tenant, line-of-business software, firewall, phones, laptops, cloud backups, website, DNS, security tools, or administrator accounts. In small and mid-market environments, critical systems are often registered under an employee’s personal email, an old vendor’s account, a departed founder’s login, or a reseller portal the business cannot directly access.

Ask for an inventory that identifies:

• Domains, DNS hosts, registrar accounts, and renewal dates
• Microsoft 365, Google Workspace, Azure, AWS, and SaaS tenants
• Firewalls, switches, wireless controllers, servers, NAS devices, and endpoint fleets
• Backup platforms, storage destinations, and encryption-key ownership
• Security tools such as EDR, MDR, SIEM, MFA, email filtering, and vulnerability scanning
• Phone systems, internet circuits, and copier or print management contracts
• Admin accounts, break-glass accounts, shared mailboxes, distribution lists, and service accounts

The point is not just asset tracking. The point is transferability. A business can have good-looking systems and still be fragile if nobody can prove ownership, recover administrator access, or transfer billing without vendor cooperation.

This is where a managed IT partner can help separate “we use the tool” from “we control the tool.” For Datapath clients, this kind of ownership mapping often overlaps with managed IT services and managed IT transition services because the first operational risk is usually access, not hardware.

2. Map identity, administrator access, and privileged accounts

Identity is the control plane for modern IT. If the acquiring company does not understand who can administer email, files, devices, security tools, accounting software, EHR systems, ERP systems, and cloud infrastructure, it does not understand its real exposure.

NIST’s Cybersecurity Framework emphasizes governance, cybersecurity risk management, and supply-chain risk management as part of an organization’s broader cyber program.¹ In practical due diligence terms, that means leadership should not treat access review as a low-level technical chore. It is a transaction risk issue.

Review:

• Global administrators in Microsoft 365 or Google Workspace
• Domain administrators and local administrators
• VPN, RMM, remote-access, and privileged support accounts
• Third-party vendor accounts with persistent access
• Former employee accounts that remain active
• Shared accounts with no named owner
• MFA coverage for administrators and remote users
• Conditional Access policies, location restrictions, and device requirements
• Emergency access accounts and whether they are monitored

The red flags are obvious but common: one global admin used by the old MSP, no MFA on privileged accounts, inactive executives with mailbox access, unknown service accounts, unmanaged remote desktop exposure, and third-party tools that can touch every endpoint.

A clean diligence package should include a current privileged-access export, MFA status, admin-role assignments, guest-user review, and a plan to rotate credentials after close or transition. If Microsoft 365 is central to the business, use Datapath’s related guidance on Microsoft 365 identity security services and conditional access policy rollout as a benchmark for what a mature review should cover.

3. Review cybersecurity controls against a real framework, not vibes

A seller saying “we have cybersecurity” is not diligence. It is marketing.

The acquiring company should ask what controls exist, whether they are enforced, who monitors them, and what evidence proves they work. NIST’s supply-chain risk management guidance describes cybersecurity supply-chain risk as something organizations must identify, assess, and mitigate across the lifecycle of technology products and services.² That applies directly when a company inherits another company’s systems, vendors, data flows, and software dependencies.

At minimum, review evidence for:

• Endpoint detection and response on servers and workstations
• Patch-management cadence and exception handling
• Email security, SPF, DKIM, DMARC, and phishing controls
• Vulnerability scanning and remediation history
• Firewall rules, exposed services, VPN configuration, and remote-access tools
• Security awareness training and phishing simulation history
• Logging coverage for identity, endpoints, email, and critical applications
• Incident-response plan, escalation contacts, and recent security events
• Cyber insurance requirements and whether controls match the application

Do not accept a screenshot of a dashboard as sufficient proof. Ask for exports, policy settings, recent reports, exception lists, remediation tickets, and evidence that someone reviews alerts.

The commercial lesson is straightforward: if the business cannot prove the control exists, the buyer should price the remediation or require cleanup before close. A pre-close cybersecurity risk assessment can prevent a painful surprise where the first 90 days of ownership are consumed by emergency patching, endpoint replacement, MFA rollout, and vendor disputes.

4. Evaluate software, SaaS, and vendor contracts before they become integration traps

Technology diligence should include vendor and software review, not just network review. A business can be technically operational but commercially trapped by non-transferable licenses, expiring contracts, weak service terms, or vendors that will not support the acquiring company’s integration plan.

CISA’s Secure by Demand guidance pushes buyers to ask direct security questions during technology procurement and to evaluate software manufacturers’ security practices as part of the buying process.³ That same discipline belongs in acquisition and transition diligence. If the target company depends on a software vendor, outsourced IT provider, cloud platform, billing system, EHR, ERP, CRM, or vertical application, diligence should test whether that vendor can safely support the transaction.

Ask each critical vendor:

• Is the contract assignable after acquisition or ownership change?
• Who owns the data, configuration, logs, and backups?
• What are the support hours and escalation paths?
• What security documentation is available?
• Does the vendor support SSO, MFA, role-based access, and audit logging?
• What happens if the company terminates service?
• How long does data export take?
• Are there early termination fees, auto-renewals, or minimum commitments?
• Does the vendor rely on another subcontractor or hosting provider?
• Are integrations documented?

This matters because many post-close IT failures are not caused by sophisticated attackers. They are caused by boring commercial blockers: a SaaS contract that cannot transfer, a phone vendor that needs 60 days, a backup vendor that will not release encryption keys, a software vendor that only supports the old MSP, or an internet provider that cannot provision the new location on time.

For regulated or multi-location organizations, vendor diligence should connect to vendor risk management services and co-managed IT services so internal IT, finance, legal, and operations are reviewing the same evidence.

5. Test backup, disaster recovery, and business continuity before close

Backup claims are cheap. Restore tests are evidence.

Before buying or taking over a business, ask for proof that critical systems can be recovered within the time the business actually needs. A backup report that says “successful” does not prove the application can be restored, that the data is usable, that credentials are available, that dependencies are documented, or that the recovery process fits the business’s tolerance for downtime.

Review:

• Backup scope for servers, endpoints, Microsoft 365, file shares, databases, and SaaS platforms
• Recovery-point objective and recovery-time objective by system
• Last successful restore test and who witnessed it
• Immutable or protected backup configuration
• Backup encryption and key ownership
• Off-site replication and geographic separation
• Runbooks for ransomware recovery and clean restore validation
• Dependencies between identity, network, storage, applications, and internet circuits
• Manual downtime procedures for critical workflows

The FTC Safeguards Rule guidance is written for covered financial institutions, but its operational logic is useful for many businesses: security programs should account for risk assessment, safeguards, service provider arrangements, testing, security events, and management response.⁴ In a transaction, those categories become diligence questions. Has the business tested the safeguards it claims to rely on? Can management see the evidence? Are service providers contractually obligated to support recovery?

For healthcare, finance, government, education, and manufacturing organizations in the Central Valley, this is not theoretical. If the acquired business cannot operate during an outage, ship product, access patient records, process payroll, invoice customers, or answer phones, the acquisition model is wrong until continuity is proven. Datapath’s disaster recovery services and related ransomware incident response planning are natural follow-up areas when diligence exposes weak recovery evidence.

6. Identify compliance and data obligations before systems are connected

Never connect two business environments until the data obligations are understood.

The acquiring company needs to know what sensitive data exists, where it lives, who can access it, how long it must be retained, whether it is encrypted, which laws or contracts govern it, and whether any known incidents or audit findings remain unresolved.

Depending on the business, this may include:

• Protected health information
• Student records
• Financial customer information
• Payment-card data
• Criminal justice information
• HR records and payroll data
• Customer contracts and confidential business files
• Intellectual property, CAD files, formulas, or proprietary operating procedures
• Email archives and legal-hold requirements
• Public-sector records retention obligations

The worst answer is “everything is in SharePoint” or “the old IT company handles that.” Diligence should map the sensitive data by system, owner, permission model, retention requirement, and integration risk.

For example, if a Modesto business acquires a healthcare clinic, the buyer should review HIPAA-related technical safeguards, backup coverage, EHR access, remote access, audit logs, and vendor business associate obligations before integrating accounts or migrating files. If a financial services company buys a local advisory practice, the review should include GLBA-related safeguards, customer information handling, vendor access, incident response, and breach notification expectations.

Relevant Datapath resources include HIPAA compliant IT services, GLBA Safeguards Rule compliance services, and cybersecurity compliance services. The main point is that compliance should shape the migration plan, not be discovered after the migration breaks something.

7. Build a 30-60-90 day IT transition plan before the deal closes

The final due diligence deliverable should not be a pile of screenshots. It should be a 30-60-90 day IT transition plan with owners, costs, risks, dependencies, and decision points.

A useful plan separates immediate containment from longer-term modernization.

In the first 30 days, prioritize:

• Administrator access verification
• Credential rotation
• MFA enforcement for privileged and remote access
• Backup validation
• Endpoint security deployment or confirmation
• Critical vendor introductions
• Known vulnerability remediation
• Documentation capture
• Support escalation paths

In days 31 to 60, address:

• Tenant cleanup
• Device standardization
• Patch-management normalization
• Network diagram and firewall review
• Vendor contract cleanup
• Security logging improvements
• Help desk process integration
• User onboarding and offboarding workflows

In days 61 to 90, move into:

• Strategic roadmap
• Budget planning
• Cloud and infrastructure modernization
• Disaster recovery exercises
• Compliance evidence packaging
• Cyber insurance control alignment
• Executive reporting and quarterly review cadence

This is where diligence becomes operational accountability. A buyer does not need every system perfect on day one. But leadership does need to know what must be fixed immediately, what can be staged, who owns the work, and what the risk is if action is deferred.

That is also where a regional IT partner can create value. Datapath works with organizations that need IT support to be practical, accountable, and tied to business outcomes, not buried in vague technical reports. For Modesto and Central Valley companies evaluating an acquisition, MSP transition, or co-managed IT model, the right question is not “Do we have IT?” The right question is “Can the business prove its technology, security, vendors, and recovery plan are ready for the next ownership or operating model?”

Practical checklist for executives

Use this list before signing, closing, or switching providers:

1. Do we control the domain, DNS, email tenant, admin accounts, and backup encryption keys?
2. Do we have a current inventory of devices, servers, cloud platforms, applications, and vendors?
3. Are all privileged accounts named, reviewed, protected by MFA, and ready for credential rotation?
4. Can the seller or incumbent provider produce evidence for endpoint security, patching, vulnerability management, email security, and logging?
5. Have we reviewed vendor contracts for assignment, termination, support, data export, and security obligations?
6. Have critical backups been restored and validated, not merely reported as successful?
7. Do we know what regulated or sensitive data exists and what obligations apply?
8. Are there known incidents, audit findings, unsupported systems, or insurance exceptions?
9. Is there a 30-60-90 day plan with owners, costs, and risk ratings?
10. Does leadership have a plain-English executive summary before making the transaction decision?

If the answer to several of these is “not sure,” the business is not ready for a clean handoff.

When should a business bring in an outside IT due diligence partner?

Bring in an outside IT due diligence partner before close, before an MSP transition, or before integrating networks, accounts, and data. The highest-value window is early enough to influence price, terms, escrow, remediation requirements, transition services, or the first 90-day operating plan.

An outside partner is especially useful when:

• The buyer does not have a large internal IT team
• The target company relies on an incumbent MSP
• The business operates in healthcare, finance, education, government, or another regulated environment
• Microsoft 365, Azure, or line-of-business applications are central to operations
• There are multiple locations, remote users, or legacy systems
• The seller cannot produce current documentation
• The buyer needs board-level or executive-ready findings

Datapath can help evaluate the technical environment, identify transition risk, and build a practical remediation roadmap for organizations in Modesto, the Central Valley, and other Datapath service markets.

Talk with Datapath about IT due diligence and transition planning.

FAQ

What is IT due diligence?

IT due diligence is the structured review of a company’s technology assets, cybersecurity controls, vendors, data obligations, backups, and operational support model before an acquisition, merger, carve-out, or major provider transition. It helps leadership identify hidden risk before ownership or responsibility changes.

How long does IT due diligence take for a mid-sized business?

A focused diligence review can often be scoped in days and completed in phases, depending on the size of the environment, number of locations, quality of documentation, and cooperation from vendors. Complex regulated environments, unsupported systems, or poorly documented networks require deeper review.

What documents should a seller provide for IT due diligence?

A seller should provide asset inventories, network diagrams, software and SaaS lists, vendor contracts, privileged-account exports, backup reports, restore-test evidence, cybersecurity policies, incident history, compliance obligations, support tickets, insurance control requirements, and documentation for critical business applications.

Is IT due diligence only needed for acquisitions?

No. IT due diligence is also useful before switching MSPs, entering a co-managed IT arrangement, consolidating locations, migrating Microsoft 365 tenants, outsourcing IT, absorbing a department, opening a new branch, or integrating a newly acquired practice or business unit.

What are the biggest IT red flags during acquisition diligence?

Major red flags include unknown admin accounts, no MFA, unsupported servers, untested backups, undocumented firewalls, personal ownership of business domains, expired licenses, non-transferable vendor contracts, unresolved security incidents, no endpoint protection, and no credible transition plan.

Footnotes

1. National Institute of Standards and Technology, “Frameworks,” Source ↩

2. National Institute of Standards and Technology, “SP 1326, NIST Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide,” Source ↩

3. Cybersecurity and Infrastructure Security Agency, “Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem,” Source ↩

4. Federal Trade Commission, “FTC Safeguards Rule: What Your Business Needs to Know,” Source ↩