What does a SOC 2 report example look like in practice?
A buyer who has been sent a SOC 2 report should expect the AICPA's illustrative Type 2 report to be the reference point. It has four parts: management's assertion, the description of the system, the service auditor's report, and the tests of controls and results. The organization owns the first two parts, because management writes the assertion and the system description. Only an independent CPA firm issues the service auditor's report and its opinion, and that opinion is the only part a reader should treat as the auditor's judgment.
The content of a real report changes with scope, system and period. A payments platform and a ticketing tool will describe different services, components, subservice organizations and principal commitments, and a Type 2 report covering twelve months will list test results that a shorter window would not. For that reason the illustrative report is a reference for structure and vocabulary, not a template to copy. The AICPA notes that the description criteria do not dictate a single format, so vendors present the same required information in different layouts. Readers should compare a vendor's report with the illustrative example to confirm each part is present, then check the specifics against the service they actually buy.
Start by confirming the four parts exist and that the system description names the services, boundaries and subservice organizations you depend on. Then check that the tests of controls and results cover the period you need, and that the auditor's report is signed by the firm. Ask the vendor to explain any section that appears generic. The AICPA's SOC 2 report walkthrough is a useful companion for a reviewer who has not read one before. A report whose descriptions and test procedures read the same as every other client's report deserves a direct question to the vendor and the CPA firm before you rely on it.
How much freedom the system description format allows
DC 200 is a set of description criteria, not a template, so two compliant system descriptions can look quite different. The cards below cover the nine areas (DC1 to DC9) that a reader should be able to find in any description, whatever order or layout the organization chooses.
Services and principal commitments
DC1 and DC2 cover the types of services provided and the principal service commitments and system requirements. Look for the commitments the organization made to customers, such as uptime or confidentiality promises, and the system requirements it set to meet them. A description that lists features without any commitments gives you nothing to test the report against.
System components and boundaries
DC3 requires the infrastructure, software, people, procedures and data that make up the system. This is where you confirm the report covers the production environment you actually use, including the hosting accounts, databases, admin consoles and third-party tools. If a component you depend on is missing, ask whether it sits inside the boundary or outside it.
Incidents and significant changes
DC4 covers significant system incidents during the period, and DC9 covers significant changes to the system. Both matter for a Type 2 report because they explain what the controls faced and what shifted underneath them. A description that reports no incidents over a long period should prompt a question about how incidents were defined.
Criteria, controls and exclusions
DC5 and DC8 cover the applicable trust services criteria with their related controls, and the criteria that do not apply to the system. Check that each in-scope criterion maps to a named control and that every exclusion has a stated reason. Vague exclusions often hide gaps the buyer would want to know about.
Complementary and subservice controls
DC6 and DC7 describe the complementary user entity controls the customer must run and the subservice organizations, with their own complementary controls. Confirm which cloud providers and tools are carved out, and whether the report says so explicitly. Your own responsibilities are often written here, so read this part with your internal team.
Layout is the organization's choice
Because DC 200 does not prescribe a format, one report may use tables and headings while another uses prose. Judge the content, not the layout: each of the nine areas should be findable, specific to this service, and consistent with the controls tested. Identical wording across unrelated vendors is a reason to look more closely, not a sign of rigor.
What the illustrative SOC 3 and representation letters show
The AICPA's illustrative SOC 3 report is a short, general use document. It contains management's assertion, a description of the boundaries of the system, the principal service commitments and system requirements, and the service auditor's report. Because it is designed for general use, it omits the detailed system description, the list of controls and the test results that appear in a SOC 2 report. A reader learns that an independent CPA examined the service against the Trust Services Criteria for the categories in scope, and what the organization says the system covers. The reader does not learn which controls were tested, how many samples were drawn, or whether any exceptions were found.
- Management's assertion: Management states that the description is fairly presented and that the controls meet the criteria in scope. This is the organization's own statement, examined by the auditor.
- System boundaries: The document defines which infrastructure, software, people, procedures and data are inside the examined system.
- Principal service commitments: It lists the commitments made to customers, such as availability or confidentiality promises, tied to the categories included.
- Auditor's report: The opinion covers the period or date stated, and the wording shows whether the opinion is unmodified.
- General use distribution: Because the SOC 3 is general use, it can be published on a website or sent to any prospect, unlike a restricted SOC 2.
Check that the categories and period in the SOC 3 match the service you buy, and that the auditor's report is signed by an independent CPA firm.
The illustrative management representation letter for a SOC 2 Type 1 examination is written by management and addressed to the service auditor. Under AT-C section 205, the service auditor must request written representations from the responsible party, because a SOC 2 is an assertion-based examination. The letter confirms that management has given the auditor the information it needs, that the description is complete and accurate as of the stated date, and that management takes responsibility for the design of its controls at that date. It is a record of what management told the auditor. It is not evidence that the controls work, and it is not an opinion.
- Addressee: The letter goes to the service auditor, not to customers, so it is not normally shared with prospects.
- Date alignment: The representations are tied to the Type 1 date, which must match the description and the opinion.
- Completeness statements: Management confirms it disclosed known incidents, noncompliance, and relevant changes, and that it made all records available.
- Design responsibility: Management confirms that the controls were suitably designed to meet the criteria in scope on that date.
- What it does not prove: The letter does not show operating effectiveness over time, so it cannot substitute for a Type 2 test of controls.
Ask the vendor whether its Type 1 description and letter are dated the same day, because a mismatch is a common reason a reader should question the scope.
The Type 2 representation letter follows the same logic but covers a period rather than a single date. The AICPA's illustrative Type 2 letter applies to reports dated on or after June 15, 2022, so a report issued after that date should carry representations in this form. Management confirms that the description fairly presents the system throughout the period, that the controls operated effectively for the whole period, and that it has disclosed all known deviations, including incidents, misstatements and noncompliance with the criteria. These statements matter because the Type 2 opinion depends on them. A reader can see that management committed to these points in writing, but the letter does not show what the tests found.
- Period coverage: The representations must span the full observation period stated in the report, not only the year-end date.
- Operating effectiveness: Management asserts that controls operated effectively throughout the period, which the auditor tests separately.
- Disclosure of deviations: Management confirms it told the auditor about exceptions, incidents and subsequent events it knew of.
- Subservice organizations: Statements about carve-out vendors and complementary controls should line up with the system description.
- What it does not prove: It does not replace the test results section, and a clean letter does not mean there were no exceptions.
Compare the period in the letter with the period in the report and the bridge letter, and look for any exceptions the description does not mention.
Why a SOC 2 report that reads like a template is a warning sign
A SOC 2 report that looks like every other report in a vendor folder is a reason to ask questions, not a reason to relax. The AICPA's peer review alert issued in May 2026 treats identical SOC 2 reports, identical risk assessments, identical sample sizes and identical testing procedures across engagements as risk indicators. The same alert notes that engagements found not to comply with standards in all material respects may be concluded nonconforming. For a customer, the practical meaning is simple: a report is only as reliable as the engagement behind it. When the system description, the risk assessment and the testing look copied from another client, the reader cannot tell whether the auditor tested this organization's controls, this organization's systems and this organization's period. Before relying on a report, ask the vendor which CPA firm issued it and whether that firm's peer review has been completed and is current, then check the firm's status through the public peer review resources.
Three other patterns deserve the same scrutiny. The first is a promise of compliance in weeks or hours. A Type 2 report covers an observation period, so no honest timeline can produce one on demand, and the AICPA's own commentary on fast and easy promises warns about this. The second is a report that is identical apart from the client logo. Ask the vendor to walk through the system description and point to the specific components, subservice organizations, complementary user entity controls and exceptions that belong to its own environment. The third is referral marketing that alludes to thousands of SOC 2 reports a year, or referral platforms promising favorable outcomes. Volume is not evidence of quality. Ask the referring party who performs the examination, who is independent of whom, and what the auditor, not the referrer, is responsible for. Remember that the vendor owns its controls and the CPA firm alone issues the opinion, so questions to the firm about its engagement letter, sampling approach and staffing are as important as questions to the vendor.
What to check in a report before you rely on it
A SOC 2 report only helps you if it describes the service you are buying, covers the period your contract needs, and was issued by a licensed CPA firm. The checks below take a reviewer from the cover page to the detail in the tests, and each one can be confirmed without specialist audit knowledge.
Does the system description name your service
Management's system description should name the actual product, the components that run it, the infrastructure hosting it and the locations involved. Check that the services and environments in the description match what you contracted for, not a broader family of products. If the description reads like a generic template, with the same wording for every client, ask the vendor which parts were written for their own system. Under the illustrative description format, the description should explain the boundaries of the system, so a missing boundary is a gap to raise before you rely on the report.
Does the period and report type fit
Confirm whether the report is Type 1 or Type 2 and whether the Type 2 observation period ends recently enough for your contract. A Type 1 report covers controls as designed on a single date, so it says less about whether they worked over time. Compare the period end date with the report issue date and with any bridge letter the vendor offers for the gap. Pick the report type your contract actually requires before you accept the report as evidence.
Do the tests show samples and exceptions
In a Type 2 report, the tests of controls section should describe what the auditor tested, how many items were sampled and what the results were. A report that says every control passed with no sample details, or that lists identical sample sizes and procedures across periods, deserves closer questions. Read the exceptions and the management responses together. An exception is not automatically a failure, but a report with no recorded results at all is not evidence of operating effectiveness.
Is the CPA firm licensed and verifiable
The report should be signed by a CPA firm. Verify the firm and the individual signing partner through CPAverify, the NASBA service that lets you confirm licensure. Also check that the firm is independent of the vendor and that the report carries the firm's name, its address and a date. A report from a firm you cannot verify, or one with an unclear signature, cannot be used to support a vendor risk decision until you resolve it with the vendor.
Are subservice organizations and CUECs described
Look for a list of subservice organizations, such as the cloud or hosting provider, and whether their controls are carved out or included. Then read the complementary user entity controls, which are the controls your organization must run for the vendor's controls to work. For each CUEC, decide whether your team owns it, and record that decision before you sign. If the report has no CUEC section for a system that clearly depends on your configuration, ask why.
How the example report is produced for a real engagement
The sequence runs from management's system description and assertion through representation letters, testing over the period, report drafting and the auditor's opinion, and each phase hands a defined output to the next.
Management prepares the system description
Management of the service organization writes the description of the system, covering the types of services, principal service commitments and system requirements, system components, and the criteria in scope. The description follows the AICPA's 2018 description criteria (DC 200), which do not prescribe a layout, so the organization chooses a structure that covers DC1 to DC9. The step closes when management has a draft description that names the boundaries of the system, the subservice organizations and the complementary user entity controls. Confirm with your CPA firm which format it expects before drafting.
Management drafts its written assertion
Management writes its assertion stating that the description is fairly presented and that the controls described were suitably designed and, for a Type 2 report, operated effectively over the period. Under AT-C section 205 the examination is assertion-based, so this document is the subject the auditor tests. The output is a signed assertion that matches the system description word for word on scope, categories and dates. Ask the auditor to review the assertion early, because a mismatch between it and the description stops fieldwork.
Auditor requests written representations
The service auditor asks management for written representations in a letter addressed to the auditor. The AICPA publishes separate illustrative representation letters for Type 1 and Type 2 examinations, and management adapts its letter to the engagement. The letter confirms matters such as the completeness of information provided, known instances of non-compliance and significant changes during the period. The output is a signed representation letter, dated and held in the engagement file, that the auditor relies on alongside its testing.
Auditor tests controls over the period
For a Type 2 examination, the auditor selects samples and tests whether each control in the description operated throughout the observation period, using inquiry, observation, inspection of documents and re-performance. Management supplies the populations, tickets, logs and approvals the auditor requests. The output is a set of test procedures, each with a sample, a result and any exceptions noted. A Type 1 examination instead tests whether controls were suitably designed as of a single date, so this phase is shorter. Confirm the test approach and sample basis in the auditor's engagement letter.
Management responds to exceptions
When testing finds a deviation, the exception is discussed with management, which may provide additional evidence or a response describing the cause and remediation. The auditor records the exception and management's response in the tests of controls and results. The output is a finalized list of exceptions with management's responses, which later determines whether the opinion is modified. Readers of the final report look at this section closely, so responses should describe what happened rather than claim the exception did not occur.
Auditor drafts the report
The auditor assembles the report: its own opinion, management's assertion, the system description, and the tests of controls and results. The SOC 3 illustrative report is a separate, shorter product drawn from the same examination. The output is a draft report that management reviews for factual accuracy, particularly the description and the dates. Management should check that the description still matches the systems that ran during the period.
Auditor issues the opinion
Once the draft is agreed, the service auditor issues the signed report containing its opinion on the description, the design of controls and, for Type 2, operating effectiveness over the stated period. Only the independent CPA firm issues this opinion, and the implementation partner or consultant has no role in signing it. The output is the final SOC 2 report, dated and restricted in use. Ask for the signed report directly from the auditor, and check the period, scope and categories against the service you intend to buy.
Which SOC report type fits which reader
This table compares the three SOC 2 report outputs by what each covers, who may receive it, and which reader it serves. Read the coverage row first, because it determines whether a report proves a design on one date or controls working over a period. The main takeaway is that a Type 1 report alone rarely answers a customer's question about ongoing operation.
| Report | What it covers | Distribution and reader |
|---|---|---|
| SOC 2 Type 1 | Management's description of the system and the suitability of control design as of a single date | Restricted use under an NDA. Useful to early-stage buyers who need evidence that controls exist, not that they have run over time |
| SOC 2 Type 2 | The same description plus an opinion on operating effectiveness over a stated observation period, with tests of controls and results | Restricted use under an NDA. The standard evidence for vendor due diligence, procurement reviews and contract clauses |
| SOC 3 | The trust services categories in scope, the system boundaries and principal service commitments, in less detail than a SOC 2 | General use and freely distributable. Suited to public trust pages and prospects who do not need control-level detail |
| Includes tests of controls and exceptions | Type 1: no. Type 2: yes, with any deviations reported in the service auditor's section | Type 1: not applicable. Type 2: review carefully, since a SOC 3 omits this detail |
| Ask the service organization for | Confirm the report type, the date or period, and whether the report is current for your contract | Confirm the report type, the observation period, and any bridge letter covering the gap to today |
Questions buyers ask about SOC 2 report examples
Is the AICPA illustrative SOC 2 report a template I can copy?
No. The AICPA's illustrative report shows the parts a SOC 2 report contains and how they fit together, but it is an example, not a form to fill in. Each real report must describe the service organization's own system, commitments, components, controls and test results. The DC 200 description criteria are not specific about format, so organizations may present the required information in different ways. What matters is that the content is specific to the system and the period examined. A report that matches the illustration word for word, with only the client name changed, is the kind of pattern an assessor or a peer reviewer would question. Use the example to learn what to ask for, not to write your own report.
Who writes the system description in a SOC 2 report?
Management of the service organization writes the system description, and management owns its accuracy. Under the 2018 description criteria (DC 200), the description must cover the services provided, service commitments and system requirements, system components, significant incidents, the applicable criteria and related controls, complementary user entity controls, subservice organizations, and significant changes during the period. An implementation partner or consultant can draft the text and check it against those criteria, but the independent CPA firm evaluates it and issues the opinion. Ask any partner to explain who signs the description and who reviews it before the examination starts.
Does a SOC 2 Type 1 example differ from a Type 2 example?
Yes, the differences are in the opinion and the testing section. A Type 1 report covers the system description and the suitability of control design as of a specific date. A Type 2 report adds an opinion on operating effectiveness over a period, and it includes the service auditor's tests of controls and their results. The AICPA publishes separate illustrative management representation letters for Type 1 and Type 2 examinations, and both require written representations from management under AT-C section 205. When reviewing a Type 1 example, expect no testing results table, and check that the opinion is dated as of a single date rather than covering a period.
Can a SOC 3 report replace a SOC 2 report for a customer?
Usually not for a customer doing due diligence. A SOC 3 report covers the same trust services categories in less detail, omits the detailed system description and the test results, and is a general use report that can be freely distributed. A SOC 2 report is generally restricted to specified parties, so customers and prospects receive it under an NDA. A SOC 3 suits a public statement of assurance, such as a trust page. A buyer checking controls, exceptions and complementary user entity controls still needs the SOC 2. If a contract names a SOC 2 Type 2, a SOC 3 does not satisfy it.
What does a SOC 2 examination ask of our internal staff?
It asks for ongoing, named ownership of controls, not a one-time document push. Staff need to operate the controls the report describes, such as access reviews, change approvals, incident handling and onboarding records, and keep the evidence those controls produce. Engineering, IT, HR and leadership each own pieces of this. Management must also sign the description and representation letter, so leadership needs to understand what it is attesting to. Expect the auditor's evidence requests to land on people who run the systems day to day. Ask a partner which tasks they will do and which will stay with your team, and how many hours of staff time they expect the plan to require.
Can a readiness partner prepare our evidence without issuing the SOC 2 report?
Yes, and that division of roles is the normal one. A partner such as DeployOpen can help prepare systems, controls and evidence, including the system description draft, control matrix, configuration records and evidence collection, but it does not issue audit reports, attestations or certifications. An independent CPA firm performs the examination and issues the opinion. Before engaging anyone, confirm in writing that the CPA firm is independent of the preparation work, which firm will test the controls, what the written scope covers, and who signs each deliverable. A fixed scope agreed before work starts makes these boundaries easier to check.
Who owns the report content and who signs the opinion
The organization that receives the SOC 2 report owns everything in it that describes its own business: management's assertion, the description of the system, the commitments it makes to customers, and the controls it says it operates. Only the independent CPA firm issues the service auditor's report and the opinion. Before the examination starts, the organization decides what goes into the system description, which criteria are in scope, and which subservice organizations are carved out. A partner can help draft those statements, but the signed assertion is management's, and the description has to match the systems people actually run. When you review a report, check that the description reads as the organization's own account and that the assertion is signed by a named person with authority to make it.
An implementation partner such as DeployOpen works on the other side of that line. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it can prepare the systems, configurations and evidence that support what management asserts. That work might include access reviews, logging, change records and backup tests, all gathered so the auditor can test them. DeployOpen does not issue SOC 2 reports, attestations or certifications, and it does not decide what the auditor concludes. Hiring a partner does not guarantee an outcome: the opinion depends on what the auditor finds when testing controls over the period, including any exceptions.
For the engagement itself, confirm in writing which party prepares each artifact before work starts: the system description, the control matrix, the evidence set and the representation letter. Ask the CPA firm which items it expects management to sign and which it will prepare with management, and ask the partner to state which evidence it delivers and which it does not. A clear division of responsibility is one of the first signs of a credible engagement. Any vendor or consultant who offers to produce the report, guarantee a clean opinion or shorten the examination should be treated as a warning sign, and your own compliance team should keep ownership of the assertion throughout.
How DeployOpen prepares systems and evidence for a SOC 2 examination
DeployOpen works on the systems and evidence behind a SOC 2 report, not the report itself. We prepare the self-hosted platforms, controls and records that an examination would test, inside your own infrastructure, so the organization and its independent CPA firm can review them against the AICPA's illustrative report structure. Only the CPA firm issues an opinion.
How we scope
- We agree a written scope covering which platforms, environments and Trust Services Criteria the examination will include.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work starts.
- We map each in-scope system component to the controls and evidence the system description would need to explain.
How we build
- We deploy and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We configure access, logging, change and backup controls so they produce records an auditor can sample.
- We document system boundaries and components in a format that supports a description aligned to the AICPA's description criteria.
How we hand over
- You receive control documentation, configuration baselines and an evidence index mapped to the in-scope criteria.
- We walk your team through where each record lives, who owns it and how to retrieve it for the CPA firm.
- Your organization keeps ownership of its controls, management assertion and representation letter, which it signs itself.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the handover.
- We can prepare evidence for the next observation period so records stay consistent across the examination cycle.
- Questions about what the auditor will test are directed to the CPA firm, which decides the procedures and issues the report.
