Technology due diligence in 90 minutes

Technology due diligence has a reputation for being either superficial or impossibly deep. The superficial version produces a PowerPoint with traffic lights and no financial translation. The deep version takes three months, misses the deal window, and buries the board in technical findings they cannot act on.

Neither serves the deal team. What a PE partner or board member actually needs is a structured assessment across the domains that matter, with findings mapped to financial impact, in a format that informs both valuation and integration planning. That is achievable in 90 minutes of structured engagement with the target, if you know what to look for.

This article is about the thinking behind that assessment, not the tool. The tool (available here) gives you the scorecard. This explains what the scores mean and why those questions were chosen.

Start before you engage the target

Before the first meeting with the target, a technology diligence team should have already run an independent public scan. This is not about distrust. It is about having an evidence base that is not filtered through the target's own framing.

The public scan covers three areas. First, breach and incident history: news articles, regulatory disclosures, and industry breach trackers will surface any public incidents, the size of disclosed impact, and critically, the detection-to-disclosure timeline. A long gap between occurrence and disclosure is a more meaningful signal than the incident itself.

Second, external attack surface: tools that scan internet-facing infrastructure will reveal exposed services, certificate and TLS configuration quality, email domain protections (SPF, DKIM, and DMARC alignment), and any staging or test environments that are publicly accessible. These are visible to any attacker and take minutes to check.

Third, engineering culture signals: public code repositories, job postings, and professional network profiles tell you whether security appears as a hiring priority, whether the organisation employs dedicated security leadership, and sometimes, through inadvertent credential or secret exposure in public repositories, exactly how seriously they take operational hygiene.

None of this replaces the direct engagement. But it arms you with questions the target cannot anticipate, and gives you independent verification of claims they will make about their compliance status and security posture.

The first question: what kind of deal is this?

Before any domain assessment begins, one question shapes everything else: what is the intended integration style? The three patterns are distinct:

• Absorption: the target's systems and processes are migrated onto the acquirer's estate. Speed of integration matters most. Technical debt in the target becomes your cost to remediate. ERP fragmentation, legacy infrastructure, and undocumented integrations all have direct cost implications.
• Stand-alone: the target continues to operate independently post-close. Technical debt is a run-rate risk, not an integration cost. The key concern shifts to: can this estate operate without the acquirer's support for the foreseeable future?
• Best-of-breed: selected capabilities from the target are adopted by the acquirer. The scope of diligence narrows to the specific systems being absorbed. Everything else can be assessed at lower depth.

This question is often not answered cleanly before due diligence begins, but the CTO should push for an answer early. Doing absorption-depth diligence on a stand-alone deal wastes time and creates findings that are not decision-relevant. Doing stand-alone-depth diligence on an absorption deal misses the integration cost picture entirely.

The non-negotiables: Day 1 controls

Every technology estate has debt. That is not disqualifying. What matters is whether certain baseline controls are in place before a deal closes, and whether the absence of any of them creates an exposure that cannot be accepted.

The controls that consistently produce the most material findings fall into four clusters. Identity and access management: whether MFA is enforced across critical applications, whether privileged access is governed, and whether deprovisioning happens reliably and quickly when people leave. Incident response: whether a plan exists, has been tested, and whether the organisation knows how long it takes to contain a critical incident. Endpoint protection: whether company-managed devices have consistent endpoint detection and response coverage, with no known unmonitored gaps. And third-party risk: whether high-risk suppliers have been assessed and are being actively monitored.

These four clusters are non-negotiable because they represent the controls that determine whether a post-close security incident is contained quickly or escalates. An acquirer that integrates a target with gaps in any of them inherits those gaps immediately.

The assessment question for each is not "does a policy exist?" but "is it operating at a measurable level of performance?" A policy for incident response that has never been tested is not evidence of capability. An MFA policy with 60% coverage is not evidence of protection.

The financial translation

This is where most technology diligence reports fail. They produce accurate findings but leave the financial translation to someone else, usually someone who does not have the technical context to do it well.

Technology findings translate into four financial outcomes. Understanding which bucket a finding belongs to determines how it affects valuation, purchase agreement terms, and integration planning.

