7 Technology Risks to Check Before Buying a Business

Technology due diligence when buying a business can uncover costs the accounts will not show

Technology due diligence when buying a business can expose risks that are almost invisible in the financial statements.

The revenue may look healthy. The customer base may be loyal. The business may have good people and a convincing growth story. Yet underneath it all could sit ageing systems, weak cyber security, undocumented software, expensive contracts, a developer who holds all the knowledge, or technology that needs replacing shortly after settlement.

I have seen enough technology environments over more than 35 years to know that what appears to work today is not necessarily what you want to inherit tomorrow.

A proper technology review helps answer a simple question:

What am I actually buying, and what might I have to spend after I buy it?

That matters whether you are buying a software company, professional services firm, retailer, manufacturer, healthcare organisation or a business where technology appears to play only a supporting role.

Technology is now part of almost every business.

So it belongs in due diligence.

Takeaways

What is technology due diligence?

Technology due diligence is an independent assessment of the technology you are about to acquire.

It looks beyond whether the computers turn on and the software appears to work.

Good technology due diligence examines areas such as:

• business-critical systems
• software architecture
• infrastructure and cloud services
• cyber security
• data and privacy
• software licences and supplier contracts
• intellectual property
• technical debt
• technology costs
• IT staff and external suppliers
• key-person dependency
• backups and disaster recovery
• development practices
• future technology investment
• integration with the buyer’s existing systems

For a software or SaaS business, the review goes deeper into the product itself. That could include the architecture, source code ownership, development process, hosting, scalability, security, product roadmap and development team.

EY describes technology due diligence as increasingly important for validating integration readiness, technical risks, scalability, team capability and system compatibility before completing a transaction.

For a traditional SME, the questions may be simpler, but they still matter.

If a company cannot operate without Microsoft 365, its accounting platform, CRM, ecommerce system, cloud applications or specialised industry software, those systems are business assets.

The mistake is assuming that because technology is operational, it is safe.

It might simply be surviving.

1. Ageing systems and hidden technical debt

Technical debt is the future work created when technology has been built, maintained or changed in ways that make it increasingly difficult or expensive to support.

Sometimes that debt is deliberate. A company may have made sensible shortcuts when it was small.

The problem arises when those shortcuts remain for five or ten years.

You might inherit:

• unsupported operating systems
• old programming languages or frameworks
• ageing servers
• outdated databases
• undocumented integrations
• fragile spreadsheets running critical processes
• software that only one person understands
• applications that cannot easily integrate with newer systems
• years of deferred upgrades

None of this necessarily stops the business operating today.

That is precisely why it can be missed during acquisition discussions.

The seller says, “It works.“

They may be completely correct.

My next question would be, “What will it take to keep it working for the next three years?“

That produces a very different conversation.

What to ask

Ask for:

• a list of business-critical systems
• system ages and versions
• technology architecture documentation
• outstanding upgrade projects
• known defects and issues
• technology roadmaps
• support arrangements
• planned replacements
• previous technology assessments

For a software business, examine the product architecture, development backlog and technical debt in much greater detail.

Recent Australian M&A guidance from EY specifically highlights legacy technology, scalability, infrastructure and the cost of modernisation as areas that can affect investment value.

You are not necessarily looking for perfect technology.

You are looking for known technology.

A business with older systems, good documentation and a sensible replacement plan may represent less risk than one with newer technology nobody properly understands.

2. Cyber security weaknesses you could inherit

Cyber security is one of the areas where a buyer should avoid assumptions.

The company might never have experienced a major cyber incident.

That does not prove the environment is secure.

It could simply mean nobody has found the problem yet.

I would want to understand:

• Is multi-factor authentication in place?
• How are administrator accounts controlled?
• Are systems and applications patched?
• Are backups performed and tested?
• Is endpoint security managed?
• Are departing employees removed promptly?
• Are security incidents recorded?
• Has penetration testing or security testing been performed?
• Are staff given cyber security training?
• Who can access sensitive company or customer data?
• Are third-party suppliers properly controlled?

The Australian Signals Directorate’s Essential Eight provides a useful baseline for assessing common cyber controls, including patching, multi-factor authentication, restricted administrative privileges and regular backups.

The exact framework matters less than understanding the actual risk.

A buyer needs to know whether weaknesses exist, what they would cost to fix and whether there is evidence of existing compromise.

