Templates · Last updated 31 July 2026 · 6 min read

The SOC 2 system description template, section by section

Section 3 is management’s document, not the auditor’s. What belongs in each part, and the wording that gets sent back.

The system description is Section 3 of a SOC 2 report, and you write it.¹ Not the auditor. Management asserts that it is accurate, and your controls are then tested against what it says rather than against what you meant.

All eleven parts are below, plus a worked boundary paragraph. The boundary is the part that costs engagements.

Every SOC 2 system description template you find is an outline. Services, infrastructure, software, people, data. All true, and all easy. Nothing in that outline tells you the paragraph you write in an afternoon becomes a stated condition on your own assertion.

This is management’s document

Section 3 is written by you, in your voice, about your system. A firm that drafted it would be examining its own work, and independence does not survive that.² The auditor says what has to be covered and sends back sentences it cannot test. The words stay yours.

The description is an input to the report, not a summary of it. A loose sentence in it widens what gets tested.

Write it narrow. Every claim you add is a claim somebody verifies.

The description, part by part

Eleven parts, in the order they usually appear. The middle column is what belongs there. The right column is what comes back, and it is worth reading first.

Part	What belongs in it	What gets sent back
Services and commitments	What the service does, who uses it, the commitments you make	A sentence about a secure, leading platform. No system in it
System boundary	The products and environments inside the examination, and what is outside	Our production environment and supporting systems. Names nothing, bounds nothing
Infrastructure	Cloud accounts, regions, networks, databases and object storage, by name	Hosted on a major cloud provider. One vendor is not an inventory
Software	The application, repositories, build and deploy pipelines, identity, logging, ticketing	Industry standard tooling. Nobody can request evidence from an unnamed tool
People	Roles that operate the system, who they report to, who holds production access	The team follows least privilege, written where a structure belongs
Procedures	How change, access, incidents and vendor review actually run	Policies are documented and maintained. A policy is not a procedure
Data	What customer data you hold, how it arrives, where it rests, how long you keep it	Retention stated as required by law, with no period behind it
Subservice organizations	Every vendor the description depends on, named, with your method stated	A vendor list with no method. Nobody can tell what was tested
User entity controls	What the customer must operate for your controls to achieve what you claim	Customers are responsible for their own security. Names nothing, moves nothing
Controls and criteria	Your controls, written the way they run, mapped to the criteria in scope	A control in the future tense. This section describes what runs
Changes in the period	Material changes inside a Type 2 window, and when each one happened	No significant changes, in a period that contains a migration

A boundary that bounds something

This is where descriptions fail, and they fail quietly. Nothing is rejected on the day. The auditor cannot tell what sits inside the examination, so fieldwork opens with a scoping conversation instead of testing, and every test after it inherits the ambiguity.

Vague reads as generous. It is the opposite. An undefined boundary lets an internal tool or a second product get pulled in, and you end up producing evidence nobody asked for.

Worked boundary paragraph, ten person software company

The system is the Acme web application and the infrastructure supporting it, running in a single Amazon Web Services account in one region. In scope are the production Kubernetes cluster, the primary PostgreSQL database, the object storage bucket holding customer uploads, and the GitHub repositories and Actions pipelines that build and deploy the application. Access to the application is controlled through Okta and access to the cloud account through AWS Identity and Access Management. The corporate laptop fleet and the Acme marketing site are outside the boundary. Acme operates no data center, so physical controls belong to Amazon Web Services and are carved out.

Five sentences, and each one names something: the account, the region, the components, the identity systems, and the two things that are out. A reader can draw the line on paper.

Subservice organizations, and the choice you state

Your description leans on vendors whose controls you cannot test. The cloud provider runs the data center. The identity provider holds the authentication. Name each one, then say which of two methods you used.

Carve out: You name the vendor, state the controls you assume it operates, and leave those controls outside your examination. What gets tested instead is your own vendor management: the review, the report you read, the assessment before onboarding.
Inclusive: The vendor’s controls sit inside your description and inside your examination. That needs the vendor’s cooperation and its own management assertion, which a ten person company will not win from a hyperscaler.

State the method in the sentence. A vendor list with no method leaves the reader unable to tell what was tested, and that reader is a security reviewer hunting for this gap. Carve out versus inclusive works through both, and how to verify a report shows what the person on the other side does with your answer.

The CUEC list

Carving a vendor out points down the stack. The complementary user entity control list points up it, at your customer. These are the controls the customer operates so that yours achieve what the description claims, and they sit at the end of Section 3.

Write them as tasks with an owner. Customers are responsible for security transfers nothing. The user entity reviews its administrative users quarterly and removes access when an employee leaves names a control, a frequency and a trigger, and a reader can tell whether they do it. How to word a CUEC puts weak and strong versions side by side.

The assertion, and what the auditor does with all this

Section 2 is management’s assertion. It is short. It states that the description presents the system as designed and implemented, and that the controls in it were suitably designed for the criteria in scope.³ You sign that.

The auditor then reads Section 3 as a stated condition on that assertion rather than as background, and tests your controls against your own wording. Which is why overclaiming beats underclaiming for damage. You widened the thing being tested, then signed for it. The planning request in the PBC list asks for this document before fieldwork opens.

Scope narrows the job. Polara G.R.C. scopes Security only, fixed rather than a setting, so the description covers the common criteria and nothing wider.⁴ Which criteria you need covers when that makes us the wrong fit.

Where this sits in what you pay

Type 1 is $4,000 one time, and Section 3 is drafted from the answers you give in the questionnaire rather than handed over as a blank outline. Type 2 is $600 per month on a 12-month term, and each examination is $5,000, available once the 3-month observation window has completed and the subscription is active.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Questions

What is the system description in a SOC 2 report?

It is Section 3, the part that describes the service being examined: what it does, where its boundary sits, the infrastructure and software inside it, the people and processes that operate it, the vendors underneath it, and the controls it runs. Management writes it and asserts that it is accurate. The auditor tests the controls against what it says.

Who writes the SOC 2 system description, the company or the auditor?

The company. A CPA firm that drafted your description would be examining its own work, and independence does not survive that. The firm will tell you what a description has to cover and will send it back when a sentence is untestable, but the words are yours and your name goes on the assertion that they are accurate.

What goes in a SOC 2 system boundary statement?

Named things. The specific products and environments inside the examination, the cloud accounts and regions that host them, the databases and repositories and pipelines that support them, the identity systems that control access, and an explicit list of what sits outside. A reader should be able to draw the line on paper from your paragraph alone.

Should you carve out or include your subservice organizations?

Carve out, in almost every small company case. The inclusive method puts the vendor controls inside your description and inside your examination, which requires that vendor to provide its own management assertion and sit for testing alongside you. Carving out means you name the vendor, state the controls you assume it operates, and have your own vendor management tested instead.

What happens if the system description is vague?

Fieldwork opens with a scoping conversation instead of testing, and the ambiguity is inherited by every test after it. A boundary that names nothing also lets systems nobody asked about get pulled in, so you end up producing evidence for an internal tool or a second product. Vague is not generous. It is a wider examination.

Sources

SOC 2 Report AICPA. What a SOC 2 report is and who may issue one. Checked 1 August 2026.
AICPA Code of Professional Conduct AICPA. Independence, integrity, commissions and referral fees. Checked 1 August 2026.
Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.
TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers. Checked 1 August 2026.

Get audit-ready without a compliance team.

$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.

Get started