TECHNICAL DUE DILIGENCE

Understand the security risk behind the decision before you commit.

Independent security diligence for investors, acquirers, and enterprise buyers who need to know what they would actually be taking on.

Discuss your scope Meet the team

Diligence scope

What we evaluate

Diligence is a question of evidence, not impressions. We separate what the target can demonstrate from what it is asserting, and tell you which is which.

Four claims made by a diligence target passing through an evidence check: two verified, one contradicted by the record and raised as a red flag, and one that the available access could not establish, reported as an open question rather than a pass
  1. 01 What they have actually built We look at the architecture and the critical code behind the claims, rather than the diagram in the deck.
  2. 02 What they can prove We separate demonstrated security posture (findings, fixes, incident history) from assertions with nothing behind them.
  3. 03 What you would inherit We surface the vendors, platforms, and technical debt that become yours on the day the deal closes.
  4. 04 What we could not establish We state the evidence gaps plainly, so an unanswered question never reads as a clean result.

Timing

Best used before you buy or commit.

Investment or acquisition

A commitment depends on the target’s technical reality.

Vendor selection

A strategic platform will inherit trust and operational reach.

Ecosystem commitment

A grant or partnership needs independent validation.

Claims need evidence

Security assertions made during a deal require technical review.

Process

From security claims to decision-ready evidence.

  1. 01

    Define the decision

    Set the investment, acquisition, vendor, grant, or partnership question and the red flags that could change it.

  2. 02

    Test claims against evidence

    Review the architecture, code, controls, incidents, dependencies, documentation, and access available.

  3. 03

    Investigate material gaps

    Focus technical review on the weaknesses, unknowns, and inherited risks with the greatest decision impact.

  4. 04

    Translate the findings

    Deliver material red flags, unresolved questions, and their implications for the commitment under review.

Outputs / What you receive

Evidence you can take into the decision.

Material red flags

Risk drivers and the evidence behind them.

Prioritized questions

Evidence gaps and unresolved technical issues.

Executive summary

Findings translated into implications for the transaction or commitment.

Typical engagement team

Who typically leads this work

The exact team depends on the scope. Every engagement has a principal who owns it from scoping through delivery, joined by the specialists the system calls for, and whoever is assigned is named in your proposal.

Piotr Cielas portrait

Piotr Cielas

Principal Advisor

Head of Security at Agora, responsible for security, data protection, and corporate IT risk. Earlier at EY, led assessments across financial services, healthcare, and government.

Currently

Head of Security, Agora

$45B+ in volume

Timur Güvenkaya portrait

Timur Güvenkaya

Founder & Partner

Led a security engineering practice for Rust and non-EVM systems across Substrate and NEAR. Earlier, built vulnerability-detection engines at Invicti used by Fortune 50 and public-sector organizations.

Paul Vijender portrait

Paul Vijender

Specialist Advisor

Head of Security at Gauntlet, with depth across product security, IAM, cloud, DevSecOps, and blockchain. Previously held security roles at Tensor, EY, Broadcom, and ADP.

Currently

Head of Security, Gauntlet

$1.6B+ TVL

Meet the full team

FAQ

Questions before scoping

How much access do you need to the target?

It depends on what the process allows. We work with whatever is granted, whether documentation only, a data room, interviews, or code, and the output states which conclusions the available access could support and which it could not.

What if the target will not give you code access?

Common, and not disqualifying. A great deal can be established from architecture, operational evidence, incident history, and interviews. We stay explicit about the difference between what we verified directly and what we could only assess indirectly.

Can you work inside a deal timeline?

Usually. Diligence scopes are shaped by the date rather than the other way around. Where a timeline forces us to leave something unexamined, it is stated as an open question instead of being quietly dropped.

Do you give a go or no-go recommendation?

We give you the risk picture, a view of what it would take to fix, and what remains unknown. The decision stays yours; our job is to make sure it gets made with the technical reality visible.

What do we walk away with?

The material red flags with the evidence behind each one, the questions still open and why they matter, and a summary that translates technical risk into terms of the transaction.

Related services

Risk AssessmentGive leadership a prioritized view of where security risk concentrates and what to address first.Secure Code ReviewsFind security flaws in critical code where automated scanners and checklist reviews stop.Digital Asset Program AdvisoryMake security, custody, vendor, and operating-model decisions across a broader digital asset program.

Next step

Make the commitment with a clearer risk picture.

Share the target, decision, access available, timeline, and claims that need validation. We will define a focused diligence scope.

Discuss your scope