EY’s guidance on cyber security in mergers and acquisitions notes that weak security can expose buyers to financial, operational, intellectual property and reputational risks.

Cyber risk can therefore affect the deal itself.

It is not simply an IT department problem to sort out after settlement.

3. Data ownership, privacy and compliance problems

Data can be one of the most valuable things you acquire.

It can also be one of the most dangerous.

You need to understand:

What data does the business hold, why does it hold it, where is it stored, who can access it and whether it has the right to transfer that data to you?

This becomes especially important where the company handles:

• health information
• customer personal information
• financial information
• employee records
• identification documents
• payment information
• commercially sensitive information
• children’s information

Do not assume data belongs to the company simply because it sits inside its systems.

There may be contractual, legal, regulatory or privacy restrictions around its collection, use, storage and transfer.

For organisations covered by Australia’s Privacy Act and Notifiable Data Breaches scheme, obligations can continue well beyond basic IT security. The OAIC notes that businesses covered by APP 11 also have responsibilities under the Notifiable Data Breaches scheme where eligible data breaches occur.

Check the history as well as the current position

Ask whether the company has experienced:

• data breaches
• privacy complaints
• accidental disclosures
• lost devices
• ransomware
• compromised accounts
• unauthorised staff access
• regulator enquiries

A clean answer should preferably be supported by records.

“No breaches that I know of” is not quite the same as having good incident management.

If customer trust forms part of the value of the business you are acquiring, poor data practices can undermine the asset you thought you were buying.

4. Software licences, contracts and intellectual property

This is one of my favourite due diligence questions:

Does the business actually own what it says it owns?

It sounds obvious.

It is not always obvious at all.

A business may rely on software developed by employees, freelancers, agencies, overseas developers or a founder’s mate who “helped out with the original system.”

Who owns that code?

Where is the agreement that proves it?

Software intellectual property should not be assumed to transfer automatically just because the buyer acquires the company or its assets.

Review:

• source code ownership
• employee IP clauses
• contractor IP assignments
• software development agreements
• open-source software obligations
• domain ownership
• cloud accounts
• application store accounts
• licences
• subscriptions
• database rights
• trademarks and digital assets

The same thinking applies to ordinary business software.

Some supplier contracts may not be transferable.

Pricing may change after ownership changes.

A seller may also benefit from grandfathered pricing that disappears when the agreement is renegotiated.

Watch for accounts owned personally

I have encountered businesses where important technology services were registered under individual staff email addresses or personal accounts.

That is convenient until that person leaves.

During acquisition due diligence, identify who actually controls:

• domains
• DNS
• Microsoft 365 or Google Workspace
• cloud infrastructure
• source code repositories
• website hosting
• social media
• analytics
• accounting platforms
• password managers
• software subscriptions

Ownership should move cleanly to the business.

A $20 domain name can cause a surprisingly large headache when it controls the company’s email, website and identity.

5. Key-person dependency

Sometimes the biggest technology risk is not technology.

It is a person.

Perhaps one developer built the system and nobody else understands it.

Maybe the IT manager has been there for 18 years and keeps almost everything in their head.

Perhaps an external supplier controls the hosting, backups, passwords and documentation.

If that person disappears the week after the acquisition, what happens?

This is why my approach remains people before technology.

Technology risk often starts with knowledge, accountability and communication.

Look for concentrated knowledge

Ask:

• Who understands each critical system?
• Who has administrator access?
• Who knows how backups work?
• Who deals with technology suppliers?
• Who understands the software architecture?
• Who can deploy the company’s software?
• Where are passwords and credentials stored?
• Is important knowledge documented?
• Who could take over tomorrow?

Then ask the uncomfortable version:

If this person left tonight, could the business operate normally tomorrow?

If the answer is no, you have found a risk.

That risk might justify:

• a retention agreement
• a structured handover
• documentation before settlement
• additional recruitment
• a support agreement with the seller
• a change to the acquisition timetable

This is particularly important in smaller businesses where one capable person can quietly become the technology department, security team, architect, developer and help desk.

They may be excellent.

That concentration of knowledge is still a business continuity risk.

6. Technology costs that are not obvious in the financials

One line in the profit and loss statement called “IT” tells you very little.

You need to understand what sits underneath it.

Review technology spending across:

• cloud services
• software subscriptions
• telecommunications
• managed IT support
• cybersecurity services
• developers
• consultants
• licences
• hosting
• hardware
• maintenance
• support contracts
• project costs

