What is a pentest attestation letter?

A pentest attestation letter is a short, signed document from the testing firm confirming that a penetration test was performed against a defined scope, during a defined window, by named or credentialed testers, with a high-level summary of the result. It is not the full report. It is the artefact a buyer can share with a customer, an auditor, or a procurement team without releasing the technical findings. The letter answers the questions a third party legitimately needs to know (was a test done, against what, by whom, when, and with what overall outcome) without exposing the reproduction steps a third party should not have.

When does a buyer need an attestation letter rather than the full report?

Three common situations. The first is a security questionnaire that asks for evidence of recent third-party penetration testing; the buyer wants to share something authoritative without uploading a sensitive PDF. The second is a customer due diligence request where the buyer is the vendor; sending the full report exposes attack paths against systems the customer now relies on. The third is a regulatory or audit context (PCI DSS, ISO 27001 surveillance, SOC 2, vendor risk reviews) where the auditor or assessor needs evidence the test happened and was current, but does not need the working notes. The attestation letter is the artefact for all three.

What must be in a pentest attestation letter?

Six load-bearing elements. The testing firm name and identifiable signatory (engagement lead, with role and credentials). The buyer (the organisation that commissioned the test). The scope, named precisely enough to be matched to the asset under question, but not so specifically that the letter becomes a target list. The testing window (start and end dates). The methodology referenced against a recognised framework (PTES, NIST SP 800-115, OWASP WSTG, CREST). The overall result, expressed at a level a third party can act on (for example, that critical findings have been remediated and verified on retest, with remaining items tracked). Anything less is not durable evidence; anything more drifts toward releasing the report itself.

What should never be in a pentest attestation letter?

Specific findings, CVE numbers tied to internal systems, exact tool names tied to specific paths, IP addresses or hostnames in scope, working credentials or authentication mechanisms, screenshots, payloads, and any text that would let a reader reproduce a vulnerability. The attestation is a statement of work and a high-level outcome, not a redaction of the report. If the third party needs more, the right response is a controlled report share under NDA, not a more detailed letter. The mistake of bolting findings onto the letter is the most common reason an attestation becomes a leak.

Should the letter mention residual or open findings?

Yes, but at a categorisation level rather than a specifics level. A defensible pattern is to state the count of findings by severity at end-of-test, the count remediated and verified, the count still in remediation with target windows, and the count formally accepted with documented business justification. That is enough for the auditor or customer to understand the residual risk posture without exposing the specific issues. Saying nothing about open findings reads as a clean test even when material exposure remains, which is misleading; saying everything reads as a redacted report. A counted summary at severity level is the right disclosure.

How long should the letter be?

One page for most engagements, two pages where retest verification or compliance mapping is included. Anything longer is drifting toward an executive summary or a redacted report and should be treated as one. The brevity is a feature: a one-page signed letter is easy to share, easy to archive, and hard to misread. A four-page document with appendices ends up being read as a report excerpt and gets used in ways the firm did not intend.

Who signs the letter?

The engagement lead from the testing firm, with role and any relevant individual credentials (for example, CREST Certified Tester, OSCP, CEH-Master, or CHECK Team Leader). For panel arrangements where multiple testers ran the engagement, the lead signs on behalf of the team and the team composition is noted. A countersignature from a director or CTO of the firm is conventional in regulated sectors. The buyer typically does not countersign the attestation because the letter is the firm asserting facts about the test it performed, not a joint statement.

How long is an attestation letter valid for?

It is dated, not valid. The letter states the engagement window. The relying party (auditor, customer, regulator) decides whether that window is current enough for their purpose. PCI DSS expects annual external testing for in-scope systems and after significant change; SOC 2 surveillance typically references the most recent test against the audit period; vendor due diligence reviews usually accept letters dated within twelve months. The firm does not declare the letter valid for a fixed period; the buyer presents it with a date, and the relying party applies their own currency rule.

How does SecPortal help produce attestation letters?

SecPortal stores the engagement record (scope, dates, methodology, team), the findings with CVSS vectors and current status (open, in remediation, verified, accepted), and the retest history on a single record per engagement. The AI report generator produces draft attestation letters from that record using the same factual basis as the full report, so the letter is consistent with the report rather than a separately drafted document that drifts. The branded client portal then serves the attestation alongside the full report with role-based access, so customers and auditors can be granted attestation-only access without exposure to the technical findings.

← Back to Blog

Guides7 May 202613 min read

Pentest Attestation Letter: What to Include and What to Avoid

