What enterprise reviewers expect from a pentest report

A large customer is close to signing. Their security team sends a questionnaire, and somewhere in it is a line like “Provide your most recent third-party penetration test report”. What happens next depends less on how many findings the report contains than on whether it answers the questions the reviewer is about to ask.

This guide describes what those reviewers typically look for, based on the common shape of vendor security questionnaires and review processes. Every customer is different. When the deal matters, ask the reviewer what they need before you commission the test. That one email often saves a second engagement.

Who is reading and what they are deciding

The person reading your report is rarely trying to find vulnerabilities in your product. They are deciding whether your product is an acceptable risk for their organisation, and they need evidence they can put in a file. Usually they are one of:

• a third-party risk or vendor assurance analyst working through a standard questionnaire;
• an application security engineer asked to look more closely because your product will hold sensitive data or integrate deeply;
• a procurement or legal reviewer checking that the evidence exists and is current.

Each wants slightly different things, but all three start with the same questions: is this report recent, does it cover what we are buying, and who wrote it?

What reviewers typically ask for

Recency

Questionnaires commonly ask for the date of the most recent test, and many organisations expect testing at least annually or after significant change. There is no single universal rule. Your customer’s policy, your own risk assessment and any contractual commitments decide the cadence.

What matters to the reviewer:

• The testing dates, not just the report date. A report issued in March for testing done the previous October tells a different story.
• The build or release tested. If you have shipped a new permissions model since the test, a careful reviewer will ask whether it was covered.
• Whether a newer test is planned. If the last test is getting old, a scheduled engagement with a signed scope is better evidence than silence.

Scope coverage

This is where most reports fall short. Reviewers want to see that the test covered the product they are buying, in the way they will use it.

They will look for:

• the applications and APIs tested, by name and base URL (for example app.example.com and api.example.com);
• the roles tested, especially admin and tenant-admin roles;
• whether tenant isolation was tested, if your product is multi-tenant;
• the environment tested and how it relates to production;
• what was excluded, and why.

A report covering only your marketing site and login page does not reassure a reviewer whose users will hold admin rights in your platform. The scoping guide covers how to build a scope that answers these questions in advance.

Independence of the tester

Many questionnaires ask for a “third-party” or “independent” test. Reviewers want to know that the people who tested the product are not the people who built it, and that the report was not edited to remove findings.

Things that help:

• the report names the testing organisation and the commissioning organisation;
• the methodology is described, with the standards followed (for example OWASP WSTG, ASVS or the API Security Top 10);
• the delivery chain is clear. If the report was delivered through a partner or reseller, it says who performed the testing.

Some reviewers or contracts specify tester qualifications or provider accreditations. If yours does, get that requirement in writing before you choose a provider, and ask the provider to confirm in the proposal how it will be met. Do not assume.

Severity summary

Reviewers want a quick read of risk before the detail. A good report gives:

• counts by severity (critical, high, medium, low, informational);
• the scoring method used, such as CVSS or a stated risk-rating scheme;
• a short narrative of the most significant issues in plain language.

Open findings do not automatically end a review. What reviewers object to is uncertainty: a critical issue with no remediation status, or severity ratings with no explanation.

Remediation status and retest evidence

For each finding, a reviewer would like to know whether it has been fixed and whether anyone has checked. That means:

• a remediation status per finding: open, fixed, risk accepted, or fixed and verified;
• for verified fixes, a retest date and what was checked;
• for risk-accepted findings, who accepted the risk and why.

“We fixed it” is a claim. “The tester retested ZP-SYN-0003 on a given date against build 4.2.1 and confirmed the authorisation check is enforced” is evidence. If a retest is part of your engagement, agree in the proposal what it covers and how the updated status will be reported.

Executive summary versus the full report

Most organisations do not want to send their full pentest report to every prospect. It contains reproduction steps that would help an attacker until every issue is fixed. Reviewers know this.

Document	Typical contents	Typical sharing
Executive summary or shareable summary	Scope, dates, tester identity, methodology, severity counts, remediation status	Shared on request, sometimes without NDA
Attestation-style letter	Confirmation that a test occurred, its dates, scope and summary outcome	Shared early in a review
Full report	Every finding with evidence, reproduction steps and fixes	Shared only under NDA, or reviewed in a screen-share, or not at all
Coverage record	What was tested per role, tenant and workflow, plus gaps	Shared with reviewers who ask about depth

Whether ZenoPentest supplies a shareable summary or letter for a given engagement is agreed in the proposal. Decide early which documents you expect to share, so the test produces them.

Sharing under NDA

If a reviewer insists on the full report, common approaches include:

