Tech DD vs IT DD vs Cyber DD: Where the Boundaries Sit

The Four Workstreams, Precisely Defined

The confusion starts with vocabulary. Advisory firms use these terms inconsistently, and some use them interchangeably on purpose, because a broader-sounding scope wins more mandates. Define them by the question each one answers, not by the label on the invoice.

Technology diligence: does the product work and will it scale

Technology diligence is a product and engineering assessment. It evaluates the thing the company sells. The core questions: is the architecture capable of supporting the growth case in the model, what is the quality and maintainability of the codebase, how competent and how deep is the engineering organization, how fast can this team ship, and what does the roadmap actually cost to deliver.

Typical deliverables include an architecture review, a code quality assessment (often static analysis plus a sample read), engineering velocity metrics pulled from the ticketing system, a technical debt register, a scalability opinion, and an engineering organization assessment covering seniority mix, attrition, and key person concentration.

The practitioner is usually a former CTO or VP of Engineering. The evidence is architecture diagrams, a read-only code repository, sprint data, and management interviews.

IT diligence: what does running the business cost

IT diligence is a cost and operations assessment of the internal estate, not the product. The core questions: what does the company spend on technology, what is in the contract stack, what is the license position, how is the help desk staffed, what is the state of the end-user environment, and what will all of that cost under sponsor ownership with the growth plan applied.

Typical deliverables include an IT spend baseline, a vendor and contract inventory with renewal dates and termination rights, a license compliance position, a run-rate model, a synergy or dis-synergy estimate, and a one-hundred-day IT plan.

The practitioner is usually a former CIO or an IT consultancy. The evidence is the general ledger, vendor contracts, license entitlements, and the IT org chart.

IT diligence is the workstream most often confused with technology diligence, and the confusion is expensive in both directions. A sponsor buying an enterprise software company who commissions IT diligence gets a good analysis of Microsoft licensing and the managed service provider contract, and learns nothing about whether the product can carry the growth case. A sponsor buying a distribution business who commissions technology diligence gets an architecture opinion on an ERP the company did not write.

Cyber diligence: is it defensible, and is someone already inside

Cyber diligence is a security posture and active threat assessment. It has two halves, and most buyers only get the first one.

The first half is posture: what controls exist, how mature is the security program, what does the identity architecture look like, what is the backup and recovery position, what regulatory obligations attach to the data, and what is the third-party risk profile. This is the half that gets covered by a questionnaire and a policy review.

The second half is the one that matters on the deal clock: is there evidence of current or historical compromise in this environment right now. That is a different activity entirely. It requires telemetry, not documents. It is answered by a compromise assessment, by threat hunting against endpoint and identity logs, by dark web monitoring for exposed credentials, and by external enumeration of the internet-facing footprint.

The practitioner is a security assessor or an incident response firm. The evidence set is the only one of the four that is not primarily documents: it is logs, endpoint data, identity provider telemetry, and external scanning.

IP diligence: do they own what they are selling you

IP diligence is a legal and provenance assessment of the intellectual property. Core questions: is the code owned outright, were contractors and contingent workers subject to enforceable work-for-hire or assignment agreements, what open source is embedded and under what licenses, are there copyleft obligations attached to distributed code, are the trademarks and domains properly held, and are there outstanding claims or prior employer entanglements.

The practitioner is IP counsel. The evidence is assignment agreements, contractor contracts, employee invention agreements, a dependency inventory, and registration records.

IP diligence is the workstream most often deferred to legal and therefore most often scoped narrowly. Counsel reviews the agreements. Counsel does not run a scanner against the codebase to find out what open source is actually in there. That distinction has ended deals.

The Comparison Table

