Glossary

What is a SOC report?

Key takeaway

A SOC report is the attestation a CPA firm issues after a SOC examination. What the four sections contain, what the auditor's opinion means, and the checks to run on a vendor's report.

What is a SOC report?

A SOC report (System and Organization Controls report) is the document a licensed CPA firm issues at the end of a SOC examination. It describes a service organization's system, lists the controls that were tested, and gives the auditor's opinion on them.

The word "report" does a lot of work here. A SOC report is not a certificate and not a pass/fail score. It is a narrative document -- commonly 30 to 100+ pages -- that a reader is expected to work through and form their own judgement about. That is why buyers ask for the report itself rather than a badge.

Three reports share the name. SOC 1 covers controls relevant to a customer's financial reporting, SOC 2 covers security, availability, processing integrity, confidentiality, and privacy, and SOC 3 is a short public-use summary of a SOC 2. For help choosing between them, see SOC 1 vs SOC 2 vs SOC 3.

What sections does a SOC report contain?

The AICPA publishes an illustrative SOC 2 report, and real reports follow its shape. It contains management's assertion, the description of the system, the service auditor's report, and the tests of controls and their results. In practice you will see them ordered like this:

SectionWhat it containsWho writes it
Independent service auditor's reportThe scope, the period covered, and the opinionThe CPA firm
Management's assertionManagement's formal statement that the system description is accurate and the controls are suitably designedThe service organization
Description of the systemInfrastructure, software, people, procedures, data, subservice organizations, and what was scoped outThe service organization
Tests of controls and resultsEach control, how the auditor tested it, and what the test foundThe CPA firm

Many reports add a fifth section, usually titled "other information". It is outside the scope of the examination and is not covered by the auditor's opinion -- management's response to an exception typically sits here. Read it, but weigh it differently from the four audited sections.

What does the auditor's opinion mean?

The opinion sits in the first section and is the fastest read in the document. Four outcomes are possible:

  • Unqualified -- the controls were suitably designed and, in a Type 2, operated effectively. This is the normal good result.
  • Qualified -- one or more controls were not designed or not operating effectively, and the auditor is naming the exception.
  • Adverse -- the problems are pervasive enough that the auditor cannot stand behind the system description or the controls.
  • Disclaimer -- the auditor could not gather enough evidence to form an opinion at all.

An unqualified opinion does not mean there were no exceptions. Exceptions are listed control by control in the tests-of-controls section, so read that section as well as the opinion.

Is there a SOC report example you can look at?

The AICPA publishes an illustrative SOC 2 report with an illustrative system description, which is the reference the audit profession works from. It is the closest thing to a canonical example and it shows the assertion, the description, the auditor's report, and the tests of controls in full.

Vendors' own reports are restricted-use documents, so you will not find a real one published openly. Ask the service organization directly and expect to sign an NDA first. A SOC 3 report, by contrast, is written for public distribution, so a vendor's SOC 3 is often available on request without one -- it is a useful shape reference even though it omits the detailed testing results.

What is the difference between a Type 1 and a Type 2 report?

A Type 1 report covers whether controls were suitably designed as of a single date. A Type 2 report covers whether those controls also operated effectively across a period, commonly three to twelve months.

The practical consequence is in the tests-of-controls section. A Type 1 has no operating-effectiveness testing to report, so that section is far thinner. Enterprise buyers generally want Type 2 because a snapshot says little about whether a control survives contact with a normal quarter.

How do you review a vendor's SOC report?

Most people meet a SOC report because procurement handed them one. Six checks cover most of the risk:

  1. Read the opinion first. Unqualified, qualified, adverse, or disclaimer.
  2. Check the period. A Type 2 covers a window, and that window has an end date. If it closed more than a few months ago, ask for a bridge letter covering the gap.
  3. Confirm the service you buy is in scope. The system description names the products and services examined. A company-wide report does not automatically cover the specific product in your contract.
  4. Read the exceptions, not just the opinion. Work through the tests of controls and look at what failed and how management responded.
  5. Check which criteria were included. Security is the baseline; availability, processing integrity, confidentiality, and privacy are included only if the service organization chose them. See Trust Services Criteria.
  6. Find your own obligations. Reports list complementary user entity controls -- things the report assumes you do. If you do not do them, the vendor's controls do not work as described.

How long is a SOC report good for?

A SOC report does not carry a formal expiry date. What it carries is a period, and the report says nothing about what happened after that period ended.

Convention in buyer security reviews is to treat a report as current for about twelve months from the end of the audit period, and to expect an annual refresh. Where there is a gap between the last period end and today, service organizations issue a bridge letter -- a short statement from management that nothing material changed in the interval. A bridge letter is management's word, not audited work, so it carries less weight than the report.

How does episki help with SOC reports?

episki holds the material a SOC examination runs on: controls with explicit pass, fail, or inconclusive verdicts rather than filed screenshots, evidence that carries provenance showing how it was gathered, and complementary user entity controls kept as structured records instead of a paragraph someone rewrites each year. The system description and the control narratives your auditor needs are drafted in the platform and approved by your team. Service auditors get guest access scoped to a single assessment, and it is not billed per seat. See the SOC 2 audit process for how a full engagement runs.

Dealing with this in your own program? episki's agents handle the drafting, mapping, and evidence work.

Start free trial

See how episki handles this

Start a free trial and explore controls, evidence, and automation firsthand.