Technology Due Diligence Red Flags That Kill Deals

Calibration: Three Questions That Sort Real From Ordinary

Run every finding through three questions in order. A finding that clears all three is a red flag. A finding that fails the first is a note for the hundred-day plan.

Question one: does it threaten the thesis?

Write the investment thesis in one sentence, then test each finding against it. The same technical fact can be a red flag in one deal and irrelevant in another.

A monolithic architecture with tight coupling and no service boundaries is a serious finding if the thesis is triple the customer base in four years and bolt on three acquisitions onto this platform. It is close to irrelevant if the thesis is steady cash generation from a stable customer base with a product roadmap that is mostly maintenance. Monoliths run profitable businesses for decades. The question is whether this monolith is being asked to do something it cannot do.

Same test for the rest. Slow release cadence matters if the thesis requires rapid product expansion into adjacent segments. Hosting cost inefficiency matters if the margin expansion case depends on operating leverage. A thin security program matters most when the target holds regulated data, sells to enterprises with audit rights, or is about to be connected to a larger portfolio estate.

A provider who cannot map findings to the thesis has not been told the thesis. Tell them. It is the single change that most improves the usefulness of a technology diligence report.

Question two: what does fixing it cost, in dollars and in months?

A finding without a remediation number is not actionable. Convert every material finding into three figures: the one-time cost, the ongoing run-rate change, and the elapsed time with the engineering capacity it consumes.

That third figure is the one deal teams routinely underweight. An eighteen-month platform remediation does not merely cost its budget. It consumes the engineering capacity that was supposed to deliver the product roadmap in the model. The real cost of technical remediation is frequently the growth it displaces, which is why the finding belongs in the model rather than in an appendix. The methodology is in Quantifying Technical Debt in M&A.

Once a finding carries a number, it becomes tractable. A $2 million remediation on a $60 million enterprise value is a price conversation. The same $2 million on a $12 million enterprise value is a different conversation entirely. Severity ratings obscure that distinction. Dollars do not.

Question three: is it a defect or a symptom?

This is the question that separates a good technology diligence practitioner from a competent one.

An unpatched server is a defect. It is fixable in an afternoon. An unpatched server in an environment with no asset inventory, no patch cycle measurement, and no named owner for the function is a symptom, and the symptom is worth far more than the defect. You are not buying one unpatched server. You are buying an organization that will generate unpatched servers indefinitely, because nothing in it is structured to prevent them.

The diagnostic question is simple: would this have been caught by a functioning process, and does that process exist? Findings that a functioning process would have caught are the ones that indicate the process is absent. Those are the findings that should be aggregated into a single management finding rather than listed individually, because they have one root cause and one remediation.

The Ordinary Ugliness That Is Not a Red Flag

An explicit list, because deal teams reading their first technology diligence report frequently overreact to these.

• Legacy code and old frameworks. A ten-year-old codebase running a supported framework version two releases behind current is normal. Escalate only when the runtime, framework, or database has passed end of support, which converts it from an aesthetic issue into a security and vendor risk issue with a hard deadline.
• Documentation gaps. Nearly universal. Matters when it compounds key person risk, which is a different finding.
• Some manual processes. Manual deployment is a velocity constraint, not a crisis, unless only one person can execute it.
• No dedicated security team at a sixty-person company. Expected. The finding is whether security is owned by someone named, with budget and a cadence, or owned by nobody.
• A technical debt backlog the team complains about. Engineers complaining about technical debt is the baseline condition of the profession. The signal is whether the debt is measured, prioritized, and funded, or whether it is a folklore list.
• Vendor concentration on a major cloud provider. Frequently flagged, rarely material. Multi-cloud portability is expensive and almost never exercised.

Against that baseline, what follows is the material set.

Red Flag One: Key Person Risk, Tested Rather Than Asserted

Every technology diligence report mentions key person risk. Most do it badly, by asking management who is critical and reporting the answer. Management will name two or three people and describe the rest of the team as solid. That is not a finding. That is an interview transcript.

