Technical Due Diligence: From Evidence to Deal Questions

A scoped technical due diligence method with eight assessment dimensions, separate risk and confidence labels, an evidence register and a worked remediation planning...

Decision brief

Audience: technical leads supporting an acquisition, investment or integration assessment, alongside the deal sponsor, security, legal and finance specialists.

Decision: which technology assumptions are supported, which are contradicted, and which remain unknown before the authorized decision-maker accepts exposure.

Thesis: a useful technical assessment connects each material conclusion to reproducible evidence, its limitations and an accountable owner. A composite score or architecture label cannot replace that chain.

This paper supplies an eight-dimension assessment, an evidence register, a finding template and an illustrative remediation estimate. It does not report Ampity transactions, customer outcomes or deal adjustments. It is not a valuation model, legal opinion, security certification or authorization to access a target's systems.

The primary output is a decision packet. It should let a sponsor distinguish an observed defect from a missing artifact, understand what would change the conclusion, and assign follow-up work. An apparently precise number is less useful than a clearly bounded unknown when access is incomplete.

The technical due diligence playbook covers the day-to-day execution sequence and access closeout. This whitepaper addresses the harder interpretation questions: which evidence deserves weight, how the transaction thesis changes the required operating model, and where a technical finding ends and specialist judgment begins. Use the two together without turning either into an automatic deal recommendation.

1. Establish scope and authority before collecting evidence

Write down the transaction question. Acquiring a product for its technology, integrating a customer base and taking a minority investment can expose different risks. The technical review should serve that question, not become a generic repository inspection.

Agree the environments, repositories, subsidiaries, product versions and reporting period in scope. Identify excluded areas, contractual access restrictions and what can be reproduced. A screen-shared demonstration is not equivalent to direct read access, but it may be the only authorized evidence. Describe that limitation without implying concealment.

Specify which checks are read-only and which would change state or create load. Vulnerability scanning, restore tests, synthetic transactions and load tests require explicit approval, an isolated environment where appropriate, and a stop mechanism. Never infer permission to test production from permission to inspect a data room.

Protect the information collected. Use an approved evidence location, least-privilege access, retention limits and a process for deleting temporary copies. Do not place credentials, personal data or confidential source code into an unapproved analysis service. A useful report can cite a restricted artifact identifier without reproducing its sensitive contents.

Let the transaction thesis change the evidence request

A product that will continue independently needs a credible path to operating continuity: account control, people, supplier access, incident response, and recovery. A product that will be absorbed into another platform adds compatibility questions about identity, data meaning, APIs, and customer obligations. An acquisition of selected intellectual property may place more weight on demonstrable ownership, reproducible artifacts, and the dependencies required to use that property outside the target's environment.

The same observed condition can therefore lead to different questions. A custom identity service might be a manageable operating responsibility for an independent business, but a critical transition dependency if the sponsor assumes immediate federation. The reviewer should ask for a supported integration path and a rollback boundary, not deduct points because the technology differs from the acquirer's preferred stack.

Record the thesis as testable assumptions. “The receiving team can operate the product” becomes evidence requests for an independently executed release, incident investigation, and recovery exercise. “Customers can migrate without interruption” becomes questions about contract compatibility, data reconciliation, identity changes, and the meaning of interruption. The sponsor owns the commercial assumption; technical reviewers identify what the available evidence can and cannot support.

At the end of scoping, list which findings could change the thesis, which can change transition sequencing, and which belong in ordinary improvement work. This keeps a long inventory of low-impact defects from obscuring one dependency that makes the proposed operating model infeasible.

2. Keep risk separate from evidence confidence

Use one qualitative risk rubric throughout the assessment:

| Risk label | Meaning in this review | Decision implication | | --- | --- | --- | | Blocking condition | A stated mandatory condition is not met, or a decision-critical uncertainty cannot be accepted by the authorized owner | Resolve, narrow the scope, or obtain an explicit decision before proceeding | | Material exposure | A plausible failure could materially affect the scoped product or integration objective | Define mitigation, owner, effort assumptions and acceptance conditions | | Improvement opportunity | A change may reduce operating friction, but no material exposure is established | Prioritize with the normal delivery plan | | No material issue observed | The reviewed evidence did not reveal a material issue within the stated sample | Preserve sample and limitations; do not imply absence of all defects |

