Technical Due Diligence: Evidence Collection and Decision Handoff

Run a scoped technical assessment with authorized access, reproducible evidence, contextual risk findings, unit-correct remediation estimates and a clear decision...

trigger="An acquisition, investment or partnership decision depends on understanding a bounded technology asset and its operating risks." owner="The diligence lead owns technical findings; the deal sponsor owns the transaction decision with legal, finance and security specialists." participants={["Diligence lead", "Target technical owner", "Deal sponsor", "Legal/IP counsel", "Finance lead", "Security and data owners"]} prerequisites={["Written assessment scope and decision questions", "Authorized access and information-handling rules", "A system and evidence inventory", "Named technical contacts and escalation channels"]} outputs={["An evidence register with limitations", "Contextual technical findings and rebuttals", "Remediation scenarios with explicit units", "A decision handoff and separately authorized integration backlog"]} doneWhen={["Material conclusions link to inspected evidence", "Unknowns are visible rather than treated as passed checks", "Legal and financial interpretations are routed to qualified owners", "Access is closed and the sponsor accepts the residual uncertainty"]} />

Assess the asset against the reason for the deal

Technical diligence is a bounded investigation, not a certificate that a company is safe to buy. Begin with the transaction thesis. An asset intended to run independently raises different questions from a product that must integrate with an acquirer's identity and data systems.

This playbook owns the working sequence: access, sampling, findings, estimates and handoff. It does not prescribe valuation adjustments or a universal architecture score. A modular monolith, shared database or single-region design can be appropriate when it demonstrably meets the required isolation, load and recovery objectives.

The sponsor should state what could change the decision: inability to operate the product, unclear rights to critical code, a mandatory integration that cannot be delivered, or a material unresolved security exposure. Those questions guide the evidence request.

1. Agree access, scope and prohibited actions

The diligence lead and target owner document repositories, environments, accounts, data classes and time periods in scope. Default to read-only evidence collection. A request for technical assessment does not authorize penetration testing, production load, credential verification against live services or a configuration change.

| Control | Agree before access | Evidence to retain | |---|---|---| | Authorization | Permitted systems, reviewers, tools and actions | Scope approval and access expiry | | Confidentiality | Approved storage, recipients and redaction | Handling plan and restricted evidence index | | Testing | Non-production environment and allowed techniques | Test plan and target-owner acceptance | | Escalation | How to report active compromise or exposed secrets | Named security contact and secure channel | | Closure | Revocation, retention and deletion responsibilities | Access closeout and retained-record policy |

Do not upload private code, logs, customer records or contracts to external analysis tools without explicit authorization. Review tool data retention and processing terms through the applicable owners. Avoid collecting personal employee data that is unnecessary for the technical question.

Gate: the reviewer can explain which actions are allowed. If access is denied or delayed, record the limitation and its decision impact; do not infer deception or incompetence from the absence of a document.

2. Build the evidence register and sampling plan

Request the system inventory, architecture and data flows, build/release configuration, incident history, recovery evidence, dependency inventory and material supplier agreements. Tailor the request to the asset and decision rather than demanding every document on a generic checklist.

Evidence register
  Evidence ID / question answered:
  System, environment and version:
  Source owner and collection date:
  Document, revision or restricted location:
  Observed directly / supplied assertion / reproduced test:
  Sample boundaries and exclusions:
  Contradictory evidence or missing information:
  Reviewer notes and confidence:
  Handling restrictions and retention:

Use risk-based samples. Trace a critical user journey, a recent production change, an incident, a recovery exercise and a privileged administrative action. Sample across service boundaries and historical data, not only the newest repository.

A walkthrough demonstrates what the presenter showed. A current configuration export demonstrates a particular state. A successfully reproduced test provides different evidence again. Preserve these distinctions rather than treating all three as independent confirmation.

Gate: every material question has a planned evidence source or an explicitly unresolved gap.

Keep an evidence request small enough to answer

The diligence lead groups requests by decision consequence and assigns a target owner to each group. Start with the product boundary, the authoritative repositories and data stores, the supported release path, and the evidence for restoring the service. These establish which asset is being assessed. Defer low-consequence formatting and documentation gaps until the critical questions have an answer or a recorded limitation.