Key person risk is measurable. Measure it.

Commit concentration

Pull the commit history for the trailing twenty-four months and compute the distribution of authorship across the codebase, weighted toward the components that matter commercially. The pattern that should concern you is not a high overall share for one engineer. It is one engineer holding a dominant share of commits in a specific high-value component that nobody else has touched in eighteen months.

Then cross-reference against the code review record. An engineer whose commits are consistently reviewed by two colleagues is transferring knowledge. An engineer whose commits are self-merged or rubber-stamped is accumulating it.

Credential holders

Ask for the named individuals who hold, personally: root or organization owner in the production cloud accounts, domain administrator, the code signing certificates and their private keys, the domain registrar login, and the DNS provider login. Then ask how many of those names are the same person.

This is a short exercise with a disproportionate yield. Code signing keys held by one departing engineer is a supply chain problem. A domain registrar controlled by a founder's personal email account is an existential dependency on one person's goodwill and one mailbox's security. Both are common in founder-led companies and both are invisible to an architecture review. The discipline that should be governing this is covered in What Is Privileged Access Management.

On-call rotation depth

Ask for the on-call schedule for the last six months and the paging records. A rotation of three or fewer people, or a rotation where one name appears on most of the escalations regardless of whose week it is, tells you the formal rotation is decorative. Count the escalation path, not the roster.

Systems only one person can safely change

Ask the engineering leadership directly: which systems would you not let anyone other than one specific person modify, and why. Engineers answer this question honestly because it is a practical operational reality rather than a judgment about their competence. Then ask the named individual the same question and compare.

Converting the measurement into a deal term

Key person findings do not go in the remediation budget. They go in the deal structure, and they get sized.

The sizing logic runs on displacement cost. If a named engineer holds exclusive knowledge of a component the growth case depends on, estimate what the departure costs: the months of delay before a replacement is productive on that component, the engineering capacity diverted to reconstruction, and the roadmap value pushed to the right. An illustrative example, and the numbers are purely illustrative: if the loss of one platform engineer would delay a revenue-generating release by six to nine months in a model where that release carries several million dollars of contribution, then a retention package in the low to mid six figures over a two to three year vesting period is inexpensive insurance, not a generous gesture.

Structure it properly. Retention should vest over the period in which knowledge transfer must occur, and the agreement should carry explicit documentation and cross-training obligations rather than only a continued-employment condition. Paying someone to stay without requiring them to distribute what they know preserves the risk while adding cost. Name the individuals in the deal documents, size each package against displacement cost rather than against current salary, and make the signed agreements a closing condition where the concentration is severe. The general mechanics of converting findings into instruments are covered in Turning Diligence Findings Into Deal Terms.

Red Flag Two: Intellectual Property Provenance and Open Source Licensing

This is the category with the highest ratio of severity to attention. It is chronically under-examined because it falls between workstreams: technology diligence is assessing code quality, IP counsel is reviewing agreements, and neither is walking the dependency tree. The boundary problem is described in Tech DD vs IT DD vs Cyber DD.

It is also the only category on this list that can produce an outcome worse than an expensive remediation. Licensing and provenance findings can make the asset unsellable in its current form.

Copyleft contamination in a distributed product

The mechanism is specific and worth stating precisely, because it is frequently described loosely.

Strong copyleft licenses, principally the GNU General Public License family, attach a source disclosure obligation to distributed derivative works. If a company distributes software that incorporates GPL-licensed code in a way that creates a derivative work, the license conditions that distribution on making the corresponding source available under the same terms. The Affero GPL extends a comparable obligation to software made available over a network, which removes the hosted-software carve-out that many software-as-a-service companies assume protects them.

For a private equity buyer this is not a compliance irritation. If a core differentiated component of the product carries an unresolved copyleft obligation, the remedies are limited and each is expensive: rewrite the affected component from clean specifications, negotiate a commercial license from the copyright holder if one is available, or comply and publish the source. The third option may destroy the differentiation the buyer is paying for.