Separately label evidence confidence: reproduced, corroborated, asserted, or unknown. Reproduced means the reviewer observed a repeatable check in the recorded environment. Corroborated means multiple relevant artifacts support the assertion without reproducing it. Asserted means a responsible person or document makes the claim. Unknown means the available evidence cannot answer the question.

These labels are proposed reporting conventions, not validated industry scores. A serious risk can have low confidence and still warrant investigation. High-confidence evidence of a minor defect does not automatically make it a deal blocker. Do not average these categories into a valuation adjustment.

Test whether corroboration is genuinely independent

A slide deck, an interview, and a policy document may all repeat the same untested assertion. Counting them as three confirmations creates false confidence. Ask whether the artifacts arose from separate observations: a release record, its identified artifact, and runtime evidence can support a stronger claim when their identities and timestamps align. If all three were manually prepared for the review, say so.

Use rival explanations for consequential findings. A mismatch between an architecture diagram and a deployment inventory could indicate an outdated diagram, a temporary migration state, or an unknown production dependency. The next request should distinguish those explanations. Preserve the observed mismatch while avoiding a conclusion about intent or competence that the evidence does not establish.

Sampling also limits absence claims. A reviewed API path may reject another tenant's identifier while an export worker uses a different authorization implementation. Report the tested path and ask whether the other path shares its controls. Do not generalize a successful sample to every product boundary unless the evidence supports that extension.

The diligence lead should revisit confidence after significant late evidence. A reproduced test can reduce one uncertainty while exposing another, such as recovery succeeding only with access held by a departing employee. Keep separate findings when consequences and owners differ. A single reassuring summary label would conceal the operating dependency that still needs a decision.

3. Enumerate eight assessment dimensions

Use exactly these eight dimensions for the initial register. Add a clearly identified specialist workstream when the transaction requires it, rather than silently changing the denominator.

| Dimension | Core question | Example evidence | | --- | --- | --- | | 1. Product and architecture | Can the implementation support the capabilities and constraints assumed by the deal? | Critical-flow walkthrough, dependency map, architecture decisions | | 2. Code and delivery | Can authorized people change important behavior safely and repeatedly? | Reproduced build, sampled change history, behavioral tests, release evidence | | 3. Security and access | Are important trust boundaries and privileged actions understood and controlled? | Identity configuration, access review, threat model, remediation records | | 4. Data and information handling | Are ownership, lifecycle, integrity and permitted uses understood? | Data inventory, lineage, retention configuration, reconciliation tests | | 5. Reliability and recovery | Can the organization detect failure and recover within its stated requirements? | Incident records, restore evidence, dependency-failure exercises | | 6. Infrastructure and cost | Are operational dependencies, capacity and cost assumptions credible? | Resource inventory, invoices, utilization context, commitments | | 7. People and ownership | Is important knowledge accessible and responsibility sustainable? | Ownership map, support coverage, onboarding evidence, handover plan | | 8. Integration and transition | What must change after the decision, and what could interrupt the product? | Identity and data boundary plan, transition dependencies, exit criteria |

NIST's Cybersecurity Framework organizes cybersecurity risk management, while its Secure Software Development Framework describes software-development practices. They can structure selected questions, but neither framework turns this assessment into a certification or complete control test. NIST CSF and NIST SSDF 1.1.

4. Preserve the evidence-to-decision chain

5. Sample critical behavior, not just code metrics

Choose samples based on the scoped product's failure consequences. An authorization boundary, billing calculation, tenant export or recovery path may deserve deeper examination than a large low-risk utility package.

For each sample, record how it was selected and what it excludes. Trace one change from requirement to code, test, deployment and production observation. Reproduce a build from an identified revision in an authorized environment. Inspect dependency provenance and whether the deployment artifact corresponds to the reviewed source.

