# IT due diligence must price the handover

> IT due diligence gives acquirers one evidence-backed view of systems, contract traps, security exposure, transfer risk, and integration cost.

An acquirer does not need three disconnected reports on systems, contracts, and security. It needs one evidence-backed view of what transfers, what can keep operating on day one, and what it will cost to own. When those workstreams run separately, each can look acceptable while the deal still contains a six-month integration bill nobody priced.

The useful unit of IT due diligence is a business capability linked to its systems, data, people, suppliers, contract rights, security evidence, and replacement cost. A list of applications is only the beginning. I have seen clean architecture diagrams hide an unassignable cloud agreement, a founder-controlled domain, and a production database that nobody had restored. All three are integration facts, not footnotes.

## One inventory must connect four views

Build one inventory that connects operations, ownership, contracts, and security. Separate spreadsheets encourage false agreement because teams use the same system name for different things. Finance means the vendor invoice, engineering means the workload, security means the identity tenant, and legal means the signed order form. The acquirer pays for the gaps between them.

Use one row per operating asset or tightly coupled service. Do not force an entire product into one row if its components can fail, transfer, or be replaced independently. A customer portal, its identity provider, its payment processor, and its data warehouse deserve separate rows even if management calls all of them the platform.

The minimum fields are concrete:

- Business capability and revenue or operational dependency
- Technical owner, business owner, and administrator identity
- Hosting location, data classes, integrations, and recovery target
- Supplier, agreement, renewal date, spend, and transfer condition
- Evidence reviewed, open finding, planned disposition, and cost range

Add stable IDs so evidence and questions can point to a row without relying on names. Record a source and an observation date for every material field. Unknown is a valid value; blank is not. A blank quietly turns into an assumption, while an explicit unknown becomes a request, a cost reserve, or a deal condition.

This structure sharpens a distinction teams routinely blur: an asset inventory describes what exists, while a transaction inventory describes what the buyer can control after closing. NIST Cybersecurity Framework 2.0 separates inventories of hardware, software and services, supplier services, data, and network flows. That scope is right for operations. An acquisition adds transfer rights, administrative custody, separation dependencies, and a priced disposition to every item.

A practical starting artifact is a CSV with columns that survive export from a deal room:

```csv
asset_id,capability,system,owner,admin_identity,data_class,upstream,downstream,supplier,agreement_id,renewal,transfer_status,evidence,day1_disposition,target_disposition,cost_low,cost_high,confidence
IT-014,customer_login,identity_tenant,platform_lead,buyer_pending,customer_pii,customer_portal,support_console,external_vendor,AGR-022,2027-03-31,consent_required,admin_export_2026-08-05,retain,migrate,45000,90000,medium
```

The sample row does more work than a red risk label. It tells the deal team that login depends on a supplier, consent is unresolved, buyer administration is not ready, and migration has a bounded estimate. Replace the example values with evidence from the target. Never let the target mark transfer_status as clear without linking the clause or consent that supports it.

## Evidence beats the management application list

Start with management's list, then try to disprove it using operating evidence. The fastest inventory method runs several discovery paths in parallel and reconciles the results. Ask for exports, not screenshots, because exports can be sorted, compared, and sampled.

Pull at least these sources: the general ledger and payables vendor list, identity provider applications and groups, cloud organization accounts and subscriptions, domain and certificate records, source control organizations, mobile app publisher accounts, endpoint management, backup consoles, network configuration, and the latest data-flow or architecture diagrams. For software dependencies, an SPDX or CycloneDX bill of materials can expose direct and transitive components. CycloneDX also models external services and dependency relationships, which makes it more useful than a flat package list, but it still does not tell you who owns an account or whether the contract transfers.

Reconciliation matters more than collection. A vendor paid by finance but absent from identity records may use shared credentials. An active single sign-on application with no recent invoice may sit on a founder's card or a free plan that cannot support the buyer's controls. A production hostname absent from the architecture diagram may point to an abandoned environment that still receives customer data.

Use four tests on each material system:

