This IT due diligence checklist helps operating partners review a target’s infrastructure, applications, integrations and vendors before an acquisition. Each item names its area and whether it is visible from outside or needs access. Use it to record evidence, assign an owner and build an authorized request list for unresolved questions.
In short
- Copy the checklist directly from this page; every task has an area and an access label.
- Start with public front-end, app, tag, domain and hosting evidence, then request internal records.
- Attach evidence, an owner and an open question to each task before turning findings into actions.
What should be included in a due diligence checklist?
An IT due diligence checklist should cover the public stack, internal systems, data integrations, technical debt, vendors and security questions. It should identify the evidence each task needs and whether the task can be answered from outside.
Map public front-end technologies and shared templates. Record visible defects and the pages where they appear.
Record tags and measurement tools visible on public pages. Keep their presence separate from whether internal reporting is accurate.
Review customer-facing apps at normal browsing rates and record where the public journey breaks.
Map public domain and hosting evidence, including the source and the date observed.
Review internet-facing exposure, certificates and security headers using passive public sources only.
Request the app inventory and architecture records, then reconcile them with the public stack map.
Request data integration maps and records of dependencies between internal systems.
Review authorized code and technical debt evidence. Separate visible symptoms from verified internal causes.
Request vendor contracts, license records and SaaS spend to test duplication and understand obligations.
Agree written scope and authorization before active scans, login attempts or penetration testing.
Source: Meo Advisors checklist. As of October 2026.
This checklist supports the technology due diligence review. Adapt the tasks to the acquisition plan and the target’s systems before requesting records.
How should an operating partner use this checklist?
Use the checklist as an evidence and request list. Record what was observed, who owns the question, and which document or authorized check would resolve a gap.
- Set the acquisition question and the review scope before collecting evidence.
- Copy the tasks into the working review document and assign an owner to each.
- Add the evidence source, observation date and finding beside each completed task.
- Keep unanswered tasks open with the record or permission needed; missing evidence is never scored as a failure.
- Turn supported findings into actions with an owner and a completion measure.
The IT due diligence guide explains how these tasks fit into the review process and the deal decision.
What are the key components of a technology due diligence checklist?
The components split between the public front end, tags, customer-facing apps, domains and hosting, and the internal apps, integrations, code and contracts that need authorized access.
| Visible from outside | Needs authorized access |
|---|---|
| Front end and templates | App internals |
| Tags and measurement | Data integrations |
| Customer-facing apps | Code and technical debt |
| Domains and hosting | Vendor contracts and SaaS spend |
Which checklist items can be answered from outside the target?
Public front-end and template checks, visible tags, customer-facing apps, domains, hosting and passive exposure observations can start outside the target. Contract terms, spend, internal dependencies and code quality need additional evidence.
Before authorization we use passive public sources only: DNS, certificate transparency, third-party internet-scan datasets, and the target’s public pages at normal browsing rates. No port scans, vulnerability scans or login attempts without written authorization.
Use the cybersecurity due diligence checklist for the security review and its authorization boundary.
What are five core parts of due diligence?
For an IT review, use five working parts: scope, evidence, risks, access requests and actions. Together they connect the acquisition question to supported findings and accountable follow-through.
| Part | What to record |
|---|---|
| Scope | The acquisition question, systems in scope and review boundary |
| Evidence | The observation, source and date for each task |
| Risks | The supported finding and its potential effect on the plan |
| Access requests | The record, permission or interview needed to resolve an open question |
| Actions | The owner, proposed fix and completion measure |
Connect the IT work with the other areas through the private equity due diligence checklist.
What should the completed IT checklist produce?
A completed checklist should produce a stack map, technical debt flags and an access request list, with evidence and owners attached to the findings.
What we deliver
A Stack Map, Technical Debt Flags & an Access Request List.
The sample diligence deliverables show how findings connect to the plan, risk register and scorecard.
How can I copy or save this IT due diligence checklist?
The full IT checklist is visible in HTML on this page. Select and copy the tasks into your working document, or use your browser’s print command to save the page as a PDF.
Keep the area and access labels when copying. Add your evidence, owner, status and open question beside each task so the saved version preserves the review boundary.
Meo Advisors Editorial writes and maintains this page. Its numbers are Meo Advisors’ own statements or cited external benchmarks, and every mock is labelled Illustrative. See the editorial policy and corrections process.