Inside a CodeBridge software check.

The CodeBridge method for checking a software company before you sign: the 2 to 6 week timetable, the terms that protect both sides, what a good report contains, three real Australian jobs, the rules that apply, and the questions we are asked most often. Every finding is signed, and every one points at an exact line of code.

How we do it in 2 to 6 weeks

Before we start

Access and Permission

  • We fully expect to sign a confidentiality agreement first. Ours runs for three years, and up to five if you ask. See section 2.
  • The owner gives us read-only access to where the code is kept. We work with all the common ones, whichever the company uses.
  • We agree with the client and the seller how we will hold the code, inside their own systems, or in a locked-down environment of ours. Their choice, written into the agreement.
  • We build a copy of the running system in a sealed environment, so we can watch how it behaves without touching anything live.
  • Nothing aggressive runs without written permission. The stress and break testing in section 10 needs sign-off from the owner of the software and whoever hosts it. No sign-off, no test. That is not a formality: running our tools against a system we do not have authority over is a criminal matter, and we treat it as one.

* Please note we are an approved security partner with Anthropic’s Cyber Verification Program and hold OpenAI Codex security verification.

week 1

Set up

  • Build a complete map of the codebase, showing how each component connects and operates within the wider system.
  • Catalogue cloud services, third-party code, dependencies, and external services that the software uses or communicates with.
  • Meet with the seller’s technology leadership and lead engineers to establish how the system is intended to operate.
  • Compare the intended design with the system’s actual behaviour as the review progresses, identifying any gaps, undocumented dependencies, or areas requiring further investigation.
week 2

Dig in

  • Read the complete codebase, including checks for cross-file vulnerabilities: individually safe pieces of code that combine to create an exploitable pathway.
  • Run the Missing Pieces Pass, identifying functionality, safeguards, or documentation that should exist but is absent from the codebase.
  • Stress-test the running system against the eight common ways systems fail, assessing its resilience under realistic failure conditions.
  • Review AI-written code with the complete system map in view, assessing how each component fits into the wider architecture and identifying associated risks.
  • Calculate the projected cloud expenditure for the next 12 months, using the organisation’s growth plans and expected usage.
  • Where a handover is contested, run the Deliberate Damage Checks, covering time-based damage, hidden access paths, unauthorised re-entry, doors left open, and dependencies on a single individual.
week 3

Report

  • Separate relevant findings from non-applicable findings, explaining clearly why each item does or does not apply to the system.
  • Prioritise the remaining findings across three dimensions: ease of exploitation, potential impact on value, and estimated remediation cost.
  • Document every finding with precise references, including the relevant file and line number.
  • Review the draft report with the client and the seller’s technology leadership, ensuring the technical assessment and its implications are clearly understood by all parties.
  • Finalise, sign, and formally deliver the report.
week 4-6

If you want more

  • Complete a full assessment against the rules in Section 6, confirming that the system has been evaluated against every required check.
  • Prepare the evidence pack required by cyber insurers, covering security controls, monitoring, backup and recovery, incident response, access management, and other information needed to assess exposure and price the policy.
  • Develop an integration-risk plan for bringing the two companies together, addressing systems and technology, security controls, data handling, third-party dependencies, people and access, compliance, and insurance.

How both sides are protected

The engagement proceeds only with the consent of the intellectual property owner and on terms agreed by all parties. The arrangements are structured to protect the interests of both the IP owner and the client, ensuring that the review can be conducted with appropriate authority, confidentiality, and clarity.

Four elements make this possible:

A three-year confidentiality agreement

The industry standard is one year. Ours is three as standard, and five on request, at no extra cost. That matters more than it sounds. A deal that falls over in month eight leaves the seller exposed under a one-year agreement well before the commercial risk has passed. Three years covers the period in which the information could still be used against them. It is also the single most common reason a nervous seller says yes to us after saying no to someone else.

Read-only access

We can look. We cannot change anything. This is set at the source, not promised in an email.

The owner decides where the code is stored

