SOC 2 system description template
A first draft of the system description for your SOC 2 report, built in your browser from the answers you gave the free policy generator. Facts the generator knows (hosting, tools, owners, data types, vendors, scope) are written in; everything else is a clearly marked placeholder. Word or Markdown, no signup.
What a system description is
Every SOC 2 report contains management’s description of the system being examined. In most reports it follows the auditor’s report and management’s assertion, and comes before the auditor’s description of the tests. It tells a reader what the service does, what the company has promised customers, what the system is made of, where its boundaries are, which vendors it depends on and what customers are expected to do themselves.
Management writes it and asserts that it is accurate. The CPA firm examines it alongside the controls and its report covers both, so the description is not marketing text: a statement that does not match how the system works becomes a problem in the examination. This template gives you a structured first draft. It does not decide anything for you, and it is not ready to hand over until you have replaced every placeholder.
What is in the template
- About this description: Draft status, who prepares and approves it, report type and period.
- Company overview and services provided: What the company does and which services the report covers.
- Service commitments and system requirements: What customers are promised and the requirements the policies set to deliver it.
- System components: Infrastructure, software, people, procedures and data, from your generator answers.
- System boundaries: What is in and out of scope.
- Trust Services Categories in scope: Security plus Availability or Confidentiality if you chose them.
- Subservice organizations: Hosting providers and vendors, with the method and the controls expected of each.
- Complementary user entity controls: Controls customers are expected to operate, as examples to confirm.
- Control environment, risk, communication and monitoring: How governance, risk assessment, communication and monitoring work.
- Changes and incidents during the period: Significant system changes and incidents, for a Type II report.
What the generator fills in, and what it leaves to you
The draft only states a fact when one of your generator answers supplies it. The rest is marked [Fill in: ...] with a note on what belongs there.
| Part of the description | Filled from your answers |
|---|---|
| Company and services | company name, product name, application type |
| Infrastructure | cloud and hosting providers |
| Software | source control, CI/CD, identity provider, MFA, device management, password manager, logging and backup tools |
| People | headcount, work model, Security Owner, approver, incident contact |
| Data | data types (personal, health, payment) |
| Categories in scope | Trust Services Categories you chose |
| Subservice organizations | hosting providers and the vendor list |
| Risk assessment | policy review cadence |
Always yours to write: your service commitments (quote your contracts, do not paraphrase them generously), the system boundaries, how each procedure actually runs, which vendors are subservice organizations and by which method, and for a Type II report the changes and incidents during the period. If you have not used the generator, the template still downloads with placeholders throughout; answering the 23 questions first saves most of the typing.
Common mistakes
- Describing the system you plan to have. The description has to match the system during the period. A control that starts next quarter does not belong in it yet.
- Commitments that go beyond the contract. If the description promises more than your customer agreement, the auditor tests the bigger promise.
- Every SaaS tool listed as a subservice organization. Only vendors whose controls you rely on to meet your commitments belong there; the rest live in the vendor inventory under the vendor risk policy.
- User entity controls copied from a vendor’s report. Your customers’ responsibilities depend on your product, not on your hosting provider’s.
- Vague boundaries. “Our platform” is not a boundary. Name the environments, accounts and services in scope, and what is out.
- Forgetting the period. A Type II description that does not mention a migration or a significant incident that happened during the period will be caught in testing.
The template, section by section
Below is the whole draft as it downloads for Northwind Cloud Inc, the fictional company in the sample Audit Kit. Your download carries your own answers instead.
Sample draft
Northwind Cloud Inc SOC 2 System Description
1. About this description
This is Northwind Cloud Inc's description of the Northwind system for its SOC 2 report. Management writes this description and states in its assertion that it describes the system as designed and operated. The CPA firm examines it alongside the controls and reports on both.
This draft was generated from Policyseed generator answers. Statements that come from those answers are written in; everything else is a placeholder. Replace every [Fill in: ...], remove anything that does not match how the system actually works, and agree the structure with your auditor, who may prefer a different order.
| Item | Value |
|---|---|
| Report type | [Fill in: Type I (a single date) or Type II (a period)] |
| Description as of / period covered | [Fill in: date, or start and end dates of the period] |
| Prepared by | Dana Whitfield, CTO |
| Approved by | Priya Natarajan, CEO |
| Version | Draft 0.1 |
2. Company overview and services provided
Northwind Cloud Inc provides Northwind, a web application delivered as software as a service. [Fill in: two or three sentences on what the service does for customers and who the customers are]
Services in scope
- Northwind: [Fill in: the features, environments and regions covered by this report]
- [Fill in: any other service included, or delete this line]
Services not in scope
- [Fill in: products, beta features or internal tools excluded from this report, or state that there are none]
3. Service commitments and system requirements
Principal service commitments
Northwind Cloud Inc makes security commitments to customers in its customer agreements, its order forms and any public security or trust page. Summarize the commitments a customer can rely on, and quote only what the documents actually say.
- Security: [Fill in: for example the protections described in the customer agreement or data processing addendum]
- Availability: [Fill in: the uptime or support commitment from your agreement or SLA, if any]
- Other: [Fill in: for example breach notification terms, data location, or delete this line]
System requirements
The requirements the system must meet to deliver those commitments are set by Northwind Cloud Inc's security policies, which management approves and reviews annually. The policies cover access, authentication, change management, secure development, vulnerability management, logging, incident response, backup, continuity, vendor management, data handling, encryption and endpoints. [Fill in: add any requirement from laws, regulations or contracts that applies to you]
4. System components
The system is made up of the infrastructure, software, people, procedures and data described below.
Infrastructure
| Component | Provider | Notes |
|---|---|---|
| Hosting and compute | AWS and Vercel | [Fill in: which services and regions run production] |
| Production data stores | [Fill in: databases, object storage, caches] | [Fill in: where customer data is stored] |
| Network edge | [Fill in: load balancers, CDN, DNS, firewall] | [Fill in: how traffic reaches the service] |
Software
| Purpose | Tool | Used for |
|---|---|---|
| Source control | GitHub | Code review and branch protection |
| Build and deployment | GitHub Actions | Automated tests and deployment to production |
| Identity provider | Okta | Workforce sign-in and access groups |
| Multi-factor authentication | Required for workforce accounts | Workforce authentication |
| Device management | Kandji | Laptop encryption, screen lock and updates |
| Password manager | 1Password | Storing and sharing credentials |
| Logging and monitoring | Datadog | Security logs and alerts |
| Backups | AWS Backup, daily | Backup of production data |
People
Northwind Cloud Inc has 11-50 people and works remotely.
| Role | Who | Responsibility |
|---|---|---|
| Security Owner | Dana Whitfield, CTO | Runs the security program and owns most policies |
| Approver | Priya Natarajan, CEO | Approves the policies and this description |
| Incident reporting contact | security@northwindcloud.example | Receives security reports from staff and customers |
| Engineering Lead | [Fill in: name and title] | Owns change management, development, logging and recovery |
| IT/Operations Lead | [Fill in: name and title] | Owns devices, assets and remote work |
| People/HR Lead | [Fill in: name and title] | Owns hiring, training and leaver steps |
Procedures
Northwind Cloud Inc's procedures are set out in its security policies. For each area, describe how the procedure actually runs.
| Area | Policy | How it runs |
|---|---|---|
| Governance and policy management | Information Security Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Risk assessment | Risk Assessment and Management Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Hiring, training and leavers | Human Resources Security Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Access provisioning and reviews | Access Control Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Authentication | Authentication and Password Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Change management | Change Management Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Secure development | Secure Software Development Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Vulnerability management | Vulnerability and Patch Management Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Logging and monitoring | Logging and Monitoring Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Incident response | Incident Response Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Backup and recovery | Backup and Recovery Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Business continuity | Business Continuity and Disaster Recovery Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Vendor management | Vendor and Third-Party Risk Management Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Data classification and handling | Data Classification and Handling Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Encryption | Encryption and Key Management Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
| Endpoint security | Endpoint and Workstation Security Policy | [Fill in: how it runs in practice: tool, cadence, record kept] |
Data
The system stores and processes customer data that includes personal information. Data is classified and handled under the Data Classification and Handling Policy. [Fill in: describe how customer data enters the system, where it is stored, who can reach it and how it is deleted; a data flow diagram helps]
5. System boundaries
The system boundary includes the Northwind production environment hosted on AWS and Vercel, the supporting tools listed above and the people and procedures that operate them.
- In scope: [Fill in: environments, accounts or projects included, for example production only]
- Out of scope: [Fill in: for example development and staging environments, corporate IT, other products]
- Services provided by the subservice organizations in section 7 are [Fill in: carved out or included].
6. Trust Services Categories in scope
This report covers the following Trust Services Categories:
- Security (the common criteria, included in every SOC 2 report)
- Availability
Processing Integrity and Privacy are not included.
7. Subservice organizations
Northwind Cloud Inc uses other organizations to deliver parts of the system. Only vendors whose controls are needed to meet the commitments in section 3 are subservice organizations; remove the rest from this table and keep them in the vendor inventory. With the carve-out method, which is common, the vendor's controls are excluded from the examination and the description lists the controls the company expects the vendor to operate.
| Organization | Service | Method | Controls expected of it |
|---|---|---|---|
| AWS | Hosting of production infrastructure | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
| Vercel | Hosting of production infrastructure | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
| Supabase | [Fill in: service it provides] | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
| Stripe | [Fill in: service it provides] | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
| Datadog | [Fill in: service it provides] | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
| Slack | [Fill in: service it provides] | [Fill in: carve-out or inclusive] | [Fill in: controls you rely on it to operate] |
Northwind Cloud Inc reviews each subservice organization's SOC 2 report or equivalent under its Vendor and Third-Party Risk Management Policy.
8. Complementary user entity controls
Some controls depend on customers. Customers are expected to operate the controls below; check each one against how Northwind actually works and delete what does not apply.
- Customers manage their own users' access to the service and remove users who no longer need it.
- Customers protect the credentials for their accounts and enable the sign-in protections the service offers.
- Customers report suspected security incidents to security@northwindcloud.example promptly.
- Customers decide what data they send to the service and that they are allowed to send it.
- [Fill in: any other control your product relies on customers to operate]
9. Control environment, risk, communication and monitoring
Control environment
Priya Natarajan, CEO approves the security policies, and Dana Whitfield, CTO is accountable for the security program. The Human Resources Security Policy requires background screening, security awareness training and policy acknowledgment; [Fill in: confirm which of these are operating and since when, or describe what is in place instead]. [Fill in: describe the management and oversight structure, for example board or leadership reviews of security]
Risk assessment
The Risk Assessment and Management Policy requires risks to the commitments to be identified, scored and treated, with a review every year. [Fill in: date of the last risk assessment and where the register is kept]
Information and communication
Policies are published to staff through [Fill in: where staff find the policies, for example the wiki or HR system], and security concerns are reported to security@northwindcloud.example. Customers are told about changes to commitments through [Fill in: channel, for example email or the status page].
Monitoring
Northwind Cloud Inc checks that controls keep operating through [Fill in: for example quarterly access reviews, alert review, an internal control review] and tracks deficiencies to closure in [Fill in: where deficiencies are tracked, for example the issue tracker].
Control activities
The controls that address each Trust Services criterion are listed in the controls section of the report, mapped to the criteria. Policyseed's crosswalk maps each criterion to the policy section that documents it.
10. Changes and incidents during the period
For a Type II report, describe anything during the period that a reader should know about. For a Type I report, delete this section.
- Significant changes to the system during the period: [Fill in: for example a new hosting region, a new identity provider, a major product change, or state there were none]
- Significant security incidents during the period: [Fill in: incidents that affected the commitments, or state there were none]
Download this template with your own answers. For the policies the description refers to, see the SOC 2 policies list; for the evidence behind the controls, the SOC 2 evidence checklist; for vendor reports to collect from subservice organizations, where to get vendor SOC 2 reports.
Frequently asked questions
- Who writes the SOC 2 system description?
- Management. The company describes its own system and signs an assertion that the description is accurate. The CPA firm examines the description together with the controls, and its report covers both. Auditors and readiness consultants often comment on drafts, but the text is the company's.
- How long should a system description be?
- Long enough that a reader who has never seen your company understands what the service is, what it runs on, who operates it and where its boundaries are. For a small SaaS company that is usually a handful of pages before the control listing. Length matters less than accuracy: every statement in it is something the auditor may test.
- What are complementary user entity controls?
- Controls your customers have to operate for your controls to achieve their purpose, such as managing their own users' access or protecting their API keys. They are listed in the description so a customer's auditor knows what the customer is responsible for. Only list the ones your product actually relies on.
- Is every vendor a subservice organization?
- No. A subservice organization is a vendor whose controls you need in order to meet your commitments, typically your hosting provider and any service that stores or processes customer data on your behalf. Other tools stay in your vendor inventory. The draft lists your hosting providers and vendors as candidates so you can remove the ones that do not qualify.
- Does the description change between Type I and Type II?
- The structure is the same. A Type I description is as of a single date. A Type II description covers the period and should also mention significant changes to the system and significant incidents during it, which is why the template ends with a section you delete for a Type I report.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.