Most technology due diligence checklists I’ve come across online read like they were written by someone who has never actually run a technical assessment on a live deal.
They’re either too generic to be useful, “assess the technology stack” tells you nothing about what to actually look for, or too theoretical to apply under deal pressure. A comprehensive list of everything that could possibly matter, organized by category, with no indication of what actually predicts deal outcomes versus what’s noise.
I’ve run technical assessments across dozens of acquisitions, from distressed fintechs going through NCLT proceedings to growth-stage SaaS platforms being acquired by PE funds. After enough deals, you start to see which parts of the assessment consistently change the price, the deal structure, or the decision to proceed, and which parts fill pages in a report that nobody reads twice.
This is the checklist I actually use. Not everything that could matter. The things that do matter, organized by how they affect the deal, with enough context to explain what you’re looking for and why.
Before the Checklist: Understanding What You’re Actually Doing
Technology due diligence serves one purpose. It closes the gap between what the information memorandum says the technology is and what the technology actually is.
That gap exists in every deal. It’s not because anyone is lying, though occasionally they are. It’s because the people who write IMs are not technology assessors. They describe what management believes about the technology, filtered through the lens of what makes the asset attractive to buyers. The gap between belief and reality is where the unpriced risk lives.
A good tech DD doesn’t just find problems. It quantifies them in terms the deal team can use, remediation costs that belong in the financial model, structural risks that need to be reflected in deal terms, and dependencies that affect the investment thesis itself.
With that framing, here’s what the checklist needs to cover.
Intellectual Property Ownership
This comes first because it can kill a deal regardless of how good everything else looks.
What you’re checking:
Does the corporate entity, not the founders, not individual employees, not a holding company in another jurisdiction, cleanly own every piece of intellectual property that makes the product valuable?
What to actually do:
Pull every IP registration. Patents, copyrights, trademarks, domain registrations. Cross-reference the registrant against the corporate entity that’s being acquired. Any registration held by an individual rather than the company is a finding that needs resolution.
Then pull every contractor agreement and employment agreement from the company’s first eighteen months. This is the period when the core product was likely built, often by people who are no longer with the company. Check whether IP assignment clauses exist and are legally enforceable. Pay particular attention to the first version of the product, if it was built as a side project before incorporation, or by contractors on informal arrangements, the assignment chain might have a gap.
If the founding team had departures, especially contentious ones, check whether the separation agreements explicitly confirm that the original IP assignments survived the departure. A standard employment agreement with an IP clause doesn’t automatically resolve this if the separation agreement is silent on the topic.
Why this matters for the deal:
An IP ownership gap doesn’t necessarily kill a deal. But it changes the negotiation entirely. If the gap involves a departed founder who left acrimoniously and retained lawyers, the remediation path is uncertain and potentially expensive. The deal structure needs to account for this, through indemnities, escrow, or price adjustment, before close, not after.
Architecture and Scalability
This is where the gap between the IM description and reality tends to be widest.
What you’re checking:
Can the platform actually support the growth thesis that the investment model is built on? Not whether it works today at current load, whether it can get to where the fund needs it to be without a rebuild that nobody has budgeted for.
What to actually do:
Map the system architecture. Identify whether it’s monolithic or service-oriented, how components communicate, where state is managed, and how the system handles failure. The IM might say “cloud-native.” The reality might be a monolith deployed on EC2 instances, technically in the cloud, architecturally unchanged from 2019.
Check for horizontal scalability. Can the system add capacity by adding instances, or does scaling require re-architecting core components? If the growth thesis assumes a tenfold increase in transaction volume over the hold period, the platform needs to support that without a ground-up rebuild.
Look at the deployment infrastructure. Is there CI/CD? Automated testing? Infrastructure-as-code? A staging environment that mirrors production? Or does deployment depend on one person running scripts from their laptop in a specific order they keep track of mentally?
Why this matters for the deal:
The remediation cost of bringing a legacy architecture up to the level the growth thesis requires is real money. Fourteen to eighteen months of rebuild work at meaningful engineering cost is not unusual for platforms that have accumulated years of architectural debt. That cost needs to be in the financial model, reflected in the price, or addressed through deal structure. Discovering it after close means the fund is absorbing a capital requirement that was never in the plan.
Vendor Dependencies and Third-Party Risk
This is the section that catches deal teams off guard most often, because it requires looking at contracts, not code.
What you’re checking:
Is any capability that the IM describes as proprietary actually dependent on a third-party vendor? And if so, what happens to that dependency when the company changes ownership?
What to actually do:
Identify every third-party service, platform, API, and tool that the product depends on to function. Not just the obvious ones, the cloud provider, the database, but the ones embedded deeper in the stack. The credit decisioning engine that’s actually a configuration layer on top of a vendor platform. The data enrichment service that the product can’t function without. The analytics infrastructure that’s provided under a license agreement tied to the current ownership.
For each material dependency, pull the vendor contract and check three specific things. First, does the contract include a change-of-control clause? This is standard boilerplate in many vendor agreements, but in an acquisition context it can trigger renegotiation rights, price resets, or termination provisions that activate at exactly the moment the deal closes. Second, who owns the data? If the vendor stores or processes data that’s critical to the product’s value, the data rights might be tied to the service contract rather than belonging to the company outright. Third, what’s the termination path? If the vendor relationship ends, can the company continue operating, and at what cost?
A comprehensive technology due diligence checklist will always include vendor dependency mapping as a core component, not an afterthought. In our experience, vendor-related findings change the deal economics more frequently than pure codebase issues.
Why this matters for the deal:
A vendor dependency with a change-of-control clause that triggers renegotiation at market rates can add millions to the post-acquisition cost structure. A data dependency where the vendor owns the historical records that make the product valuable can fundamentally undermine the value thesis. These findings don’t kill deals, but they change the price, add conditions to close, or require vendor contract novation as a pre-condition of the acquisition.
Code Quality and Test Coverage
This is the section most people think of when they hear “tech DD.” It matters, but it matters in a more specific way than most checklists suggest.
What you’re checking:
Not whether the code is beautiful. Whether it’s maintainable, safe to modify, and reliable in the areas that matter most to the business.
What to actually do:
Request the test coverage report broken down by module, not just the headline number. The headline number is almost always misleading. A company can report 78% test coverage while the payment processing module sits at 11% and the authentication middleware sits at 8%. The utility functions and helper libraries are thoroughly tested. The code that handles money, identity, and data integrity, the code where a bug has financial, regulatory, or operational consequences, is effectively untested.
This pattern is nearly universal in companies under pressure. When teams are understaffed and shipping to survive, they write tests for what’s easy to test and skip what’s hard to test. The hard-to-test code is usually the complex, business-critical code. Which means the most important code is the least tested.
Look at the dependency health. Are libraries up to date? Are there known vulnerabilities in the dependency tree? How many dependencies are abandoned or unmaintained? A product built on libraries that haven’t been updated in three years has a remediation cost that accumulates quietly.
Check the commit history. Is development active and distributed across the team? Or has all meaningful development been done by one or two people for the past year? The commit history tells you more about the real engineering culture than any management presentation.
Why this matters for the deal:
Low test coverage on critical modules means the code cannot be safely modified without risk of breaking things nobody will notice until a customer calls. The remediation cost of bringing critical modules to a responsible coverage level, writing the tests, refactoring the code to be testable, fixing the bugs that the tests reveal, is a real line item. If coverage on business-critical modules is below 40%, that cost belongs in the deal model.
See also: Why Company Formation Services Hong Kong Continue Supporting Modern Business Development
Security Posture
Security assessment in tech DD isn’t about running a penetration test. It’s about understanding whether the company’s security practices are appropriate for the data it handles and the regulatory environment it operates in.
What you’re checking:
Are there security practices that would require immediate remediation post-close? Are there exposures that could create regulatory, legal, or reputational risk for the acquirer?
What to actually do:
Check how secrets are managed. Are API keys, database credentials, and encryption keys stored securely, or are they hardcoded in the codebase, saved in environment files committed to version control, or stored in someone’s browser password manager? This sounds basic. You would be surprised how often it’s the finding.
Review access controls. Who has production access? Is access role-based and auditable? Can the company produce a list of everyone who can touch production systems right now? In distressed companies, access management often degrades as people leave and nobody revokes their credentials.
Check for data handling compliance. Does the application handle personally identifiable information? If so, are encryption, access logging, and data retention practices consistent with applicable regulations? A product that handles financial data without adequate encryption or audit trails creates immediate compliance exposure for the acquirer.
Look at incident history. Has the company experienced security incidents? How were they handled? What changes were made afterward? The absence of any documented incidents in a company that handles sensitive data is sometimes more concerning than a well-handled incident, it might mean incidents happened but weren’t detected or documented.
Why this matters for the deal:
Security remediation that needs to happen immediately after close is an unplanned capital requirement. In regulated industries, inheriting a product with inadequate security practices means inheriting the compliance exposure that comes with them. The cost of bringing security practices up to the acquirer’s standards, or up to regulatory requirements, needs to be quantified and reflected in the deal economics.
Team and Key-Person Dependencies
The technology is only as durable as the team that maintains it.
What you’re checking:
Can the product survive the departure of any single person? And in a distressed acquisition where morale and retention are already fragile, how likely is that departure?
What to actually do:
Identify the bus factor for critical functions. How many people can deploy to production? How many people understand the core business logic deeply enough to modify it safely? How many people can diagnose and resolve a production incident at 2am?
If the answer to any of these is one, that’s a key-person dependency that belongs in the risk section of the investment memo. If that person has already indicated they’re leaving, or if the compensation and retention structure makes departure likely, the dependency becomes a critical path item.
Check how knowledge is documented. Are there architecture documents? Runbooks for common operations? Documentation of business logic and decision rules? Or does essential knowledge live exclusively in people’s heads? In distressed companies, the team that built the product is often partially or fully gone. The knowledge that left with them is knowledge the acquirer will need to reconstruct, and that reconstruction has a real cost.
Why this matters for the deal:
A key-person departure in the first six months after close can create an operational crisis if nobody else can perform their critical functions. The retention plan for key technical staff needs to be part of the deal structure, retention bonuses, earnout conditions, or transition periods that ensure knowledge transfer happens before the person leaves.
Data Infrastructure and Quality
The condition of the data underneath the product determines how much of the technology’s value is real and how much is theoretical.
What you’re checking:
Is the data clean enough, structured enough, and accessible enough to support both the current product and the growth plans the fund has modeled?
What to actually do:
Assess the data architecture. Where does data live? How does it flow between systems? Is there a single source of truth, or are there multiple conflicting data stores that get reconciled manually? Are there data pipelines, and are they monitored and maintained?
Check data quality on a sample. Run actual queries against the production data. Look for inconsistencies, gaps, duplicate records, format mismatches, and stale data. Almost every organization overestimates the quality of its own data. The reality usually becomes apparent within a few hours of looking at it.
Evaluate data governance. Are there defined owners for critical datasets? Is there documentation of data schemas and business rules? Can the company explain what each field means and where it comes from? In companies that grew fast under resource constraints, data governance is often nonexistent, not because nobody cared, but because it was never urgent until now.
Why this matters for the deal:
If the investment thesis depends on the data, for AI capabilities, for analytics, for customer insights, the condition of that data directly determines whether the thesis is viable. Data remediation is expensive and time-consuming. Adding 25 to 30 percent to the build budget for data preparation is a reasonable rule of thumb for companies whose data has never been audited for machine consumption.
Putting It All Together
A tech DD checklist is only as useful as the judgment applied to its findings. The goal isn’t to produce a list of problems. It’s to produce a picture of the technology that the deal team can use to make better decisions.
Some findings change the price. Some change the deal structure. Some change the integration plan. Some are non-issues that look alarming on paper but are standard for companies at this stage. And occasionally, a finding changes the decision to proceed entirely.
The assessment exists to make sure the fund knows what it’s buying before it writes the check. In distressed M&A, that’s not a luxury. It’s the most basic form of deal protection available.
The gap between what the IM describes and what the technology actually is, that gap is where the write-offs come from. A rigorous checklist, applied by people who have seen enough deals to know what matters, is what closes it.
