A free SOC 2 system description template, part by part
You write Section 3, not the auditor. Here is every part, a filled example, a worked boundary, and the wording that comes back.
This SOC 2 system description template is free, and it matters more than its length suggests. Section 3 of the report is written by you, not the auditor.1 Your controls are then tested against your exact words, so each sentence you add is something someone will check.
The Word and PDF versions carry a prompt for every part. Below you also get a filled excerpt from a sample report and a worked boundary paragraph.
Narrow wording costs less
Each system, tool or team you name in Section 3 becomes part of what the auditor examines. Name an internal admin tool by accident and you owe evidence for it. Describe a second product loosely and it may get pulled in. That is extra hours for you and for the firm, on work no buyer asked for. Write only what the examination should cover.
The document is yours because independence demands it. A firm that drafted it would be examining its own writing.2 The auditor can tell you what must be covered and send back what it cannot test. It cannot write the words.
The thirteen parts to fill in
These appear in roughly this order in most reports. The last column shows the kind of wording that gets returned, which is useful to read before you start writing each part.
| Part | Write here | Gets sent back |
|---|---|---|
| Services and commitments | What the service does, who uses it, the commitments you make, and the system requirements behind them | 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 |
| System incidents | Incidents that came from a control failure or significantly failed a commitment: nature, timing, extent and disposition | No incidents occurred, when the incident log shows one. The log is read |
| 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 |
| Criteria not relevant | Any applicable criterion that does not apply to the system, and the reason for each | Not applicable, with no reason. An exclusion has to be explained |
| 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 |
What a filled Section 3 looks like
Here is how Section 3 opens in a sample report for Northwind Example Systems, Inc., a company that does not exist. The sample is marked as a draft and has no auditor opinion, since nobody examined it. Notice the voice: present tense, named systems, and commitments a reader can test.
Northwind Example Systems builds an analytics platform for mid-market operations teams. Northwind ingests customer operational data, models it, and serves dashboards, scheduled reports and a query API to mid-market operations teams.
Management represents the following in support of its commitments to user entities:
- Service availability with a target of 99.9%.
- Transport Layer Security (TLS) is used for all external connections.
- Databases and backups are encrypted at rest.
- Role-based access is used for production systems.
- Management reviews the overall security and compliance program at least annually.
| Service | Category | Purpose |
|---|---|---|
| Amazon Web Services | Cloud hosting | Cloud infrastructure provider |
| Okta | Identity provider | Identity and access management service |
| GitHub | Source code hosting | Source code hosting service |
| Datadog | Monitoring | Monitoring and observability platform |
Each row names a real vendor, so each row is something an auditor can ask evidence about. The full sample report goes on through infrastructure, software, people, procedures and data, in the same order as the parts table. The procedures it describes come from your policies, such as the information security policy and the vendor management policy.
A sample boundary paragraph
The boundary is where loose writing hurts most, and the damage is quiet. Nothing is rejected up front. Instead the auditor starts fieldwork by working out what is in scope, and every test after that carries the doubt. Here is one for an eight person company on Azure.
The system is the Harbor Metrics analytics application and its supporting infrastructure, hosted in one Microsoft Azure subscription in the East US region. In scope are the production App Service plan, the Azure SQL database holding customer records, the storage account for uploaded files, and the GitLab repositories and CI pipelines that build and release the application. Staff sign in through Microsoft Entra ID, which also controls access to the Azure subscription. The company website and employee laptops are out of scope. Harbor Metrics runs no data center of its own, so physical security rests with Microsoft and is carved out.
Every sentence names something: the subscription, the region, the components, the sign in system, and what is excluded. A reader could draw the line from this paragraph alone.
The vendors underneath you
Your system rests on vendors whose controls you cannot test yourself. The cloud runs the data center. The identity provider handles sign in. Name each one and state your method. With a carve out, you list the controls you assume the vendor operates, and the auditor tests your vendor oversight instead: the report you read, the review you did before onboarding. With the inclusive method the vendor’s controls sit inside your examination, which needs the vendor’s own assertion and cooperation. A small company will not get that from a hyperscaler. A list of vendors with no method leaves the reader guessing. Complementary user entity controls covers both methods, and how to tell if a report is real shows how a buyer reads your answer.
What your customers have to do
A carve out points down to your vendors. The complementary user entity controls point up to your customers. These are tasks the customer must perform so your controls deliver what Section 3 claims, and they are listed near its end. Write them as tasks with a pace and a trigger. “The customer reviews its admin users each quarter and removes access when an employee leaves” can be checked. “Customers are responsible for their own security” cannot.
How Section 3 ties to your signature
Section 2 is management’s assertion. It states that the description presents the system as designed and implemented and that the controls were suitably designed for the criteria in scope.3 An officer signs it, and the management assertion template has the wording. The auditor treats Section 3 as the terms of that statement. Claiming too much costs more than claiming too little, because you widened what is tested and then signed for it. The PBC list asks for this document before fieldwork. A Security only scope keeps it to the common criteria; the scoping tool shows when more is needed.4
Write it yourself, or have it drafted
With this template, a founder can draft Section 3 in a day. Hiring it out is priced differently:
- Comp AI states that a vCISO or compliance consultant might charge $150 to $400 an hour, which can total $20,000 to $50,000 for a full SOC 2 prep engagement. Source, checked 2026-07-30.
cybersoftware drafts Section 3 from your questionnaire answers, not as a blank outline, and keeps it in step with your evidence. Onboarding is $2,000 one time. Or choose $4,000 one time, which adds the SOC 2 Type 1 examination and report with the independent partner auditor fee included. Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. It starts once the 3-month observation window has completed. Take the free readiness assessment or see pricing.
cybersoftware 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?
Does the company or the auditor write it?
What should a boundary statement include?
Carve out or inclusive for vendors?
What goes wrong with a vague description?
Sources
Get audit-ready without a compliance team
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Start with a free readiness assessmentcybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.