Dimension	Technology DD	IT DD	Cyber DD	IP DD
Core question	Does the product work and scale?	What does running the business cost?	Is it defensible, and is someone inside?	Do they own it?
Subject	The product and the engineering org	The internal IT estate	The whole environment plus the supply chain	The code, the marks, the agreements
Practitioner	Former CTO / VP Engineering	Former CIO / IT consultancy	Security assessor / IR firm	IP counsel
Primary evidence	Code, architecture, sprint data	GL, contracts, licenses, org chart	Logs, endpoint and identity telemetry, external scan	Assignment agreements, dependency manifest
Deal impact	Growth case, capex, roadmap credibility	EBITDA quality, run rate, synergies	Indemnity, escrow, closing conditions, insurability	Reps, fundamental warranties, walk rights
Typical timeline	3 to 5 weeks	2 to 4 weeks	2 to 4 weeks	2 to 6 weeks
Explicitly excludes	Security testing, license compliance, IP ownership	Product architecture, code, threat detection	Product scalability, IT cost modeling, contract review	Security posture, code quality, cost

Read the bottom row twice. The exclusions are the useful part of this table. Every one of them is a live risk that somebody on the deal team believes is covered.

Why the Labels Drift

Three forces push these scopes out of alignment.

First, practitioners expand their own labels. A technology diligence firm that adds a security questionnaire to its deliverable will describe itself as covering cyber. It is covering the documentary half of posture. It is not doing detection work, and its practitioners are not incident responders. The line item says security review. The buyer reads that as cyber diligence complete.

Second, deal teams compress. Under a tight exclusivity window, the corp dev lead or the deal partner picks one provider to cover everything technical, because managing four workstreams across four vendors is operationally painful. The single provider is genuinely strong in one of the four and adequate in the other three. The report reads evenly. The depth is not even.

Third, the seller's data room is organized to answer documentary questions, not evidentiary ones. It is full of policies, certificates, architecture diagrams, and org charts. A workstream that consumes documents will feel productive inside that data room. A workstream that requires telemetry will feel obstructed, because the telemetry is not in the data room and getting it requires a separate negotiated access grant. Guess which workstream gets quietly descoped when the timeline compresses.

The practical consequence: scope drift is not usually anyone lying. It is four honest providers each doing their own job well, and nobody holding the map that shows what falls between them. For a fuller treatment of the cyber-specific half of that map, see What Is Cyber Due Diligence and What Is M&A Cyber Due Diligence.

Where You Pay Twice

Overlap is the less dangerous failure, but it is the one that annoys deal partners most, because it is visible on the invoice. Four areas overlap reliably.

Cloud architecture review

Technology diligence reviews cloud architecture for scalability and cost efficiency. Cyber diligence reviews the same cloud environment for identity configuration, network exposure, logging coverage, and public storage. Both teams request console access. Both teams run an assessment tool against the same accounts. Both bill for it.

The fix is not to pick one. The two reads are genuinely different: a workload can be beautifully scalable and catastrophically exposed. The fix is to grant console access once, jointly, and require in both SOWs that the provider consume the other's read-only export rather than re-running enumeration. That typically saves five to fifteen thousand dollars per side on a mid-market deal and, more importantly, saves the target's engineering team from provisioning access twice under time pressure.

Third-party and vendor inventory

IT diligence builds a vendor inventory for cost, contract, and renewal analysis. Cyber diligence builds a vendor inventory for data-flow and third-party risk analysis. These are the same list of companies analyzed on different axes.

Build it once. Have IT diligence produce the master vendor list with spend, contract terms, and renewal dates. Have cyber diligence enrich that list with data classification, integration type, and access scope. One artifact, two columns sets, no duplicated interview burden on the target's controller.

Engineering organization assessment

Technology diligence assesses the engineering organization for capability, depth, and key person risk. IT diligence assesses technology headcount for cost. Cyber diligence assesses who holds privileged access. Three teams interview the same VP of Engineering about the same twenty people.

Open source inventory

This one is the most consequential overlap because it is usually an overlap in name only. IP counsel asks management for a list of open source components. Technology diligence may run a static analysis tool that happens to enumerate dependencies. Neither of those is a software composition analysis with license resolution and transitive dependency walking. Both parties may believe the other has it covered. See the gap section below.

