Security diligence that separates evidence from claims

What this workstream answers

A deal team rarely needs a vulnerability list. It needs to know whether the target’s security position could hurt the investment case. The review is organised around a small set of decision questions agreed at the start, for example:

• Could a security gap block or delay enterprise sales in the next 18 months?
• Do the target’s security claims to customers match what it can show?
• Is customer data separated between tenants by design, or by convention?
• What will the first year of security work cost in engineering attention?

The questions shape what gets examined. A target selling to banks and one selling to small businesses deserve different emphasis.

How the memo labels evidence

Every observation carries a label, so the deal team can weigh it:

Label	Meaning
Observed	Seen directly in a system, configuration or authorised check
Documented	Supported by a supplied record, such as a report or ticket history
Stated	Asserted by management in interview, not yet supported
Unverified	Claimed but not examinable in the time or access available

This matters most with assurance documents. A SOC 2 report covers a defined system and period, and its exceptions and carve-outs can matter as much as the opinion. A pentest summary covers the scope it names, which may not include the product being invested in.

What the target is asked for

Requests stay proportionate to the deal stage. A typical list:

• An architecture overview or a one-hour walkthrough with the technical lead
• The most recent assessment reports, with their scope statements
• Open security findings and how they are tracked
• How staff and support access production, and who approves it
• Any SOC 2 or ISO report, including exceptions and bridge letters

Credentials, source code and customer data are not requested for a document review.

Light-touch testing, only with authorisation

Some questions cannot be settled on paper. Does tenant A’s token really fail against tenant B’s records? Where a check would change the answer, ZenoPentest asks the target for written authorisation to run narrow tests, ideally on a test tenant with synthetic data.

The fund cannot grant this permission. If the target declines, the memo records the claim as unverified. A diligence window is too short for a full penetration test, and the memo does not present light checks as one.

Working inside a deal timeline

The first conversation sets the investment committee date, the evidence available and the questions that matter most. The proposal states what can credibly be covered in that window. If the window is too short for a useful answer, ZenoPentest says so before engagement rather than producing a thin memo.

After the investment: portfolio baselines

Diligence often leaves a list of known gaps. After closing, the company can commission a scoped baseline:

1. A penetration test of the main application and API
2. An authorization or architecture review where diligence raised questions
3. A ranked remediation plan the company owns

The portfolio company is usually the client for this work. What the fund sees is agreed with the company in advance.

Independence and conflicts

Diligence conclusions and follow-on work stay separate. Prior work for the target is disclosed. Remediation is scoped as a new engagement. We propose that fees do not depend on the conclusion or on completion of the deal.