Technology Due Diligence Checklist for Buying a Business

A Technology Due Diligence Checklist Can Expose What the Accounts Miss

A technology due diligence checklist helps you understand the systems, software, people, security risks and technology costs you may be acquiring along with a business.

Financial reports can tell you a lot about revenue, costs and profitability. They will not necessarily tell you that the business depends on software maintained by one person, that a critical system is approaching end of life, or that nobody knows who controls the company domain.

Those problems can become yours the day the transaction completes.

Australian Government guidance recommends reviewing the records, operations, legal documents, assets, liabilities and agreements of a business before buying it. Technology deserves the same attention because it now supports almost every part of how a business operates, serves customers and makes money.

My approach to Technology Due Diligence is straightforward. Work out what the business depends on, establish who controls it, identify what could fail or become expensive, and turn those findings into business decisions before the deal is done.

Takeaways

What Is Technology Due Diligence?

Technology due diligence is an independent assessment of the technology risks, assets, costs, dependencies and capabilities associated with a business transaction.

It asks a simple question:

What technology are you really buying, and what will it take to operate it safely after the acquisition?

That can include:

• business applications
• websites and online services
• custom-developed software
• cloud hosting
• computers and network equipment
• customer and business data
• cybersecurity controls
• backups and disaster recovery
• software licences
• technology suppliers
• intellectual property
• technology staff and contractors
• documentation
• current technology projects
• future technology spending

For a traditional business, technology due diligence might focus on Microsoft 365, accounting systems, CRM software, websites, industry applications, cybersecurity and suppliers.

For a SaaS or software business, the review becomes deeper. Source code, software architecture, development practices, cloud infrastructure, technical debt, security, intellectual property and the development team may form a large part of the value you are acquiring.

Technology due diligence and IT due diligence are sometimes used interchangeably. I tend to look at the wider business picture. Technology is no longer confined to the IT department.

If customers cannot book without the website, warehouse staff cannot operate without the ERP system, or revenue depends on a software platform, those systems are business assets.

Why Technology Due Diligence Matters When Buying a Business

Buying an established business can give you customers, revenue, employees, processes and intellectual property from day one.

It can also give you someone else’s technology problems.

The Australian Government’s guidance on buying an existing business recommends gathering as much information as possible before signing the contract and reviewing the business’s records, operations and legal documents.

Technology should form part of that investigation.

A business might appear profitable while quietly carrying a large technology bill that has not yet arrived.

Imagine acquiring a business and discovering shortly afterwards that:

• its main business system must be replaced
• its website developer owns important accounts
• its backups have never been tested
• software licences cannot be transferred
• customer information is being stored insecurely
• its custom application has barely any documentation
• a critical employee plans to leave after the sale
• the company relies on unsupported software
• cloud costs are increasing much faster than revenue
• integration with your existing systems will cost hundreds of thousands of dollars

None of these automatically means you should abandon the acquisition.

They do mean you should know about them before you decide what the business is worth.

Technology due diligence is therefore less about passing or failing the technology and more about improving the quality of the investment decision.

Technology Due Diligence Checklist at a Glance

This is the high-level checklist I would use to begin reviewing a technology-dependent business.

Area	What to Check	Why It Matters
Technology ownership	Domains, cloud accounts, administrator accounts, software ownership	You need control after completion
Business systems	CRM, ERP, finance, operations and industry systems	Critical processes may depend on them
Custom software	Architecture, code, documentation and technical debt	Replacement or repair can be expensive
Infrastructure	Cloud, servers, networks, devices and hosting	Affects reliability and ongoing costs
Cybersecurity	Access, MFA, patching, vulnerabilities and incidents	Weak controls can transfer serious risk
Data and privacy	Data held, location, access and handling	Creates operational and legal exposure
Intellectual property	Code ownership, contractor agreements and licences	The seller must own what you think you are buying
Suppliers	SaaS, MSPs, developers, cloud and support contracts	Key services may depend on third parties
People	Skills, responsibilities and key-person dependency	Knowledge may leave with an employee or founder
Documentation	Procedures, diagrams, credentials and recovery information	Poor documentation makes transition harder
Business continuity	Backups, recovery procedures and incident plans	The business must continue after the deal
Current projects	Upgrades, migrations and software development	You may inherit unfinished commitments
Costs	Licences, cloud, staff, support and replacement costs	Historical IT spend may hide future spending
Integration	APIs, identity, data and system compatibility	Integration can affect the economics of the deal
Day 1 readiness	Account transfer, access and supplier continuity	Ownership change must not interrupt operations