Where the Risk Actually Lives: The Six Gap Items

These six items are not covered by default in any of the four standard scopes. Each one has to be explicitly bought. In a large share of mid-market deals, none of them are.

1. External attack surface enumeration

Nobody on a standard scope enumerates what the target exposes to the internet from an attacker's vantage point. Technology diligence looks at the architecture as designed. IT diligence looks at the contract stack. Cyber posture review looks at whatever the target listed in its asset inventory.

The problem is that the target's asset inventory is not the target's attack surface. Forgotten subdomains, an abandoned marketing microsite with a vulnerable content management system, a staging environment with production data and no authentication, an exposed remote access appliance from a 2019 project, a developer's cloud account outside the main organization: these do not appear on the inventory precisely because nobody is managing them. Attack surface management is a discipline the target does not have, which is why you have to run the enumeration yourself.

Cost on a mid-market target: modest, often a few thousand dollars. Value: this is where the single highest-yield finding in cyber diligence most often comes from.

2. Dark web credential exposure

Nobody checks whether the target's corporate credentials are already for sale. Posture review asks whether multi-factor authentication is deployed. It does not ask whether an infostealer log from eighteen months ago contains a session cookie for the target's identity provider, or whether an initial access broker has already listed the company.

The finding matters for a specific and time-sensitive reason: if credentials are in circulation, the window between your signing and your closing is a period of elevated risk, and the seller has no economic incentive to spend on remediation during it.

3. Compromise assessment

This is the biggest gap and the most expensive one. None of the four workstreams asks, as a matter of course, whether there is an adversary in the environment right now.

Posture review is documentary. It establishes that a SIEM exists. It does not hunt in it. A compromise assessment is an evidence-driven search across endpoint, identity, and network telemetry for indicators of current or historical intrusion. It is the only workstream output that speaks to the question the sponsor actually cares about, which is whether the thing you are buying is already broken into.

Mandiant's M-Trends reporting has put global median dwell time in the low double digits of days in recent years, which is substantially better than the months-long figures of the prior decade. That improvement is driven heavily by ransomware, which announces itself. Quiet intrusions, the kind that matter for a deal, still run long. An adversary present during diligence is an adversary you inherit, and post-close your fund is the deep pocket. That exposure is treated in What Is Sponsor Cyber Liability.

4. Testing the controls a SOC 2 report merely asserts

A SOC 2 Type II report is a useful artifact and a widely misread one. It reports an auditor's opinion on whether controls the company itself selected operated effectively over a review period, against criteria the company scoped. It is not a security test. It is an attestation about a control description.

Three things a SOC 2 report will not tell you. It will not tell you what was excluded from scope, unless you read the system description carefully and notice the absence. It will not tell you whether the controls would withstand an attacker, because nobody attacked them. And it will not tell you about the subservice organizations carved out of the report, which is where a meaningful share of real risk sits.

Read the exceptions section. Read the scope boundary. Read the carve-outs. Then test the two or three controls the investment thesis actually depends on. SOC 2 compliance is a floor, not a finding.

5. Software composition analysis

IP counsel asks for the open source list. Management provides a list. The list is generated from memory, or from a direct dependency file, and it stops at the first level.

Modern applications pull hundreds to thousands of transitive dependencies. A permissively licensed direct dependency can pull a copyleft transitive dependency four levels down. Black Duck's annual Open Source Security and Risk Analysis reporting has consistently found open source in the overwhelming majority of commercial codebases audited, with a large share carrying license conflicts and known vulnerabilities. A real software composition analysis walks the full dependency tree, resolves licenses at every level, and produces a software bill of materials you can actually rely on.

Nobody owns this by default. Technology diligence is looking at code quality. IP counsel is looking at agreements. The dependency tree sits between them.

6. Penetration testing

Sellers rarely permit active testing during a live process, and that is a reasonable position. The failure is not the absence of a pen test. The failure is treating the target's most recent pen test report as equivalent.

