Pentest the product your customers depend on

Start from what changed

Most product pentests are commissioned for one of three reasons: something significant shipped, a customer asked, or an auditor did. Each changes the scope. A release that rewrites tenant isolation needs depth on authorisation across workspaces. A questionnaire needs a report the reviewer can read and accept. Audit evidence needs a scope your auditor recognises as covering the system in question.

Investor diligence and new integrations follow the same logic. The question is always what the reader of the report needs to see, and which part of the product they are worried about.

Tell us the trigger first. The penetration testing page lists what is covered and what drives the size of an assessment.

What enterprise reviewers look for

Reviewers rarely read every finding. They usually check:

• what was in scope and what was excluded
• when testing happened and against which environment
• who performed it, and whether they were independent of your developers
• how many high-severity findings were raised, and whether they were verified fixed

That is why the report states scope, dates and attribution plainly, and why the retest records a result per finding. If the reviewer has a template or a list of required sections, send it before scoping so the report can be checked against it, not retrofitted after testing. The guide to what enterprise reviewers expect from a pentest report goes into more detail.

Findings your engineers can reproduce

Each finding includes the request, the response, the role and tenant it was observed from, the affected workflow and a correction grounded in how your application works. A finding your team cannot reproduce wastes a sprint. Severity is explained against your context, not copied from a scanner, so the fix order makes sense to the people doing the work. A readout session lets engineers ask how each issue was found. The sample report shows the format with synthetic data, ungated.

Roles, tenants and APIs first

For most SaaS products the serious risks sit in authorisation: one customer reaching another’s data, a read-only role triggering a write, or an API that trusts an ID the interface never exposes. Testing works through your real role and tenant model rather than a generic checklist. The method is published in authorisation and tenant isolation.

AI features and integrations

An assistant that reads customer records and calls tools is a new path to the same data. So is an SSO configuration that accepts the wrong assertion, or a webhook that does not verify its sender. These are scoped alongside the application test, or on their own. See AI security and enterprise integrations.

After the first assessment

Fixes are yours. The retest confirms them. When a later release changes roles, tenants or integrations, that change can be scoped as a fresh assessment. Recurring arrangements are discussed only when there is a sustained need, not sold up front.

Before you get in touch

You do not need a complete asset inventory to start. A short product description, the trigger, the deadline and an engineering contact are enough for a first scoping conversation. Detailed assets, accounts and access are agreed during scoping, after which the system owner signs the authorisation. No testing starts from an enquiry. The pentest readiness checklist lists what to prepare.

If your customers or implementation partners need testing too, the partnership models page explains how a software ecosystem relationship works.