1. Can the operator show the production account and current administrator list?
2. Can finance tie it to a supplier, invoice, or credible internal ownership record?
3. Can engineering trace its upstream and downstream dependencies?
4. Can someone produce recovery evidence or explain the replacement path?

This is one of the two practical walkthroughs in the review, so keep it focused. Sample every tier-one system and a risk-based selection from lower tiers. A 500-row inventory with no tested records is weaker than a 120-row inventory where every revenue-bearing path has evidence.

Do not equate a current SOC 2 report with evidence that the target configured or operates a service safely. The report describes the service organization's controls and scope. You still need the target's tenant configuration, access list, incident history, backup responsibility, and exceptions. The same caution applies to penetration tests: a report can be genuine, recent, and irrelevant to the system you are buying.

Inventory completeness has an observable finish condition. Every material ledger vendor, privileged identity application, production endpoint, code repository, data store, and critical supplier should map to an inventory ID or a documented exclusion. Track unmatched items as a queue. When the queue stops shrinking because the target cannot explain entries, convert the uncertainty into a cost or closing condition instead of extending interviews forever.

## Criticality comes from failure, not architecture labels

Rank systems by the consequence of losing them, not by how senior the owner sounds or how modern the architecture looks. A small file-transfer job can be more important than the analytics platform if it sends the day's settlement file. The acquirer needs to know which failures stop revenue, breach an obligation, corrupt records, or prevent staff from serving customers.

For each capability, write a plain failure statement: If this system stops at noon on a weekday, what happens by noon tomorrow? Name the affected customers or internal process, the manual workaround, the data at risk, the maximum tolerable outage, and the person who can authorize recovery. If the answer depends on an engineer who plans to leave after closing, the people risk belongs on the same row.

Use tiers sparingly. Tier 1 should mean that interruption creates immediate revenue, safety, regulatory, or contractual harm and that the workaround cannot carry the normal load. Tier 2 can tolerate a limited outage with a tested workaround. Tier 3 has a replacement or delay that the business can absorb. Do not let half the estate become Tier 1. That usually means the team has not made tradeoffs.

Then draw the dependency chain for each Tier 1 capability. Begin at the customer or employee action and follow identity, DNS, network, application, queue, database, external API, observability, and support access. Record shared components once and reference them. This reveals concentration that system-by-system questionnaires miss. Ten products may all depend on one identity tenant, one cloud organization, or one person with registrar access.

Ask operators to demonstrate one ordinary transaction and one failure path. For an order flow, watch an order enter, reach its downstream records, appear in monitoring, and enter a recovery or support process when something fails. You are testing whether the diagram matches the running company, not whether the demo looks polished.

The distinction between recoverable and recovered also matters. A backup policy, successful job status, or vendor feature shows that data might be recoverable. A dated restore record with scope, duration, errors, and owner shows that someone recovered it. Price the gap. If a Tier 1 database has never been restored, the integration plan needs a restore test before migration, plus time to fix whatever the test exposes.

## Contract clauses can rewrite the technical plan

Read technology contracts as operating constraints. Counsel should decide legal meaning and enforceability; the IT review should identify how each clause changes day-one continuity, migration timing, security duties, and cost. A clause is material when it can remove access, force a purchase, delay a transfer, or restrict the buyer's intended architecture.

Assignment and change-of-control language is the first trap. Contracts may treat an equity sale, asset sale, merger, internal restructuring, or transfer to an affiliate differently. Some require prior written consent. Some let the supplier terminate, change pricing, or withhold consent. The inventory should record the exact trigger, required notice, consent owner, expected lead time, and fallback. Writing assignable after reading only a master agreement is reckless if the order form or later amendment controls.

Commercial terms hide another integration bill. Look for automatic renewal windows, minimum usage commitments, prepaid credits, tier resets, termination fees, minimum seats, mandatory support packages, audit charges, and price protections that end after a transaction. Compare contract spend with actual consumption. A three-year commitment can make consolidation uneconomic even when the buyer already owns a preferred tool.

Data clauses can block the proposed target state. Record hosting regions, localization promises, deletion periods, subprocessor terms, customer notice duties, audit rights, security schedules, encryption commitments, and restrictions on combining datasets. A plan to move all customers into the buyer's shared analytics environment fails if the target promised isolation or a specific region. The cost model then needs a compliant exception, customer consents, or a different migration.

