One of the most common failures in M&A technology due diligence is inconsistency. Each engagement is approached differently, assessed by whoever is available, and reported in a format that reflects individual judgment rather than a repeatable methodology. The result is findings that cannot be compared across transactions, risk assessments that miss entire categories of exposure, and investment committees that cannot calibrate one TDD report against another.

A structured framework changes this. At VeryDiligent, we assess technical risk across four distinct layers — each one examining a different dimension of the target’s technology, each one informing and validating the others. Together, they produce a complete, consistent picture of what an acquirer is actually buying.

Here is how the model works.

Layer 1: Application Architecture and Technology Stack

The first layer examines the foundation of the platform — the architectural decisions, technology choices, and design principles that determine what the system can and cannot do.

This layer asks: is the platform built on sound structural foundations? Is the architecture extensible — capable of supporting new features, new markets, and new scale without fundamental re-engineering? Are the technology choices mainstream enough to support ongoing talent acquisition and vendor support? Are there architectural constraints that would make integration with an existing portfolio complex or expensive?

Key areas assessed at this layer include the overall architectural pattern (monolithic, microservices, event-driven), database design and data architecture, third-party integrations and API strategy, authentication and security architecture, and the identification of technical debt at the structural level.

This is the layer that most directly informs the acquirer’s integration planning and value creation thesis. Architectural constraints discovered here do not just flag risk — they reframe the assumptions underlying the deal.

Layer 2: Codebase Quality and Engineering Practices

The second layer goes inside the code itself — examining the quality, maintainability, and operational maturity of what has actually been built.

This is where the gap between appearance and reality is most commonly found. A platform can appear well-architected at the documentation level while the actual codebase tells a different story: years of accumulated shortcuts, inadequate test coverage, outdated dependencies, and business logic that is undocumented and understood by only one or two people.

Assessment at this layer uses a combination of automated analysis tools — open-source scanners, SAST/DAST tools, dependency review — and direct human review by experienced engineers. Automated tools surface metrics quickly: test coverage, code complexity, known vulnerability exposure in dependencies. Human review surfaces the judgment-intensive findings: the quality of the engineering decisions, the consistency of the standards applied, the maturity of the development processes.

Specific dimensions assessed include code readability and modularity, version control and CI/CD maturity, dependency management and compliance, quality assurance practices, and performance characteristics at the code level.

Security as a Cross-Layer Dimension

Security does not fit neatly into a single layer — which is precisely why it is so often assessed incompletely. At VeryDiligent, we treat security as a cross-cutting dimension that is examined at every layer of the model.

At Layer 1, we assess security architecture — authentication design, data isolation, encryption strategies, and compliance with applicable frameworks such as GDPR, HIPAA, or PCI DSS. At Layer 2, we examine security at the code level — identifying vulnerabilities through SAST/DAST scanning, assessing secure coding practices, and reviewing open source components for known CVEs. At Layer 3, we evaluate the security of the infrastructure itself — network exposure, access controls, patch management, and incident response capability. At Layer 4, we assess the human dimension of security — access governance, offboarding processes, and the security awareness culture within the engineering team.

Where a target cannot provide a recent penetration testing report from a trusted third party, we offer penetration testing as an additional service — actively testing the platform for exploitable vulnerabilities rather than relying solely on documentation and automated scanning.

The result is a security assessment that is integrated into the overall technical picture, not bolted on as an afterthought — giving acquirers a complete view of their security exposure before they commit.

AI Risk as an Emerging Fifth Dimension

As AI acquisitions become an increasing proportion of technology M&A deal flow, the four-layer model has been extended to address a category of risk that did not exist at meaningful scale in most acquisition targets five years ago.

AI-specific risk assessment examines four areas that sit across and beyond the standard four layers. First, model architecture and performance — distinguishing genuine proprietary AI capability from thin wrappers built on top of third-party foundation models, and independently evaluating whether performance claims hold up under realistic conditions. Second, training data provenance and compliance — assessing whether datasets were appropriately licensed, whether personal data was used with a valid legal basis, and whether the data reflects the real-world population the model will serve or embeds biases that create regulatory or reputational exposure. Third, AI regulatory compliance — evaluating the target’s posture against the EU AI Act and other applicable frameworks, particularly for high-risk AI systems. Fourth, AI talent concentration — mapping the distribution of model knowledge across the team and assessing the retention risk of the individuals on whom the AI capability depends.

For acquirers targeting AI businesses, this extended framework ensures that the specific risks of AI acquisitions are assessed with the same rigour as the underlying software platform.

Layer 3: Infrastructure and Operational Resilience

The third layer moves from the software itself to the environment in which it runs — examining how the platform is hosted, operated, and protected against failure.

This layer is frequently underweighted in informal technical assessments, and the consequences show up in post-close operational surprises. A platform that runs well under normal conditions may have no tested disaster recovery plan, no meaningful monitoring, and a deployment process that relies on manual steps prone to human error.

Assessment at this layer covers cloud hosting architecture and maturity, scalability and capacity planning, disaster recovery and backup posture, Infrastructure as Code adoption, regional resilience and failover capability, and the maturity of monitoring, alerting, and incident response processes.

For acquirers with operational continuity requirements — particularly in regulated sectors — this layer is often as important as the codebase assessment above it.

Layer 4: Engineering Organisation and Human Risk

The fourth layer examines the human dimension of the technology — the team, the processes, and the distribution of knowledge that determines whether the platform can be sustained, improved, and integrated post-close.

Technology does not maintain itself. The value of a software platform is inseparable from the people who built it and the processes that govern how it evolves. An assessment that ignores this layer is incomplete by definition.

Key areas assessed include engineering team structure, seniority distribution, and skillset coverage; the concentration of critical knowledge across team members; SDLC maturity and development process rigour; onboarding efficiency as a proxy for documentation and architectural clarity; and engineering team stability over the preceding 12 to 18 months.

This layer is where key person dependency risk is identified and quantified — one of the most commonly underestimated risks in technology acquisitions, and one of the most directly actionable through deal structuring.

How the Layers Work Together

The value of a four-layer model is not just in the comprehensiveness of each individual layer — it is in the relationships between them. Findings in one layer frequently illuminate or validate findings in another.

A clean architecture at Layer 1 that is undermined by poor engineering practices at Layer 2 tells a specific story: good design decisions, inconsistent execution. A strong codebase at Layer 2 running on fragile infrastructure at Layer 3 tells another: technical quality that is operationally exposed. An impressive engineering team at Layer 4 that cannot be retained post-close reframes the entire risk picture.

It is this cross-layer synthesis — not any individual finding in isolation — that produces the actionable risk picture an investment committee can use.

Consistent Assessment Across Every Transaction

Regardless of deal size or target complexity, every VeryDiligent engagement applies the same four-layer framework. The depth of assessment in each layer scales with the size and complexity of the target — but the structure remains constant.

That consistency is what makes findings comparable across transactions, risk scores meaningful over time, and investment committees confident that what they are reading reflects a rigorous, repeatable methodology rather than the judgment of whoever happened to conduct the review.

At VeryDiligent, our four-layer model has been refined across numerous technology due diligence engagements — calibrated against real-world findings to ensure that the most consequential risks are always assessed, and always reported in terms that inform commercial decisions.

Contact us today to discuss how our framework applies to your upcoming transaction.

Related reading: Our Framework for Technology Due Diligence Explained | How Technical Risk Impacts Valuation Multiples | The Hidden Technical Debt That Kills Post-Acquisition Value