“broken glass 2” by Nesster is licensed under CC BY 2.0.
You Failed Tech DD. Now What?.
Your deal is not dead. Let us start there, because that is almost certainly what you are feeling right now.
A technology due diligence report has come back with significant findings. Red flags. Material concerns. Language like "critical risk" and "immediate remediation required." If you are the seller, your stomach has dropped. If you are the buyer, you are recalculating your offer. And both of you are wondering whether the transaction can survive.
Having conducted technology due diligence assessments across the UK market for years, I can tell you this with confidence: most technology problems are fixable. The question is not whether they can be resolved, but how long it will take, how much it will cost, and whether the remediation timeline fits the deal timeline. Only ten to fifteen per cent of the issues we see in due diligence are genuinely unfixable within twelve months. The rest are a matter of prioritisation, investment, and competent execution.
“Most technology problems are fixable. The question is not whether they can be resolved, but how long it will take, how much it will cost, and whether the remediation timeline fits the deal timeline.”
The Five Types of DD Failure
Technology due diligence findings map, broadly, to five categories. Understanding which category your findings fall into determines the severity, the fixability, and the commercial response.
1. People Failure
What it looks like: Critical knowledge concentrated in one or two individuals. The CTO is the single point of failure for the entire technology. The team is too junior for the complexity of the system. There is no succession plan, no documentation of key decisions, and no realistic path to distributing knowledge.
Severity: High for deal risk, but fixable.
The remediation path: Knowledge distribution is a three-to-six-month programme. It requires deliberate pairing, documentation, and — in some cases — strategic hires to create redundancy in critical areas. The immediate action is identifying exactly which knowledge is concentrated and beginning structured transfer. A fractional CTO can accelerate this process significantly, because they know what questions to ask and how to extract knowledge from individuals who have never had to articulate what they know.
Typical timeline: Three to six months for meaningful risk reduction. Twelve months for full resilience.
Typical cost: Minimal direct cost — this is primarily a leadership and process change, not an infrastructure investment. The main cost is the productivity overhead of pairing and documentation during the transfer period.
2. Process Failure
What it looks like: No automated testing. Manual deployment processes. No documentation. No roadmap discipline. No incident response procedures. The team is shipping software through a combination of heroic individual effort and institutional memory rather than through repeatable, scalable processes.
Severity: Moderate. This is common, fixable, and — to experienced assessors — expected at certain company stages.
The remediation path: Process improvement is the fastest fix in technology. Establishing automated testing, CI/CD pipelines, sprint discipline, and documented procedures can be accomplished in weeks rather than months. The challenge is not technical complexity — it is cultural change. The team has been working without these processes, and introducing them requires leadership, not just tooling.
Typical timeline: Four to eight weeks for the foundational processes. Three months for embedded cultural change.
Typical cost: Low. Most process improvements require configuration of existing tools (GitHub Actions, Jenkins, CircleCI) rather than new infrastructure investment. The primary cost is engineering time dedicated to building the pipeline rather than building features — typically two to four weeks of focused effort.
3. Product and Architecture Failure
What it looks like: The architecture will not scale. The codebase quality is below acceptable standards. Technical debt has accumulated to the point where it materially constrains the business. The technology stack is built on frameworks or languages with declining ecosystems. The database design cannot support the data volumes anticipated in the growth plan.
Severity: High, and the remediation timeline is the longest of any category.
The remediation path: Architecture problems cannot be fixed quickly, but they can be managed strategically. The key is identifying which architectural limitations actually matter for the investment thesis and addressing those first. Not all technical debt is equal — some is cosmetic (the code is ugly but functional), some is operational (it slows the team but does not limit the product), and some is structural (it will prevent the business from scaling). Only the structural debt is a dealbreaker, and even that is fixable with the right plan and sufficient investment.
Typical timeline: Six to eighteen months for meaningful architectural improvement. Some fundamental technology migrations (changing the core language, replatforming to a different cloud provider, replacing a legacy ERP) can take two to three years.
Typical cost: Significant. Architecture remediation typically requires dedicated engineering capacity — either redeploying existing engineers from feature work or hiring additional resource. For a mid-market company, budget between fifty and two hundred thousand pounds for a six-to-twelve-month remediation programme, depending on the scope and severity.
4. Protection and Security Failure
What it looks like: No penetration testing has ever been conducted. Encryption is incomplete or absent. Access controls are inadequate — every developer has production database access. There are no security incident response procedures. GDPR compliance is superficial or absent. There is no formal approach to secrets management.
Severity: Critical, but often fixable faster than people expect.
The remediation path: Security remediation is typically the first priority in any post-DD action plan, because the risks are existential. A data breach or regulatory penalty can destroy value far more rapidly than any other technology problem. The good news is that security improvements are among the most straightforward to implement: penetration testing can be commissioned immediately, access controls can be tightened within days, encryption can be implemented within weeks, and incident response procedures can be documented and rehearsed within a month.
Typical timeline: Four to eight weeks for the critical gaps. Three to six months for a comprehensive security programme. Twelve months for certification (ISO 27001 or SOC 2) if required.
Typical cost: Moderate. An annual penetration test costs five to fifteen thousand pounds. Access control improvements are primarily configuration changes. Encryption implementation varies by scope but typically costs ten to thirty thousand pounds in engineering time. ISO 27001 certification, if required, costs fifty to one hundred thousand pounds including consultancy and audit fees.
5. Platform and Infrastructure Failure
What it looks like: The infrastructure cannot handle growth. There is no disaster recovery plan. The cost structure is unsustainable — cloud spend is growing faster than revenue. The platform is hosted on deprecated technology or relies on a single provider with no failover capability.
Severity: Moderate to high, depending on the specific findings.
The remediation path: Infrastructure modernisation is well-understood territory. Moving to managed cloud services, implementing infrastructure-as-code, establishing disaster recovery with tested procedures, and optimising cloud spend are all achievable within defined timeframes. The key decision is whether to remediate on the existing platform or migrate — a question that depends on the severity of the current limitations and the cost-benefit of migration versus improvement.
Typical timeline: Three to six months for infrastructure modernisation. Six to twelve months for a full platform migration.
Typical cost: Variable. Cloud cost optimisation often pays for itself — we typically identify twenty to forty per cent savings in over-provisioned environments. Infrastructure-as-code implementation costs fifty to one hundred thousand pounds in engineering time. A full platform migration is a significant investment: two hundred to five hundred thousand pounds for a mid-market company, though the long-term savings and scalability improvements typically deliver positive ROI within eighteen months.
Which Failures Are Dealbreakers?
Very few. Everything else — process gaps, architecture debt, security vulnerabilities, knowledge concentration, infrastructure limitations — is fixable with time, investment, and competent leadership.
“The most effective response to difficult DD findings is not to dispute them but to demonstrate that you understand them and have a credible plan to address them. That shift — from defensive to proactive — changes everything.”
The Three Genuine Dealbreakers
Fundamental technology obsolescence. If the core product is built on a technology that is genuinely end-of-life — not just unfashionable, but actually unsupported and declining — and the cost of migration exceeds the value of the business, that is a dealbreaker.
Irreplaceable key-person dependency with no mitigation path. If the entire technology is the creation of one person who has already left (or is planning to leave) and the system is undocumented to the point where it cannot be maintained by anyone else, the risk may be unacceptable.
Undisclosed material liabilities. If the DD reveals that the company is operating in breach of regulations (data protection, industry-specific compliance) and the cost of remediation plus potential penalties exceeds the deal rationale, the findings may kill the transaction.
For Sellers: Using DD Findings to Your Advantage
If you are on the sell side and the buyer's DD has surfaced significant findings, your natural instinct is defensive. Resist it. The most effective response is not to dispute the findings but to demonstrate that you understand them and have a credible plan to address them.
Prepare a remediation roadmap that acknowledges each finding, proposes a specific action, assigns a timeline, and estimates the cost. Present this alongside the DD findings, not as a rebuttal but as evidence of operational maturity: "We agree these areas need attention. Here is our plan."
This approach works because it reframes the conversation. Instead of the buyer using the findings as leverage to reduce the price, the seller is presenting themselves as a management team that identifies problems and solves them — exactly the quality that acquirers value most.
The strongest position is to have conducted your own pre-sale technology audit twelve to eighteen months before going to market. When the buyer's DD team arrives, you can present the original audit, the remediation plan, and the evidence of progress. Instead of defending legacy decisions, you are demonstrating operational maturity — showing the buyer a management team that finds problems and fixes them. That shift is worth a material premium in any transaction.
For Buyers: How to Price Technology Risk
DD findings should inform your price, not kill the deal. The framework is straightforward:
Quantify the remediation cost. For each finding, estimate the cost and timeline to remediate. Your DD provider should be able to help with this — and if they cannot, they are the wrong DD provider.
Adjust the offer accordingly. The remediation cost should be reflected in the purchase price, either as a direct reduction or as a retention holdback tied to remediation milestones.
Assess the management team's capability to execute the remediation. The findings matter less than the team's ability to address them. A strong team with significant DD findings is a better investment than a weak team with a clean bill of health — the strong team will fix the problems, while the weak team will create new ones.
Consider the post-deal support model. Many buyers commission DD from firms that also provide fractional CTO services precisely because the transition from "identify the problems" to "help fix the problems" is seamless. The DD assessor already understands the technology, the team, and the priorities — bringing them back to support remediation avoids the knowledge loss of starting again with a new advisor.
The Path Forward
Whether you are a buyer or a seller, the response to a difficult DD report should be the same: treat the findings as a roadmap, not a verdict. The problems are almost certainly fixable. What matters is whether the investment required to fix them is justified by the value of the transaction.
In our experience, it usually is. Technology problems are solvable. Business fundamentals — market position, customer relationships, unit economics — are much harder to create. If those fundamentals are sound and the technology problems are addressable, the deal should proceed with adjusted terms that reflect the remediation investment required.
Related Reading
- Technology Audit — pre-sale and buy-side technology due diligence
- Sell-Side Due Diligence — prepare your technology for investor scrutiny
- What Does a Fractional CTO Cost? — pricing for post-DD remediation support
Frequently Asked Questions
References
- IBM Security. Cost of a Data Breach Report 2025. IBM / Ponemon Institute (2025).
- UK DSIT. Cyber Security Breaches Survey 2025. GOV.UK (2025).
- McKinsey & Company. Unlocking Success in Digital Transformations. McKinsey (2018).
- NCSC. 10 Steps to Cyber Security. National Cyber Security Centre, GOV.UK (2024).
- PwC. 2025 Global Digital Trust Insights. PwC (2024).
Failed technology due diligence?
We help companies remediate the issues that due diligence uncovers and prepare for successful reassessment.