Ownership needs proof at both company and component level. Check employee invention assignments, contractor intellectual-property clauses, repository ownership, source-code escrow obligations, third-party code, and open-source licenses. SPDX can communicate provenance and license information, but the SPDX project explicitly does not make legal interpretations. Treat a bill of materials as evidence for review, not a legal conclusion. Counsel must assess obligations where reciprocal licenses, missing notices, copied code, or unclear provenance appear.

Watch for operational poison pills outside the obvious software agreement: a reseller owns the tenant, the target has no direct support right, a parent company licenses the ERP, a customer contract mandates a named security control, or a transition service expires before the migration can finish. Each one should produce a disposition and price. Red flags without a proposed decision merely make the report feel busy.

## Security claims must survive a live check

Test control claims against current configuration and recent evidence. Security questionnaires reward complete sentences; acquisitions need proof that the buyer will inherit a controlled environment. Focus on paths that could produce a material incident before or during integration.

Begin with identity. Export users, groups, service accounts, privileged roles, authentication methods, dormant accounts, and external guests from each identity plane that controls production. Trace break-glass accounts and recovery channels. Check whether founders, contractors, a seller's parent company, or a managed provider retains authority. Shared administrator accounts create both security and handover risk because the buyer cannot attribute actions or know who still has the secret.

Then test exposure and response. Compare internet-facing hosts with the inventory. Review a sample of critical vulnerabilities to see how the team validates, assigns, remediates, and accepts them. Ask for recent security incidents and near misses, the decision log, customer notices where applicable, and proof that corrective work reached production. An empty incident register may mean excellent operations, but it can also mean the company never defined an incident.

For data protection, follow a sensitive record through collection, storage, replication, analytics, support access, backup, export, and deletion. Confirm encryption and access claims in configuration. Ask how the company deletes a customer across primary systems, derived stores, and backups. Do not accept we encrypt everything as an answer until the team names the boundaries, keys, exceptions, and owners.

Recovery deserves a witnessed sample for every Tier 1 path. Review backup coverage, isolation, retention, monitoring, and restore evidence. Select one representative system and ask the target to restore into a safe environment during diligence if deal timing allows. Record the actual time, missing permissions, undocumented steps, and validation result. A failed test is often more informative than a perfect policy because it gives the integration team a real work package.

Keep severity tied to transaction outcomes. A critical scanner label is not automatically a deal issue, and a low-severity finding can be one if it exposes the only domain account. Use four decisions: remediate before close, hold money or add a covenant, accept with a funded post-close plan, or change the transaction perimeter. The report should state who owns each decision and what evidence will close it.

## Control of accounts decides whether the asset transfers

Verify custody of every account that can approve, publish, recover, or redirect the business. Legal ownership of code does not help if the mobile application publisher, domain registrar, code-signing identity, cloud root account, or payment administration remains with a founder's personal email. These accounts often sit outside the normal employee directory, so ordinary access reviews miss them.

Create a custody register for domains, DNS, certificates, app stores, source control, package registries, cloud organizations, identity tenants, messaging providers, payment services, support portals, backup vaults, monitoring, and status communications. For each, record the registered entity, primary email, recovery email, phone, hardware authentication holders, billing owner, support entitlement, and transfer procedure.

The buyer needs a day-one access plan, not a promise that credentials will be shared. Named buyer administrators should receive accounts through the service's supported process. Privileged access should use individual identities and strong authentication. Rotate secrets after control changes, but sequence rotations by dependency. Rotating an integration credential before finding every consumer can create the outage diligence was meant to prevent.

People and systems must be assessed together. Identify who can deploy, restore, approve access, explain billing, respond to incidents, and contact each material supplier. Mark single-person dependencies, planned departures, retention terms, location constraints, and documentation quality. Do not reduce this to a headcount table. Two engineers may hold different parts of the same recovery process, and losing either one can break it.