Ask three questions of any pen test report in the data room. What was the scope, and did it include the crown jewel application or only the corporate network? Was it a full penetration test or an automated vulnerability scan with a cover page? And critically: were the findings remediated, and is there a retest report proving it? A two-year-old report with fourteen open high-severity findings and no retest is not evidence of a security program. It is evidence that somebody bought a report.

The Compounding Effect

Each of these six is individually cheap. Together they typically add a small fraction to a total diligence budget that already runs into six figures across financial, legal, commercial, and technology workstreams.

The asymmetry is the point. Enumerating an external attack surface costs less than one hour of a deal lawyer's time on the purchase agreement. The finding it produces can reprice a deal, add a specific indemnity, or, in the case of an active compromise, stop one. Sponsors who have lived through a post-close incident do not need this argument made to them. Sponsors who have not are the ones underwriting the risk.

Writing the Scope Boundary Into the SOW

The mechanism that closes these gaps is not a bigger budget. It is one paragraph in each statement of work, and a fifteen-minute meeting.

The exclusion clause

Require every technology-adjacent provider to include, in the SOW itself and not in a verbal assurance, an affirmative statement of what the engagement does not cover. The language to insist on:

"Provider affirmatively states that the following are outside the scope of this engagement and are not addressed in the deliverable: [enumerated list]. Provider will notify Client in writing within three business days of identifying any material risk observed during the engagement that falls outside this scope."

That second sentence matters as much as the first. A technology diligence practitioner reading a codebase will sometimes notice a hardcoded production credential or a copyleft license header. Without a notification obligation, that observation stays in the practitioner's head because it was not in scope. With one, it reaches you.

The scope-boundary meeting

Before any workstream starts, run a single call with all providers and the deal team. Put one artifact on the screen: a line-item list of every diligence item you believe you are buying. Go down the list. For each item, one provider claims it or nobody does.

Items nobody claims become a decision, made consciously and in the open: buy it, accept it as a known unknown, or convert it to a deal term. All three are legitimate. Discovering it post-close is not.

This call takes fifteen minutes and is the single highest-return process change available in technology diligence. Run it before the kickoff, not after the first draft reports arrive.

The deliverable-integration requirement

Four separate reports, delivered in four formats, with four sets of severity ratings, produce an investment committee memo written by whoever read them last. Require every provider to rate findings on a common scale and to express material findings in dollars and in deal-term language: purchase price adjustment, specific indemnity, escrow, closing condition, or post-close remediation budget. A finding expressed only as high severity is not usable by a deal partner. A finding expressed as $800,000 of remediation over eighteen months, of which $250,000 must occur pre-close to preserve insurability is. The mechanics of that translation are covered in Turning Diligence Findings Into Deal Terms.

The Conflict Nobody Names

A large share of technology and cyber diligence providers also sell post-close remediation, managed services, or integration work. That is not automatically disqualifying. Continuity between the team that found the problem and the team that fixes it has real value, and the diligence team's environmental knowledge is genuinely useful in the first hundred days.

But the incentive is structural and it runs in one direction. A provider whose diligence fee is fifty thousand dollars and whose potential remediation engagement is eight hundred thousand dollars has an economic interest in findings that are serious enough to require a large remediation program and not so serious that the deal dies. Nobody has to be dishonest for that gradient to bend a report.

Three controls. First, disclosure: require every provider to state in the SOW whether it intends to bid on post-close work, and whether it has any existing relationship with the target, the seller, or the seller's advisors. Second, separation on the deals where it matters: on a platform acquisition where the technology is the thesis, use a diligence provider that is contractually excluded from bidding on remediation, and run a separate competitive process for the remediation work using the diligence report as the specification. Third, on every deal, ask the provider directly to name the findings that argue against the transaction. A provider that cannot produce a single one has either found a remarkable company or has already decided what the report says.

