Technology due diligence checklist: assessing software, security and the team behind it

A technology due diligence checklist is the part of a deal review that looks at software, infrastructure, security and the engineering team. For technology companies it is often where the valuation is tested hardest: revenue can be verified from accounts, but whether the product can scale, whether the company actually owns its code, and whether a security incident is waiting to happen can only be found by looking.

What a technology due diligence checklist covers

• Architecture: how the system is built, its main dependencies, and known scaling limits.
• Code ownership: IP assignments from employees and contractors, and open-source licences in use.
• Code quality: test coverage, documentation, technical debt and how it is tracked.
• Infrastructure and hosting: providers, costs, redundancy and disaster recovery.
• Security: recent assessments, penetration tests, incidents, access controls and vulnerability management.
• Data: what personal data is held, where, under what legal basis, and how it is protected.
• Team: key people, knowledge concentration, hiring and retention risks.
• Roadmap: what is planned, what it depends on, and whether estimates have historically been met.

Run the review in stages

1. Start with documents: architecture diagrams, security reports, licence scans, infrastructure costs.
2. Hold structured interviews with the technical lead and key engineers.
3. Review a sample of the code and the deployment pipeline, directly or through an independent reviewer.
4. Check open-source licences against how the software is distributed — some licences impose obligations that matter commercially.
5. Verify security claims against evidence: test reports, incident logs, policy documents.
6. Summarise findings by severity and by what they mean for price, warranties or post-deal work.

Missing IP assignments from early contractors are the most common serious finding in software acquisitions. Ask for them first — they can take weeks to fix and occasionally cannot be fixed at all.

Security questions worth asking directly

• When was the last independent penetration test, and were critical findings fixed?
• Who has production access, and how is it granted and removed?
• Has there been a security incident or data breach, and how was it handled and reported?
• Which certifications or attestations are held, and what is their scope?
• How are secrets and credentials stored and rotated?

Keep findings in a register

Technology findings span many areas and many people, so track them as a register: one row per request or finding with area, severity, owner, status and evidence. Ettex Records holds that shape and lets the deal team see open items by severity at a glance. The same register becomes the post-deal integration plan, which is where most technology findings are ultimately resolved. It sits alongside the wider due diligence checklist and, for information security, an iso 27001 risk assessment where one exists.