A first enterprise security review
A portfolio company's first large customer sends a questionnaire and asks for a recent pentest report.
Introduce a portfolio company with a launch, an enterprise security review or a set of findings to fix. Or scope the security workstream for an investment you are evaluating. Each company engagement has its own scope, client and disclosure terms.
A portfolio company's first large customer sends a questionnaire and asks for a recent pentest report.
A company is about to ship an assistant or agent that can read customer records or take actions.
The deal team needs to know what the target's security claims rest on before investment committee.
An accelerator cohort keeps asking the same questions about pentests, SOC 2 evidence and secure defaults.
Evidence review, red-flag memo and explicit unknowns for a deal team. Any testing needs the target's written authorisation.
Penetration testingWeb and API testing a company can hand to enterprise reviewers, with findings, evidence and agreed verification.
Security engineeringThreat-model reviews, authorization design and remediation for companies fixing root causes, not individual endpoints.
A synthetic walkthrough. The companies and systems are fictional.
Example Ventures, a fictional fund, is evaluating Ledgerline, a fictional billing platform at app.example.com. The deal partner asks whether Ledgerline's enterprise security claims hold up.
The engagement letter names the fund as client, the deal team as recipients and four decision questions. Ledgerline agrees to a data room, two interviews and, after discussion, narrow checks on a test tenant.
The SOC 2 report's system description excludes the public API. The last pentest covered the marketing site only. Management states support staff cannot see invoice data; this is recorded as stated, not verified.
An authorised check on api.example.com shows one test tenant's token returning another test tenant's invoice. The memo labels this observed, lists three other observations by evidence strength and sets out management questions.
Ledgerline commissions its own pentest and an authorization redesign. Northwind receives a status summary only, under terms Ledgerline agreed.
Agreed in writing before any testing starts.
| Task | Fund | Portfolio company | ZenoPentest |
|---|---|---|---|
| Set diligence decision questions and recipients | Owns | Not involved | Involved |
| Authorise any testing of the company's systems | Not involved | Owns | Involved |
| Provide evidence, access and interview time | Not involved | Owns | Involved |
| Carry out review and testing within agreed scope | Not involved | Involved | Owns |
| Write the memo or report | Not involved | Not involved | Owns |
| Decide whether and on what terms to invest | Owns | Not involved | Not involved |
| Commission post-investment work | Involved | Owns | Not involved |
| Approve sharing company findings with the fund | Involved | Owns | Involved |
| Fix findings | Not involved | Owns | Involved |
Owns owns Involved involved
Funds come to security work from two directions, and they need different arrangements.
Before investment, the fund is the client. The question is whether security risk affects the investment case. The output is a memo for the deal team, built from evidence the target supplies and any checks it authorises. See investment security diligence.
After investment, the portfolio company is normally the client. It needs a pentest for an enterprise review, or engineering help to fix what testing found. The fund’s role is the introduction, and sometimes the funding.
Mixing the two causes problems. A company that commissioned its own pentest should not find its findings in a fund report it never agreed to.
Every company engagement settles three things in writing before work starts:
The responsibility table above shows the default split. A funded programme can change who pays. It does not change who authorises testing.
Start small. A fund introduces one company with a real trigger: a customer review, a launch or a backlog of findings. That engagement is scoped and delivered on its own terms. If more companies follow, a fund and ZenoPentest can discuss a defined arrangement, such as a cohort session or a standard scoping route. Reserved capacity only makes sense after demand is shown.
An introduction moves faster when it names the company contact who owns the system, the trigger and its date, and who is expected to pay. Do not forward reports, credentials or deal documents by email. Those follow later through an agreed secure process, once the company is the client.
Ungated. A fictional company, a real structure, and a note on why each section exists.
| Severity | Findings |
|---|---|
| Critical | 0 |
| High | 2 |
| Medium | 2 |
| Low | 1 |
| Info | 1 |
| Verified fixed | 4 / 6 |
No fund relationships are claimed. This page describes how a portfolio relationship could work, to be agreed with each fund.
No. Only the system owner can authorise testing. A fund can commission a review, but technical checks need the company's written permission.
Usually the portfolio company commissions and pays. A fund-funded programme is possible if the payer, client and reporting terms are agreed first.
Only what the company agrees to share. The default is that findings belong to the company that commissioned the work.
No programme terms are published. Any arrangement for a fund or accelerator is agreed individually and in writing.
It can be discussed as a defined session with a stated agenda. It is not a substitute for a scoped assessment of any company.
No. It contributes a bounded security assessment. Valuation, investment merit and wider technical diligence stay with the fund and its other advisers.
Tell us the system, the deadline and who needs the report. You get scoping questions, then a fixed quote.