The inverse conflict is worth naming too. A provider that has no remediation capability and no operating experience sometimes produces findings that are technically accurate and commercially useless, because the practitioner has never had to fix anything on a budget. The correction for both failure modes is the same: make every material finding carry a cost, a timeline, and a named deal instrument.

What Good Looks Like

A properly scoped technology diligence program on a mid-market platform acquisition has four characteristics.

• Every item is claimed. A written coverage map exists, produced before kickoff, showing which provider owns each diligence item and which items were consciously excluded.
• The evidentiary work is bought explicitly. External enumeration, credential exposure, and compromise assessment are separate line items, not assumed components of a posture review.
• Absence of evidence is treated as a finding. A target that cannot produce an asset inventory, a restore test record, or an incident log has not been managing those things. That is a governance finding independent of whether anything bad has happened yet. The artifact-level version of this discipline is laid out in the Technology Due Diligence Checklist.
• Findings arrive in deal language. Every material finding carries a remediation cost, a timeline, an owner, and a recommended instrument.

None of that requires a larger budget than a sponsor is already spending. It requires the coverage map and the fifteen-minute call.

Related Reading

• Technology Due Diligence: The Complete Guide
• The Technology Due Diligence Checklist
• Technology Due Diligence Red Flags That Kill Deals
• Active Compromise Discovered During Due Diligence
• What Is Cyber Due Diligence
• What Is Sponsor Cyber Liability

Frequently Asked Questions

Is cyber due diligence just a subset of technology due diligence?

No. They answer different questions using different evidence. Technology diligence evaluates the product: architecture, code quality, scalability, and engineering capability. Cyber diligence evaluates defensibility and active threat: identity architecture, control effectiveness, external exposure, and whether an adversary is present. A technology diligence practitioner is usually a former engineering leader reading code and architecture. A cyber diligence practitioner is a security assessor reading logs and telemetry. Many technology diligence providers include a security questionnaire in their deliverable, which covers the documentary half of posture and none of the detection work. Treating that questionnaire as cyber diligence is the single most common scope error on mid-market deals.

If the target has a SOC 2 Type II report, do I still need cyber diligence?

Yes. A SOC 2 Type II is an auditor's opinion on whether controls the company selected operated effectively over a period, against criteria the company scoped. It is an attestation, not a test. Three things it will not tell you: what was excluded from scope, whether the controls would survive an actual attacker, and what happens inside the subservice organizations carved out of the report. Read the exceptions section and the carve-outs, then test the two or three controls your investment thesis actually depends on. A clean SOC 2 report and an active intruder can coexist in the same environment without contradiction.

Which of the four workstreams should I buy if I can only afford two?

It depends on what you are buying. If the product is the thesis, as in a software platform acquisition, buy technology diligence and cyber diligence, and push IP questions into the reps and warranties with a fundamental warranty on code ownership. If you are buying a services, distribution, or manufacturing business where technology is an operating cost rather than the product, buy IT diligence and cyber diligence. In every case, buy the compromise assessment as a separate explicit line item. It is the cheapest of the gap items relative to the loss it prevents, and it is the one no standard scope includes.

What does it cost to close the six gap items?

On a mid-market target the incremental cost is typically modest relative to a total diligence budget that already runs well into six figures across financial, legal, commercial, and technology workstreams. External attack surface enumeration and dark web credential exposure checks are the cheapest and often the highest-yield. A compromise assessment is the largest single line item of the six and scales with the number of endpoints and the depth of available telemetry. Software composition analysis is largely tool-driven with analyst interpretation. The asymmetry is the argument: the enumeration work costs less than an hour of deal counsel's time on the purchase agreement.

Can one provider do all four workstreams?

Some can, with genuine depth in each. Most cannot, and the report will read evenly regardless. Test it by asking for the named practitioner and the specific evidence set for each workstream. If the same person is reading the code, modeling the IT run rate, hunting in the SIEM, and opining on copyleft obligations, you have one workstream wearing four labels. Ask who holds the incident response credentials, ask whether IP counsel is reviewing the assignment agreements, and ask to see a redacted sample deliverable for each of the four. A provider with real four-way capability will produce them without friction.