Three things make this worse than it first appears. First, the obligation usually arrives through a transitive dependency, four or five levels below anything a developer consciously chose. Second, it is invisible to code quality review, because the code works perfectly. Third, it is invisible to agreement review, because there is no agreement. Only a software composition analysis that resolves licenses across the full transitive tree finds it, and producing a reliable software bill of materials is the mechanism for doing that. Black Duck's annual open source risk reporting has consistently found license conflicts in a substantial share of the commercial codebases it audits.

Contractor and work-for-hire gaps

The default legal position is less favorable than founders assume. Absent a written assignment, a contractor who writes code generally owns the copyright in what they wrote. Work-for-hire doctrine under United States copyright law applies to employees acting within the scope of employment and, for independent contractors, only to specifically enumerated categories of work under a signed written agreement. Software is not reliably within those enumerated categories, which is why competent technology contracts use an explicit present assignment of rights rather than relying on work-for-hire language alone.

The diligence procedure: pull the list of every individual who has committed code, including contractors, interns, agency developers, and offshore teams. Match each name against a signed agreement containing a present assignment. Then check the agreement's effective date against the person's first commit. Work performed before an agreement was signed is not covered by it unless the agreement expressly reaches back.

In founder-led companies the gaps cluster in the earliest period, which is also when the most architecturally central code was written. A missing assignment from a 2018 contractor who built the core engine is a materially different problem from a missing assignment from a 2024 contractor who built a marketing page.

Prior employer entanglement

Ask whether any founder or early engineer developed the initial product while employed elsewhere, and whether that employer's invention assignment agreement could reach it. This is uncomfortable to ask and it is the origin of some of the most damaging IP disputes in technology. The check is quick: the founders' prior employment agreements, and the commit timestamps for the earliest code.

AI-generated code of uncertain provenance

This is the newest item and the one with the least settled law, which is precisely why it belongs in diligence rather than being waved through.

The practical questions are answerable even where the legal questions are not. Does the company have a written policy governing the use of AI coding assistants? Which tools are in use, under which license tier, and do those tiers include the vendor's indemnification and output-filtering provisions? Is AI-assisted code identified anywhere, in commit metadata or code review practice? Has the company assessed whether generated code may reproduce licensed material?

The legal uncertainty about copyright status of machine-generated output is real and unresolved. The governance question is not uncertain at all. A company with no policy, no tool inventory, and no idea what proportion of its codebase was machine-generated has an unquantified provenance exposure in the asset you are buying. Record that as a finding, seek a specific representation on code provenance rather than relying on the general IP rep, and consider a specific indemnity where the exposure is material.

Red Flag Three: The Target That Cannot Produce Evidence

The pattern: every answer arrives verbally and confidently, and no answer arrives as an artifact. Asked for the asset inventory, management describes their approach to asset management. Asked for restore test records, management confirms that backups run nightly. Asked for the incident log, management states there have been no incidents.

That last answer deserves particular attention. A company of any meaningful size reporting zero security incidents across five years is far more likely to lack detection capability than to have experienced nothing. The absence of incidents in an environment with no logging, no endpoint detection, and no monitoring coverage is not evidence of safety. It is the expected output of not looking.

Three reasons evidence absence is a first-class finding rather than a documentation gap.

It is structural. Operational artifacts are byproducts of the operations themselves. A company running a real backup program generates restore test records without effort. A company managing its estate maintains an inventory because it needs one to patch. When the artifact does not exist, the practice generally does not either.

It is predictive of post-close cost. A management team that has not measured patch compliance, recovery times, or privileged access counts has no baseline. Establishing baselines, instrumenting, and building the reporting cadence is six to twelve months of work before any actual improvement begins.

It compounds every other finding. Every claim in a data room rests on management's word. In a company that produces evidence readily, a verbal claim is probably reliable because the culture produces artifacts. In a company that produces nothing, no claim can be verified, and the appropriate diligence posture shifts from verification to assumption of the downside. The artifact-level discipline for testing this is laid out in the Technology Due Diligence Checklist.

