IT Due Diligence Checklist Template

Start about ten weeks before the target signing date. The first task names the four people and asks two questions: does the target build and sell its own software, and is it a whole company or a carve-out from the seller’s group. Every due date counts back from the signing date, in working days.

• Set up the IT due diligence — the target, the deal, the target signing date (which every due date counts from), whether the target builds and sells its own software, whether it is a whole company or a carve-out, and the four people; later tasks are assigned from these fields
• Agree the scope and materiality with the deal lead — the systems, sites and group companies in scope, the value above which a contract or cost is reviewed in full, the look-back period for incidents, whether a specialist security or code review is needed, and what the legal, financial and management workstreams cover instead
• Confirm the confidentiality terms and the rules for testing — the non-disclosure agreement in place, who on the buyer’s side may see security reports and architecture documents, and written agreement from the seller and the target, with its scope, before anyone scans or tests the target’s systems
• Agree the report format and the rating scale — a red-flag report of issues only or a full report by area, how each finding is rated, the date of the information reviewed, and whether lenders or a warranty and indemnity insurer will read it
• Send the IT request list to the seller — the documents and answers needed for each area in scope, numbered so every reply and every data room document can be traced to a request, with a date for the first replies

Agree how personal data is handled before anyone opens the room, get the reviewers in, see what is missing, keep one Q&A log and one issues list, and meet the target’s IT leaders. Answer the red-flag question on the issues list as soon as a red flag is found.

• Agree how personal data in system extracts and logs is handled — which user lists, access logs, incident reports and system extracts hold personal data, what is shared in full and what is summarised or has names removed, who may see it, and how long the buyer keeps it
• Set up data room access for the IT reviewers — a user for each reviewer, the folders each one may open, whether security documents can be downloaded, and the person who asks the seller for more access
• Check the data room index against the IT request list — which requests have documents, which are answered only in part, which are missing, and the IT documents in the room that no request asked for
• Set up the Q&A log and the issues list — one log of every question to the seller with its request number, date and answer, and one issues list of every finding with its area, rating, cost and proposed protection, kept up to date until signing
• Hold the IT sessions with the target’s IT leaders — an agenda sent beforehand, the target’s CIO, CTO or IT manager and the people who run security and infrastructure, the questions answered in the room, and the follow-up requests added to the Q&A log

Find out what the business runs on and what depends on what. A target that builds and sells its own software adds two tasks on the product itself.

• Build the systems and application inventory — each system with its business use, owner, users, where it is hosted, the contract or licence behind it, and when its vendor’s support ends
• Map the architecture and the key data flows — how the main systems connect, the integrations and interfaces between them, data that moves to customers, suppliers or the seller’s group, and any single point of failure
• Review the applications the business cannot run without — the systems behind sales, operations, finance and payroll, how much each is customised, whether its version is still supported, and who could support it if the people who built it left
• Review the data the business depends on — where the customer, product and financial data is held, how it is kept accurate, what is kept and for how long, and what would be needed to move or merge it after completion
• Review the product’s architecture and how it scales — how the product is built and hosted, how it handles growth in users and data, its availability record, and the third-party services it depends on
• Review the code, development practices and open-source use — code quality and test coverage, how changes are reviewed, tested and released, who holds the source code and the build tools, and the open-source components in the product and their licences

Find where everything runs, what the hosting and cloud contracts commit the target to, and whether the business could recover from an outage.

• List the infrastructure and where it runs — data centres and server rooms, cloud accounts and who owns them, networks and sites, end-user devices, and the age of the main hardware
• Review the hosting and cloud contracts — each provider’s term, notice period, minimum spend, where the data is held, service levels, and how the data comes back at the end
• Review cloud costs and commitments — the monthly cost for the last year, reserved or committed capacity still to pay for, costs that grow with users or data, and spending nobody owns
• Review backup, disaster recovery and continuity — what is backed up and how often, the recovery times the business expects, when recovery was last tested and what the test found, and the plan for losing a site or a key provider
• Review how IT is supported and run — the service desk, managed service providers, support hours, service levels and whether they are met, and how changes and incidents are handled

Find how well the target protects its systems and data, and what has already gone wrong. The security reviewer named on the first task leads this phase.

• Review the security policies, controls and certifications — the security policies and who owns them, the controls in place, and each certification or assurance report with what it covers and the period or date it relates to
• Review identity and access management — who has administrator rights, whether multi-factor authentication is used, how joiners, movers and leavers are handled, and what access suppliers and the seller’s group have
• Review patching, vulnerability management and recent testing — how quickly updates are applied, systems past the end of vendor support that are still exposed, the latest penetration test or security assessment, and what was fixed after it
• Review past security incidents and personal data breaches — incidents and breaches in the look-back period, how each was found, contained and fixed, what was notified to a regulator or to the people affected, and whether any claim or investigation is still open
• Rate the security posture and the cost to fix the gaps — the gaps found against the buyer’s own security standard, what it would cost and how long it would take to close each one, and which must be closed before the target connects to the buyer’s systems