Use the following request record to prevent a data room from becoming an unstructured file collection. “Received” and “reviewed” are different states, and neither means that the supplied assertion has been verified.

| Request field | What the lead records | | --- | --- | | Decision affected | Operate independently, integrate identity, support a market, or meet a recovery requirement | | Evidence requested | Exact environment, revision, period, and artifact needed | | Named provider | Target owner able to explain the evidence | | Handling boundary | Approved reviewers, storage, redaction, and expiry | | Review result | Inspected, reproduced, contradicted, unavailable, or out of scope | | Decision consequence | Which conclusion remains conditional and who accepts it |

Prefer reproducible redacted evidence over unnecessary production access. For example, a target operator can demonstrate a release from a named revision in an approved environment while the reviewer observes logs and artifact identity. Record whether the environment represents production and what was deliberately excluded. A prepared demonstration has value, but it does not prove that every release follows that path.

Check freshness against the change history. A restore test from before a database migration may no longer answer the current recovery question. Ask for a repeat or narrow the conclusion to the tested version. Do not replace the missing current evidence with an arbitrary confidence score.

3. Follow a transaction from identity to recovery

The technical reviewer traces one representative workflow through authentication, authorization, application logic, persistence, external services and operational telemetry. Identify the authoritative data source and the effect of retries, failures and cancellations.

| Area | Operational question | Useful evidence | |---|---|---| | Product behavior | Does the system perform the required transaction and reject prohibited actions? | Reproduced workflow and negative tests | | Delivery | Can an identified revision be built and deployed through the supported path? | Build provenance, release record and rollback rehearsal | | Data | Can the team restore usable records and reconcile subsequent changes? | Restore results, recovery objectives and consistency checks | | Scale | Has the expected workload been tested with realistic data? | Dated workload model, test conditions and bottlenecks | | Security | Are material threats controlled within the actual boundary? | Threat model, scoped findings, remediation and verification | | Operation | Can more than one authorized person operate critical tasks? | An independent runbook exercise and access review |

A backup job succeeding is not a restore test. A penetration report covers its tested scope and date, not every later release. A certificate or assurance report needs its covered entity, services, period, exclusions and exceptions reviewed by the appropriate specialist.

NIST SSDF supplies a vocabulary for examining software-development practices and supplier discussions. It is not a transaction approval or a substitute for evidence that the practices operate in this system.

The target operator, not the diligence reviewer, owns any authorized restore or release exercise. Before it begins, confirm the isolated destination, synthetic or approved data, test credentials, and stop conditions. Identify who can restore the prior test environment if the procedure fails. A request to inspect recovery does not authorize overwriting production or restoring customer data into an unapproved account.

Record the source backup or artifact identity, required keys, dependency access, elapsed stages, integrity checks, and the user operation completed after recovery. Stop if the exercise requires access outside the agreed boundary. The output should identify the demonstrated recovery scope and remaining dependencies, including secrets, identity, external integrations, and data created after the recovery point.

4. Evaluate maintainability and knowledge concentration

The engineering reviewer inspects code near critical behavior and active change boundaries. Use test, complexity and dependency reports to select samples, then inspect the underlying behavior. There is no universal line-coverage percentage that makes an asset maintainable.

Interview people about a recent change or incident rather than asking them to rate the culture. Request a demonstration of how another operator deploys, restores or diagnoses a critical service. Commit counts identify contributors, not the number of people who can safely operate the system.

Use service-level delivery trends in context. DORA's current guide cautions against disparate comparisons and focuses on improvement within an application or service. Do not turn benchmark tiers into a personnel ranking or automatic deal deduction.

A team structure, technology age or missing metric should produce a question, not a verdict. For example, an unsupported runtime is a support and remediation question; its cost depends on compatibility, deployment constraints and the demonstrated upgrade path.

Gate: findings describe a consequence and supporting evidence rather than a disliked architecture label.

5. Route licensing and ownership questions to counsel

