The Hidden IT Debt That Kills Deal Value

If you’re preparing for a transaction, the technology side of diligence is one of the few places where a couple of weeks of work can move the price by hundreds of thousands of pounds. Almost every founder I’ve worked with through a sale has discovered the same thing: the IT debt they thought was tolerable was visible to the buyer’s diligence team and got used as leverage.

This post is the version I wish more founders saw twelve months before the process starts. It’s a list of the categories of technology debt that consistently show up in due diligence and consistently move price.

Unsupported Software in Production

This is the single most common finding. An old database version, an unsupported operating system on a key server, a desktop app that hasn’t been updated in years, a finance system on a release the vendor stopped patching three years ago.

To the buyer this signals two things. First, an immediate cost they’ll have to absorb to bring you onto a supportable footing. Second, evidence that operational hygiene isn’t a strength — which raises questions about everything else.

The fix is usually not exciting. Inventory what you have, identify everything outside support, and either upgrade, replace, or document a deliberate compensating control. The work isn’t hard; it’s that nobody’s been paid to do it. Twelve months out from a sale is the right time.

Identity and Access Sprawl

Diligence teams routinely pull a list of accounts with administrative privileges across your core systems. The list is almost always longer than expected, and it almost always includes:

– People who left the business months or years ago
– Service accounts with admin rights and no clear owner
– Shared accounts where the password is in someone’s notes
– Personal email addresses still tied to systems
– Vendors and ex-vendors with access nobody has revoked

A buyer reads that list and sees risk. Specifically, they see that an attacker who compromises any one of those accounts has admin reach across the estate.

The corrective work is straightforward — a structured access review, removal of dormant accounts, mandatory MFA on what remains, separation of normal-user and admin identities — but it takes time to do properly. Done in a panic during diligence, it raises more questions than it answers.

Single Points of Failure

Every business has a few. The contractor who set up the original infrastructure and has the only credentials. The one engineer who knows how the data warehouse actually works. The single internet line at the head office. The cloud account that’s billed to a personal credit card. The third-party processor your operations cannot function without.

Buyers don’t expect zero of these. They expect them to be documented, with mitigation in flight. What kills value isn’t the existence of dependencies — it’s the discovery that nobody has thought about them.

The fix is partly technical (redundancy, secondary suppliers, properly owned cloud accounts) and partly documentation. Mostly it’s documentation. A diligence team is far less concerned about a single supplier dependency that you’ve identified, scoped, and have a plan for than they are about one they’ve found you didn’t know existed.

Audit and Compliance Gaps

If you process customer data — and almost every business does — your UK GDPR position will be reviewed. So will your security controls against any framework you’ve claimed: Cyber Essentials, ISO 27001, SOC 2. Buyers will check that your claims match reality.

Common findings:

– Records of processing that haven’t been updated in years
– Data Protection Impact Assessments that don’t exist for systems where they should
– A Cyber Essentials certificate from two years ago, with the controls now lapsed
– Audit logs that aren’t actually being retained
– A list of subprocessors that doesn’t match the systems in production

Each of these is a moderate fix in isolation. Together they paint a picture of compliance theatre, and that picture is hard to repair under deal-team pressure. The right time to look at this is when you have months, not days.

Patching and Vulnerability Backlog

Most diligence engagements I’ve been part of include a vulnerability scan or, at minimum, a request for evidence that one has been done recently. The result almost always includes a tail of unpatched vulnerabilities that have been accumulating quietly.

What raises the buyer’s concern isn’t the existence of vulnerabilities — every estate has them. It’s the absence of a process that systematically tracks, prioritises, and resolves them. If your IT manager or MSP can’t produce a patching SLA and evidence that it’s being met, the buyer will assume the worst.

A defensible patching position takes a few months to establish. You need an inventory, a prioritisation method, an SLA your team can actually meet, and the evidence that proves it. None of this is technically complex. All of it takes time.

Cloud Cost and Architecture Surprises

If you’re running on AWS, Azure, or GCP, the buyer’s team will look at three things: what you’re spending, whether the architecture is appropriate to that spend, and whether you have any commercial commitments (Reserved Instances, Savings Plans, Enterprise Discount agreements) that affect the post-deal economics.

Common findings:

– Tens of thousands of pounds a month going to over-provisioned compute or unused storage
– Architecture decisions made early that no longer fit the business
– Multi-year commercial commitments that lock the new owner in to a specific spend pattern
– A cloud bill split across multiple accounts and personal cards with no clear ownership

This is one of the easier categories to address pre-deal — a competent cloud architect can produce a remediation plan in a couple of weeks. But it has to be done before the buyer’s team finds it, because once it’s in their report, the saving is theirs to negotiate, not yours.

Vendor Contracts and Lock-In

Buyers will read your major technology contracts. They look for auto-renewal clauses that have just triggered, change-of-control provisions that require vendor consent, multi-year commitments at above-market rates, and termination penalties that affect the integration plan.

Surprises here are particularly painful because they affect the buyer’s post-completion options, not just the price. A discovered change-of-control clause requiring a key supplier’s consent can delay or even block the deal entirely.

The fix is contract-by-contract: a structured review of your top vendor agreements, identification of the issues, and either renegotiation or clear documentation. This is unglamorous work that founders generally don’t want to spend money on. The pre-sale period is the moment when it pays for itself many times over.

What Pre-Sale Cleanup Actually Looks Like

The pattern across all of these is the same. Each finding, taken alone, is fixable in a few weeks. The problem is that there are usually six or seven of them, they all need somebody senior to triage and prioritise, and the actual remediation involves coordination with internal teams, MSPs, vendors, and lawyers.

A useful pre-sale technology engagement is typically two to four months of part-time work, starting twelve to eighteen months out from the process. The output is:

– A clear inventory of the technology and security position
– A prioritised list of findings that would matter to a diligence team
– A realistic remediation plan with effort and cost
– Resolution of the highest-risk items before the data room opens
– Documentation that turns the remaining items from surprises into footnotes

What you’re buying with that engagement is a much better starting point for the diligence conversation. The buyer’s team will still find issues — they always do. The difference is that they’re issues you’ve already identified, scoped, and either fixed or explained. Which means the conversation in the negotiation room isn’t should we adjust the price, it’s we agree this is in flight.

If you’re a founder twelve months out from a planned sale, or a fund-side advisor preparing a portfolio company for exit, this is the right time to look at the technology position. The cost of doing it now is small. The cost of having it found in someone else’s report is not.

—

If you’re preparing a UK business for sale and want a clear read on the technology position before the data room opens, this is the kind of work I do. The full description is on the Technical Transformation & M&A service page, and the private-equity sector page covers the buy-side and portfolio engagements. Or just get in touch for a 30-minute conversation.