Find what the target pays for, whether it is licensed for what it uses, and which IT contracts the deal affects. The lawyers read the terms; this phase records which contracts matter and what they mean for running the business.

• List the software licences and subscriptions — each vendor and product, the licence type, the number of users or seats, the annual cost and the renewal date, including licences held in the seller’s group name
• Check licence compliance and audit exposure — use against what was bought, any audit or true-up by a vendor in the look-back period, and the cost of putting any shortfall right
• List the IT contracts with change-of-control or assignment terms — which software, hosting and service contracts the deal could let a supplier end or reprice, which need consent or a new contract, and what that would mean for the business if consent were refused
• Review the outsourcing and managed service contracts — what each provider runs, service levels and credits, how dependent the business is on it, and the exit help and notice the contract gives
• Review IT spending and the budget — IT running costs and investment for the last three years and the current budget, spending that sits outside the IT budget, and costs that will rise after the deal

Find who runs IT and what they know that nobody else does, what is old and must be replaced, and what is already planned. The leaders’ own contracts and retention belong to management due diligence.

• Review the IT team, contractors and key people — the IT organisation and headcount, contractors and agencies, the people the systems depend on, and who might leave because of the deal
• Find knowledge held by one person or one supplier — systems only one person can run or change, undocumented processes, passwords and accounts held personally, and suppliers the business could not replace quickly
• Assess technical debt and end-of-life systems — systems past or near the end of vendor support, workarounds the business relies on, and the cost and time to replace or upgrade each one
• Review the IT roadmap and projects in flight — projects under way and their budget, status and contracts, investment already committed, and plans the buyer would stop, keep or change

Work out what the deal will cost in IT after completion. A carve-out adds four tasks on separating the target from the seller’s group; every run estimates the integration cost. This template leaves about a week and a half after Phase 7 for the seller’s answers to open questions.

• Map what the target shares with the seller’s group — the systems, networks, licences, contracts, data and IT staff the target uses but the seller’s group owns or runs
• Agree the separation approach for each shared service — whether each shared system or service is copied, moved, replaced or provided by the seller for a period after completion, and what has to be ready on the first day
• Draft the IT transitional services the seller will provide — each service, its service level, how long it runs, the charge, how it ends, and who on each side manages it
• Estimate the one-off separation cost and the stand-alone running cost — the cost of separating each service, the transitional service charges, and what the target’s IT will cost to run on its own once the services end
• Estimate the integration cost and the first year’s IT plan — the one-off cost of bringing the target onto the buyer’s systems or running it alongside them, the costs that rise or fall each year, the fixes the review found, and what must happen in the first 100 days

Bring the findings together, agree what each red flag means for the deal, get the decision before signing, and make sure the deal documents carry what was agreed. Nothing after the decision task can be completed until it is done.

• Escalate each red flag to the deal lead — what was found, where, why it matters, what it could cost, what more the seller has been asked, and whether the timetable needs to move
• Agree how each red flag will be dealt with — a price change, a specific indemnity, money held back, a fix the seller makes before completion, a cost added to the integration budget, or walking away
• Write the IT red-flag report — each finding by area with its rating and cost, the documents and sessions behind it, the treatment proposed, the integration cost, and the questions still open, with the date of the information reviewed
• Check the report with the other workstreams — the legal, financial, tax and management findings that touch the IT ones, so each issue and each cost is counted once and has one owner
• Present the findings to the decision maker — the red flags, the treatment proposed and the seller’s position on each, the integration and separation costs, and the questions still open
• Decision maker decides on the IT findings — the decision maker records proceed, proceed with specific protections, or stop before the buyer signs; nothing after this task can be completed until it is done
• Record the decision to stop and close the IT review — tell the deal team, the advisers and the seller as agreed, record the reasons, return or destroy the seller’s information under the non-disclosure agreement, and mark the tasks that no longer apply as not applicable
• Agree the specific protections for the IT red flags — for each red flag the decision named: the indemnity, money held back, price change or fix before completion, with the lawyers who draft it and the seller’s agreement
• Confirm the IT conditions and steps before completion — supplier consents, fixes the seller makes, the transitional services agreement where there is one, and what the seller may not change in IT between signing and completion, checked in the final documents
• Hand the findings to the integration team — the issues list, the integration cost estimate and its assumptions, the open consents and fixes, and the first 100 days in IT