Architecture audit vs. technical due diligence

The mandate changes the assessment

Architecture audit

Usually commissioned to understand a system, assess an approach or prioritize change. Define which architecture, code and operating evidence is included and what written findings the team needs.

Technical due diligence

Commissioned around a transaction. Define the buyer's questions, the target systems, access limits and reporting audience. Connect technical observations to the risks and unresolved assumptions relevant to that transaction.

Focused review session

A narrower starting point when one decision or part of a system needs attention. It does not replace a scoped assessment of a codebase or a transaction.

A long report is not proof of a broad assessment. A short report is not necessarily superficial. The useful question is whether the work examined the evidence needed for the commissioning decision and clearly identifies what it could not verify.

Ask what each conclusion rests on

Request a distinction between observed behavior, supplied documentation, interviews and inference. A diagram can describe an intended system without proving that production matches it. A passing test only supports the behavior it actually exercises. A missing artifact should remain an open question until investigated.

NIST's Secure Software Development Framework v1.1 describes practices and a common vocabulary that purchasers can use in discussions with suppliers. It can inform questions about development practices; referencing it does not make an assessment a security certification. NIST SP 800-218: SSDF v1.1 (2022).

For your scope, identify which claims materially affect the decision and what evidence would support them. Code access alone may not answer questions about deployment, incident handling, supplier dependencies or the people needed to operate the system.

Set the scope before commissioning work

• Decision and audience: who commissions the work, who receives it and what decision must it support?
• Boundary: which products, repositories, environments and integrations are included or excluded?
• Evidence and access: what can be inspected, who can answer questions and what is unavailable?
• Deliverable: what findings, evidence references, priorities and unresolved questions must be recorded?
• Timing: when will evidence be available, and what happens if access arrives late?
• Follow-through: who can clarify findings, and are remediation or further investigation separately scoped?

In a transaction, also agree confidentiality, permitted recipients and the handling of third-party information with the appropriate advisors. Technical findings contribute to the decision; they do not replace legal or financial advice or guarantee an investment outcome.

Compare proposals by coverage and limits

Put proposals against the same brief. Compare systems covered, evidence access, deliverables, exclusions and the approach to uncertainty. Ask how an unverified claim will appear in the report. Treat guaranteed discovery of every defect or an unconditional clean bill of health as a reason to clarify what is actually being promised.

For an existing system and an improvement decision, review the Architecture Audit offer. For an investment or acquisition, review Technical Due Diligence. Both Robles Consulting engagements are separately scoped; their published prices are starting points, with scope and delivery agreed before work begins. Neither is instant checkout.