IT Projects & Technical Due Diligence
Technical due diligence needs a defined decision question and system boundary before any checklist is applied. The examination identifies the product, repositories, environments, dependencies, operating model and evidence classes that fall within scope, then relates observed technical risks to the depth of access and residual uncertainty.
Short answer
A broad request to 'review the technology' is not yet an examinable scope. The purpose may be to understand delivery risk, maintainability, security, scalability, dependency concentration or another technical decision factor.
Sampling can be appropriate when it is risk-based and transparent. The report should state which repositories, systems or artefacts were examined in depth and which remain outside the same level of review.
1. Clarify the examination purpose and technical decision question
The scope should follow the decision that needs technical support
A due-diligence review can focus on maintainability, delivery capability, scalability, security, software supply chain, operational resilience or technical debt. These objectives require different evidence and depth.
The report should avoid pretending to answer commercial, financial, tax or legal questions through technical evidence. Those disciplines may use the technical findings, but they apply their own criteria.
Priorities can be set before detailed review so that examination time is allocated to systems and risks most relevant to the decision.
2. Define product and system boundaries unambiguously
The technology under review may span more than one repository
The scope can include source repositories, mobile and web clients, APIs, data stores, cloud infrastructure, CI/CD, third-party services, identity systems and operational tooling. The relationship among these components should be mapped.
Version and environment matter. A codebase presented in a repository may differ from the productive artefact. Build, release and deployment evidence can therefore be part of the system boundary.
Acquired or externally operated services should be identified separately so that inaccessible provider internals are not silently treated as examined.
3. Define evidence classes and depth of access
Interviews and technical artefacts have different roles
Source code, repository history, build logs, SBOMs, deployment records, architecture documentation, monitoring, incident history and configuration exports can each support different aspects of the review.
Management or developer interviews can explain context and direct examination toward relevant systems. Statements from interviews should remain distinguishable from independently verified technical artefacts.
Read-only or sampled access can be sufficient for some questions, while others require controlled execution, build reproduction or configuration inspection. The report should describe the actual access depth.
4. Examine software supply chain and development practices
Delivery capability depends on more than source-code quality
Build reproducibility, dependency management, provenance, secrets handling, code review, CI/CD controls and release processes can materially affect maintainability and security.
NIST SSDF and SLSA can structure the examination of secure development and provenance without turning the due-diligence result into a formal compliance certification.
OWASP SAMM can provide a structured view of software-security practices. Its use should be stated as a reference model rather than as automatic evidence of maturity.
5. Integrate architecture, operations and security risks
Risks should connect technical conditions to plausible impact
Architecture concentration, unsupported dependencies, fragile deployment paths, missing recovery capability, weak access controls or poor observability can create different kinds of operational and security risk.
The assessment should distinguish observed fact from risk interpretation. A single database, for example, is a fact; whether it represents unacceptable concentration depends on redundancy, recovery design, workload and required availability.
Where safe and proportionate, controlled tests can turn abstract risk assumptions into observable evidence. Otherwise, existing incidents, monitoring and staging evidence can support the analysis.
6. Make examination depth and residual uncertainty transparent
Evidence gaps can themselves be material findings
When critical releases, data provenance or permission models can only be explained orally and are not supported by technical artefacts, the evidence gap should be reported separately. It is not automatically a defect, but it limits confidence.
Sampling should be explicit. If three of twelve repositories receive deep review because they control authentication, billing and deployment, the remaining repositories should not be described as if they received the same examination.
The final due-diligence conclusion states what was examined, what risks were supported, what was sampled and which uncertainties remain. It does not make an investment or acquisition decision.
Is the technical due-diligence scope aligned with the decision question and available evidence?
- Is the technical decision question defined before detailed review?
- Are product, repository, infrastructure and external-service boundaries mapped?
- Is the relevant version or productive state identified?
- Are evidence classes and access depth documented?
- Are interviews distinguished from independently verified technical artefacts?
- Are software-supply-chain, architecture, operations and security risks considered where relevant?
- Is sampling risk-based and transparent?
- Are evidence gaps and unexamined systems carried into the residual uncertainty?
Constructed example
A software platform contains twelve repositories. The review selects three for deeper examination because they control authentication, billing and deployment. Build and release evidence for those repositories is examined in detail, while the remaining repositories receive a higher-level dependency and activity review.
The report describes this sampling explicitly and does not generalise every detailed code finding across the whole platform. The result supports a bounded technical risk assessment rather than a blanket statement that the entire technology stack has been fully examined.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- NIST guidance NIST SP 800-218, Secure Software Development Framework Version 1.1, used as a structured reference for secure software-development practices. Open source.
- Technical specification SLSA v1.2, used for software-supply-chain provenance and integrity concepts. Open source.
- Technical security framework OWASP SAMM v2, used for structured consideration of software-security practices. Open source.
- Author methodology Sources and Methodology of the German knowledge base. Open source.
Further reading
- Reconstructing Architecture Decisions and Technical Risks
- Reconstructing Test, QA and Release Evidence
- Reconstructing the History of an IT Project
- Reconstructing Project Documentation and Decision History
Critical review and methodological limitation
Technical due diligence is inherently scope-dependent. The absence of a finding in sampled systems does not establish the absence of the issue elsewhere, and limited access can materially constrain the strength of conclusions.
Reference frameworks can structure the examination but do not substitute for system-specific evidence or automatically create a compliance or maturity certification.
- Scope: the system boundary and decision question determine what can be concluded.
- Evidence depth: interviews, documents and technical artefacts should remain distinguishable.
- Sampling: risk-based selection must be visible so results are not over-generalised.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Project Assessments & Project Reconstruction
Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.
Explore this assessment service