Due diligence is a purposeful investigation before a significant decision, such as acquiring a company or choosing a technology. Its first question is not “What is wrong?” but “Will this meet the intended need?” Like a home inspection, it should reveal potential surprises before the buyer takes responsibility for them. section 14.5 section 14.5.1
Agree on what the purchase is meant to achieve before investigating it. A buyer interested in gaming would examine a TV differently from one interested in news and streaming; a company transaction likewise needs questions shaped by the buyer’s plans. Generic questionnaires can miss the reasons behind a decision. section 14.5
For a technology review, use a focused conversation rather than an interrogation:
- Research the organization and its technology in advance. Bring questions about whether it can serve the intended operational need, not just a standard spreadsheet. section 14.5.1
- Ask how people communicate, manage tasks, develop and release code, and run the system’s major components. Keep a short topic checklist to catch gaps, without imposing a fixed question order. section 14.5.2
- Separate consequential problems from different but workable choices. Consider what the acquiring team would have to address—and what useful practices it could adopt—after the transaction. section 14.5.1
- Where source-code ownership matters, check code provenance and open-source licensing. Unregistered copied code can put a transaction at risk; a claim that no open source is used may also warrant closer inquiry. section 8.7.4
Turn a technical finding into a decision
“The main database has no active standby and has a public IP address” identifies a configuration. A useful finding also states the consequence: a failure could stop the business for days, and maintaining continuity would require an investment. Put the technical evidence in supporting documentation so decision-makers can assess the risk. section 14.5.3
Report what was examined, when and with whom, what was unavailable, and the findings. Order concerns by severity of consequence and list strengths separately. Write for nontechnical readers, distinguish factual risk from personal preference, and, where time allows, ask the people interviewed to check the report for accuracy before it is presented. section 14.5.3
If your organization is being evaluated, prepare the records you already need to run it: architecture and network diagrams, technologies and versions, licenses and costs, an organizational chart, onboarding information, recent support issues, and development priorities. Give an honest account without disclosing protected information indiscriminately; agree on disclosure boundaries with the CEO and, if needed, HR. section 14.5.4
