How to report a partial security assessment to a customer

Tell the customer what was assessed, at which revision and environment, what the evidence supports, what remains unassessed, and when the next decision is due. Put the material limitation beside the conclusion, not in small print. Separate verified findings from candidates and unanswered questions. Give the customer a useful next action: accept a bounded report for now, request a missing artifact, or wait for a scheduled follow-up. A partial report can be credible and helpful when its scope is exact; it cannot be presented as a full penetration test, an ASVS certification or proof that no vulnerabilities remain. The wording changes when new evidence arrives, so keep the original report dated and issue a revision rather than editing its history.

The OWASP Web Security Testing Guide's reporting chapter explains why findings and conclusions need to be useful to distinct audiences. OWASP ASVS 5.0.0 is a requirements standard; use its versioned IDs for selected checks, but a tool's tag or a source review does not establish application-wide conformance.

What the customer actually needs to decide

A customer usually wants to know whether the activity reduces uncertainty about the system they use, which issues could affect them, and what happens next. Start with the customer-facing service and affected data. Keep methods and exclusions visible enough that a technical reviewer can interpret the result. If sensitive evidence cannot be placed in the report, provide a controlled route to inspect it, a redacted summary and the owner who can answer questions. Do not disclose another tenant's source, personal data or exploit details just to make the report look complete.

Use three layers:

1. Decision summary: what was examined, most material supported issue or unresolved question, practical customer impact, and next date.
2. Scope and results table: versions, methods, components, evidence and states, including skipped work.
3. Restricted technical appendix: exact paths, authorized test records and evidence references for reviewers who need them.

For a source-only assessment, say “source review.” If no authorized runtime testing took place, say so. If a vulnerability candidate was identified but not verified, label it a candidate. If a verified issue exists, explain the customer-relevant effect, prerequisites and current mitigation without exaggerating certainty. OWASP's secure code review guidance covers one important method; it does not turn a source inspection into an executed test.

Copyable partial assessment template

Replace every bracketed item. Delete a row only when it truly does not apply, and explain consequential omissions in the scope section.

Report title and status: [service or product] security assessment, partial, report version [number], issued [UTC date].

Customer decision summary: We assessed [components and actions] at [immutable revisions] in [environment] using [methods] from [date] to [date]. We found [number and state of verified findings, or “no verified finding within this assessed scope”]. [Material candidate or unanswered control] remains [status]. This report supports [narrow conclusion]; it does not assess [material exclusions] or establish product-wide security or standard conformance. The next update is due [date/trigger].

Scope and reference: [repositories, deployed versions, routes, data types, selected standard/version/requirements, agreed exclusions].

Work performed: [source paths or review obligations completed; configuration inspected; authorized tests executed; tools used only as leads]. Link [evidence index and reviewer/date].

Results: [verified and approved findings with impact, prerequisites and remediation state]; [candidate investigations kept separate]; [control conclusions supported/inconclusive/unassessed].

Limitations: [missing services or paths, inventory limits, inaccessible settings, tests not run, sampling method, environments unlike production]. State how each limit could change the conclusion.

Next actions and owners: [artifact or test], [owner], [due date], [how the result will be communicated].

Contact and evidence access: [security contact, secure evidence route, report approval owner].

“No verified finding within this assessed scope” must be used only if it is true, and it still says nothing about unassessed paths. Never substitute “no known vulnerabilities” for an unresolved investigation. If the customer requests a standard claim, identify the selected requirement set and assessment boundary; list inconclusive and excluded obligations separately. ASVS requirement identifiers should be versioned, for example v5.0.0-8.2.2, according to OWASP's citation guidance.

Filled example: HarborLedger's invoice service

Everything in this example is illustrative, including the service, counts, dates and findings. No live test or customer assessment is being claimed. HarborLedger's customer asks whether one tenant can read another tenant's invoice. The team has reviewed selected API source and a staging gateway export. It has not received PDF worker policy evidence or two test tenant accounts.

HarborLedger invoice access review — partial — version 1, 18 October 2026 UTC. We assessed the JSON invoice-read route at API revision api-7c2 and the PDF enqueue path at worker revision pdf-4b1, against selected authorization requirements in OWASP ASVS 5.0.0. The methods were source inspection and review of a dated staging gateway export. No cross-tenant runtime request was executed, and production identity-provider settings were not inspected.