The technical reviewer identifies components, versions, modifications, build inputs and how software is used, combined, distributed or exposed over a network. Counsel determines obligations and transaction consequences in the relevant jurisdictions.

The GNU license FAQ distinguishes private use from distribution and permits commercial activity under the license terms. GPL software in a commercial environment does not automatically require publishing every product's source. The covered work, version, distribution method and combination with other code matter.

AGPL version 3 section 13 adds a source-offer condition for users interacting remotely with a modified version of the program. Do not reduce that to “any network use opens the entire stack.” Counsel must examine the actual implementation and license obligations.

Permissive does not mean obligation-free. Apache License 2.0 includes redistribution conditions, notice requirements and patent provisions. LGPL, dual-licensed and source-available components require their own review; a scanner's label is only an input.

License/IP question record
  Component and exact version:
  Source, license text and applicable exception:
  Modified, linked, embedded, redistributed or network-exposed:
  Product artifact and distribution path:
  Notices, corresponding-source mechanism or commercial entitlement:
  Contributor/contract evidence available:
  Unresolved question for counsel:
  Counsel owner, response and follow-up:

Collect relevant employment, contractor and supplier agreements through authorized channels. Do not declare ownership proven or defective from a missing file alone. Counsel assesses chain of title, applicable law, rights granted and evidence still needed.

6. Write findings that survive challenge

The diligence lead separates confirmed issues, plausible risks and unknowns. Let the target owner correct factual errors and supply missing context without removing the original evidence trail.

"type": "flow", "title": "A diligence conclusion needs an evidence trail", "steps": [ ], "caption": "Missing evidence remains an explicit unknown. A technical finding informs the sponsor's decision; it does not determine price or legal liability." }} />

A usable finding states:

• The affected system, version and business requirement.
• What was observed, where and when.
• The consequence if the condition persists.
• Evidence confidence, coverage and competing explanations.
• Feasible remediation or containment options.
• Dependencies, estimate range, decision owner and unresolved questions.

Do not average an untested restore process away with high scores for observability or modern technology. Material constraints should stay individually visible. Likewise, “no issue found in the sample” is not equivalent to “no issue exists.”

Worked finding: a backup exists, but recovery remains unproven

Consider an illustrative assessment in which the target supplies successful backup-job records but cannot supply a restore result for the current database version. The supported conclusion is “current recovery has not been demonstrated within the reviewed evidence.” It is not “backups are broken” or “the product will lose all data.” Those stronger claims require different evidence.

The reviewer links the backup records, system version, stated recovery requirement, and unanswered request. The potential consequence is an unverified ability to resume the required workflow after data loss. The target might then provide a successful rehearsal, explain that another team owns restoration, or identify a missing encryption-key dependency. Preserve the initial question and the response so the sponsor can see how the finding changed.

The remediation option is an authorized recovery exercise with integrity and business-operation checks, followed by repair of any observed gap. Engineering estimates the test and likely repair separately. The sponsor may request this evidence before deciding, accept the uncertainty with a named owner, or change the operating assumptions. No technical score should automatically set the transaction price.

7. Estimate remediation with consistent units

Finance validates rates, currency, cost treatment and the comparison period. Engineering estimates work, sequencing, verification and transition operation. Separate internal capacity allocation from incremental cash expenditure and speculative opportunity effects.

Illustrative arithmetic, not a deal estimate:

Four engineers
x 20% allocation
x $15,000 per engineer-month
x 8 quarters
x 3 months per quarter
= $288,000 of allocated labor cost

The example assumes the allocation and rate remain constant across 24 months. It excludes tooling, contractor expense, operating overlap and uncertainty unless added as explicit rows. The 20% allocation is an example, not a recommended staffing rule. An allocated labor cost is not automatically a purchase-price deduction.

Similarly, an illustrative $45,000 monthly saving multiplied by 24 months equals $1.08 million of undiscounted savings before implementation costs and other adjustments. That is not net present value. Any discounted cash-flow analysis needs finance-approved timing, rates, costs and assumptions.

Avoid blanket risk multipliers or severity-to-dollar tables. Ask which work must happen, who can do it and what can change the estimate. Keep uncertain scenarios separate when the evidence does not support a single number.