The attestation letter is the artefact buyers actually share. The full report is read by the security team and the engineers who will fix the findings; the attestation letter is forwarded to customers, regulators, and procurement teams who need evidence that the test happened without seeing the working notes. Most consultancies still produce attestation letters as one-off Word documents drafted from memory at the end of the engagement. That is how attestation letters drift: a phrase that promised more than the test delivered, a scope description that does not match the report, an open-finding count that quietly went stale. This guide gives the structure that holds, the elements that must be in every attestation, the elements that must never be in one, and a sample one-page letter you can adapt.

For the bookends on either side of the engagement, see the kickoff meeting agenda and the debrief meeting guide.

Why the Attestation Letter Exists

A penetration test produces three kinds of artefact. The full technical report, the executive summary, and the attestation letter. They are not interchangeable. The full report carries the findings, the reproduction steps, the evidence, and the recommended remediation; it is read by the buyer security team and the engineers who own the fixes. The executive summary distils the report for the buyer's leadership; it is read by people who will not open the appendix. The attestation letter is the artefact the buyer can share outside the organisation: with a customer asking for due diligence evidence, with an auditor running PCI DSS or SOC 2, with a procurement team checking the vendor box on a security questionnaire.

The three artefacts all describe the same test, but they have very different audiences, and treating them as a single document with three views is the source of most attestation problems. The executive summary leaks specifics that should stay in the report. The attestation drifts toward the executive summary and starts naming findings that should not be in a shareable letter. The full report becomes the document that never gets shared because every shareable version was carved out of it badly. The fix is to treat the attestation as its own artefact with its own structure, its own constraints, and its own delivery channel.

The Three Artefacts Compared

Artefact	Audience	Length	Includes findings detail	Shareable outside the buyer
Full report	Security team, engineering owners	20 to 80 pages	Yes, with reproduction steps and evidence	Only under NDA, with deliberate redaction
Executive summary	Buyer leadership and steering committees	2 to 4 pages	Severity counts, themes, no reproduction	Internally, generally not externally
Attestation letter	Customers, auditors, procurement, regulators	1 to 2 pages	No specifics; counted summary at most	Yes, this is its primary purpose

The attestation letter sits at the bottom of the table for a structural reason. It is the only artefact designed to leave the buyer's organisation, so the contents have to be drafted with that in mind from the first line. The mistake of starting from the executive summary and trimming it down produces letters that read like leaked summaries rather than purpose-built attestations. The attestation should be drafted from the engagement record, not from the report.

What Must Be in the Letter

Six load-bearing elements. Each maps to a question a third party legitimately needs the answer to, and each can be answered without exposing technical detail.

1. Testing firm and signatory

The firm name, the engagement lead by name, and the lead's role and individual credentials where relevant (CREST Certified Tester, OSCP, CHECK Team Leader). The third party needs to know who is making the assertion, not just that an assertion was made. Accreditation references (CREST member firm, CHECK approved) belong here if they apply to the firm; they belong nowhere else in the letter.

2. Buyer and engagement reference

The buyer organisation that commissioned the test, plus an internal engagement reference. The reference matters because the letter may be one of several across a multi-engagement programme; the relying party needs to be able to ask, by reference, for the underlying scope document if a question arises during audit.

3. Scope

