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.1 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.
Each part is below, followed by a complete Section 3 written for a fictional company, so you can see every part filled. The boundary is the part that costs engagements.
A SOC 2 system description template that stops at an outline of services, infrastructure, software, people and data leaves out the part that matters. The paragraph you write in an afternoon becomes a stated condition on your own assertion. The Word and PDF versions here carry a prompt for every part and the wording that gets sent back.
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.3 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 system description template, part by part
The parts run 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, 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 |
SOC 2 system description example: a filled Section 3
Below is a complete Section 3 for Moonrake, a fictional ten person company that sells API threat detection to fintech companies and runs on AWS, GitHub, Okta and Google Workspace. Every part of the template is filled, in the same order. The AICPA description criteria set what a description has to disclose,2 and this one discloses each of them in the voice a description uses: present tense, named systems, commitments a reader can test.
Moonrake, Inc., a fictional company
System Description, worked example
- Report
- SOC 2 Type 2, Section 3
- System
- The Moonrake platform
- Period
- 1 January to 30 June
- Categories in scope
- Security
- Prepared by
- Moonrake, Inc. management
1. Services and commitments
Moonrake, Inc. ("Moonrake") provides the Moonrake platform, a software as a service product that detects threats in the application programming interface (API) traffic of fintech companies. Customers install the Moonrake collector, a small component Moonrake publishes, in their own cloud environment. The collector sends metadata about each API call to the platform, which scores it for credential stuffing, unusual call patterns and policy violations and raises alerts. Customers read alerts and reports in the Moonrake web dashboard and through the Moonrake REST API.
This description covers the Moonrake platform for the period 1 January to 30 June and the Security category of the trust services criteria.
Moonrake makes the following service commitments in its master subscription agreement, its data processing addendum and the security page at moonrake.io/security:
- The platform is available 99.9 percent of each calendar month, excluding maintenance announced at least 48 hours ahead.
- Customer data is encrypted in transit with TLS 1.2 or higher and at rest with AES-256.
- Affected customers are notified within 72 hours of Moonrake confirming a security incident that involves their data.
- Customer data is deleted from production within 30 days of a subscription ending, and from backups as they expire.
- Only Moonrake staff who operate or support the platform can access customer data.
To meet those commitments, Moonrake sets the following system requirements in its policies:
- Every staff account signs in through Okta single sign on with multi-factor authentication.
- Production access is granted by role, approved by the Chief Technology Officer and reviewed every quarter.
- Every code and infrastructure change is reviewed by an engineer other than its author and passes automated tests before it is deployed.
- The production database is backed up continuously, and a restore is tested every quarter.
- Security events are logged centrally, kept for one year, and page the on call engineer.
2. System boundary
The system is the Moonrake platform and the infrastructure, software, people, procedures and data that support it. The platform runs in one production Amazon Web Services (AWS) account in the us-east-1 region, across three availability zones, with backups copied to a separate AWS backup account in us-west-2. In scope are the ingestion, scoring, dashboard and API services running on Amazon ECS with AWS Fargate; the Amazon RDS for PostgreSQL database; the Amazon S3 buckets holding customer reports; the AWS Key Management Service keys; the GitHub repositories and GitHub Actions workflows that build and release the platform and the collector; and the Terraform code that defines the AWS environment. Staff access is controlled through Okta and AWS IAM Identity Center.
Outside the boundary are the collector once a customer has installed it, which the customer operates in its own environment; the moonrake.io marketing site; and the billing and accounting systems. Moonrake operates no data center or server room, so physical and environmental controls belong to AWS and are carved out.
3. Infrastructure
| Component | What it is | Provider and region |
|---|---|---|
| Compute | Amazon ECS on AWS Fargate running the ingestion, scoring, dashboard and API services, in private subnets behind an Application Load Balancer | AWS, us-east-1, three availability zones |
| Database | Amazon RDS for PostgreSQL in a Multi-AZ deployment, encrypted with an AWS KMS key, with point in time recovery for 35 days | AWS, us-east-1 |
| Object storage | Amazon S3 buckets for customer reports and exports, versioned, with public access blocked | AWS, us-east-1 |
| Backups | Daily database snapshots and S3 replicas, copied to a separate backup account | AWS, us-west-2 |
| Network | One virtual private cloud, AWS WAF in front of the load balancer, and security groups defined in Terraform | AWS, us-east-1 |
| Keys and secrets | AWS KMS keys with automatic yearly rotation, and application secrets in AWS Secrets Manager | AWS, us-east-1 |
4. Software
| Purpose | Tool | What it does in the system |
|---|---|---|
| Application | Moonrake platform (Python services, React dashboard) | Receives call metadata from collectors, scores it, stores alerts, and serves the dashboard and the REST API |
| Collector | Moonrake collector | Runs in the customer environment, drops request and response bodies, and sends call metadata to the platform over TLS 1.3 |
| Source code and pipelines | GitHub and GitHub Actions | Code hosting, required pull request review, automated tests, and deployment to Amazon ECS |
| Infrastructure as code | Terraform | Defines the network, compute, database and access configuration. Changes go through the same review as application code |
| Staff identity | Okta and AWS IAM Identity Center | Single sign on with enforced multi-factor authentication, and short lived AWS sessions by role |
| Customer identity | Moonrake platform | Customer sign in to the dashboard with multi-factor authentication, and API tokens for the REST API |
| Logging and monitoring | Amazon CloudWatch and AWS CloudTrail | Application, infrastructure and audit logs, kept for one year, with alarms on errors, latency and security events |
| Alerting | PagerDuty | Pages the on call engineer when an alarm fires |
| Ticketing | GitHub Issues | Access requests, changes, incidents and review actions |
| Email and documents | Google Workspace | Staff email, policies and evidence records |
5. People
Moonrake has ten employees, most of whom work remotely in the United States and Canada. Company laptops are enrolled in device management, encrypted and set to lock after five minutes.
| Role | Reports to | Responsibility | Production access |
|---|---|---|---|
| Chief Executive Officer | Board of directors | Approves policies and accepted risks, and chairs the quarterly security review | No |
| Chief Technology Officer | Chief Executive Officer | Owns the security program, approves production access and runs the quarterly access review | Yes, administrator |
| Engineers (five) | Chief Technology Officer | Build and operate the platform. One is on call each week | Yes, by role |
| Customer success (two) | Chief Executive Officer | Onboard customers and answer support requests | No |
| Operations lead | Chief Executive Officer | Hiring, onboarding and offboarding, the vendor register and training records | No |
6. Procedures
| Process | How it runs | Governing policy |
|---|---|---|
| Access | Requested in a ticket and approved by the Chief Technology Officer, then granted through Okta groups mapped to AWS IAM Identity Center permission sets. Reviewed every quarter. Removed on the last working day through the offboarding checklist. | Access Control Policy |
| Change | Every change is a pull request. Branch protection requires one approving review from someone other than the author and passing tests, and GitHub Actions deploys the merged change. Nobody changes production by hand in the AWS console. An emergency change is reviewed within one business day. | Change Management Policy |
| Incidents | An alarm or a report opens an incident. The on call engineer sets the severity and runs the response, the Chief Executive Officer sends customer notices, and a written review follows within five business days. | Incident Response Plan |
| Vulnerabilities | Dependency and container scans run on every pull request. A third party penetration test runs once a year. Critical findings are fixed within 14 days. | Vulnerability Management Policy |
| Vendors | Every vendor is in the vendor register with a tier. The SOC 2 reports of tier 1 vendors are read and the review recorded once a year. | Vendor Management Policy |
| Backups and recovery | Continuous database backups, a restore test every quarter, and a recovery tabletop once a year. | Business Continuity and Disaster Recovery Plan |
| People | Background checks before a start date, security training at hire and once a year, and a signed acknowledgment of the policies. | Security Awareness Training Policy |
| Risk | The risk register is reviewed once a year and after any major change, and the quarterly security review checks open actions. | Risk Assessment Policy |
7. Data
Customer data is classified Confidential. It can include personal information, such as end user identifiers and IP addresses, and transaction metadata, such as amounts and merchant identifiers. The collector does not send request or response bodies.
| Data | How it arrives | Where it rests | How long it is kept |
|---|---|---|---|
| API call metadata | From the collector, over TLS 1.3 | Amazon RDS and Amazon S3, us-east-1, encrypted with AWS KMS | 90 days, rolling |
| Alerts and threat scores | Created by the scoring service | Amazon RDS, us-east-1 | Subscription term, then deleted within 30 days |
| Reports and exports | Generated when a customer asks | Amazon S3, us-east-1 | Subscription term, then deleted within 30 days |
| Customer user accounts | Created by customer administrators | Amazon RDS, us-east-1 | Subscription term, then deleted within 30 days |
| Logs | Application, infrastructure and AWS API activity | Amazon CloudWatch and AWS CloudTrail | One year |
| Backups | Snapshots and point in time recovery | Backup account, us-west-2 | 35 days |
8. System incidents
No system incident during the period resulted from controls that were not suitably designed or not operating effectively, or otherwise resulted in a significant failure to achieve Moonrake's service commitments and system requirements. The incident log records four security events triaged during the period. None involved customer data.
9. Subservice organizations
Moonrake uses the subservice organizations below and presents them using the carve out method: their controls are not part of this description, and the controls Moonrake assumes they operate are listed beside each one.
| Organization | Service | Method | Controls assumed of it |
|---|---|---|---|
| Amazon Web Services | Hosting, database, storage and key management | Carve out | Physical access to data centers is restricted to authorized staff, the facilities are protected against environmental threats, and storage hardware is wiped before disposal |
| Okta | Staff single sign on and multi-factor authentication | Carve out | The sign in service is available and enforces the policies Moonrake configures |
| GitHub | Source code hosting and build pipelines | Carve out | Repositories and workflow runners are protected from access by anyone Moonrake has not authorized |
| PagerDuty | On call paging | Carve out | Alerts are delivered to the on call engineer when sent |
Moonrake monitors each of them by reading its SOC 2 report once a year, checking the complementary user entity controls it assigns to Moonrake, and recording the review in the vendor register. Google Workspace holds staff email and documents but performs no control the platform commitments depend on, so it is a vendor rather than a subservice organization.
10. Complementary user entity controls
Moonrake designed its controls assuming that customers operate the controls below. They are needed, together with Moonrake's controls, to meet the service commitments.
| Control the customer operates | Owner at the customer | Frequency or trigger |
|---|---|---|
| The customer installs the collector, keeps it on a supported version and protects its API token. | Customer engineering | At install and at each release |
| The customer grants dashboard access only to people who need it, reviews that access, and removes it when someone leaves. | Customer administrator | Quarterly, and on each departure |
| The customer turns on multi-factor authentication for its dashboard users. | Customer administrator | At setup |
| The customer reviews Moonrake alerts and acts on them. | Customer security team | As alerts arrive |
| The customer tells Moonrake when it suspects its tokens or accounts are compromised. | Customer security team | On discovery |
11. Controls and criteria
| Control ID | Control, as it runs | Criteria |
|---|---|---|
| AC-01 | The Chief Technology Officer approves production access in a ticket before it is granted. | CC6.2, CC6.3 |
| AC-02 | Access to AWS, GitHub, Okta and PagerDuty is reviewed every quarter, and each change it finds is tracked to closure. | CC6.2, CC6.3 |
| AC-03 | Okta enforces multi-factor authentication for every staff account. | CC6.1 |
| EN-01 | Customer data is encrypted at rest with AWS KMS keys and in transit with TLS 1.2 or higher. | CC6.1, CC6.7 |
| CM-01 | Branch protection requires an approving review by someone other than the author and passing tests before a merge. | CC8.1 |
| MO-01 | Security alarms page the on call engineer through PagerDuty. | CC7.2 |
| IR-01 | Incidents are triaged by severity, handled under the Incident Response Plan and reviewed within five business days. | CC7.3, CC7.4, CC7.5 |
| BC-01 | A production database backup is restored to a separate environment every quarter and the result recorded. | CC7.5, CC9.1 |
| VM-01 | The SOC 2 reports of tier 1 vendors are reviewed once a year. | CC9.2 |
| RA-01 | The risk register is reviewed once a year and after any major change. | CC3.1, CC3.2 |
| HR-01 | Staff complete security training at hire and once a year. | CC2.2 |
The full list of controls, with the tests the service auditor performed and their results, is in Section 4 of the report.
12. Criteria not relevant to the system
Every criterion in the Security category is relevant to the Moonrake platform. CC6.4, restricting physical access to facilities and protected information assets, is met through the controls Moonrake assumes at AWS, which are carved out, rather than through controls Moonrake operates itself.
13. Changes during the period
| Change | Date | Effect on the system or its controls |
|---|---|---|
| The production database moved from a single instance to an Amazon RDS Multi-AZ deployment | 14 March | Failover between availability zones is now automatic. Backup and restore controls did not change, and the next quarterly restore test used the new deployment. |
| Long lived AWS access keys were replaced by AWS IAM Identity Center sessions through Okta | 2 May | Engineers now receive short lived credentials by role. From that quarter on, the access review covers Identity Center permission sets instead of access keys. |
Every row names a vendor, a region or a role, so every row is something an auditor can request evidence about. The procedures it describes are the ones your policies set, such as the information security policy and the vendor management policy. The watermarked sample report shows where Section 3 sits beside the assertion and the controls.
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.
Read section 2 of the Moonrake example as the model. It names the account, the regions, the components, the identity systems and the three things that are out, and it states why physical controls are carved 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.4 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 sets the size of the job. A Security scope keeps the description to the common criteria,5 and a category you add in the Polara GRC assessment brings its own criteria into it. Which criteria you need walks that choice.
Star is $2,000 one time, and Section 3 is drafted from the answers you give in the questionnaire rather than handed over as a blank outline. A Type 1 report is $2,000 more. On Orbit, $7,800 a year, your SOC 2 Type 2 audit is included in every contract year. The first one starts once the 3-month observation window has completed.
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?
Who writes the SOC 2 system description, the company or the auditor?
What goes in a SOC 2 system boundary statement?
Should you carve out or include your subservice organizations?
What happens if the system description is vague?
Is there a SOC 2 system description template I can copy?
What does a good SOC 2 system description example look like?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.