Gate: every material estimate is reproducible and labeled as observed, quoted or assumed. Only the qualified deal and finance owners determine how it affects commercial terms.

For each remediation scenario, separate discovery, implementation, compatibility work, migration, verification, and overlapping operation. Name the dependency that can change each estimate. An unsupported runtime upgrade, for example, may require replacing a library, rebuilding an image, updating deployment automation, and rehearsing recovery. Counting only the source-code change understates the work needed to operate the upgraded service.

The engineering lead records whether the work can happen alongside product delivery and whether the necessary operators are available. Finance then checks whether the rate represents salary allocation, fully loaded internal cost, an external quote, or incremental cash. Do not add those categories together if they describe the same labor. Present uncertain paths separately: a compatible upgrade and a failed compatibility test that requires a replacement are different scenarios, not a single precise estimate with a hidden multiplier.

8. Handoff without starting integration prematurely

The sponsor receives material findings, unresolved questions, evidence limits and options: proceed with accepted risk, seek more evidence, require a condition, or reconsider the thesis. The technical reviewer does not automatically recommend walking away because a system is old or deducting a fixed percentage because of a score.

Create an integration backlog separately from the assessment. Record authority to act, service ownership, identity and data boundaries, vendor dependencies and recovery requirements. No pre-close account transfer, credential change or system connection should occur without authorization.

| Problem during assessment | Response | Safe continuation | |---|---|---| | Exposed credential or active compromise | Stop unsafe handling and notify the named security owner securely | Follow an authorized containment plan; do not test the credential casually | | Evidence conflicts | Preserve both sources and ask for version/context | Narrow the conclusion or reproduce the check | | Test affects a system unexpectedly | Stop the test and contact its owner | Owner-led recovery, incident record and revised test scope | | Critical access is unavailable | Record the unknown and decision impact | Request an alternative or have the sponsor accept the limitation | | A post-decision integration fails | Halt the separately authorized change | Use its compatibility, rollback and data-reconciliation plan |

Read-only diligence normally has no production rollback. Closeout still requires revoking temporary access, returning or deleting copies according to agreement, and recording what evidence remains authorized for retention.

9. Reconcile the final report with the evidence room

Before handoff, the diligence lead selects every material finding and follows its references back to an accessible artifact. Check that redaction has not removed the fact supporting the conclusion. Mark evidence that only a specialist can inspect, and identify that specialist's unresolved question without copying restricted material into the general report.

The target owner receives factual statements for correction within the agreed process. Record corrections, disagreements, and late evidence with dates. An unresolved disagreement should state both positions and what would distinguish them. Do not quietly delete a finding to produce an agreeable report, or preserve it unchanged after its factual basis has been disproved.

10. Obtain acceptance of the assessment boundary

The sponsor signs off the question coverage, material findings, and unresolved limitations. Legal, finance, and security owners accept their own interpretations or leave conditions open. Acceptance means the report answers the authorized assessment as far as the evidence permits; it does not approve an acquisition or certify the target's future operation.

The final handoff contains the scope, system/version inventory, evidence register, reproducible tests, finding responses, remediation scenarios, and access-closeout record. Give each remaining question an owner and decision deadline. If a separately authorized integration will follow, transfer only the approved evidence and requirements into its backlog, with its own change and recovery authority. Begin that next task from the demonstrated system state rather than from assumptions introduced during deal discussions.

Completion checklist and limits

"Scope, access, tool use and information handling were authorized", "Each material question has evidence or a visible limitation", "Samples include critical behavior, privileged actions and recovery", "Architecture findings are tied to requirements rather than labels", "License, ownership and compliance questions have specialist owners", "Cost examples use consistent periods and do not masquerade as valuation", "The target's factual responses and unresolved disagreements are retained", "The sponsor receives decision options and residual uncertainty", "Temporary access and evidence copies are closed under the agreed policy" ]} />

This is an engineering assessment method, not legal, investment or financial advice. It does not provide a comprehensive security audit or guarantee future performance. Before opening a data room, write the decision questions and the permitted evidence plan. Technology stack evaluation is the relevant technical service scope.