What if a customer rejects my SOC 2 report?

Scope. The report covers a different product or entity than the one they’re buying, or only the Security criterion when their policy requires Availability or Confidentiality too. Age and type. The period ended too long ago, or you sent a Type 1 where their policy names a Type 2 — procurement checklists are literal about this.

Exceptions. Their reviewer read the testing section and hit a threshold: too many exceptions, repeats from last year, no management responses, or a qualified opinion. Subservice coverage. Your report carves out a subservice organization they consider critical, and nothing in hand covers it.

Whatever the trigger, make them name it in writing. “Rejected” almost always means a checkbox failed for a reviewer applying a written standard — and the written objection tells you whether the cure is a document you already have, a commitment you can date, or a genuine scope change. SOC 2 in due diligence maps how those reviewers work.

Stale period: bridge letter plus the next report’s date. Exceptions: management response, remediation evidence, and a short call between security teams. Missing criteria or wrong type: a dated contractual commitment to the expanded report next cycle — reviewers reject documents, but they routinely accept dated plans. Carve-outs: send the subservice organization’s own SOC 2 with your responsibility mapping. And when the checkbox truly can’t flex, escalate to a security-to-security conversation; that’s where standards get applied with judgment instead of literally.