Software Code Audit Before You Buy a Software Company in Canada

A software code audit before you buy a software company tells you what you are really paying for. The financial and legal reviews check the revenue, contracts and corporate records. They rarely check whether the code is owned by the company, safe to run, and possible to maintain once the founders leave. For private equity firms, search fund buyers, strategic acquirers and investors in Canada, a short technical review before closing can change the price, the deal terms or the decision. Here is what a good audit covers and what to ask the seller.

What a software code audit covers

A useful audit looks at the code and at how the team works, not just at the output of a scanning tool. It usually covers:

1. Ownership. Who wrote the code, whether employees and contractors signed agreements that give the company the rights, and whether any code was copied from somewhere it should not have been.
2. Open source licences. Almost every product uses open source libraries. Most licences are easy to follow. Some, such as the GPL and AGPL, can require you to release your own code under the same licence if you distribute the product or, for the AGPL, let users reach it over a network. The audit lists every licence and flags the ones that need a closer look.
3. Security. Known vulnerable libraries, passwords or keys left in the code, weak permission checks, and how personal information is stored and protected.
4. Quality and maintainability. Whether there are automated tests, whether a new developer could build and deploy the product from the instructions, and how much of the code is old and fragile.
5. Key people. If one developer wrote most of the code and holds all the knowledge, that is a risk to price in or plan for.
6. Architecture, costs and outside services. Whether the system can grow with your plans, what it costs to host, which outside services and paid licences it depends on, and whether any of those agreements end or need consent when the company changes hands.
7. Data and privacy. What personal information the product holds, where it is hosted, and how it handles the privacy rules its customers expect, such as PIPEDA or Quebec's Law 25.

Points specific to buying in Canada

A few Canadian rules come up often. These are questions to raise with your lawyer or tax advisor, not legal or tax advice:

1. Employees and contractors are treated differently. Under the Copyright Act, an employer generally owns the copyright in code an employee writes as part of their job, unless they agreed otherwise. A contractor generally owns what they write unless they assigned it in writing. Whether someone was really an employee or a contractor depends on the facts, not just the job title. Ask for the signed agreements, especially from founders for code written before the company was formed, early contractors and offshore teams, and check that an offshore assignment is valid where the developer lives.
2. Moral rights cannot be assigned, only waived. Canadian copyright includes moral rights that stay with the author. Check whether the agreements include a written waiver.
3. Sharing personal information during a deal. PIPEDA, and similar laws in Quebec, Alberta and British Columbia, allow personal information to be shared for a prospective business transaction under conditions: it must be needed for the deal, the buyer must agree to use it only for the deal and protect it, and it must be returned or destroyed if the deal does not close. In practice, auditors rarely need real customer data. Ask for read-only code access and test data instead.
4. SR&ED claims. If the company claimed SR&ED tax credits for its development work, ask your tax advisor how those claims and their records affect the deal.

How the audit works

A typical audit of a small or mid-sized product takes one to four weeks, depending on the size of the code and how fast the seller gives access:

1. Access under NDA. Read-only access to the code repositories, the build and deployment setup, and the documentation. If the seller will not share the full code, a supervised review session or a clean team arrangement can work.
2. Automated scans. Software composition analysis tools produce a list of every open source component and its licence, often called a software bill of materials, along with known vulnerabilities. Other tools look for secrets in the code. This is the starting point, not the audit.
3. Manual review. Senior engineers read the parts that matter most: login and permissions, payments, data handling and the core features customers pay for.
4. Interviews. Short conversations with the technical lead about how they build, test, release and handle incidents.
5. A build test. Can the product be built and run from the code and the instructions alone?
6. A written report. Findings ranked by risk, in plain language a non-technical buyer can act on, with a rough estimate of the time and cost to fix the serious ones.

How findings change the deal

Very few audits end a deal. Most change its terms. Common outcomes include:

1. A price adjustment for work that must be done after closing.
2. A holdback or escrow until a problem is fixed.
3. Specific statements and promises from the seller in the purchase agreement (representations, warranties and indemnities). If you are buying representation and warranty insurance, note that it usually excludes problems found during due diligence, which is one reason specific indemnities matter.
4. Conditions to meet before closing, such as getting missing IP agreements signed or replacing a library with a problem licence.
5. A plan for the first 100 days.

Your lawyer decides how to write these into the agreement. The audit gives them the facts.

Sellers can use the same process. A seller who commissions an audit before going to market can fix the worst issues first and usually gets through the buyer's due diligence faster.

Red flags worth slowing down for

1. No signed IP agreements from the people who wrote most of the code.
2. GPL code built into software the seller gives to customers, such as apps, on-premise installs or devices, or AGPL code in a product offered online, with no plan for it.
3. Passwords or keys in the code, or real customer data in code or test repositories.
4. No automated tests, and only one person who knows how to release the product.
5. Hosting accounts, domains or code repositories owned by a founder personally instead of the company.
6. A security incident the seller cannot explain clearly.

Ten questions to ask the seller

1. Who wrote the code, and do we have signed IP agreements from every founder, employee and contractor, including moral rights waivers?
2. Can you give us a list of every open source library and its licence?
3. Is any GPL or AGPL code in the product, and how is it used?
4. When was the last security test, and what happened to its findings?
5. Have you had a security incident or data breach, and how was it handled?
6. Where is customer data hosted, and what personal information does the product hold?
7. Could a new developer build and deploy the product from your documentation?
8. How many developers know each part of the system, and who is staying after the sale?
9. Who owns the hosting accounts, domains and code repositories, and do any paid licences or API agreements end or need consent on a change of control?
10. What would you fix first if you had another six months?

If several answers are vague, that is your list of things to check.

How we approach it

NorthSight Technologies is a software development company in Ontario, Canada. Senior engineers review the code, the build and the team's practices, and write a plain-language report a buyer, board or lender can act on, with an estimate of what the serious issues would cost to fix. Because we build and fix software every day, we can also do that work after closing if you want us to. We do not give legal or tax advice, and we work alongside your lawyer and financial advisors.

If you are buying or investing in a software company and want a software code audit before you close, we offer a free 20-minute call. You can read how we work and book the call on our secure code review and application security page.

Also published on LinkedIn →