Red Flag Four: Security Findings That Change the Deal Rather Than the Budget

Most security findings are remediation line items. A few are not.

• Evidence of current or historical compromise. This changes the transaction, not the budget. It raises questions of pre-close liability, notification obligations, insurability, and whether the seller will remediate before funding. Treated in full in Active Compromise Discovered During Due Diligence.
• Undisclosed incidents that surface in diligence. The finding is not only the incident. It is that the seller either did not know or did not say. Both change how you read every other representation, and both are reasons to tighten the reps and the escrow.
• Inaccurate cyber insurance attestations. If the target attested to controls it does not have, coverage may be contestable at the moment it is needed. See What Is a Cyber Insurance Attestation.
• Regulated data outside the environment management believes it is in. Protected health information in a development database, cardholder data in application logs, or personal data in a third-party analytics tool that was never assessed. Each carries specific regulatory exposure that predates your ownership and follows the entity.
• Backups that are neither isolated nor tested. Not a technical observation. It is the determinant of whether a ransomware event is a two-week disruption or an existential one, which makes it a direct input to the downside case.

The Near-Disqualifying List

Few technology findings kill a deal outright. Most convert into price, escrow, indemnity, or conditions. The following four are different, because in each case the standard instruments do not adequately transfer the risk.

1. Undisclosed active compromise the seller will not remediate before close

Discovery of an active intrusion is not itself disqualifying. It happens, and it can be managed: the parties pause, a qualified incident response firm scopes and contains it, remediation is completed as a closing condition, and the deal proceeds on adjusted terms.

What is close to disqualifying is a seller who, once informed, declines to investigate or to remediate before funding. That response tells you the seller intends the buyer to inherit both the intrusion and the notification decision. An escrow does not solve it, because the harm is not only monetary: the buyer assumes the regulatory notification obligation, the customer relationships, and the disclosure exposure. For a public acquirer, the SEC's cybersecurity disclosure rules, effective for most registrants from December 2023, require a current report within four business days of determining that an incident is material. Inheriting an unremediated intrusion means inheriting that clock.

2. Code the company cannot demonstrate it owns

Where a material portion of the core product was written by individuals with no signed present assignment, and those individuals cannot be located or will not sign a confirmatory assignment, the company cannot convey clean title to the asset the buyer is paying for.

Representations and warranties do not fix this. A rep is a promise backed by a claim against a seller whose proceeds are already distributed, and representations and warranties insurance typically excludes matters known at signing. A known title defect is precisely what the policy will not cover. The remedies are narrow: obtain confirmatory assignments before close as a condition, or rewrite the affected components.

3. Unresolved copyleft obligation on the core differentiated product

If software composition analysis finds GPL or AGPL licensed code embedded in the component that constitutes the product's differentiation, and the company has distributed or hosted it without complying, the buyer faces a choice among rewriting, licensing commercially if a license is available, or complying and publishing the source.

This is near-disqualifying not because the risk of enforcement is necessarily high in any given case, but because the remedy interacts directly with the thesis. A buyer paying a premium for proprietary differentiation cannot hold a position where the credible remedy is publishing that differentiation.

4. Regulated-data compliance failure with an open regulator matter

A compliance gap is a remediation project. A compliance gap plus an open inquiry from a regulator or a state attorney general is a different instrument, because the quantum is unknown, the timeline is outside the parties' control, and the matter follows the entity through the transaction.

The specific problem is sizing. An escrow requires a number. An open regulatory matter at an early stage does not have one, and may not have one for two to three years. Where the potential exposure is large relative to enterprise value, the structural answers are limited: a substantially larger and longer escrow, a seller-retained liability with meaningful credit support behind it, an asset purchase structured to leave the liability behind where that is achievable, or no deal.

How to Read the Report You Receive

Four demands to make of any technology diligence provider, which improve the deliverable more than any increase in scope.