Deloitte’s Australian technology due diligence guidance highlights historic IT spending, forecast costs, infrastructure, applications, staffing, cyber security and data protection as important parts of an acquisition assessment.

The historic cost is only half the story.

I would also look for deferred spending.

Suppose the company spends $100,000 a year on technology but needs a $600,000 system replacement within 18 months.

Your true view of the technology cost is very different.

The seller may not be hiding anything.

They may simply have decided that replacing the system is a job for the next owner.

Fair enough.

You still want to know before you become that owner.

Build a three-year view

A useful approach is to separate costs into:

Cost type	What to identify
Current operating cost	Software, infrastructure, support and staff
Committed cost	Existing contracts and licence commitments
Remediation cost	Security, compliance and technical fixes
Replacement cost	Systems nearing end of life
Integration cost	Connecting the acquired business to your systems
Growth investment	Technology required to support expansion

This turns technology due diligence into something the commercial team can use.

Instead of saying, “The ERP is old,” you can say:

“The ERP is likely to require replacement within two years, with an estimated investment range that should be included in the acquisition plan.“

That is a business conversation.

7. Whether the technology can support your plans after acquisition

A company does not have to be technologically perfect.

Its technology does need to support what you plan to do with the business.

That distinction matters.

Imagine you are buying a company because you plan to double its customers over three years.

Can the current systems handle twice the transaction volume?

Can the team release changes quickly enough?

Will infrastructure costs rise sensibly with growth?

Can the systems integrate with your existing business?

Can reporting provide the information you will need?

Technology that works perfectly for a $5 million business may become completely unsuitable for a $20 million business.

PwC has previously highlighted this exact M&A issue, recommending buyers understand what technology they are acquiring, how it fits with existing systems and what further investment may be required.

Start with the acquisition thesis

I prefer to work backwards from why you are buying the business.

If the acquisition depends on:

Growth, examine capacity and scalability.

Integration, examine APIs, data structures and system compatibility.

Cost reduction, identify duplicate systems and contract exit costs.

Product expansion, examine architecture and development capability.

Geographical expansion, examine infrastructure, security, support and regulatory requirements.

Operational improvement, examine workflows, data quality and automation opportunities.

Technology due diligence becomes far more useful once it is linked to the reason for the deal.

Otherwise, you can end up with a beautiful technical report that answers questions nobody making the investment actually asked.

A simple technology due diligence risk framework

You do not need to classify everything as good or bad.

I prefer a straightforward framework.

For each issue, record:

Current State → Evidence → Risk → Business Impact → Cost → Recommendation → Priority

For example:

Area	Current state	Business risk	Priority
Backups	Daily backups but restore not tested	Recovery may fail after major incident	High
Key developer	One person understands core platform	Loss of key person could stop development	High
CRM	Supported SaaS platform	Low operational risk	Low
ERP	Unsupported version	Security and upgrade risk	High
Microsoft 365	MFA implemented for all users	Good baseline control	Low

This keeps the review focused on decisions rather than producing a technical shopping list.

Red flags that deserve closer investigation

One issue rarely kills a deal on its own.

Patterns matter more.

I would investigate further if I found:

• no reliable technology documentation
• nobody clearly accountable for technology
• one person controlling critical systems
• unsupported software
• untested backups
• shared administrator accounts
• no multi-factor authentication
• unexplained security incidents
• unclear intellectual property ownership
• software accounts registered personally
• unusually high developer turnover
• repeated major project delays
• no technology budget or roadmap
• major system replacement repeatedly postponed
• sensitive data stored without clear governance
• vendor contracts that cannot transfer
• large amounts of undocumented custom software

One red flag might have a simple explanation.

Seven red flags deserve a much longer conversation.

Technology due diligence does not necessarily mean walking away

Finding technology problems does not automatically make an acquisition bad.

Sometimes it makes the deal better informed.

A business might have excellent customers and strong revenue but poor internal systems.

That creates risk.

It may also create opportunity.

Technology due diligence can lead to several outcomes:

1. Proceed unchanged. The technology risk is acceptable.
2. Proceed with a remediation plan. Problems exist, but they are manageable.
3. Renegotiate the price. Future technology investment changes the value calculation.
4. Add transaction conditions. Specific matters must be resolved before settlement.
5. Require a transition arrangement. The seller or key staff provide support after completion.
6. Walk away. The technology risk materially undermines the investment case.