• sharing under a mutual NDA with an explicit purpose limitation;
• a time-limited, view-only link rather than an attachment;
• a screen-share walkthrough where the reviewer sees the report but does not receive a copy;
• redacting reproduction steps for findings that are still open.

Check your contract with the testing provider to confirm you may share the report and in what form. Some reports carry restrictions on onward distribution.

How SOC 2 and ISO 27001 auditors use pentest evidence

A penetration test is not a SOC 2 report and does not certify you against ISO 27001. A SOC 2 examination is an assurance service performed by a CPA firm. ISO 27001 certification is issued by an accredited certification body. A pentest provider issues neither.

What a pentest can provide is testing evidence that an auditor may review when assessing your controls. Depending on your control set and the auditor’s approach, that evidence may support statements about:

• how you identify and evaluate technical vulnerabilities;
• how you respond to and remediate findings within your stated timescales;
• how you test security before or after significant changes.

The auditor decides whether the evidence is sufficient. Things that generally make it more useful:

• the scope matches the systems in your audit boundary;
• the testing date falls within or close to the audit period;
• remediation is tracked through your normal change or ticketing process, with evidence of closure;
• risk-accepted findings follow your documented risk-acceptance process.

Before commissioning a test for audit purposes, ask your auditor what they expect to see: scope, cadence, provider independence and the format of evidence. Then put those requirements into the scope.

Red flags that a report is a reformatted scan

Reviewers who read many reports learn to spot scanner output with a new cover page. If you are buying a test, these are worth checking before you share anything.

Findings with no reproduction steps. A real finding tells an engineer exactly how to reproduce it: the request, the account used, the response. A scanner result says a header is missing.

No authenticated findings. If every issue could have been found without logging in, the roles and tenants in your product were probably not tested.

No authorisation or business-logic findings, with no explanation. A clean result is possible. But if the report never mentions testing cross-tenant access or role boundaries, a reviewer cannot tell whether that is because the controls held or because nobody checked.

Generic remediation text. “Ensure input is validated” applied to twenty findings. Real remediation advice names the endpoint, the parameter and the check that is missing.

Severity inflated or deflated without context. A missing security header rated high, or a tenant isolation bypass rated medium, suggests ratings came from a tool’s defaults rather than an assessment of impact.

Tool names everywhere, testers nowhere. A report that lists the scanners used but not who performed the test or how.

Huge finding counts of low value. Hundreds of informational items bury anything important and suggest no one triaged the output.

A useful test: hand one finding to an engineer who was not involved and ask them to reproduce it from the report alone. If they cannot, the report will not survive a careful reviewer either.

The labelled synthetic sample report shows how ZenoPentest structures findings, coverage and remediation status. Every company, domain and finding in it is fictional.

Matching questionnaire items to evidence

Questionnaire wording varies, but the same handful of questions recur. It helps to know in advance which document answers each one.

Typical questionnaire item	Evidence that answers it
When was your last third-party penetration test?	Testing dates and build in the report or shareable summary
What was in scope?	Scope record listing applications, APIs, roles, tenants and environment
Who performed the test?	Testing organisation named in the report, with the delivery chain stated
Were critical and high findings remediated?	Per-finding remediation status, with retest dates for verified fixes
How do you handle findings you have not fixed?	Risk-acceptance records naming the owner and the reason
How often do you test?	Your documented testing policy, plus the next scheduled engagement
Can we see the report?	Shareable summary first; full report under NDA if your policy allows

If you cannot point to a document for one of these rows, that is the gap to close before the next review, not during it.

Preparing before the reviewer asks

If enterprise reviews are part of how you sell, a few habits make each one easier.

• Keep a current shareable summary. Update it when a retest changes remediation status.
• Keep the scope record with the report. Reviewers ask about coverage. The scope and coverage record answer that directly.
• Track remediation in your own system. Link findings to tickets so you can show closure dates.
• Test after material change. A new role model, SSO integration or AI feature is a reasonable point to scope a focused test.
• Write down your answers. Recency, scope, tester identity and remediation status come up in every questionnaire. A short internal note with agreed wording saves time and keeps answers consistent.
• Ask the reviewer early. If a specific customer needs a specific scope or provider attribute, you want to know before the test, not after.

None of this guarantees a reviewer will accept your evidence. Each organisation applies its own policy. It does mean the conversation is about your product’s actual risk rather than gaps in the paperwork.

Next steps

• Look at the synthetic sample report to see findings, coverage and remediation status laid out.
• Read how ZenoPentest approaches reporting and retest.
• Use the pentest readiness checklist and the scoping guide to build a scope that answers the reviewer’s questions in advance.
• If a customer review is driving the test, start a scope and include the reviewer’s requirements. No testing starts from an enquiry: a written scope and signed authorisation from the system owner come first.