A checklist is useful, but ticking boxes is not the objective.

The real question behind each item is: What happens to the business if this fails, disappears or costs more than expected?

1. Find Out Who Actually Controls the Technology

Start with ownership and access.

You want to know who controls the systems required to run the business.

Check:

• internet domains
• DNS services
• website hosting
• cloud platforms
• source code repositories
• Microsoft 365 or Google Workspace
• social media accounts
• payment gateways
• analytics accounts
• software administration accounts
• SSL certificates
• backup platforms
• app stores
• business phone services

Do not assume an account belongs to the company because the company pays for it.

I have seen technology arrangements where control sits with an external developer, previous employee, contractor or individual account created years ago. That can work while relationships are good. It becomes much more interesting during a change of ownership.

Check whose name is on the account, who has administrator access and whether ownership can be transferred.

This is one of the simplest due diligence checks, yet it can uncover surprisingly serious risk.

2. Build a Technology and Software Inventory

Ask the seller for a list of the technology used across the business.

Do not limit the request to what the IT team considers important.

Ask each business area what it relies on.

Typical systems include:

• accounting
• payroll
• customer relationship management
• point of sale
• eCommerce
• inventory
• rostering
• project management
• customer support
• document management
• industry-specific applications
• communications
• reporting
• data analytics
• marketing platforms

For each important system, record:

• business purpose
• owner
• supplier
• number of users
• annual cost
• renewal date
• contract term
• integration points
• data stored
• administrator
• support arrangements
• business impact if unavailable

You are trying to uncover dependencies rather than create a beautiful spreadsheet that nobody reads again.

A $100 monthly application that controls every customer booking may deserve more attention than a $50,000 system that supports a minor internal process.

3. Review Custom Software and Software Development

If the business owns custom software, the level of review should increase.

Custom software can represent valuable intellectual property. It can also hide years of deferred maintenance.

Look at:

• software architecture
• programming languages and frameworks
• source code repositories
• code ownership
• documentation
• automated testing
• deployment processes
• development environments
• production environments
• release history
• defect backlog
• technical debt
• security testing
• dependencies and libraries
• supported software versions
• current development roadmap

The important question is not whether the code looks elegant.

It is whether the software can continue supporting the business economically and reliably.

A system may work perfectly well today yet depend on obsolete technology that is becoming harder to support.

That changes its value.

A deeper Technology Due Diligence review may include software architecture, security, technical debt, development practices and delivery capability when software forms a material part of the acquisition.

4. Confirm Intellectual Property Ownership

A business selling software does not automatically mean it owns all the software.

You need to establish who created it and under what terms.

Review:

• employee agreements
• developer contracts
• contractor agreements
• IP assignment clauses
• third-party software licences
• open-source software
• purchased components
• APIs
• data licences
• design assets
• documentation ownership

Pay particular attention to software developed by contractors.

A founder may sincerely believe, “We paid for it, so we own it.“

The contract might say something different.

Your legal adviser should determine the contractual position. The technology review helps identify which components and relationships require that legal attention.

5. Assess Cybersecurity Risk

Cybersecurity problems do not politely reset themselves when a business changes owners.

You may inherit weak passwords, excessive administrator access, outdated software, compromised accounts or years of poor security practices.

The Australian Signals Directorate’s current Small Business Cyber Security Handbook recommends practical measures including multi-factor authentication, timely software updates and regular tested backups.

During due diligence, I would look for evidence around:

• multi-factor authentication
• administrator access
• user account management
• password practices
• patching
• endpoint security
• firewall and network controls
• vulnerability management
• event logging
• backups
• security awareness
• incident response
• security testing
• previous cyber incidents
• third-party access

Ask specifically about incidents.

Has the business experienced ransomware, phishing, business email compromise, data loss or unauthorised access?

What happened?

What was changed afterwards?

A mature answer does not have to be “we have never had a security incident“. That claim can sometimes deserve more questioning.

A better sign is a business that understands its risks, documents incidents, responds properly and improves its controls.

6. Understand What Data You Are Acquiring

Data can be one of the most valuable assets in a business.

It can also create serious obligations.

Identify:

• what customer data exists
• what employee data exists
• what sensitive information is stored
• where information is located
• who has access
• why it is collected
• how long it is retained
• where backups are stored
• which suppliers process it
• whether information leaves Australia
• how data can be exported or deleted