The scope at the right level of abstraction. Specific enough that an auditor can match the letter to the asset under review (the buyer's production web application, the corporate Active Directory environment, the customer-facing API at a logical boundary). Not so specific that the letter becomes a list of in-scope hostnames or IP ranges. The scope description should be drawn from the statement of work rather than rewritten from the report; consistency between the SOW, the report, and the attestation matters more than literary variation.

4. Testing window

Start and end dates of the active testing window. If the engagement was paused for client environment issues, that detail belongs in the report, not the letter; the letter states the inclusive window. The testing window is the basis on which the relying party will judge currency, so it must be unambiguous.

5. Methodology

The reference framework the test followed: PTES, NIST SP 800-115, OWASP WSTG for web applications, OWASP MASVS for mobile, CREST methodology, or a named internal methodology aligned to one of the above. The relying party uses the methodology line to gauge how the test was conducted without needing to read the report. Naming a framework you did not actually follow is the second most common attestation defect after over-claiming the result.

6. Overall result

A counted summary at severity level: total findings at end-of-test by severity (Critical, High, Medium, Low, Informational), how many have been remediated and verified on retest, how many remain in remediation with named target windows, and how many have been formally risk-accepted with business justification. Anything less obscures the residual posture; anything more begins to leak the report.

What Must Never Be in the Letter

The attestation is shareable by design. Anything in the letter is, in practice, public information from the buyer's perspective the moment the letter is forwarded to a customer or uploaded to a vendor portal. Treat the contents accordingly.

Specific findings, including titled findings ("a stored XSS in the admin console").
CVE numbers tied to internal systems, particularly when the CVE has a known exploit.
Hostnames, IP addresses, URL paths, or any asset identifier that could become a target list.
Working credentials, authentication mechanisms, or session-related detail.
Screenshots, request and response payloads, exploit code, or attack chain narrative.
Tool names tied to specific paths ("sqlmap was used against /api/users").
Internal team names, individual buyer-side staff, or organisational structure detail.
Cloud account IDs, project IDs, or any cloud-specific resource identifier.

The line is not artistic. The line is operational: would the relying party still get what they need to know if this sentence were redacted? If yes, redact it. If no, the sentence belongs in the report under NDA, not in the attestation. For practical guidance on what evidence belongs where during the test itself, see the finding triage protocol.

Sample One-Page Attestation Structure

The structure below is a working default. It fits on a single side of A4 or US Letter, sits cleanly under firm letterhead, and answers each load-bearing question without drifting into report territory.

[Firm letterhead]

[Date of issue]

Penetration Testing Attestation

This letter confirms that [Firm Name], a [CREST member firm / CHECK approved supplier] accredited under [reference], conducted a penetration test on behalf of [Buyer Organisation] under engagement reference [REF-2026-XX].

Scope

The engagement covered [the buyer's production web application at the application boundary / the buyer's customer-facing API / the buyer's corporate Active Directory environment within a defined network boundary], as detailed in the engagement statement of work dated [date].

Testing window

[Start date] to [End date], inclusive.

Methodology

The test was conducted in accordance with [PTES / NIST SP 800-115 / OWASP WSTG v4.x], with manual testing complemented by tool-assisted enumeration where appropriate. Tester credentials: [CREST Certified Tester / OSCP / CHECK Team Leader].

Overall result

At end-of-test, the engagement identified the following at severity:

Critical: [n] (Remediated and verified: [n] / In remediation: [n] / Risk accepted: [n])
High: [n] (Remediated and verified: [n] / In remediation: [n] / Risk accepted: [n])
Medium: [n]
Low: [n]
Informational: [n]

All Critical and High findings were retested and verified as remediated as of [retest date], save for [n] in active remediation with target closure of [date].

The full technical report is available to the buyer and may be released to additional parties at the buyer's discretion, subject to a non-disclosure agreement.

For verification of this letter, contact [firm verification address].

[Signature]

[Engagement Lead Name], [Role]

[Credentials]

[Firm Name]

The structure is deliberately conservative. Firms that want to lengthen the letter usually do so by adding mapping to compliance frameworks (PCI DSS Requirement 11.4, ISO 27001 Annex A 8.29, SOC 2 CC7) or by appending a retest verification statement; both are acceptable additions and stay within the constraint of not exposing specifics. Adding executive prose, marketing language, or a finding narrative is the path that drifts the letter back toward an executive summary.

Compliance Mappings That Belong in the Letter

For engagements driven by a regulatory or contractual requirement, a brief mapping line in the attestation is genuinely useful for the relying party and stays within the shareability rule. The mapping is the framework reference and the requirement, not the test detail.

PCI DSS: reference the version (v4.0), the requirement (typically 11.4 for external and internal penetration testing), and whether the test followed an industry-accepted methodology consistent with the requirement.
ISO 27001: reference Annex A 8.29 (technical reviews and tests of information systems) under ISO 27001:2022. Mapping to A.8.8 (management of technical vulnerabilities) is appropriate when the engagement included vulnerability management workflow as a control.
SOC 2: reference the relevant trust services criteria (typically CC7 for system operations and CC9 for risk mitigation) under SOC 2.
DORA / TIBER-EU: for financial entities in the EU, reference Article 26 of DORA or the relevant TIBER-EU cycle. Threat-led penetration testing engagements have additional attestation requirements driven by the joint test report and the test summary report; the attestation letter pattern adapts but does not replace those.
CREST and CHECK: where the firm is a CREST member or a NCSC CHECK approved supplier, state the accreditation and the credential held by the engagement lead.

The mapping line keeps the letter useful for assurance work without lengthening it materially. It is the place where the firm asserts that the test methodology aligns with the requirement the relying party is checking against.

Common Drafting Mistakes

Five patterns produce defective attestations. Each one is easy to make under deadline pressure and each one undermines the letter as evidence.

1. Over-claiming the result

Sentences like "no significant security issues were identified" that inflate a clean test. If Critical and High count is zero, say so with the count. Generalised reassurance reads as marketing language and erodes the relying party's confidence in the rest of the letter.

2. Inconsistency with the report

The letter says nine findings at end-of-test; the report (under NDA) shows eleven. Or the letter says all High findings remediated; the report shows two still open. Inconsistency is the failure mode that converts an attestation from evidence into a liability. The fix is to draft both artefacts from the same engagement record so the counts cannot drift.

3. Stale retest claims

A letter dated three months after the retest verifies findings that have since been modified by deployment. The fix is to date the retest claims explicitly: "as of [date], the following findings were verified as remediated." Currency belongs to the relying party to assess.

4. Scope drift between engagement and letter

The SOW says the test covered the production web application; the attestation says the test covered the buyer's digital estate. Buyers occasionally ask for broader scope language; that ask should be refused unless the test actually included that broader scope. Scope drift is the defect that converts an attestation from a defensible artefact into a misleading one.

5. Hand-drafted from memory

The letter is typed into a Word document at the end of the engagement, with the tester half-remembering the exact dates and the buyer name copied from the wrong template. The fix is to generate the letter from the engagement record, with the signatory adding the human elements (firm-specific language, mapping detail) on top of the factual base. The structural fields (firm, buyer, scope, dates, methodology, counts) should never be retyped.

Delivery: Who Gets the Letter and How

Drafting the letter well is necessary; delivering it well is what stops the attestation from sprawling. The pattern that works is to treat the letter as a controlled artefact on the engagement record rather than a Word attachment that can be copied indefinitely.

The letter is countersigned and dated at issue, and a copy lives on the engagement record alongside the report and the retest history.
The buyer is granted full access to the engagement record; downstream parties (customers, auditors, regulators) are granted attestation-only access through the client portal rather than receiving a Word file by email.
Reissues (with updated retest verification, or with a corrected count) are tracked as new versions on the same record rather than overwriting the original. The relying party can see the version, the date, and the basis for the change.
Where the buyer is a vendor responding to customer security questionnaires at scale, attestation-only access through the portal lets dozens of customers verify the same letter without circulating PDFs that go stale.

Delivery on the same record as the report has a second benefit: the version of the attestation in circulation is always the version the firm last signed. Word-attached letters, by contrast, are forwarded for years after they go stale, often without the firm being aware. The portal-served pattern keeps currency under the firm's control.

For Pentest Firms and Consultancies

On the firm side, the attestation letter is one of the most reused artefacts in the engagement and one of the most under-systemised. Most firms have a Word template, a tester who knows the format, and a delivery channel that consists of an email attachment to the buyer. That is the path that produces drift, inconsistency with the report, and sprawling distribution.

The systemisation that pays back is structural: build the attestation from the engagement record, not from a fresh template; pull the firm-specific language from a standardised block; populate the load-bearing fields (firm, buyer, scope, dates, methodology, counts, signatory) automatically from the same data the report uses; countersign once; deliver through a portal that supports attestation-only access. The firm's engagement lead spends the saved time on the parts of the letter that require judgement (compliance mapping, retest narrative) rather than on retyping fields that are already on the record.

For pentest firms, security consultants, and MSSPs running multiple attestations a month, the systemised pattern is the difference between an artefact that holds up under audit scrutiny and one that quietly accumulates inconsistencies until a buyer notices.

For Pentest Buyers

On the buyer side, the attestation is the document you actually use most often, and the one you have least visibility into during drafting. Three asks of the firm pay back disproportionately.

Ask for the attestation as part of the engagement deliverables list at SOW signature, not as an afterthought after the report lands.
Specify the compliance mappings you need (PCI DSS Requirement 11.4, ISO 27001 Annex A 8.29, SOC 2 CC7, the relevant DORA article) so the firm produces them inline rather than by reissue.
Specify the delivery channel: a portal-served attestation that downstream parties can be granted access to is materially better for vendor-side organisations than a PDF attachment.

The attestation is the artefact your customers, auditors, and procurement teams will see on your behalf. Treating it as a deliverable with structure rather than a courtesy attachment is what keeps it useful. For the wider context of how reports get delivered, see the pentest report delivery workflow and the penetration testing report template.

How SecPortal Handles Attestation Letters

SecPortal stores the engagement record (scope, dates, methodology, team), the findings with CVSS vectors and current status (open, in remediation, verified, risk accepted), and the retest history on a single record per engagement. The AI report generator produces draft attestation letters from the same record the full report draws from, so the counts, dates, and scope statements do not drift between artefacts.

The branded client portal then serves the attestation alongside the report with role-based access from the team management controls, so customers and auditors can be granted attestation-only access without exposure to the technical findings. Reissues with updated retest verification track as new versions on the same record rather than overwriting the original.

The platform does not write the judgement parts of the attestation for you (the compliance mapping language, the retest narrative, the exact scope wording). It does make the load-bearing fields self-consistent with the report, the retest history, and the engagement record, which is the part of the attestation that drifts most often when it is hand-drafted.