Ask each owner to perform a handover task: grant a test permission, locate the signed agreement, explain an alert, restore a sample, or trace a customer deletion. This detects ceremonial ownership, where a name appears in a spreadsheet but the actual work belongs to someone else. It also gives the buyer a realistic list of transition sessions instead of a generic knowledge-transfer budget.

The cleanest close packet includes approved administrator changes, recovery channels controlled by the buyer, a secret-rotation sequence, retained seller access with expiry dates, and evidence that critical notifications reach buyer staff. If a provider will not transfer an account, state whether the buyer must create a new tenant and migrate. That is an architecture decision with a schedule, not an access-ticket detail.

## Integration cost needs a range and a reason

Estimate integration cost as a set of work packages with uncertainty, dependencies, and owner rates. A single percentage of purchase price has no operational basis. So does one engineering estimate produced before anyone reads the contracts. The estimate should be traceable back to inventory rows and deal assumptions.

Use five cost buckets: continuity before and just after close, security remediation, contract and license changes, technical migration or consolidation, and temporary duplication or separation. Add internal labor, external specialists, supplier fees, new licenses, data egress, hardware, retention payments, and transition services where they apply. Keep recurring run-rate changes separate from one-time integration spend.

For each work package, estimate optimistic, expected, and adverse effort. Multiply role-days by loaded daily rates, then add direct supplier costs. Do not hide uncertainty inside an arbitrary contingency. Name its source: unknown data volume, pending consent, undocumented integration, untested restore, scarce specialist, or customer approval. An uncertainty with a trigger can be managed.

Use this calculation:

```text
one_time_cost = internal_role_days + external_services + supplier_fees + data_movement + temporary_duplicate_run
recurring_delta = new_annual_run_rate - retired_annual_run_rate
adverse_case = expected_case + priced_uncertainties_that_trigger
```

The internal_role_days term means the sum of days for each role multiplied by its loaded daily rate. Keep schedule separate from effort. Forty engineer-days may fit into two weeks with four available engineers, or take two months when one specialist owns the work and must also run production. A deal model that buys all of someone's time while operations still need that person counts the same capacity twice.

Sequence the work through dependencies. Consent must precede an account transfer. A restore test should precede a database migration. Identity federation should precede disabling seller accounts. Data classification should precede moving datasets. The longest dependency chain sets the earliest credible completion date, even when individual tasks look small.

Attach confidence to each range. High confidence needs observed configuration, a named owner, a signed contract, known volume, and a tested procedure. Medium confidence can tolerate one bounded unknown. Low confidence means the estimate rests on interviews or missing evidence. Present low-confidence material items separately so the investment committee can reserve money or change terms.

## A worked estimate exposes the hidden assumptions

Consider a target with a customer application, a separate identity tenant, one cloud account, a data warehouse, and a support system. The buyer plans to retain the application, move identity into its standard tenant, consolidate analytics, and replace support. The target says integration will take four weeks because each tool has an export.

The inventory changes that answer. The identity contract requires supplier consent, customer logins use tenant-specific identifiers, and three background jobs call the old tenant with static secrets. The warehouse contains regional customer data that cannot enter the buyer's default region under current commitments. The support export excludes attachments unless the target buys a service package. The only engineer who restored the application plans to leave at close.

Turn those facts into work packages. Continuity includes retaining that engineer for a bounded handover, testing an application restore, and establishing buyer administration. Identity includes consent, identifier mapping, code changes, dual-running, customer communication, and rollback. Analytics includes data classification, a compliant target region, pipeline changes, validation, and duplicate storage. Support includes the service package, attachment export, data mapping, retention rules, and agent training.

Now price three cases. The optimistic case assumes prompt consent, clean identifier mapping, no customer approvals, and complete exports. The expected case includes one migration rehearsal, a month of duplicate services, normal supplier lead times, and engineering rework discovered during testing. The adverse case triggers if consent fails, regional commitments require a separate environment, or the departing engineer does not complete the restore handover.

Do not turn this into false precision. Use rounded ranges and show the assumptions beside them. The decision-ready output might say that the expected case uses 110 to 150 role-days, supplier fees stated in the agreements, and two months of duplicate run cost, while the adverse case adds a new identity tenant and regional analytics environment. Those numbers are examples of output shape, not benchmarks. The target's evidence must supply the real values.

