How to read an assurance report when you are the seller

A customer asks, “Do you have an assurance report?” You send the file. The next question is harder: “Does this report prove the control I just asked about?”

That is where sellers need judgment.

An assurance report is evidence, but it is evidence with boundaries. The commercial mistake is to turn possession of the report into a universal statement about the product, the customer’s configuration or every security control.

The AICPA & CIMA overview of System and Organization Controls, published 23 April 2026, explains that different SOC engagements address different subject matter and user needs. Its resource library distinguishes reports relevant to financial reporting from reports addressing areas such as security, availability, processing integrity, confidentiality or privacy. [Source: AICPA & CIMA, 23 April 2026.]

For a seller, the first discipline is therefore basic: do not answer from the label alone.

Read what the report says it covers. If the customer asks about a control or service outside that description, the report may still be useful background, but it is not the evidence for the claim.

Which product, service, environment or component is actually inside the report?

Large suppliers often operate several services. A report for one hosted environment should not silently become evidence for another offering, a partner-operated service or a customer-managed component.

This is especially important in deals where responsibility is split. The supplier may operate the platform, while the customer controls identity settings, endpoint configuration, data classification or downstream integrations.

CISA’s Secure by Demand Guide, released 6 August 2024, makes a similar distinction in procurement: buyers should look not only at a supplier’s enterprise-security posture but also at how product security is handled. [Source: CISA, 6 August 2024.]

The seller should preserve that separation.

Assurance evidence belongs to a stated date or period.

When a buyer asks whether a report is “current,” do not improvise a definition. State the period shown in the report and, if relevant, route questions about coverage after that period to the assurance owner.

This matters when a product has changed, when a customer is evaluating a new service, or when a report covers a historical operating period. The seller should not convert an old period into a current operating claim merely because the file is still the latest report available.

The AICPA & CIMA SOC resource centre, updated 15 May 2026, describes SOC resources around defined criteria and specific types of reporting. [Source: AICPA & CIMA, 15 May 2026.]

A seller should therefore look for the exact control area or criterion relevant to the customer’s question.

If the buyer asks about access control, find the relevant evidence. If the question is about availability, do not substitute a statement about confidentiality. If the question concerns the customer’s own tenant configuration, do not point to a supplier control unless the report actually includes that configuration.

The right answer may be, “The report addresses the hosted control, while your tenant setting needs separate evidence.”

That is not a weak answer. It is a precise one.

Salespeople naturally look for clean conclusions. Assurance reports may contain exceptions, carve-outs, complementary controls or customer responsibilities that complicate the story.

Do not hide them.

An exception does not automatically mean the solution is unusable. It means the customer’s question has to be answered with the exception visible. The right internal owner can then explain remediation, compensating controls, current status or whether the issue is relevant to the proposed scope.

Likewise, a control that depends on customer action is not “fully covered” simply because the supplier has done its part.

An assurance report is rarely the only evidence in a security deal.

The buyer may also ask for architecture information, a penetration-test summary, data-flow details, contractual terms, incident processes, product-security documentation or a PoC result.

Do not make one document carry a claim that belongs to another.

A useful response pattern is: “This report supports this part of the question. This other evidence supports the next part. This remaining point is not established yet, and this owner is providing it.”

That structure turns assurance from a badge into decision evidence.

Do not say “we are compliant” when the evidence supports only a narrower statement. Do not say the report proves the customer’s environment is secure. Do not treat a report period as timeless. Do not erase exceptions because they are commercially inconvenient.

The seller does not need to become an auditor. The seller needs to know where the report starts, where it stops and who can answer the next question.

That is often enough to keep a security conversation credible.

Next step: Explore the ASTRA Cybersecurity Sales Specialist programme to practise using assurance evidence without stretching it beyond its documented boundary: https://www.astraready.com/programmes/