• Give them the thesis in writing. A provider assessing the technology in the abstract will produce an inventory of issues. A provider testing the technology against a stated thesis will produce a recommendation.
• Require dollars and months on every material finding. One-time cost, run-rate change, elapsed time, and the engineering capacity consumed. A severity rating is not an input to a model.
• Require an explicit top-five. Ask which five findings would change the decision, ranked, with the reasoning. This forces prioritization and exposes a provider who cannot do it.
• Ask what would argue against the deal. A provider that cannot name a single argument against the transaction has either found a remarkable company or already decided what the report says. The conflict is sharpest where the provider also sells post-close remediation.

And one discipline for the deal team: distinguish findings that change the price from findings that change the structure. Remediation cost is a price conversation. Unquantifiable or untransferable risk is a structure conversation, and the instruments are different. Conflating the two produces a bid that is priced for a risk the buyer has not actually transferred. The final packaging of all of this is covered in The Technology Due Diligence Report.

Related Reading

• Technology Due Diligence: The Complete Guide
• The Technology Due Diligence Checklist
• Tech DD vs IT DD vs Cyber DD: Where the Boundaries Sit
• Active Compromise Discovered During Due Diligence
• What Is Sponsor Cyber Liability
• What Is an SBOM (Software Bill of Materials)

Frequently Asked Questions

How do I tell a real red flag from normal engineering ugliness?

Three questions in order. Does it threaten the stated investment thesis? The same monolithic architecture is a serious finding when the plan is to triple volume and bolt on three acquisitions, and close to irrelevant when the plan is steady cash generation. What does fixing it cost in one-time dollars, run-rate change, and months of engineering capacity consumed? And is it a defect or a symptom? An unpatched server is a defect. An unpatched server in an environment with no asset inventory, no measured patch cycle, and no named owner is a symptom, and you are buying an organization that will keep generating them.

How do I measure key person risk instead of just asking about it?

Four measurements. Pull twenty-four months of commit history and compute authorship concentration weighted toward commercially important components, then cross-reference against code review records to see whether knowledge is being transferred or accumulated. Ask for the named individuals who personally hold root or cloud organization owner, domain administrator, code signing keys, the domain registrar login, and DNS provider access, and count how many are the same person. Pull the on-call schedule and paging records for six months and look at who actually gets escalated to. And ask engineering leadership which systems they would let only one specific person modify.

How should key person risk convert into a deal term?

Through retention packages sized against displacement cost, not against current salary. Estimate what the departure would cost: months of delay before a replacement becomes productive on that component, engineering capacity diverted to reconstruction, and roadmap value pushed to the right. Size the package against that number. Structure it to vest over the period in which knowledge transfer must occur, and include explicit documentation and cross-training obligations rather than only a continued-employment condition. Name individuals in the deal documents, and where concentration is severe make the signed retention agreements a closing condition rather than a post-close intention.

Why is open source licensing treated as a serious finding rather than a compliance item?

Because strong copyleft licenses attach a source disclosure obligation to distributed derivative works, and the Affero variant extends a comparable obligation to software delivered over a network, which removes the hosted-software assumption many SaaS companies rely on. If a core differentiated component carries an unresolved obligation, the remedies are rewriting it, licensing commercially if a license is available, or complying and publishing source. The third option can destroy the differentiation the buyer is paying for. The obligation usually arrives through a transitive dependency several levels down, invisible to both code quality review and agreement review.

What should diligence ask about AI-generated code?

The legal questions about copyright status of machine-generated output are unsettled, but the governance questions are answerable now. Does the company have a written policy on AI coding assistant use? Which tools are in use, at which license tier, and do those tiers include the vendor's indemnification and output-filtering provisions? Is AI-assisted code identifiable in commit metadata or review practice? Has anyone assessed whether generated output may reproduce licensed material? A company with no policy, no tool inventory, and no estimate of what share of its codebase was machine-generated has an unquantified provenance exposure. Seek a specific representation on code provenance rather than relying on the general IP rep.

What findings are close to disqualifying?