Privacy deserves particular care during the acquisition process itself.

The Office of the Australian Information Commissioner guidance on selling a business explains that organisations covered by the Privacy Act must continue protecting personal information during due diligence. Where possible, information provided to prospective buyers should be de-identified or aggregated.

Do not ask for copies of customer databases simply because you can.

Ask what you genuinely need to assess the business.

People before technology applies here too. Those records represent real customers, employees and individuals who trusted the company with their information.

7. Review Technology Suppliers and Contracts

Businesses increasingly depend on technology they do not own.

Cloud hosting, SaaS applications, managed service providers, payment services, telecommunications and external developers may all be critical.

For each important provider, determine:

• what service they provide
• annual cost
• contract term
• renewal date
• termination conditions
• service levels
• account owner
• data location
• available alternatives
• transfer conditions
• dependency on the supplier

Then ask what happens if that supplier disappears.

Could the business continue?

Could another provider take over?

Could the data be exported?

Would replacing the service take hours, weeks or a year?

Supplier dependency is especially important when the target relies heavily on one software developer, MSP or specialised technology provider.

8. Look for Key-Person Technology Risk

Sometimes the most valuable technology asset is not software.

It is a person.

You might hear:

“Ask Peter. He knows how that works.“

Keep asking questions.

If Peter knows how the website works, controls the cloud account, understands the database, manages the backups and knows where all the passwords are stored, you have identified a business continuity problem.

Review:

• technology roles
• responsibilities
• length of service
• specialist knowledge
• succession arrangements
• documentation
• contractor dependencies
• upcoming resignations
• retention plans

Then ask:

What stops working if this person leaves tomorrow?

This issue appears in companies of every size.

A Technology Leadership review can also help where the concern extends beyond individual dependency into broader leadership, accountability and technology governance.

9. Examine Backups, Disaster Recovery and Business Continuity

“Yes, we have backups” is not enough.

Ask:

• What is backed up?
• How frequently?
• Where are backups stored?
• Who monitors them?
• Are backups protected from the production environment?
• When was a restore last tested?
• How long would recovery take?
• What happens if the office is unavailable?
• What happens if the primary cloud provider fails?
• Who coordinates recovery?

A backup that has never been restored is still partly a theory.

Business continuity should also cover people and suppliers.

Technology recovery is useless if nobody knows what to do.

10. Identify Unsupported and Ageing Technology

Old technology is not automatically bad technology.

An older system that is stable, supported and suitable for the business may be perfectly sensible.

The risk appears when software:

• no longer receives security updates
• depends on discontinued products
• runs on unsupported operating systems
• cannot integrate with newer systems
• relies on unavailable skills
• prevents necessary business changes
• becomes increasingly expensive to maintain

Ask for lifecycle information about critical technology.

This helps distinguish technology that merely looks old from technology that creates a real financial or operational risk.

11. Examine Current Technology Projects

You are not only buying existing technology.

You may also inherit unfinished work.

Request a list of active technology projects, including:

• software development
• CRM implementations
• ERP upgrades
• cloud migrations
• cybersecurity programs
• data projects
• website replacements
• infrastructure changes
• AI initiatives

For each one, ask:

• Why was it started?
• What was the original budget?
• What has been spent?
• What remains?
• Who is delivering it?
• What contractual commitments exist?
• Is it on schedule?
• What value is expected?
• Can it be stopped?

A half-finished project can carry substantial hidden cost.

Where delivery itself is a concern, an independent Project Delivery assessment can help determine whether the project needs to continue, change direction or stop.

12. Understand the True Technology Cost

Historical technology spending is useful, but it does not necessarily represent your future cost.

Build a forward-looking technology cost picture covering:

• software subscriptions
• cloud services
• telecommunications
• managed IT
• cybersecurity
• contractors
• technology employees
• hardware replacement
• support
• licences
• planned projects
• required remediation
• system replacement
• integration

This can materially change how you think about the purchase price.

Imagine the target reports annual IT expenditure of $120,000.

Your review discovers that its main operational system needs replacing within 18 months at an estimated cost of $400,000.

The historical accounts can still be completely accurate.

They simply do not tell you the whole story.

13. Check Whether the Technology Supports Your Plans

Due diligence should not only ask whether the technology works today.

Ask whether it supports what you intend to do with the business.

Perhaps you plan to:

• double customer numbers
• expand nationally
• open new sites
• launch eCommerce
• automate operations
• combine businesses
• introduce new products
• improve reporting
• use AI
• reduce administrative work