How do I stop paying twice where the workstreams overlap?

Grant access once and require providers to consume each other's outputs. Cloud console access should be provisioned jointly, with one enumeration export shared across technology and cyber workstreams rather than two separate runs. The vendor inventory should be built once by IT diligence with cost and contract columns, then enriched by cyber diligence with data classification and access scope. Management interviews should be consolidated so the VP of Engineering is not interviewed three times about the same twenty people. Write the consumption obligation into each SOW so it is a contractual expectation rather than a hopeful request at kickoff.

Should I use the same provider for diligence and post-close remediation?

It is common and not automatically disqualifying, but the incentive gradient is real: a provider with a small diligence fee and a large potential remediation engagement benefits from findings serious enough to require a big program and not serious enough to kill the deal. Require disclosure of intent to bid in the SOW. On platform acquisitions where technology is the thesis, use a diligence provider contractually excluded from remediation work and run a separate competitive process using the diligence report as the specification. On every deal, ask the provider to name the findings that argue against the transaction. An inability to name any is itself informative.

What is the fastest way to find the gaps in a diligence program already underway?

Run a coverage map exercise. List every diligence item you believe you are buying, put all providers on one call, and go down the list item by item. Each item is claimed by exactly one provider or by nobody. Items nobody claims become a conscious decision: buy it, accept it as a known unknown, or convert it to a deal term such as a specific indemnity or a closing condition. All three outcomes are defensible. Discovering the gap after close is not. The call takes fifteen minutes and is the highest-return process change available in technology diligence.

Marriott and Starwood: A Scope Gap With a Four-Year Dwell Time

Marriott International completed its acquisition of Starwood Hotels and Resorts in September 2016. In November 2018, Marriott disclosed that unauthorized access to the Starwood guest reservation database had been occurring since 2014. Marriott's initial disclosure estimated up to approximately 500 million guest records affected. The company later revised the figure to roughly 339 million guest records globally, including a subset with passport numbers and encrypted payment card data.

The intrusion predated the acquisition by roughly two years. It continued through the diligence period, through the close, and for more than two years of Marriott ownership before detection.

The UK Information Commissioner's Office issued a notice of intent to fine Marriott just over £99 million in July 2019 and ultimately imposed a penalty of £18.4 million in October 2020, reduced in part for remediation and for the impact of the pandemic on the hospitality sector. The ICO's penalty notice was explicit about the diligence point: it found that Marriott had failed to undertake sufficient due diligence when it bought Starwood and should have done more to secure its systems.

That is a regulator stating, in a published enforcement decision, that acquisition diligence scope is a data protection obligation of the acquirer.

Map the failure to the four workstreams. Technology diligence on the Starwood transaction would have evaluated the reservation platform's architecture and its capacity to merge with Marriott's. IT diligence would have modeled the integration cost of two large hospitality estates. IP diligence would have addressed brand and franchise agreements. Cyber posture diligence, if performed, would have reviewed Starwood's security policies and certifications.

None of those four activities, performed competently and to their standard scope, would find an adversary quietly resident in a reservation database. Only a compromise assessment would, and a compromise assessment is precisely the gap item that none of the four workstreams owns by default.

The counter-example runs the same logic in the buyer's favor. Verizon agreed to acquire Yahoo's operating business for approximately $4.83 billion in July 2016. Yahoo subsequently disclosed two historical breaches, including one ultimately confirmed to affect all three billion Yahoo accounts. In February 2017 the parties amended the agreement, reducing the purchase price by $350 million to approximately $4.48 billion, and agreeing to share certain post-closing liabilities, with Yahoo's remaining entity (renamed Altaba) retaining others.

The difference between Marriott and Verizon is not that one company was more careful about security. It is that in one transaction the security facts surfaced before the price was fixed, and in the other they surfaced two years after the money moved. Scope determines which of those two outcomes a buyer gets.