Technical due diligence checklist for Australian software companies

Who orders technical due diligence, and what do they want to know?

Technical due diligence is ordered by whoever is about to put money at risk: a venture or private equity investor, a trade buyer, a lender, or sometimes a large customer signing a long contract. Each wants the same core answer: is the technology what the company says it is, does the company own it, and what will it cost to fix what’s wrong?

The emphasis shifts with the buyer. A venture investor cares most about whether the platform can scale and whether the team can keep shipping. A trade acquirer cares about integration, overlap with its own systems and the people it needs to keep. Private equity wants hidden costs quantified so they can be priced. In every case, findings end up in the deal: a lower price, a specific warranty or indemnity, an escrow, or a condition that must be met before completion.

This page excludes the building and property sense of “technical due diligence”, which is a different discipline.

IP: who owns the code, including contractors and offshore teams

The first thing a careful reviewer checks is chain of title: written proof that the company owns every significant piece of its code. It is also the finding most likely to delay a deal, because fixing it means tracking down people who may have left years ago.

Australian law makes this a real risk. Under section 35(6) of the Copyright Act 1968, copyright in work an employee makes under a contract of service generally belongs to the employer. Contractors are different: they own what they write unless they assign it, and section 196(3) says an assignment of copyright has effect only if it is in writing and signed by or on behalf of the assignor. A founder who wrote the first version before the company existed, a freelance developer on a handshake, or an offshore agency whose contract says nothing about IP can each leave a gap. Our guide to who owns the source code in Australia covers the basics.

What the reviewer asks	Evidence to have ready	Red flag
Who wrote the core platform?	Contributor list from version control, mapped to people	Unknown or shared accounts
Did every contractor and agency assign IP?	Signed assignment deeds or contracts with assignment clauses	Contracts that only grant a licence, or none at all
Did founders assign pre company work?	Founder IP assignment to the company	Code written before incorporation, never assigned
Are there third party components you don’t own?	Licence register for paid libraries, SDKs and APIs	Licences in a founder’s personal name

Code quality, architecture and technical debt

Reviewers judge whether the codebase can be safely changed and scaled, not whether it is elegant. They read samples of the code, run the build, look at test coverage on the critical paths and ask the engineers to walk through recent changes.

What they look for: a build that runs from a clean checkout, automated tests around payments, permissions and data handling, a deployment pipeline that doesn’t depend on one person’s laptop, clear separation of components, and a documented list of known debt with rough estimates. Debt that is known and costed is normal. Debt nobody can explain becomes a price adjustment. An independent code audit before a raise or sale gives the company a chance to find these first.

Security posture, incidents and notifiable data breaches

Expect to disclose every material security incident and notifiable data breach, with what you changed afterwards. Under the Notifiable Data Breaches scheme, organisations covered by the Privacy Act must notify affected individuals and the OAIC when a data breach is likely to result in serious harm. A buyer will ask whether any were notified, and whether any should have been.

The security review typically covers access control and multi factor authentication across the cloud, code and admin systems, secrets management, patching, logging, backups that have been restored in a test, and recent penetration test reports with the fixes. Customers in finance and government will often have sent security questionnaires already; the answers you gave them are evidence too. See our guide to notifiable data breaches in software and penetration testing costs.

Privacy, data handling and customer contracts

The reviewer checks that what the company does with data matches what its privacy policy and customer contracts promise. The gaps are usually small but contractual: a contract promising Australian hosting while backups or support tools sit offshore, or a commitment to delete data on termination that the system can’t actually perform.

Have ready a data map (what personal information you hold, where, and why), your subprocessor list, the data terms in your top customer contracts, and evidence that deletion and access requests work. If the company uses AI on customer data, show the model provider terms on training use and retention.

Open source licences and AI generated code

Every software company uses open source; the question is whether any licence obligations conflict with the business model. Most permissive licences need little more than attribution. Copyleft licences can require you to share source code, and the GNU Affero GPL is designed so that if you run a modified program on a server for users, they can get the source.

Generate a software bill of materials from the build, flag copyleft components, and record where each is used. AI coding tools add a newer question. Australian copyright subsists in a work by virtue of human authorship, as the Full Federal Court held in Telstra v Phone Directories, so code produced mostly by AI with little human contribution may not be protected. Be ready to describe how AI tools were used, under which licence terms, and how generated code was reviewed.

Team, documentation and key person risk

If one engineer is the only person who understands deployment, billing or the data model, the reviewer will flag key person risk and the buyer will try to price or contract around it.

Reduce it before the process starts: architecture and runbook documentation that someone else has tested, shared access to every system through company accounts with no personal logins, a second person who has deployed to production, and retention arrangements for critical people. A fractional CTO can help a founder led team organise this if there is no technical leader in place.

R&D Tax Incentive records and claims exposure

If the company has claimed the R&D Tax Incentive, the buyer will want to know that each claim is supported by records, because an adverse eligibility finding can reduce or reverse the benefit. Business.gov.au says companies must keep records of R&D activities from the time they intend to start them until they make the claim, and that if records can’t be provided, the department is likely to find the activities ineligible. The department can examine registrations where it sees high eligibility risk.

Also note that the government announced changes in the 2026 to 27 Budget, taking effect from 1 July 2028, including removing supporting R&D activities from eligibility and raising the turnover threshold for the refundable offset from $20 million to $50 million. A buyer modelling future offsets will factor those in. We are not tax agents; a registered R&D tax agent should review claims history. Our guide to the R&D Tax Incentive for software development explains the activity tests.

Foreign acquirers: FIRB and national security

A foreign buyer of a software or data business may need to notify the Foreign Investment Review Board. Acquiring a direct interest in a national security business is a notifiable action, the guidance includes sector material on information technology, data and the cloud, and investments that are not notified can be called in for review later while under foreign ownership. This is a question for the buyer’s lawyers, but the target should know whether its customers or data could make it relevant.

Preparing your company before the data room opens

Start preparing three to six months before a raise or sale; most fixes take time, not money.

1. Collect every IP assignment; get missing ones signed now.
2. Generate a software bill of materials and resolve copyleft conflicts.
3. Write or update the architecture overview and runbooks, and have someone else test them.
4. Move every system to company owned accounts with multi factor authentication.
5. Compile the incident and breach register with remediation notes.
6. Check customer contract data terms against what the system does.
7. Gather R&D registrations with their contemporaneous records.
8. Commission an independent review, so the findings are yours to fix first.

How AWLabs approaches this

We run independent code audits for companies preparing for investment or sale, and for buyers who want a second opinion on a target. The audit covers the code, architecture, security posture, IP evidence and open source inventory, and ends with findings ranked by severity and a fixed price Schedule of Work for any remediation, with three options. See why we start with an audit. Legal questions about IP, FIRB and warranties belong with your lawyers; tax questions with a registered R&D tax agent.