January 26, 2024

Security Due Diligence: A (short) Guide for Technical Consultants

By Matt James / 4 min read

When a client asks whether a technology investment is safe, the honest answer requires more than a glance at the product sheet.

Security advisors and technical consultants sit at a difficult intersection. They are asked to provide assurance about technology they did not build, in markets they may not know well, on behalf of clients who are about to commit real capital. The pressure to say "yes, this looks fine" is structural. The cost of saying it without basis is borne by someone else, at least until it isn't. A rigorous due diligence process does not eliminate that tension, but it gives the answer a foundation.

Start with the market, not the product

The most natural place to begin is the technology itself, but that is often the wrong starting point. Before you can evaluate whether a product is secure and viable, you need to understand whether the problem it solves is real and whether the vendor is the kind of organization that will be around to support it.

Market analysis means asking whether the technology addresses a genuine need or carves out a differentiated position in a crowded space. It also means looking hard at the vendor: their financial health, their customer history, their track record managing deployments of similar scale and complexity. A product with excellent security posture built by a vendor that is twelve months from insolvency is not a safe investment. The longevity of a technology depends on the organization sustaining it, and that is worth understanding before you spend time on technical evaluation.

Dig into what has already been tested

Once you have confidence in the market and vendor context, the next question is what the vendor already knows about their own product's security. A mature vendor should have a threat model, ideally a qualitative one that maps the system's assets, trust boundaries, and attack surfaces. If they have third-party assessment results, penetration test reports, or SOC 2 attestations, those are worth reviewing in detail: not to accept them at face value, but to understand the rigor of the process and whether the findings were actually addressed.

When comprehensive assessments have not been performed, or when what exists is thin, consultants need to recommend the next steps explicitly: security audits, threat modeling engagements, targeted penetration testing against the highest-risk components. The goal is not to conduct all of that work yourself during diligence, but to characterize the gap clearly so your client understands what assurance they are actually getting and what remains unverified. Unverified assumptions should be priced into the investment, one way or another.

Test it in the real world before the deal closes

Market analysis and document review can tell you a lot. They cannot tell you how the technology behaves under real operational conditions. Pilot testing closes that gap. Running the product in a realistic environment, with representative data flows and integration points, surfaces operational issues that no amount of vendor documentation will reveal: integration failures, unexpected performance characteristics, edge cases the vendor's QA process did not anticipate.

The analysis of pilot results matters as much as running the test. Efficiency, scalability, and reliability under load each carry different implications depending on the deployment context. A system that performs well at small scale but degrades under enterprise workloads is a different risk than one that is slow but consistent. Understanding which failure modes you are observing, and whether they are acceptable given the investment thesis, is the work that turns test results into a recommendation.

What assurance actually means

Technical due diligence is not about finding a reason to kill a deal. It is about ensuring that when you tell a client their technology investment is sound, you have done the work to mean it. Market analysis establishes that the vendor and the product have a future. Verification of prior assessments establishes what the vendor knows about their own risk surface. Pilot testing establishes whether the product does what it claims in conditions that resemble production. Together, these three activities give a recommendation its credibility.

The alternative, skipping steps because the timeline is short or the vendor's pitch is persuasive, is how organizations end up with expensive problems that a few weeks of rigorous diligence would have surfaced early.