The existing systems may be perfectly adequate for the current owner and completely inadequate for your strategy.

That does not make them bad systems.

It means there is a gap between the technology you are buying and the business you intend to build.

This is where Technology Strategy can connect acquisition findings with what needs to happen after completion.

14. Estimate Integration and Separation Costs

If the business will become part of another organisation, understand the cost of combining the two environments.

You may need to integrate:

• identity systems
• Microsoft 365
• networks
• accounting
• CRM
• HR
• reporting
• customer databases
• cybersecurity controls
• websites
• phone systems
• software development
• cloud infrastructure

The opposite issue appears when buying a division from a larger organisation.

The systems you saw during due diligence may belong to the seller and disappear after separation.

You may need new systems simply to keep operating.

Map these requirements before completion so they become part of the acquisition model rather than an unwelcome Day 30 surprise.

15. Prepare a Day 1 Technology Plan

Technology due diligence should lead naturally into Day 1 planning.

Do not finish with a 70-page report that goes into a folder and starts gathering digital dust.

Identify what must happen immediately.

That might include:

1. transferring administrator accounts
2. changing privileged credentials
3. securing domain ownership
4. confirming backup access
5. retaining key technology staff
6. notifying critical suppliers
7. documenting external developer access
8. applying urgent security fixes
9. confirming support arrangements
10. beginning high-priority remediation

The Australian Signals Directorate’s guidance on choosing secure and verifiable technologies also encourages organisations to consider security requirements, supplier risk, data handling and contractual requirements as part of technology purchasing decisions.

The same thinking is useful when buying an entire business.

Red Flags I Would Investigate Further

A red flag does not always mean “walk away“.

It means “understand this before proceeding“.

I would investigate further if I found:

• one person controls most technology
• critical accounts use personal email addresses
• source code ownership is unclear
• important software is unsupported
• there are no tested backups
• no reliable system inventory exists
• important passwords are shared
• administrator access is excessive
• serious cyber incidents were poorly documented
• custom software has no documentation
• developers cannot explain deployment
• large projects are running without clear budgets
• key suppliers have no written agreements
• the company cannot explain where customer information is stored
• technology costs are rising much faster than revenue
• the seller refuses reasonable access to technology information

That last point matters.

Incomplete information is itself information.

If an important question cannot be answered, record it as an uncertainty rather than quietly assuming everything is fine.

What Documents Should You Request?

A useful initial technology due diligence request list could include:

Systems and infrastructure

• technology asset register
• application register
• architecture diagrams
• network diagrams
• cloud platform list
• hardware inventory
• domain register

Security

• cybersecurity policies
• incident register
• penetration testing reports
• vulnerability reports
• access control policies
• backup procedures
• disaster recovery plan
• business continuity plan

Software

• source code repository details
• software architecture documents
• development roadmap
• technology backlog
• release procedures
• open-source dependency records

Suppliers and finance

• technology supplier list
• contracts
• software licence agreements
• subscription costs
• cloud invoices
• technology budget
• planned capital expenditure

People

• technology organisation chart
• role descriptions
• contractor agreements
• key-person dependencies
• succession arrangements

Governance

• technology strategy
• technology roadmap
• policies
• risk register
• audit reports
• current project reports

Do not assume missing documents prove poor management.

A smaller company may operate perfectly well with lighter documentation.

The question is whether enough knowledge exists to operate, support and transfer the business safely.

How Technology Findings Can Affect the Deal

The purpose of due diligence is not simply to identify problems.

Findings need to lead to decisions.

Technology issues may result in:

Proceeding as planned

The risks are understood, reasonable and already reflected in the price.

Negotiating the purchase price

Material remediation or replacement costs may affect what you believe the business is worth.

Requesting contractual protection

Your legal advisers may recommend warranties, indemnities, conditions or other protections based on identified risks.

Requiring action before completion

Certain accounts, licences, contracts or intellectual property issues might need resolving before the transaction completes.

Creating a post-acquisition plan

Some issues do not need fixing immediately. They simply need a clear owner, budget and timeframe.

Walking away

Occasionally, a combination of technical, security, operational and people risks makes the transaction unattractive.

Technology due diligence does not make that decision for you.

It gives you better information with which to make it.

Technology Due Diligence Should Match the Business

There is no single correct level of technology due diligence.

Buying a suburban professional services business with 15 employees is different from acquiring a SaaS company whose entire value sits in proprietary software.