Some companies do not allow their code to leave their premises because of their internal security policies or industry regulations. In those cases, we work within their systems. Other companies prefer us to take a controlled copy into our secure, isolated environment, ensuring that their production systems are never accessed or modified. Both arrangements are standard. The agreement specifies which approach applies and confirms where any copy will be securely destroyed at the end of the engagement.





Written permission is required before any penetration testing

Tools that interact with, probe, or stress a live system may be used only after both the system owner and the hosting provider have provided written approval. The agreement defines the authorised scope, systems, methods, timing, and restrictions. This protects the client, the host, and Codebridge.

Seller Controls for Buyer Access

As the seller, you are entitled to set the conditions for access to your systems and code. A buyer’s adviser who refuses read-only access, a comprehensive confidentiality agreement, or written limits on the testing they may perform may be signaling how they intend to work. Before granting access, require all three protections: read-only permissions, appropriate confidentiality obligations, and a written, clearly defined testing scope.

What a good report contains

The report is what you are paying for. Your investment committee will read it. Your insurance broker will read it. If the deal goes wrong, lawyers will read it. Almost none of those people are engineers, so the report is built in two halves.

The front – written for the person signing

  • One page, up front. The problems ranked, each marked “this changes the price” or “this does not”, with a number against it.
  • What it will cost you. The money to fix what has to be fixed, and the 12-month cloud bill under three growth scenarios.
  • What we would do about it. Where the first dollar goes, and what can safely wait.
  • What does not apply to you. The warnings that have been ruled out, and why. This is usually the longest list and the reason the short list is trustworthy.
  • A signed page, with the names of everyone who reviewed it.

The back – written for engineers

  • Every problem, worst first, each with the file, the line, how hard it is to fix, and how easy it is to attack.
  • Two-part problems, set out separately, because they need a longer explanation.
  • A full list of borrowed code and the licence attached to each piece.
  • How much AI wrote, which parts of the system it wrote, and the duplication it left behind.
  • Who knows what, worked out from the code and its history, not from interviews.
  • A rules check, against each Australian rule that applies.
  • What has been looked at and how, including which tools were used and where each finding came from.

* Important information to note: A partner or an underwriter should be able to read the first three pages and make a decision. Their technical people should be able to read the rest and start work on Monday. A report that mixes the two gets skimmed by both.

Assess the Reporting Methodology Before Engagement

Before engaging the provider, request an example of the proposed report format. It should show what was examined, how it was assessed, and what was concluded for each finding. Because the report may support negotiations and later disputes, it must be clear, evidence-based, and defensible. Assess the methodology before engagement, not afterwards.

Ongoing Technology and Risk Oversight

A pre-acquisition software assessment provides an important baseline, but it is not a substitute for ongoing oversight. Technology environments, security exposures, regulatory obligations, and cloud costs can change materially after completion.

Following the transaction, the assessment capability can remain in place across the acquired business. Quarterly reporting provides a concise view of material changes, emerging risks, cloud-cost performance against forecast, and relevant regulatory developments.

For portfolios of 20–40 companies, this approach can provide a more consistent alternative to periodic, consultancy-led reviews, while establishing an ongoing record of technology and cyber-risk governance. Continuous monitoring and documented evidence of control effectiveness can also support cyber-insurance underwriting and renewal discussions.

Evidence That Changes Decisions

Independent software due diligence identifies risks that may affect transaction terms, operational continuity, security exposure, and future technology costs. The examples below show how a focused review can turn technical findings into practical commercial decisions. Technical due diligence commonly examines code, security, infrastructure, scalability, and cloud-cost assumptions, with findings translated into risk, remediation effort, and valuation impact.

01

Protecting a disputed software handover

The Problem

An Australian point-of-sale software business was being transferred during a legal dispute. Neither party was prepared to rely on a review conducted by the other, so the parties required an independent assessment before ownership changed.

what we did

We examined the codebase and associated access pathways to identify risks that could affect the handover. The review identified:

  • Code designed to delete the system at 4:00 am if it lost contact with the former team’s code repository.
  • An internet-accessible route into the largest customer’s database, with the ability to read or destroy its contents.
  • A further externally accessible entry point elsewhere in the system.

