A manufacturer does not need to be a software company to have material technology risk. Start with whether the business can keep taking orders, delivering services, running payroll, and collecting cash under new ownership.
Start with the business, not the server list
For a non-software acquisition, we recommend reviewing seven areas: infrastructure, cybersecurity, vendors, people, applications and data, integration or separation, and post-close spending. The output should connect evidence to a deal decision, not simply record whether a document exists.
For each material issue, answer four questions:
- Business impact: What could stop, become more expensive, or fail to scale?
- Evidence: What has been inspected, and what remains a management representation?
- Timing: Does this need resolution before close, at Day 1, or during the hold period?
- Cost and ownership: Who will resolve it, and what one-time and recurring spending should the buyer consider?
This is an operating framework, not a substitute for a scoped diligence engagement. A completed checklist does not certify security, regulatory compliance, recoverability, or investment readiness.
A request list your deal team can actually use.
Start with ten priority requests. Expand into the evidence you need, with suggested owners, a target cover note, and a response-tracking template.
No confidential deal information needed. Download format: Markdown.
The seven-area IT due diligence checklist
Use the questions below to guide management interviews and evidence review. A confident answer is a starting point; the supporting records determine how much reliance to place on it.
01Infrastructure and business continuity
Map the systems that support revenue before debating modernization. Identify the dependencies behind each critical workflow, including cloud services, local equipment, connectivity, facilities, and external support.
- Critical dependencies: Which systems support ordering, production or service delivery, payroll, invoicing, and collections? Who owns each dependency?
- Supportability: Which servers, endpoints, network devices, and operating systems are unsupported or approaching a planned replacement? What limits the ability to patch or replace them?
- Recovery: When was each critical workload last restored and tested, how long did recovery take, and how much data was lost relative to the business’s accepted recovery targets?
Ask for an asset inventory, environment diagram, support-status report, backup scope, and the latest restore-test record. CISA’s joint guidance for MSPs and customers recommends tested backups and aligning backup frequency with the recovery point objective, rather than treating a successful backup job as proof of recovery (CISA MSP guidance).
A business-critical system has no demonstrated recovery path, or its recovery depends on an unavailable person or unsupported platform. Carry the uncertainty into the deal assessment until it is resolved; do not mark it low risk because the system has not failed recently.
02Cybersecurity, identity, and incident exposure
Evaluate implemented controls and exceptions, not only policies. Include the access used by the MSP, software vendors, remote employees, and administrators.
- Privileged access: Who can administer the environment, and which privileged or remote access paths have MFA exceptions? Are accounts attributable to named users?
- Control coverage: What proportion of the in-scope estate is covered by endpoint protection, patching, monitoring, and log retention? Which systems are excluded, and why?
- Incident readiness: What material incidents, claims, open investigations, or unresolved findings should be reviewed with management and counsel? Who can authorize containment outside business hours?
Ask for dated configuration exports or a supervised walkthrough, coverage reports with a defined denominator, an exception register, and incident-response ownership. CISA specifically recommends MFA on MSP accounts accessing customer environments and clear contractual requirements for that access (CISA MSP guidance).
An MSP has broad access through shared or weakly controlled accounts, or management cannot reconcile stated protection with actual coverage. Assign immediate ownership and a bounded validation step rather than assuming a tool purchase closes the gap.
03MSPs, vendors, contracts, and licensing
Separate the services the business receives from the services someone assumes are included. Have transaction counsel assess the legal effect of assignment, change-of-control, termination, and data-use provisions.
- Service scope: Who owns identity, security monitoring, backups, recovery testing, documentation, and escalation? Where do contracts leave an important responsibility unassigned?
- Commercial exposure: What renews during the transaction or early hold period? What minimum commitments, termination costs, renewal notice dates, or consent requirements need review?
- Ownership and exit: Does the target control its domains, tenants, subscriptions, administrative access, and data exports? What would a provider transition require?
Ask for executed agreements, amendments, recent invoices, service reports, and an ownership schedule. A proposal or generic service description should not be treated as the complete agreement.
The buyer plans to replace an MSP but has not established access ownership, transition assistance, or the cost of leaving. Resolve the dependency before issuing termination notice.
04IT organization and key-person risk
Draw the operating model as it exists today, including responsibilities held outside the IT department. A finance employee maintaining an integration or a contractor controlling the only recovery procedure belongs in the assessment.
- Accountability: Who makes technology decisions, approves spending, accepts risk, and directs suppliers?
- Concentration: What stops working if the IT lead, a key contractor, or the incumbent MSP is unavailable immediately after close?
- Transferability: Which runbooks, escalation paths, vendor relationships, and recovery procedures have a second person capable of using them?
Ask for a role-based organization chart, supplier responsibility matrix, key-person dependencies, and representative runbooks. Request role and coverage information first; unnecessary personal employee data does not belong in a general technology request.
Critical operations depend on one person’s undocumented knowledge. Establish a retention or transition workstream with management, HR, and counsel rather than assuming documentation can be reconstructed later.
05Applications, data, and reporting
An ordinary operating business may depend on purchased software, extensive customizations, spreadsheets, and fragile connections between them. Assess business reliance without turning every engagement into a source-code audit.
- System fit: Which ERP, accounting, CRM, industry, or scheduling systems run the business? Can they support the proposed entity structure, additional locations, reporting, and transaction volume?
- Data flow: How do orders, inventory, customer records, and financial results move between systems? Where are manual workarounds or reconciliations essential?
- Ownership and portability: Can the target export usable data, retrieve configuration, and obtain support without depending on a departed developer or uncooperative vendor?
Ask for an application register, integration map, customization inventory, reporting examples using redacted or synthetic data, and known limitations. If proprietary software or custom integrations are material to the thesis, add the appropriate specialist review instead of treating “non-software company” as an exemption.
The investment case assumes rapid reporting consolidation or ERP standardization without validating data quality, integrations, and operating requirements. Separate an interim reporting plan from the longer-term system decision.
06Integration, separation, and Day 1
Make the transaction perimeter explicit. A standalone acquisition, an add-on, and a carve-out need different technology decisions even when they use similar systems.
- Day 1 continuity: Who will control administrative access, vendor escalation, domains, communications, and critical operating systems at close?
- Shared services: Which systems, licenses, people, contracts, or data remain with the seller or depend on another group company?
- Sequencing: What must change immediately, what can operate safely in parallel, and what requires a dependency map, vendor consent, or transition agreement?
Ask for the in-scope entity and site list, shared-service inventory, proposed Day 1 model, and integration or separation assumptions. For a carve-out, identify the required technology services and exit dependencies for counsel and the transaction team to address in the TSA.
A system is presented as part of the target’s environment but is actually licensed, administered, or hosted by the seller. Do not assume a commercial agreement alone establishes a technically workable separation.
07Post-close capex, opex, and thesis readiness
Translate the findings into spending the buyer can evaluate. Distinguish correcting an inherited condition from building capabilities required by the new investment thesis.
- Current run rate: What does technology actually cost across IT, finance, operations, and departmental budgets?
- Deferred spending: Which renewals, replacements, licensing reconciliations, security fixes, or staffing needs fall shortly after close?
- Value-creation assumptions: What must be funded to support add-ons, new sites, automation, reporting, or margin improvement?
Ask for trailing-12-month actual spending, the current budget, material invoices, renewal schedules, and project commitments. For each estimate, record assumptions, range, timing, dependencies, and confidence; reconcile overlapping estimates before using them in the deal model.
A low reported IT budget excludes essential costs or relies on seller-provided services that will disappear. Assess the normalized operating requirement with finance instead of treating historical spend as the forward budget.
What to request first
Start with ten information packages that establish the perimeter, operating dependencies, and biggest unknowns. Accept existing records rather than asking a small target to manufacture a polished data room before meaningful review can begin.
- Legal entities, locations, users, and the proposed transaction perimeter.
- Critical business workflows and their supporting technology.
- Identity, administrative access, and MFA coverage.
- Executed MSP and other critical technology agreements.
- Technology vendor, subscription, renewal, and ownership schedule.
- IT roles, supplier responsibilities, and key-person dependencies.
- Core application register.
- Integration, customization, and essential spreadsheet inventory.
- Proposed Day 1 ownership and seller/shared-service dependencies.
- Trailing-12-month technology spending and current budget.
The downloadable request list expands these packages into evidence-level follow-ups. Missing records should be logged with an owner and validation route, not silently treated as a clean result.
Turn the checklist into deal decisions
We recommend keeping evidence confidence separate from risk severity. “Not yet verified” is not the same as “low risk,” while an absent document is not automatically proof that a control is absent.
| Evidence state | How to record it | Next action |
|---|---|---|
| Management representation | Record the statement, speaker role, date, and scope | Request corroborating evidence |
| Document received | Record the file, date, scope, and any limitations | Check completeness and currency |
| Validated within scope | Record what was inspected or observed and by whom | Assess residual risk and business impact |
| Unresolved | Record the missing evidence, disagreement, or access limit | Assign an owner, deadline, and transaction consequence |
The deal team can then decide whether an issue needs pre-close resolution, further investigation, funded Day 1 action, or inclusion in the longer-term plan. Potential contractual protections, insurance implications, and legal conclusions belong with the appropriate counsel and advisers.
Illustrative example: Management reports that an ERP is backed up nightly, but no recent restore-test record is available. Record the recovery capability as unverified, establish an authorized validation plan, and estimate the cost and time needed to address the exposure; do not invent an outage duration or presume the backup is unusable.
Scope boundaries
Use this checklist for technology operating risk in services, industrial, distribution, healthcare-services, and other non-software targets. Tailor the request to the business, transaction stage, and agreed access rather than treating every item as mandatory.
- Specialist work: Penetration testing, source-code review, forensic investigation, detailed ERP business-process assessment, and sector-specific assurance require explicit scope and appropriately qualified specialists.
- Access authorization: An NDA protects information; it does not by itself authorize scanning, production access, testing, or changes. Agree permissions, collection methods, and system-owner approval before technical validation.
- Information handling: Use the approved data room or secure transfer channel. Do not request passwords, MFA recovery codes, private keys, production database exports, or unredacted patient, customer, or employee records for an initial review.
- Professional boundaries: This resource provides operational guidance, not legal, tax, accounting, insurance-coverage, or investment advice. It does not establish compliance or replace transaction-specific professional review.
Frequently asked questions
How is IT diligence different when the target is not a software company?
Begin with the technology needed to operate the business and deliver the investment thesis. Code quality becomes a separate workstream when custom software is materially important, rather than the default center of the review.
Can the target’s MSP answer the checklist?
The MSP can provide important evidence about the systems and services it manages. Ask management, finance, and other critical vendors to cover the responsibilities outside that contract, and distinguish provider statements from independently validated findings.
What if the target has little documentation?
Record the gap and request an authorized walkthrough, existing exports, or representative records. Do not let the request process become a documentation project that conceals the uncertainty the buyer needs to understand.
Is an ERP replacement recommendation part of the checklist?
The checklist is designed to flag fit, support, integration, and reporting concerns. Selecting a replacement, redesigning business processes, and producing an implementation plan require additional investigation and agreed scope.
What should the buyer receive from a full review?
Look for an evidence-backed risk register, business implications, clearly stated limitations, and sequenced post-close actions with cost assumptions. Vertex’s published engagement describes a diligence memo, remediation roadmap, capex and opex forecast, and material vendor summaries (Technology Due Diligence for Private Equity).