Decision: The reviewed JSON route calls a server authorization helper, but the evidence does not yet establish that the deployed service and PDF worker enforce tenant-specific access on every in-scope path. One PDF-path concern remains a candidate under investigation, not a verified exposure. No product-wide ASVS conformance conclusion is offered. The platform owner will provide the deployed worker policy and claim mapping by 22 October; AppSec will review them and perform authorized two-tenant checks by 24 October. We will issue version 2 with the resulting decision.

The supporting table gives a customer security reviewer enough detail to understand the limitation without requiring source access:

The ASVS identifiers refer to the versioned official requirement catalog. This example deliberately does not say “passed” merely because a helper appears in code. It also does not classify C-12 as a confirmed finding before independent review. If an authorized test later demonstrates a failure, version 2 should state the tested actor, prerequisites, effect, mitigation and verification status without making readers infer those from a severity label.

Version 2 changes the PDF answer, not the production claim

The customer replies to the illustrative version 1 report: “We want to enable invoice exports in production. Please provide the missing worker evidence and tell us whether the review supports that decision. We do not need your source code.”

The team returns a restricted evidence index with the worker artifact identity, method, policy decision summary and synthetic allowed/denied case results. In this invented follow-up packet, the staging worker's mandatory object check is established and the original PDF candidate is rejected for the assessed staging path. Production artifact and identity configuration are still unavailable.

Version 2, 24 October 2026, still partial: The additional staging worker evidence supports the reviewed invoice/PDF object-access rule for the named staging build and cases. Candidate C-12 is rejected for that assessed path because the mandatory downstream check defeats it. Production mapping and identity configuration remain unassessed. This report therefore does not yet support enabling production exports on the assumption that production has the same control. The release owner will supply that binding for the next decision.

The useful customer action is now explicit: obtain the production binding or keep the feature decision pending under the customer's own process. The report supplies evidence; it does not make the customer's risk decision for them. If production differs, the team reviews that difference rather than copying the staging result.

When asked for a percentage, link the working scope ledger and explain its units. Do not add a large file-count table that obscures the one missing fact governing this customer's export decision.

Keep findings and remediation states honest

A candidate is a lead with an unresolved question. A verified finding has a defensible actor-to-effect path, reviewed counterevidence and an approval decision. A rejected candidate belongs in the record with its rejection reason; it should not be marketed as a fixed vulnerability. An open verified finding needs an owner, action and expected reassessment date. If a proposed fix merges, record “change merged; validation pending” until the checks appropriate to the original claim support closure. After positive source reassessment, “verified fixed in code; deployment pending” may be appropriate. A narrow review of the changed path can be sufficient; a whole-application reassessment is not automatically required. “The scanner stopped reporting it” is insufficient.

For a customer, state the likely business effect and practical prerequisites before a raw severity code. “A signed-in customer may be able to retrieve another tenant's invoice if the worker accepts an ID without the user's authorization context” is a conditional hypothesis. “Any customer can read all invoices” is a factual claim that would require much stronger evidence. If verification is incomplete, preserve that conditional language in the summary and table.

Correct a statement that has already been shared

If version 1 was sent with an overly broad claim, a quiet replacement file is not enough. The report owner should issue a dated correction that identifies the affected sentence, supplies the narrower supported wording and explains the customer's changed decision. Keep the explanation factual: the worker evidence concerned staging, and production mapping remained unavailable. Do not imply an incident occurred simply because the assurance statement was too broad.

Use the same controlled recipient route as the original report and preserve the corrected version in the evidence index. If sales reused the sentence in a questionnaire, update that answer as well. This is a practical reason to keep report identifiers and scope with copied claims: the owner can find the dependent statement when its basis changes.

A correction can improve trust when it tells the customer exactly what they may still rely on. Preserve the valid staging conclusion while clearly withdrawing unsupported production assurance.

Send the report through a clear review route

Assign one accountable report owner to check technical accuracy, service scope and disclosure permissions, asking the relevant specialists about material uncertainty. A small team may combine these roles; three separate approvals are not a prerequisite for every routine update. Include the issue date, version, and intended recipient. Maintain an evidence index with restricted access and a change log: new evidence should create a new version or dated addendum, not erase the prior uncertainty. Put confidential reproduction steps in an access-controlled appendix. The customer's procurement or legal process may require additional wording; this template is an evidence report, not a legal conclusion.

The immediate next action is to fill the template for one customer-relevant action, then ask an independent reviewer to challenge every sentence that sounds broader than its evidence. To build that evidence, use the requirement-to-evidence walkthrough. To express the source-only boundary consistently, use the control-labeling decision guide.