The review should reflect:

• transaction value
• technology dependency
• complexity
• regulatory requirements
• customer expectations
• amount of custom software
• sensitive data held
• integration plans
• your tolerance for risk

A smaller acquisition might need a focused review of systems, ownership, cybersecurity, suppliers, people and likely replacement costs.

A technology company may justify detailed reviews of software architecture, source code, cloud infrastructure, security, development processes, intellectual property and engineering capability.

Spend effort where failure would hurt.

Common Technology Due Diligence Mistakes

Treating technology as an IT department issue

Technology often sits directly inside sales, operations, customer service and delivery.

Review the business process, not merely the computers.

Looking only at current costs

A cheap technology environment may simply mean investment has been deferred.

Look forward.

Believing every management answer without evidence

People are usually trying to help, but memory is imperfect.

Ask for supporting evidence where the issue matters.

Ignoring people

Documentation, systems and contracts matter.

So does the person who knows how everything works.

Assuming cybersecurity can wait

You inherit the exposure when you acquire the business.

Leaving technology until the end

Discovering a major technology problem three days before signing leaves little room to investigate or negotiate.

Producing findings without business impact

“Server operating system version X is approaching end of support” means little to a business buyer.

“This system supports order processing and may require a $60,000 replacement project within 12 months” is useful.

Technology findings need to be translated into business consequences.

A Simple Decision Framework

For each material technology finding, I use five questions:

1. What is the issue?
2. What business process depends on it?
3. What happens if nothing changes?
4. What will it probably cost to address?
5. When does it need attention?

Then classify it.

Priority	Meaning	Typical Response
Critical	Could threaten the transaction or business continuity	Resolve or protect before completion
High	Material financial, security or operational risk	Cost and plan remediation
Medium	Needs attention but can be managed after acquisition	Add to post-acquisition roadmap
Low	Improvement rather than immediate risk	Monitor or address when practical

This keeps due diligence focused on decisions rather than creating a technical shopping list.

Frequently Asked Questions

What is included in a technology due diligence checklist?

A technology due diligence checklist normally covers business systems, software, infrastructure, cybersecurity, data, intellectual property, suppliers, people, documentation, continuity, current projects, costs and integration requirements.

The exact scope should depend on how much the business relies on technology and what you plan to do with it after acquisition.

Is technology due diligence different from IT due diligence?

The terms overlap.

IT due diligence often focuses on internal systems, infrastructure, networks, security and IT operations. Technology due diligence can extend further into custom software, product technology, source code, engineering teams, technical intellectual property and the ability of technology to support the buyer’s commercial plans.

For a software company, that distinction can be important.

When should technology due diligence start?

Start early enough that important findings can influence your decision, valuation, negotiations and purchase agreement.

Waiting until the transaction is almost complete reduces your options if a major risk appears.

Do I need technology due diligence when buying a small business?

It depends on the business rather than just its size.

A small business that relies heavily on online bookings, specialised software, customer data or one technical person may carry considerable technology risk.

A short, focused review may be enough. Ignoring technology entirely is a different matter.

Can technology problems reduce the purchase price?

They can affect your assessment of business value.

For example, discovering that a critical system requires substantial replacement spending may change your financial model. How that information affects the purchase price or contractual terms is a commercial and legal decision for you and your advisers.

Should a technology consultant replace my accountant or solicitor?

No.

Technology due diligence complements financial, tax, commercial and legal due diligence.

Your accountant might assess financial performance and tax position. Your solicitor might review contracts and legal ownership. A technology adviser examines the systems, software, security, people, dependencies and future technology costs behind the business.

You need the relevant advisers looking at the transaction from their respective perspectives.

What is the biggest technology risk when buying a business?

There is no universal answer.

In some businesses it is cybersecurity. In others it is ageing software, a key employee, ownership of custom software, an expensive system replacement or dependence on a supplier.

The biggest risk is often something more basic: a business-critical dependency that the buyer did not know existed.

Better Information Makes for a Better Acquisition

Buying a business should not require you to become a technology expert.

You do, however, need to understand what the business depends on, where material risks exist and what those risks could cost you after completion.

An independent review can give you that clarity without selling you software, development work or managed IT services. The aim is simply to help you make the investment decision with better information.

If technology is important to the business you are considering acquiring, my Technology Due Diligence service can provide an independent assessment before you commit.

A well-scoped technology due diligence checklist helps you understand what you are buying before the technology problems become yours.