This walkthrough reveals why exports do not equal portability. Data extraction is one task. Semantic mapping, identity continuity, contractual permission, validation, rollback, and customer obligations determine whether the buyer can use the data without breaking the business. That distinction routinely changes both the purchase agreement and the first-quarter operating plan.

## Uncertainty belongs in the deal terms

Convert unresolved material findings into specific transaction mechanisms. More diligence is not always the answer. If the target cannot produce evidence before signing or closing, decide who carries the cost and what event releases the obligation.

Use a closing condition when the buyer cannot safely operate without the result, such as control of a core domain, a required supplier consent, or resolution of an active material exposure. Use a covenant for work that can continue after signing with clear evidence and a deadline. Use a purchase-price adjustment, escrow, holdback, or indemnity only with transaction counsel and a measurable trigger. The technical team should define the condition that can be tested, not draft legal language.

Good remediation wording names the asset, action, evidence, owner, and due date. Fix access control is useless. Replace it with a statement such as: the target will remove all personal recovery channels from the production cloud organization, enroll two buyer-named administrators with individual hardware-backed authentication, and provide an exported administrator list accepted by the buyer before close.

Tie assumptions in the integration model to deal protections. If the model assumes a supplier will consent at current pricing, assign an owner to obtain written confirmation. If customer approval is uncertain, segment affected revenue and estimate the alternative environment. If code ownership documents are missing, identify the contributors and repositories involved so counsel can target the cure.

Also record accepted risks. Buyers often ask teams to fix every finding because the report contains no explicit acceptance route. That wastes time and can destabilize the target before close. A named executive can accept a bounded post-close risk when the exposure, duration, compensating controls, cost, and exit condition are clear.

The diligence team should maintain one decision log linked to inventory IDs. Record the question, evidence, decision, owner, cost effect, schedule effect, and agreement reference. This prevents legal, security, and integration teams from resolving the same issue differently in separate meetings. It also preserves why the buyer funded an exception when the people who negotiated it move on.

## The deliverable must run the first 100 days

Finish with an operating packet, not a slide deck of colored risks. The buyer should be able to hand the packet to the integration lead on closing day and use it to assign work. If the final report cannot support that handoff, the review stopped too early.

The packet should contain the reconciled inventory, evidence index, dependency maps for Tier 1 capabilities, contract obligations and consent tracker, custody register, people dependencies, security findings, cost model, decision log, and sequenced integration backlog. Each material finding must link to an asset, business consequence, disposition, owner, evidence requirement, cost range, and target date.

Set day-one, day-30, day-60, and day-100 states around operating outcomes, not meeting activity. Day one covers control, continuity, incident contacts, and forbidden changes. Later states can cover restore proof, identity consolidation, supplier decisions, security remediation, data moves, and tool retirement. Preserve rollback points until the buyer has evidence that the new path works.

Define completion for every work package. Migrated is vague. A better condition says that production traffic uses the buyer-controlled service, reconciled records match agreed checks, monitoring and recovery pass, required customers received notice, the old system is read-only, and termination has an approved date. Specific completion criteria prevent duplicate costs from lingering because nobody can declare the old service finished.

Track value separately from cost. Consolidating a tool may reduce annual run rate, reduce a single-person dependency, or improve recovery. It may also consume scarce engineering time that would generate more value elsewhere. The acquirer should rank work by continuity, obligation, risk reduction, and economic return, then fund it against actual team capacity.

The first post-close review should compare diligence assumptions with observed facts. Update cost ranges, retire resolved uncertainties, and escalate surprises while deal protections and seller knowledge still exist. Do not preserve the original estimate to make the diligence report look accurate. Its job was to expose decisions early; the operating model must now reflect reality.

One-pass IT diligence works when every important claim ends in evidence, a decision, and a price. Keep systems, contracts, security, and people on the same inventory. That is how an acquirer finds the expensive seams before they become outages, forced renewals, or an integration plan that has already missed its date.