SOC 2 system description template
SOC 2 System Description & Management Assertion Template
A structured starting point for Section III and the management assertion, designed to surface missing boundaries, responsibilities, and evidence before review.
Use the reviewable outline below before deciding whether to start a guided workflow.
What this template helps you prepare
A SOC 2 system description is the narrative of the service organization and system that the engagement will examine. This template separates the description from the management assertion so a reviewer can check that both documents use the same scope, criteria, and period.
Use it to organize real inputs from architecture, service, security, and operations owners. It is not a substitute for the AICPA criteria, professional judgment, or your service auditor’s requirements.
Section III system description template outline
| Section | Include | Reviewer should confirm |
|---|---|---|
| Company and services | Legal entity, service description, intended users, and principal commitments | Services and commitments match contracts, customer materials, and engagement scope. |
| Trust Services scope | Security plus any applicable Availability, Processing Integrity, Confidentiality, or Privacy categories | Each selected category is supported by the system and control narrative. |
| SCSR | Principal service commitments paired with the technical or operational requirements that fulfil them | A promise such as uptime is paired with the requirements and controls that support it. |
| Five system components | Infrastructure, software, people, procedures, and data | Every component is described consistently with current architecture and operations. |
| Boundaries | In-scope and out-of-scope services, systems, locations, and teams | Boundaries are specific enough to prevent accidental scope expansion or omission. |
| Subservice organizations | Provider, service, carved-out or inclusive method, and relevant complementary controls | The method is explicit and related CSOCs are documented where needed. |
| CUECs | Specific actions user entities must perform | Each CUEC is actionable, relevant to the service, and not generic advice. |
| Control environment | Governance, risk assessment, communication, monitoring, and controls mapped to the selected criteria | Control statements agree with the rest of the description and supporting evidence. |
Management assertion checklist
| Assertion element | Include | Consistency check |
|---|---|---|
| System identification | The same organization and system named in the description | Entity, service, and scope match Section III. |
| Fair-presentation assertion | A separate assertion about fair presentation under the applicable description criteria | It refers to the correct description and criteria. |
| Control assertion | A separate assertion about suitable design for Type I, or design and operating effectiveness for Type II | The language matches the engagement type and agreed dates. |
| Criteria and period | Applicable Trust Services Criteria and a specific date or period | Dates and categories match the engagement and system description. |
| Signature block | Responsible management signatory and date | Authority and timing meet the organization’s and auditor’s process. |
Ready to turn this outline into a working draft?
Start the system description workflowStart with your real inputs. Rakenne guides the draft and checks its workflow rules; your qualified reviewer remains responsible for the final document.
Information to gather before drafting
- Proposed Type I or Type II engagement, including the as-of date or period to be reviewed.
- Architecture diagrams, data flows, service commitments, SLAs, and current descriptions of the service.
- The five system components: infrastructure, software, people, procedures, and data.
- System boundaries, locations, in-scope teams, subprocessors, and whether each subservice organization is carved out or inclusive.
- Candidate CUECs, CSOCs, policies, control records, and the owner who can verify each statement.
Checks to run, and what they do not decide
The matching workflow checks the working description for required sections such as services, SCSR, components, boundaries, subservice organizations, CUECs, CSOCs, and control environment coverage. It also checks that Security is in scope and that the selected Trust Services categories have supporting control-environment content.
Those checks identify omissions in a drafting workflow. They do not establish that a description is fairly presented, that controls are operating effectively, or that an assertion is appropriate. Management, the control owners, and qualified SOC 2 professionals remain responsible for those determinations.
Common review questions
How detailed should the system boundary be?
It should let a reviewer understand what is in and out without relying on assumptions. Name the relevant services, systems, locations, data, and organizational responsibilities; avoid a boundary statement that simply says “our production environment.”
What makes a CUEC actionable?
It tells the user entity what to do, for whom, and in what circumstance. For example, requiring administrative MFA and timely deprovisioning is more reviewable than advising users to “maintain good security.”
Can the same outline be used for Type I and Type II?
The structural sections are similar, but the control assertion and period must match the engagement. Confirm the final wording and dates with the service auditor before signing an assertion.
Related SOC 2 resources
- SOC 2 System Description & Management Assertion — guided intake, structural checks, and drafting workflow.
- SOC 2 audit readiness workspace guide — see the system description in a broader readiness workflow.
- SOC 2 Readiness Gap Analysis — assess missing controls and evidence before final review.
- Rakenne vs ChatGPT for SOC 2 control narratives — a related comparison using a fixed SOC 2 drafting scenario.