The practical discipline here is to write each material finding in a two-line format. First line: the finding in plain language. Second line: the financial translation and which bucket it belongs to. If you cannot write the second line, the finding is not ready for the deal team.

A fragmented ERP landscape following a prior acquisition that was never integrated is a classic example. The finding is straightforward. The financial translation is specific: a contract cancellation fee, an estimate of the FTE time required for integration, and an assessment of the operational complexity during the transition period. That is the version the board can act on.

IP assignment is a deal term finding, not a financial one. If employment agreements do not explicitly assign IP developed by employees to the company, the seller must remedy this before the deal can proceed. No financial model adjustment resolves it. That distinction matters for how the finding is escalated.

The workforce risk you are most likely to miss

Of all the domains in a technology diligence, workforce risk is the one most likely to be underestimated. It is the domain where the numbers look fine on paper and the post-close reality turns out to be entirely different.

There are three specific risks worth examining carefully. Key-person concentration: whether there are individuals whose departure would cause critical operational or delivery risk, and whether the organisation has identified and documented this. The follow-up question is not whether those people intend to stay, it is whether their knowledge has been transferred to others. Intention does not constitute mitigation.

Contractor dependency: a high ratio of contractors to permanent staff is not inherently a problem, but it needs to be understood. Contractors do not transfer with the deal in the same way permanent staff do. If a material portion of engineering capacity sits with contractors whose engagement agreements expire around the close date, that is a workforce continuity risk that should be in the assessment.

Skills gaps relative to the roadmap: this is the most common gap in technology diligence. The question is not whether the team is capable of running the current product, it is whether the team is capable of delivering the next 12 months of what the deal thesis assumes will be built. If the deal thesis assumes a product expansion that requires capabilities the current team does not have, the hiring plan and its cost need to be in the financial model before close.

Legal protections are also frequently incomplete in targets that have grown quickly. IP assignment agreements, non-solicitation clauses, and confidentiality agreements are standard practice but not universal. Checking them is a five-minute exercise with significant consequences if the answer is no.

The 90-minute sequence

Given a single structured session with the target's CTO or senior engineer, this is the order in which to work through the domains.

Infrastructure and security go first because they surface the findings that could block the deal entirely. A critical security gap or a material undisclosed incident is a deal stopper or at minimum a deal-term issue, and discovering it late wastes everyone's time.

Engineering and technical debt come second because they produce the integration cost estimates. The financial model cannot be finalised without these. If the target is running three ERP systems from prior acquisitions that were never integrated, that needs to be in the model before any valuation discussion.

AI and data readiness, and vendor risk, come third. These are increasingly material to deal value, particularly for targets whose deal thesis involves data assets or AI capability. Vendor risk, specifically change-of-control clauses in critical contracts, can introduce deal timeline risk that affects the close date.

Team is last in the session but first in importance for post-close performance. It goes last because it requires candour from the target, and candour is easier to achieve once the session has established a constructive working relationship through the earlier domains.

Writing the one-pager

The output of technology due diligence is not a detailed technical report. It is a one-page summary that answers four questions for the deal team and the board:

• What is the overall risk rating for each domain, and what does it mean for the deal?
• What are the material findings, their financial translation, and which bucket do they belong to?
• What must be resolved before close, and what can be deferred to the integration plan?
• What assumptions in the current financial model need to be revised?

Everything else goes in an appendix. The board does not need the detail. It needs the decision-relevant summary. The CTO's job is to produce that summary, not to demonstrate the depth of the technical analysis.

One practical note on timeline: 90 minutes is achievable for an initial assessment. It is not achievable for a complete assessment of a complex enterprise estate. What 90 minutes buys you is enough signal to identify the material risks, score each domain directionally, and produce a summary that is fit for the deal team. For a large enterprise target, some domains will require follow-up sessions or third-party specialist input, particularly around cloud security configuration and data compliance. The one-pager should note which domains have been assessed with confidence and which have open items requiring further investigation.

The scorecard exists to force structure on what is otherwise an unstructured conversation. It does not replace judgment. A target that scores 4.2 overall but has a single Red finding on incident response is not a 4.2 target. The overall score is a navigation aid. The findings are the substance.