Coverage percentages show which code ran during a test suite, not whether assertions detect important failures. Complexity counts and file sizes can identify review candidates; they do not establish maintainability or justify a universal pass mark. Ask whether a critical defect could pass the existing suite and whether the team can demonstrate an appropriate negative test.

A missing test is a finding about evidence and risk, not necessarily evidence that the behavior is broken. Conversely, a passing test that mocks away the permission boundary may provide little assurance about that boundary. Keep the distinction visible in the report.

Trace the artifact as well as the code. Ask which source revision produced the running release, which build identity assembled it, where dependencies came from, and which actor could replace the artifact before deployment. SLSA v1.2 provenance describes information connecting artifacts to how they were produced. Provenance can support origin checks; it does not prove that the source is correct, that a credential is safe, or that the installed product matches every commercial promise.

The evidence request should name the actual build path. A repository may contain a clean pipeline while production images are built on an administrator's laptop. If the target cannot reproduce a release, record the exact missing input or dependency. The consequence may be inability to patch or redeploy after personnel change, rather than a general claim that all code is poor.

For an authorized reproduction, the target owner supplies an isolated environment, dependency access, and non-production configuration. Compare the resulting artifact through an agreed identity or reproducibility method and run a critical behavior test. A byte-for-byte match may be inappropriate for a build that intentionally embeds timestamps; explain the comparison instead of silently weakening it. Retain commands, versions, and exceptions so another reviewer can understand what the demonstration established.

6. Evaluate architecture against requirements

A shared tenant database is not inherently a red flag. Examine isolation controls, query authorization, operational access, noisy-neighbor behavior, backup scope and recovery requirements. Dedicated databases also introduce costs and management risks. Record why the current model does or does not meet the product's requirements.

A monolith is not automatically an integration liability. Inspect coupling, build reproducibility, change ownership, deployment failure modes and capacity. Stored procedures may centralize important transactional rules or hide poorly tested behavior. The assessment should identify which condition is observed.

Avoid prescribing service extraction before understanding dependencies. Options may include better module boundaries, tests around critical rules, incremental interfaces, targeted capacity changes or retaining the current design. Use the system architecture paper for design trade-offs; this document owns the evidence and transaction questions.

When an architecture diagram conflicts with runtime evidence, record the discrepancy and its consequences. Do not silently substitute the diagram for reality, and do not assume an outdated diagram means every implementation claim is wrong.

7. Separate security, legal and assurance questions

A SOC 2 report is an assurance report about specified controls at a service organization, not a regulation or a blanket certificate that a product is secure. Inspect the report's scope, period, exceptions and relevant customer responsibilities with a qualified reviewer. A report covering a vendor does not automatically cover the target's entire implementation. AICPA SOC resources.

Inventory software licenses, data sources, contributor agreements and customer commitments as technical evidence. Refer interpretation of ownership, licensing duties, patents, privacy obligations and contractual rights to appropriately qualified legal specialists. Repository access or a package name alone cannot establish an infringement conclusion.

Distinguish an observed configuration exposure from an untested exploit claim. Do not reproduce sensitive vulnerabilities in a broadly circulated executive summary. Link to a restricted finding and describe the business consequence at the minimum necessary level.

Security remediation estimates need a defined acceptance test. “Fix security” is not a schedulable task. “Remove an identified public access path, rotate the affected credentials under an approved procedure, and verify authorized workflows” is more concrete, while still requiring a security owner to approve scope and sequencing.

Operational and security consequences interact during transition. Removing an overprivileged account can break a deployment process that depends on it. Keeping the account indefinitely can preserve an unacceptable access path. The finding should therefore include the replacement operating method, temporary containment, approving owner, and verification that necessary releases still work after privilege removal.

Dependency inventories are useful inputs to this work. SPDX specifications provide a structured way to exchange software-component and related information. Record the inventory format version, creation method, covered artifact, and omissions. An SBOM for the source tree may omit a base image, dynamically downloaded package, or separately deployed service. A machine-readable license label does not settle the legal obligations of how a component is modified, combined, or distributed.

