Before a purchase, an investment or a succession, the question is what the software really carries. Technical due diligence answers it with evidence rather than impressions. This article shows what gets examined, which findings move the price and how it differs from a system audit.
A technical due diligence examines someone else's system on behalf of the party that wants to buy into it. It does not describe how the system was meant to be, but what is actually there. The report has to stand up in a negotiation, so on every point the evidence counts and not the impression.
Six areas get examined:
In almost every engagement the same question comes first: what is actually in there? A software bill of materials, or SBOM, answers it. It lists the components used, with version and licence. The German Federal Office for Information Security describes in its technical guideline TR-03183-2 how such a list should be built, and names the SPDX and CycloneDX formats for it. The guideline is explicitly guidance without binding character, but it gives a usable benchmark.
Where the list is missing, more than a document is missing. Without it you can say neither which known vulnerabilities sit in the product nor which licence obligations attach to it. Both are a matter of days rather than months. A seller who cannot produce the list negotiates from a weaker position from that point on.
The licence side has a benchmark of its own. ISO/IEC 5230 describes what an open source licence compliance programme looks like. ISO/IEC 18974 is the counterpart for the security side. Both come out of the OpenChain project of the Linux Foundation, which has worked on this question since 2016. Anyone who can produce neither does not yet have a problem, but also has no evidence.
Not every finding changes a valuation. A finding becomes price relevant when it costs money after the handover, when a deadline hangs on it, or when it makes a later sale harder. Four patterns come up again and again.
The Cyber Resilience Act entered into force on 10 December 2024. The reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, the full manufacturer obligations from 11 December 2027. It covers products with digital elements, which includes software on its own. Non-commercial open source products are exempt. Whoever buys a product buys these obligations with it. Article 64 of the regulation provides for administrative fines of up to 15 million euros or 2.5 per cent of worldwide annual turnover for breaches of the essential requirements, whichever is higher.
That is no reason for alarm, but it is a reason to do the arithmetic. A product without a component list, without orderly vulnerability handling and without a reporting path needs work before the end of 2027. That work belongs in the valuation, not in the period after signing.
Where the product is aimed at consumers, the German Accessibility Strengthening Act applies on top. It has been in force since 28 June 2025 and covers software, e-books and electronic commerce among other things. The exemption for microenterprises applies only to services and not to products. Microenterprises here means fewer than ten staff and at most two million euros in annual turnover or annual balance sheet total. Breaches of the accessibility requirements can be fined up to 100,000 euros under section 37. Existing service contracts have a transition period until 27 June 2030.
In practice this is a frequent finding. An application meant for consumers that does not meet the requirements carries a known volume of retrofit work. A known volume can be costed, and therefore negotiated.
A third-party component under a strong copyleft licence can, depending on how it is integrated, extend obligations to your own source code. Whether that is the case in a given instance follows from the licence text and from the way it is integrated. That is exactly why the licence review belongs at the start. The finding itself costs nothing, the rework afterwards does.
A system that only runs at one provider is more expensive to operate and harder to sell on. The Data Act of the European Union has applied since 12 September 2025 and sets the framework for customers to switch between providers of data processing services. That makes the move easier. It does not remove it. Whoever discovers the dependency only after the purchase pays for it twice.
Where a service provider processes personal data on instruction, Article 28 GDPR requires a contract in writing or in electronic form with a fixed content: subject matter and duration, nature and purpose of the processing, the categories of data and data subjects, and the obligations of the processor. Sub-processors may only be engaged with permission and have to take on the same obligations. A missing link in that chain is not a technical finding, but it is one that belongs in the negotiation.
Technical due diligence sits in our Analysis group, next to the system audit. Both look at systems. But they have different addressees, and everything else follows from that.
Confusing the two gets you either a plan nobody needs or a report that does not carry in the negotiation. How an audit runs in detail is set out in System audit: process, duration and cost.
Scope drives effort, so the boundary comes first. After that we review documentation, the environment and, as far as access allows, the source code. We speak with the people who run and develop the system. Every finding is ordered by impact and effort, with a note on what it would cost in the event of a takeover. The price for the review is fixed before we start.
Where the review also touches how exposed the system is from outside, we mark out where a dedicated penetration test would need to go deeper. A due diligence reads and assesses. It does not attack.
We do not only review for others. ORDO acquires, develops and operates companies and digital products itself. So we look at someone else's system with one simple question: would we want to run it. What we have learned from that is set out in the Portfolio.
A technical due diligence replaces neither the commercial nor the legal review. It supplies the technical part, and it supplies it with evidence. Whoever reviews early negotiates about figures instead of impressions. The further positions, from analysis through to operations, are set out openly on the Services page. If a transaction is coming up, a short first call is enough.
A reply within two working days, with a concrete scoping proposal.