These issues were not identified through a standard automated security scan.

the outcome

All three issues were remediated before the transfer. The software changed hands without triggering the deletion mechanism or exposing the new owners to the identified database-access risks.

02

Reducing an unexplained cloud-cost burden

The Problem

An established Australian software business had experienced rising cloud costs for two years. Previous attempts to reduce expenditure by moving to lower-cost infrastructure had not addressed the cause.

what we did

Codebridge reviewed the software and operating environment to determine what was driving consumption. The underlying issue was inefficient application behaviour, not the cost of the underlying machines, including repeated database queries, indefinitely retried failed jobs, and customer-facing processes that should have been handled in the background.

the outcome

The changes reduced cloud expenditure by $5,000–$6,000 per month, without a noticeable decline in customer performance. No new infrastructure was purchased and no migration was required, the saving came from correcting the software’s use of existing cloud resources.

03

Delivering decision-ready findings in 15 days

The Problem

An Australian investment fund had agreed to acquire a finance software company, but its investment committee was due to vote within 21 days. The seller would not permit the source code to leave its environment, and the first provider approached proposed a 10-week review.

what we did

Codebridge worked within the seller’s systems from the first day and completed the assessment within the required timeframe. By the end of the second week, we had identified three issues material to the acquisition:

  • Two instances of third-party code that, together, could provide an external party with a route into internal systems.
  • A payment-processing design that would not support the buyer’s planned growth and was expected to fail within six months.
  • Cloud costs projected to run 40 percent above the seller’s forecast under the buyer’s growth plan.

the outcome

A signed report was delivered in 15 working days. The buyer used the findings to adjust the purchase price for the required engineering work and revise its financial model using the projected cloud costs. The investment committee received the information it needed, and the transaction completed on schedule.

Regulatory Requirements Relevant to Software Due Diligence

A software due-diligence review should identify the regulatory obligations relevant to the business, its customers, and the jurisdictions in which it operates. The assessment should consider whether technology, security, privacy, operational-resilience, and third-party risk controls are adequate, and highlight material gaps that could affect the transaction, remediation costs, or ongoing compliance.

The table below outlines key Australian and European requirements that may be relevant, depending on the business model, customer base, and regulated entities served. APRA’s CPS 234 applies to APRA-regulated entities, while CPS 230 introduced strengthened operational-risk and resilience requirements from 1 July 2025.

Rule

Who has to follow it

What we check

APRA CPS 234

Banks, insurers and super funds, plus the companies that supply them

Installs and runs open-weight models on site with safety controls.

Can they keep data safe? Do they report break-ins on time? Do they check their suppliers?

APRA CPS 230 (from 2025)

Same companies as APRA CPS 234, but wider rules

Do they know which systems are critical? How long can each one be down? Do they have a list of who they depend on?

Australian Privacy Principles

Most Australian businesses earning over $3 million a year

How they handle personal data, whether they send it overseas, and whether they can report a leak quickly

DORA (European rule)

Any company with European finance customers

How they manage technology risk, supplier risk, and whether they test that the system keeps running under stress

Please note: If the company sells to Australian banks, or to anyone in Europe, the report must name these rules directly. If you buy a company that does not follow them, the cost of fixing that becomes yours on day one.

Common questions

Traditional consulting engagements often rely heavily on stakeholder interviews, selective code review, and high-level assessment frameworks. They can provide valuable commercial and financial context, but may not always deliver a detailed, evidence-based view of the software itself within the available transaction timeframe.

Our approach applies AI-enabled analysis across the codebase and relevant technical environment to identify specific issues, trace them to the relevant code or configuration, and explain their potential operational, security, and financial implications. This supports a faster, more granular, and more directly actionable assessment.

The approaches are complementary. We can operate as the specialist technical due-diligence partner alongside a larger advisory firm responsible for financial, commercial, legal, or broader transaction work.