Ask the target to connect material dependencies to build and runtime evidence. Counsel reviews license and ownership questions; security reviews exposure and remediation; operations reviews replacement and recovery. Retain uncertainty when the installed version or distribution path cannot be established. Do not convert an incomplete inventory into either a clean bill of health or an infringement allegation.

8. Worked finding: recovery evidence is incomplete

Consider a constructed example. A target provides successful backup-job logs and states that the product can be recovered within its internal objective. No recent isolated restore exercise or business-level reconciliation is available to the review team.

The finding is not “backups fail.” It is: the stated recovery capability has not been demonstrated by the evidence made available. Confidence is asserted for the recovery claim and corroborated for backup-job execution. Risk depends on the deal's recovery requirement and what the sponsor can accept.

A proposed next step is an authorized restoration exercise using a representative backup, documented dependencies and isolated credentials. Acceptance includes application startup, sampled and aggregate business reconciliation, identified data-loss window and measured recovery steps. A successful infrastructure restore without a usable application does not close the question.

Record alternate outcomes in advance. If encryption keys are unavailable, stop and investigate key recovery. If an external dependency cannot be simulated, state the resulting limit. If the restored data differs from expected records, preserve evidence and escalate instead of adjusting the acceptance criteria after the test.

NIST SP 800-34 Rev. 1 addresses contingency planning, priorities, and relationships with other recovery plans. It is guidance for federal information systems, not a legal requirement imposed on every acquisition target. Its planning structure can help frame the exercise, while the actual product's approved recovery requirements determine the acceptance conditions.

Include the receiving operating model in the test. A restore that succeeds only with an undocumented key, personal account, or unavailable specialist may substantiate a technical recovery path while leaving continuity unresolved. Record that dependency, its transfer authority, and an alternative if transfer is not available. A transition plan should not assume every account, contract, or person will remain accessible.

9. Estimate remediation from tasks and assumptions

The following planning example is invented for the recovery finding above. Its effort values are placeholders that demonstrate a method, not a benchmark, price or forecast.

| Work package | Low assumption | Base assumption | High assumption | | --- | --- | --- | --- | | Prepare isolated environment | 1 engineer-day: templates already work | 2 engineer-days: minor access and configuration work | 4 engineer-days: missing dependency definitions | | Restore and reconcile | 1 engineer-day: documented path succeeds | 3 engineer-days: one issue requires investigation | 6 engineer-days: multiple failed attempts and repair | | Document and hand over | 1 engineer-day: existing runbook needs edits | 2 engineer-days: operator walkthrough and revisions | 3 engineer-days: additional ownership handover | | Illustrative total effort | 3 engineer-days | 7 engineer-days | 13 engineer-days |

Effort is not elapsed time. Access approval, vendor availability, shared environments and specialist review can extend the calendar without consuming continuous engineering work. Do not call the high scenario a confidence percentile unless the estimation method supports that interpretation.

Replace these placeholders with task owners' estimates after inspecting the environment. State exclusions, prerequisites, uncertainty and the evidence that would narrow the range. Finance may apply its own validated cost assumptions. Legal and deal specialists decide whether and how a finding affects transaction terms. This paper recommends no fixed discount, valuation band or compensation rate.

10. Reusable evidence register and finding template

An evidence register should contain an artifact identifier, custodian, creation date, reviewed revision, access method, confidentiality class, relevant finding and retention rule. Add a verification note that states exactly what the reviewer did. “Reviewed repository” is weaker than “reproduced build for revision X and inspected these three critical flows.”

For each finding, complete the following:

• Question and scope: the deal assumption being tested, system boundary and period.
• Observation: what was directly seen, with restricted evidence references.
• Assertion and inference: what others stated and what the reviewer concluded.
• Risk and confidence: separate labels using the defined rubric.
• Consequence: the plausible product, transition or operating impact.
• Options: retain, mitigate, investigate further or change the proposed integration.
• Acceptance test: evidence required to close or reduce the finding.
• Owner and due decision: accountable role, dependency and decision deadline.
• Limitations: excluded systems, samples, unresolved contradictions and access constraints.