Four. An undisclosed active compromise where the seller, once informed, declines to investigate or remediate before funding, because the buyer then inherits the intrusion, the notification obligation, and the disclosure clock. Code the company cannot demonstrate it owns, where material portions were written by people with no signed present assignment who cannot be located, since a known title defect is typically excluded from representations and warranties insurance. An unresolved copyleft obligation on the core differentiated product. And a regulated-data compliance failure with an open regulator matter, because an escrow requires a number and an early-stage regulatory inquiry does not have one.

Can representations and warranties insurance cover technology findings?

Not the ones that matter most. These policies characteristically exclude matters known to the buyer at signing, which means anything diligence actually found is outside coverage. That is the structural point: a finding surfaced in diligence must be addressed through price, escrow, specific indemnity, or a closing condition, not deferred to a policy that will decline it. Undisclosed matters the buyer genuinely did not know about may fall within coverage, which is an argument for thorough diligence rather than against it. Discuss known-issue exclusions with the underwriter early, because the scope of what counts as known is negotiable at the margin.

What should I demand from a technology diligence provider to get a usable report?

Four things. Give them the investment thesis in writing, because a provider assessing technology in the abstract produces an issue inventory while one testing it against a thesis produces a recommendation. Require dollars and months on every material finding: one-time cost, run-rate change, elapsed time, and engineering capacity consumed. Require an explicit ranked top five of findings that would change the decision, which forces prioritization and exposes a provider who cannot do it. And ask directly what argues against the deal. A provider who cannot name a single argument has either found a remarkable company or already decided what the report says.

Artifex v. Hancom: The GPL Enforced as a Contract

Artifex Software develops Ghostscript, a widely used interpreter for PostScript and PDF. Artifex distributes it under a dual licensing model: available under the GNU General Public License for those willing to accept the GPL's source disclosure obligations, and available under a paid commercial license for those who are not.

That model depends entirely on the copyleft obligation being real. If GPL terms cannot be enforced, the paid license has no economic basis, because any commercial user can take the free version and ignore its conditions.

Artifex sued Hancom, a South Korean office software company, in the Northern District of California in 2016, alleging that Hancom had incorporated Ghostscript into Hancom Office without obtaining a commercial license and without complying with the GPL's requirements. Hancom moved to dismiss the breach of contract claim, arguing in substance that the GPL was not an enforceable contract because there was no signed agreement and no traditional exchange.

In April 2017 the court denied that motion. The court held that the complaint adequately alleged the existence of a contract, reasoning that the GPL's terms set out obligations a user accepts by using the software on those terms, and that the plaintiff's allegations of consideration were sufficient at the pleading stage. The case settled in December 2017.

The decision mattered because it addressed a question that had been more assumed than tested: whether open source license obligations can be enforced through contract claims, which carry different remedies and damages theories than copyright infringement alone. Later litigation developed the point further, including the Software Freedom Conservancy's 2021 suit against Vizio, which argued that a recipient of a GPL-covered product can enforce the source disclosure obligation as a third-party beneficiary. A federal court remanded that case to California state court in 2022, finding the contract claim was not preempted by copyright law.

For a private equity buyer, the practical lessons are narrow and concrete.

The obligation is real and enforceable, not a theoretical risk that compliance teams overstate. A diligence report that treats open source licensing as a low-severity hygiene item is miscalibrated.

The exposure attaches to the acquired entity and travels with it. Distribution that occurred before close does not stop being distribution because the shares changed hands, and a copyright holder's claim is against the entity.

Dual-licensed components are the highest-risk category to look for, because the copyright holder has a direct commercial incentive to enforce. An unlicensed use of a dual-licensed component is not a technicality. It is lost revenue to a company whose business model depends on collecting it.

And the finding is only reachable one way. Neither a code quality review nor an agreement review surfaces it. A software composition analysis that resolves licenses across the full transitive dependency tree does. That is a few thousand dollars of tooling and analyst time against a risk that, on the wrong component, is measured in the value of the differentiation the buyer is paying for.