The purpose is not to find reasons to stop the transaction.

It is to remove surprises.

I would much rather tell a buyer before settlement that a system needs $250,000 of work than have them discover it six months after they own the company.

When should you conduct technology due diligence?

Start early enough for the findings to influence the transaction.

Technology due diligence performed two days before settlement is mostly archaeology.

Ideally, it should happen while there is still time to:

• ask questions
• request evidence
• interview key people
• investigate concerns
• estimate remediation costs
• negotiate conditions
• change the purchase price
• plan the first 100 days

For a smaller acquisition, the initial assessment might be relatively focused.

A larger transaction, software company or highly regulated organisation may justify a deeper assessment involving cyber security specialists, software architects, privacy advisers, lawyers and financial advisers.

The scope should match the risk.

What documents should a buyer request?

A useful starting request might include:

• technology asset register
• application and software inventory
• infrastructure documentation
• architecture diagrams
• supplier contracts
• software licence agreements
• cloud service agreements
• technology budgets
• IT invoices
• security policies
• cyber security assessments
• penetration testing reports
• incident and breach records
• backup and disaster recovery procedures
• business continuity plans
• staff and contractor lists
• organisation chart
• system access lists
• privacy policies
• data retention policies
• software development agreements
• intellectual property assignments
• source code repository details
• development backlog
• technology roadmap
• current project list
• known issue register

Do not request documents simply to create an impressive data room.

Every document should help answer a question.

Sometimes the absence of a document is itself useful evidence.

Common technology due diligence mistakes

Only asking the existing IT provider

Your managed service provider or software developer may know the environment very well.

That does not automatically make them independent.

Use their knowledge as evidence, but consider whether someone independent should assess it.

Focusing only on cyber security

Cyber security matters, but technology due diligence is broader.

A secure system can still be expensive, unsupported, badly documented or unsuitable for your growth plans.

Looking only at current costs

Today’s technology bill does not tell you what needs to be spent tomorrow.

Look at future investment.

Treating technical debt as a technical problem

Technical debt becomes a financial problem when you own it.

Translate technology findings into time, money, operational risk and business impact.

Waiting until after settlement

Once you own the company, due diligence has become remediation.

The negotiating power has gone with it.

If technology represents an important part of the business you are considering, an independent technology consulting review can give you a clearer picture before the transaction becomes difficult to change.

Frequently Asked Questions

What is technology due diligence when buying a business?

Technology due diligence is the assessment of a company’s systems, software, cyber security, data, suppliers, people, costs and technology risks before an acquisition. Its purpose is to identify problems, future investment and risks that could affect the value or operation of the business.

Do I need technology due diligence if I am not buying a technology company?

Often, yes.

A retailer, healthcare provider, manufacturer, construction company or professional services business may rely heavily on technology even though it does not sell technology. If losing key systems would stop the business operating, technology deserves attention during due diligence.

Who should perform technology due diligence?

For smaller transactions, an experienced independent technology adviser may be able to conduct the core review and bring in specialists where necessary.

Larger or more complex deals may require input from cyber security specialists, software architects, lawyers, privacy advisers and other experts.

Independence matters. The people who built or currently manage the environment can provide valuable information, but they should not necessarily be the only people assessing it.

How much technology due diligence is enough?

The scope should reflect the size and risk of the acquisition.

A $1 million professional services business using standard cloud applications does not require the same technical assessment as a $50 million SaaS company whose value depends on proprietary software.

The right question is not, “How much due diligence should we do?“

Ask:

“Which technology risks could materially change our decision or the value of this acquisition?“

Then investigate those properly.

Can technology due diligence affect the purchase price?

Yes.

If due diligence finds that critical systems need replacing, cyber security needs major remediation or additional technology staff will be required, those costs can change the commercial value of the deal.

The findings might support a different purchase price, transaction conditions, retention arrangements or a funded post-acquisition improvement plan.

A clearer view before you sign

Buying a business always involves uncertainty. The goal is not to remove every risk. It is to understand the risks you are agreeing to own.

Technology deserves the same scrutiny as finance, legal matters, customers and contracts because technology increasingly supports all of them.

An independent technology due diligence review can help translate systems, software, people, cyber security and technical debt into something far more useful: business decisions.

Before signing, know what works, what needs attention and what it is likely to cost. That is the real value of technology due diligence when buying a business.