Keep contrary evidence. A finding that changes after a demonstration should retain its earlier version and the reason for revision. This supports a defensible decision trail without implying that the first conclusion was a proven fact.

11. Build a transition plan that can survive contact with reality

Translate material findings into a dependency-aware transition plan. Separate urgent access continuity from architectural improvement. Changing identity, deployment infrastructure and data ownership simultaneously can make later failures difficult to attribute.

Before replacing a system, verify what must remain compatible: customer contracts, exports, historical records, support workflows and external integrations. Name the temporary coexistence cost and the owner who can end it. Decommissioning needs explicit retention and dependency checks, not just a target date.

Create handover evidence for critical operating work. Have an authorized receiving operator demonstrate the procedure with the current owner available. A document delivered to a data room does not prove the receiving organization can use it.

Review the plan with product and customer-support owners as well as engineering. A technically feasible migration may still be unacceptable during a contractual change freeze or high-demand period. Those constraints should change sequencing, not disappear from the technical summary.

12. Deliver a decision packet, not a scorecard alone

The executive packet should identify the scoped decision, the material exposures, the decision-critical unknowns, required specialist input and proposed conditions. Attach the evidence register, access limitations, remediation assumptions and transition dependencies.

Ask the sponsor to record which risks are accepted, by whom and under which assumptions. New evidence can invalidate an accepted assumption. Define a reopening trigger such as a failed restore rehearsal, newly discovered dependency or material scope change.

Do not describe the target as “technically approved” merely because all review sessions occurred. Completion of the review, resolution of findings and acceptance of risk are separate states. The same separation applies to this paper's editorial review and its withheld publication approval.

13. Assess supplier dependence and the cost of continuity

The infrastructure reviewer maps the services required to build, deploy, run, bill, support, and recover the product. Include source hosting, package registries, identity, messaging, observability, cloud accounts, payment processing, and domain control where they are material. Tie each dependency to a named account owner and the workflow that would fail if access disappeared.

Separate observed invoices from projected cost. A discounted bill may depend on commitments, credits, utilization, or an agreement that does not transfer automatically. Finance and counsel review those terms. Engineering supplies workload, capacity, storage growth, data-transfer assumptions, and the operating effect of losing the arrangement. Do not treat a temporary credit as the normal cost of running the product.

For each critical supplier, compare continued use, migration, and bounded coexistence. Continued use can reduce transition risk but preserve concentration and commercial exposure. Migration can change responsibilities while requiring data export, compatibility work, operational training, and an exit rehearsal. Coexistence can preserve continuity but introduces two billing and support paths until an owner closes it.

| Continuity question | Technical evidence | Specialist decision | | --- | --- | --- | | Can the product run under the receiving account structure? | Account, identity, quota, and dependency inventory | Transfer and contractual rights | | Can data leave the current service in a usable form? | Authorized export, format check, and representative import | Permitted use and retention | | Can the operating team replace an unavailable dependency? | Tested alternative or explicit manual procedure | Acceptable service impact and cost | | What changes the running-cost estimate? | Demand model, resource usage, and transition overlap | Financial assumptions and commercial treatment |

The output is a continuity dependency register with an owner, evidence, open term, fallback, and decision date. A supplier's prominence or popularity is not evidence that the target can transfer its account or recover its data under the proposed transaction.

14. Evaluate data usefulness as well as data possession

A deal thesis may assume that customer records, product catalogs, historical events, or model-training data can support a new product. The technical reviewer first asks what the datasets represent, which system is authoritative, how they were collected, and which identifiers allow records to be reconciled. Counsel and the data owner separately determine permitted uses and transfer conditions.

