English for Technical Due Diligence: Vocabulary for M&A Tech Assessments
Learn the English vocabulary used in technical due diligence engagements — from code audits and architecture scorecards to risk registers and executive summaries.
Technical due diligence is one of the highest-stakes conversations an engineer can be part of. When companies acquire or invest in technology businesses, they hire senior engineers to assess the target’s codebase, architecture, and technical practices. Getting this vocabulary wrong — or speaking vaguely — costs credibility in rooms full of investors and executives who expect precise, confident reporting.
What Is Technical Due Diligence?
Technical due diligence (TDD) is a structured assessment of a company’s technology assets, risks, and capabilities, typically performed during a merger, acquisition, or investment round. The team conducting TDD is usually a mix of senior engineers, architects, and sometimes third-party consultants. Their job is to validate (or challenge) what the target company has claimed about its technology.
A TDD engagement typically includes a code audit (reviewing the codebase for quality, security, and maintainability), an architecture scorecard (rating the system design against best practices), and a tech debt assessment (quantifying how much rework the acquirer will inherit).
You will hear: “The architecture scorecard flagged a significant scalability risk in the authentication service — it’s a synchronous bottleneck with no horizontal scaling path.”
Key Risk Vocabulary
Tech debt is the accumulated cost of shortcuts, outdated dependencies, and deferred improvements. The SQALE method (Software Quality Assessment based on Lifecycle Expectations) is a formal approach to measuring tech debt in hours of remediation effort. Tools like SonarQube output a SQALE debt ratio.
Hotspot analysis identifies the areas of the codebase that are both highly complex and frequently changed — a double risk signal. Engineers present these as: “The payment processing module is a hotspot — high cyclomatic complexity and touched in 40% of all commits in the last 12 months.”
A single point of failure (SPOF) is any component whose failure brings down the entire system. In TDD reports, SPOFs are flagged as critical risks: “The system has a SPOF in the database layer — there is no read replica or failover configured.”
Vendor lock-in risk refers to dependencies on a single cloud provider, database, or third-party service that would be expensive or time-consuming to replace. “The data pipeline is deeply coupled to a proprietary AWS Glue format — migration off AWS would require significant rewrite effort.”
Scalability risk covers architectural constraints that would prevent the system from handling projected growth without major re-engineering.
Risk Classification and Reporting
Most TDD reports use a risk register — a structured table of identified risks with severity ratings. The standard colour coding is:
- Red — critical risk, deal-breaker or requires immediate remediation
- Amber — significant risk, requires a remediation plan within a defined timeframe
- Green — acceptable, no immediate action required
When presenting findings, engineers use hedged but precise recommendation language: “We recommend that the acquirer negotiate an escrow arrangement contingent on resolution of the three red-rated findings prior to close.”
The executive summary is the non-technical summary written for the leadership and investment team. It translates engineering findings into business impact. A good executive summary answers: What are the top risks? What will it cost to fix them? Does the technology support the stated growth plan?
Real Phrases from TDD Engagements
- “The codebase has no automated test coverage above 12% — this significantly increases regression risk post-acquisition.”
- “We identified four external dependencies with no contractual SLA, creating supply-chain risk.”
- “The infrastructure is provisioned manually with no IaC — any significant scaling event would require substantial DevOps investment.”
- “Our assessment is that the amber-rated items can be addressed within two quarters with a team of three engineers.”
Next Steps
If you want to practise this vocabulary, find a public post-mortem or architecture decision record (ADR) from an open-source project and rewrite its summary as a TDD finding using risk register language — red, amber, or green rating, one sentence of evidence, one sentence of recommendation. This is exactly the writing pattern used in real TDD deliverables.