Our assessment tools can operate within the seller’s controlled environment, so source code and related data do not need to leave the seller’s systems. This approach is designed for transactions where security, confidentiality, or regulatory requirements prevent external access or code transfer.

“Codebridge is approved under Anthropic’s Cyber Verification Program and holds OpenAI Codex security verification. We have been independently reviewed against Anthropic’s security, data-handling, and agent-safety standards, and separately verified by OpenAI for security-focused use of Codex.”

Alternatively, where agreed, a controlled copy can be assessed in an isolated environment, ensuring that production systems are not accessed or affected. The engagement terms specify the applicable access model, security controls, permitted activities, and requirements for the return or secure destruction of any copied materials.

Yes. Written authorisation is required from the software owner and, where applicable, the hosting provider before any penetration testing or live-environment security testing is undertaken.

Testing activities that simulate or attempt to exploit vulnerabilities can resemble an actual attack and may affect systems or services if conducted without appropriate authority. Where the required approvals cannot be obtained, the engagement can proceed with code analysis and other non-intrusive assessment activities, while live testing remains out of scope.

Verbal assurances are not sufficient; all permissions must be documented in writing.

Yes. A pre-sale technical assessment provides an independent view of the software before a buyer begins due diligence. It identifies the same types of security, code-quality, scalability, and cost issues that may later be raised by a buyer’s technical adviser.

Undertaking the assessment early creates time to prioritise remediation, prepare evidence, and address material findings before they affect negotiations. This can help reduce transaction risk, support a more efficient diligence process, and protect value at sale.

Yes. A pre-sale technical assessment provides an independent view of the software before a buyer begins due diligence. It identifies the same types of security, code-quality, scalability, and cost issues that may later be raised by a buyer’s technical adviser.

Undertaking the assessment early creates time to prioritise remediation, prepare evidence, and address material findings before they affect negotiations. This can help reduce transaction risk, support a more efficient diligence process, and protect value at sale.

Yes. We support liquidators, administrators, and their advisers where the value, condition, and continuity of a software business must be assessed quickly.

Our reviews provide an independent view of the codebase, including its likely operational viability, material technical risks, the effort and cost required to maintain it, and factors relevant to a sale or transfer. We can also support the transition process, helping incoming owners understand the software and maintain continuity of service where required.

Our reports are structured to provide clear, traceable evidence. Each finding is linked to the relevant file and code location, allowing the conclusion to be traced back to the underlying source material. The report also records the scope of the assessment, the method applied, and the basis for each conclusion.

This documentation can support scrutiny in a dispute, regulatory review, or formal investigation. We have delivered technical assessment work during active litigation at the request of the legal advisers involved.

Yes. The assessment can provide evidence relevant to cyber-insurance applications, renewals, and underwriting discussions, including information on security controls, vulnerabilities, technical risks, and remediation activity.

This enables one assessment to support both transaction due diligence and cyber-insurance requirements, reducing duplication and improving the consistency of information provided to advisers, insurers, and other stakeholders.

Fees are determined by the size, complexity, timeframe and scope of the software environment.

  • Core technical due-diligence assessment: Ranges between $60,000–$120,000
  • Extended assessment: Ranges between $120,000–$180,000, including regulatory review and a cyber-insurance evidence pack.
  • Ongoing quarterly monitoring: Approximately $8,000 per company per year, with a minimum portfolio of 10 companies.

Please note: A confirmed scope and fee proposal is provided before work commences.

Yes. Based in Melbourne, we support clients and transactions across the UK, United States, Europe, and Asia.

Our assessment model can be delivered remotely, subject to agreed security, access, and data-handling arrangements. This enables us to assess software environments regardless of where the business, codebase, or hosting infrastructure is located.

Download the Guide and Due-Diligence Checklist

Access a print-ready PDF version of the complete guide, designed for sharing with deal teams, investment committees, underwriters, legal advisers, and board members. The download also includes a practical due-diligence checklist template to support internal review and transaction planning.

talk to our teamCall 1300 840 340