Inspect a representative, authorized sample and aggregate quality evidence. Record missing fields, duplicated entities, broken relationships, unknown provenance, and retention gaps against the intended use. A large row count does not establish usable historical coverage. A new analytics use may require event-time meaning and stable identities that the original transactional workflow never needed.

Do not assume that joining the target's data to the acquirer's identifiers is a harmless technical cleanup. A join can change the privacy and access implications of otherwise separated records. Record the proposed join keys, purpose, recipients, retention, and denied-access behavior. If the integration would create a broader customer profile, route the proposed use for qualified review before testing it on real data.

For AI-related assets, separate ownership of code from rights to training data, model weights, evaluation sets, and provider outputs. Ask what can be reproduced in an authorized environment and which artifacts depend on a supplier account or inaccessible dataset. Report a model's evaluated task and limitations rather than describing a benchmark score as general capability or a transferable competitive advantage.

The decision artifact is a data-use map: source, authority, collection purpose, proposed new use, quality evidence, access rule, unresolved permission, and receiving owner. If a material use is unsupported, narrow the thesis or obtain the missing evidence. More preprocessing cannot resolve an unanswered rights question.

15. Keep assessment access separate from integration authority

During diligence, the target and acquirer remain distinct trust environments unless an explicitly authorized arrangement says otherwise. Exported evidence can be reviewed in a bounded workspace without creating a live production bridge. Any later deployment or data connection needs a separate change decision, tested permissions, and recovery plan.

Before a separately approved integration, test which identities, secrets, and tenant mappings cross the boundary. A target administrator should not automatically become an administrator in the receiving platform. A shared identity provider does not establish identical authorization rules. The receiving security owner defines the mapping and tests prohibited access as well as the intended workflow.

The migration owner defines a rollback point before writing transformed data or triggering customer-visible effects. Record source checkpoints, mapping versions, completed operations, and reconciliation results. If the receiving system has accepted new writes, disconnecting it is containment, not necessarily recovery. The team may need reverse synchronization, replay, compensation, or repair-forward under an approved plan.

Where no production connection is authorized, the assessment stops at a documented feasibility result and its limits. The reviewer should not turn an integration hypothesis into a completed capability merely because a sandbox demonstration succeeded.

16. Challenge the decision packet before closing the review

Have a reviewer who did not collect the evidence trace a material conclusion from the executive summary to the finding, artifact, and stated limitation. They should be able to distinguish what was observed from what was inferred and identify the owner of the remaining question. If they need an undocumented explanation from the original author, revise the packet.

Use this completion checklist in the sponsor meeting:

• The transaction thesis and excluded systems are explicit.
• The eight dimensions contain findings or explained limits, not empty pass marks.
• Risk and confidence remain separate throughout the report.
• Critical observations identify the environment, artifact revision, and review date.
• Negative evidence and target rebuttals are retained with their effect on conclusions.
• Operating continuity includes people, account control, recovery, and supplier dependencies.
• Security and data-use findings have specialist owners and testable acceptance conditions.
• Remediation scenarios use task-specific assumptions and do not prescribe valuation.
• Any proposed integration has its own authority, compatibility, and recovery gates.
• Evidence retention and temporary-access closeout have accountable custodians.

The sponsor records whether to seek more evidence, accept a bounded exposure, change the integration assumption, or reconsider the thesis. The reviewer records what evidence would reopen that decision. A completed assessment can legitimately end with unresolved uncertainty; concealing that uncertainty would make the decision packet less useful.

Limitations, references and next step

This framework uses constructed examples and proposed methods. It contains no independently authenticated acquisition narrative, measured transaction result or claim of Ampity engagement volume. Primary references were checked on 21 September 2026. The cited frameworks support selected definitions, not the validity of a particular target or deal.

An accountable author, technical reviewer and any required legal, security and finance specialists must be assigned before publication approval. No reviewer identity has been inferred. An unverified downloadable PDF has not been retained as evidence.

For a bounded system architecture assessment, bring the transaction question, permitted access scope, critical product flows and current evidence register. Agree the technical outputs and specialist exclusions before requesting broad access or proposing remediation.