---
title: "SOC 2 system description: what to include, how to set scope, and a worked example"
canonical: https://www.grcmana.io/vault/soc-2/system-description
published: 2024-06-19
updated: 2026-10-23
author: "Harry West"
framework: "SOC 2"
control: "Guide SOC 2 system description: what to include, how to set scope, and a worked example"
journeyStage: readiness
---

# SOC 2 system description: what to include, how to set scope, and a worked example

## Key takeaways

A SOC 2 system description is management's account of the system in scope, prepared against the AICPA description criteria (DC 200), and it sets the boundary the auditor tests. It discloses the services, commitments, components, incidents, controls, customer and subservice dependencies and, for Type 2, significant changes. Firms holding ISO 27001 can reuse their scope statement, asset inventory and supplier register, but must write their customer commitments afresh.

- **Description criteria (DC 200)** — The AICPA benchmark for a SOC 2 system description. Management writes the description against it, and the service auditor uses it to judge whether the description is presented in line with it.
- **System boundary** — Everything the service depends on: its infrastructure, software, people, procedures and data. Where readers could be confused, the description also says what sits outside, such as invoicing.
- **Incident disclosure** — Only incidents that trace to a control weakness, or that seriously broke a customer commitment, are disclosed. Each entry says what happened, when, how far it reached and how it was resolved.
- **Significant changes** — A Type 2 description also records changes during the period that matter to most report readers, with enough detail to follow them, such as when each change happened.

Your auditor has booked fieldwork, and the US prospect's security team is waiting for the report. Then the auditor tells you management has to write the SOC 2 system description, and nobody on your team has seen one. It is the part of the report you write yourself, and it sets the boundary for everything the auditor tests.

This guide is for founders, COOs and security leads at UK B2B tech firms preparing a first SOC 2 report, often with ISO 27001 already in place. It walks through each disclosure the AICPA requires and the scoping calls behind them. Then it shows a worked example for an illustrative UK SaaS firm, and what your ISO 27001 work already gives you.

## What is a SOC 2 system description?

A SOC 2 system description is management's written account of the system in scope, prepared against the AICPA description criteria (DC 200). It sets the boundary the auditor tests. It covers the services, commitments and system requirements, components, incidents, controls, complementary user entity controls, subservice organisations and, for Type 2, significant changes.

The AICPA's [2018 SOC 2 description criteria](https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report) are the benchmark for preparing the description and for evaluating it. The criteria place the job with management, because management is responsible for the system. The auditor then gives an opinion on whether your description is presented in line with the criteria.

The description is not the controls themselves. Your controls are measured against the AICPA's [2017 Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). For what SOC 2 is and why buyers ask for it, start with our [SOC 2 overview](https://www.grcmana.io/vault/soc-2). For where the description sits among the other sections, see our guide to the [SOC 2 report](https://www.grcmana.io/vault/soc-2/report).

There is no prescribed format. The criteria say the description is usually narrative, and you may add flowcharts, tables or diagrams. The AICPA's own [illustrative SOC 2 report](https://www.aicpa-cima.com/resources/download/illustrative-soc-2-r-report-with-description-and-assertion) notes that firms may organise the required information in a variety of formats.

## What must the SOC 2 description criteria cover?

The SOC 2 description criteria set out nine areas a description must disclose, where they apply to your system. They are the services, your principal commitments and system requirements, the system components, significant incidents, the criteria and controls, customer-side controls, subservice organisations, any criteria that do not apply, and, for Type 2, significant changes.

In our words, each area asks a plain question:

| Disclosure area | What you explain | The question it answers |
| --- | --- | --- |
| 1. Services | The types of service the system delivers | What does the customer actually buy? |
| 2. Commitments and system requirements | The promises you make to customers, and what the system must do to keep them | What have you promised, and what has to be true for it? |
| 3. System components | Infrastructure, software, people, procedures and data | What is the system made of? |
| 4. Incidents | Incidents tied to a control weakness, or that seriously broke a commitment: what happened, when, how far it reached and how it was resolved | What went wrong, and what did you do about it? |
| 5. Criteria and controls | The trust services criteria in scope and the controls that address them | How do you meet the criteria? |
| 6. Complementary user entity controls | Controls you assumed your customers would run | What must the customer do for your controls to work? |
| 7. Subservice organisations | Suppliers whose controls you rely on, and how they are treated in the report | Whose controls sit outside your walls? |
| 8. Criteria not relevant | Any applicable criterion that does not apply to the system, and why | What is missing on purpose? |
| 9. Significant changes (Type 2) | Relevant changes to the system and controls during the period | What moved while the auditor was watching? |

Two rules from the criteria shape everything else. The extent of disclosure can vary with the size and complexity of the organisation, so a 60-person firm does not need a bank's description. And the description should not be so detailed that it could help a hostile party exploit a weakness. It explains the risks and how they are handled, not the exploit path.

The commitments area deserves the most thought. The criteria use a GDPR example. A privacy commitment left out of the description could influence a reader's decisions, so management would add it. For a UK firm, your UK GDPR obligations to customers usually belong here.

## How do you set the scope of a SOC 2 system description?

Set the scope of a SOC 2 system description through four decisions. Choose which service the report covers, which trust services categories sit alongside Security, where the system boundary falls across systems, people, locations and data, and how each third party your service depends on is treated. Each decision changes what the auditor tests and what customers can rely on.

The AICPA's [SOC 2 report review checklist](https://www.aicpa-cima.com/resources/video/key-elements-of-a-soc-2-report-resources-for-management) says the choice of categories in scope is management's, and should reflect the nature of the services provided. That makes scope a decision you own, not one the auditor hands you.

Scope is a commercial decision before it is a technical one.

### 1. Choose the service

Start with the service your customers are asking about, usually the product they buy and connect to their own data. If you also run a separate consulting arm, we recommend leaving it out unless customers rely on it. Name the service the way your contracts name it, so a customer's reviewer can match the two.

### 2. Choose the criteria beyond Security

Every description addresses the common criteria, which make up the Security category. Availability, confidentiality, processing integrity and privacy each add their own criteria on top. Add a category when customers rely on it and your contracts promise it, such as uptime commitments for availability. Our guide to the [trust services criteria](https://www.grcmana.io/vault/soc-2/trust-services-criteria) explains what each category covers.

### 3. Draw the boundary

The boundary takes in everything the service needs to run: its infrastructure, software, people, procedures and data. If readers could be confused, the criteria say the description may need to state what sits outside the boundary. Their examples include invoicing and bringing new customers onto the system. List locations too: offices, remote staff and the cloud regions that hold customer data.

When confidentiality or privacy is in scope, the boundary covers the whole life cycle of that information. That runs from collection to disposal.

### 4. Decide how each third party is treated

A subservice organisation is a supplier whose controls you rely on to meet your commitments, such as your cloud hosting provider. Under the inclusive method, the relevant parts of that supplier's system become part of your description and are identified separately. Under the carve-out method, they are excluded, and you describe the controls you expect from them. How each method reads to a customer is covered in the report guide. We recommend deciding the method for each provider early, and holding its current assurance report before fieldwork.

The checklist adds a question that is easy to miss. Reviewers ask whether the description mentions any tool used to prepare the SOC 2 report. They also ask who owns and hosts it, and whether it counts as a subservice organisation. If you use a compliance platform, decide the answer before the auditor asks.

## What does a SOC 2 system description example look like?

A SOC 2 system description example shows each disclosure area written for one real-shaped service. It covers what the firm sells, what it promises, what the system is made of, and where its responsibility ends. The example below is a fictional UK SaaS firm, written to show tone and level of detail. It is not a template to copy.

**Illustrative example only.** "ExampleCo Analytics" is a fictional 70-person firm in Manchester, invented for this guide. It sells a reporting platform to insurers and lenders in the UK and US. A US lender has asked for a SOC 2 Type 2 report. ExampleCo already holds ISO 27001.

| Disclosure area | Sample wording for ExampleCo (illustrative) |
| --- | --- |
| Services | "ExampleCo provides the ExampleCo Reporting Platform, a hosted service that ingests customers' loan and policy data and produces regulatory and portfolio reports. Professional services and training are outside the system." |
| Commitments and system requirements | "ExampleCo commits in its customer agreements to protect customer data from unauthorised access, to make the platform available in line with its published service levels, and to process personal data under UK GDPR as a processor. To meet these commitments, the system must restrict access to authorised users, encrypt data in transit and at rest, and back up customer data daily." |
| System components | "The platform runs on a public cloud provider in its UK region. Software comprises the ExampleCo web application, data pipeline and reporting engine. Engineering, operations and customer support staff run the system under documented procedures for change, access, incident response and backup. Data comprises customer-supplied loan and policy records and the reports generated from them." |
| Incidents | "ExampleCo identified no incidents during the period that arose from a control weakness or caused a significant failure to meet a service commitment." (Where an incident did occur, describe what happened, when, its effect and how it was resolved, without exploit detail.) |
| Criteria and controls | "The report addresses the Security and Availability categories. The controls supporting each applicable criterion are listed in section 4 alongside the auditor's tests." |
| Complementary user entity controls | "Customers are responsible for approving and reviewing their own users' access to the platform, and for notifying ExampleCo promptly when a user leaves." |
| Subservice organisations | "ExampleCo uses a public cloud provider for hosting and a third-party email service for notifications. Both are carved out. ExampleCo expects the hosting provider to maintain physical security and environmental controls at its data centres, and reviews the provider's assurance reports each year." |
| Criteria not relevant | "All applicable criteria for Security and Availability are relevant to the platform." (Had privacy been in scope while customers, not ExampleCo, collected the personal data, the description would explain why the collection criteria do not apply.) |
| Significant changes | "In month four of the period, ExampleCo moved its reporting engine to a new container platform. Change, access and monitoring controls were applied to the new platform from that date." |

Notice what the example does not do. It names no firewall rules, no internal hostnames and no encryption key details. Each sentence is something an auditor can test and a customer can rely on.

The AICPA also publishes an illustrative SOC 2 report with a full sample description, available to its members. Use it to see the shape, then write your own from the system you actually run.

## What can an ISO 27001 holder reuse for a SOC 2 system description?

An ISO 27001 holder can reuse the ISMS scope statement, the Statement of Applicability, the asset inventory, the supplier register and the incident log. Together they cover much of the boundary, components, third parties and incidents. What is new is the customer-facing narrative: written commitments, complementary user entity controls, and the subservice treatment.

| ISO 27001 artefact | Reuse it for | What still needs writing |
| --- | --- | --- |
| Clause 4.3 scope statement | The system boundary, locations and exclusions | Narrowing to one service if your ISMS covers the whole firm |
| Statement of Applicability | A starting map of controls to the trust services criteria | A mapping to the trust services criteria, which are organised differently from Annex A |
| Asset inventory | Infrastructure, software and data components | A narrative a customer can read, not a spreadsheet |
| Supplier register | Candidates for subservice organisations | The inclusive or carve-out choice, and the controls you expect from each |
| Incident log | Candidates for incident disclosure | A judgement on which incidents meet the disclosure threshold |

The [Clause 4.3 scope guide](https://www.grcmana.io/vault/iso-27001/clause-4-3-determining-the-scope-of-the-information-security-management-system) covers how an ISMS boundary is drawn along data flows, and the same thinking carries straight into a SOC 2 boundary. Your supplier assessments under [Annex A 5.19](https://www.grcmana.io/vault/iso-27001/annex-a-5-19-information-security-in-supplier-relationships) give you the evidence behind each carved-out provider.

The biggest gap is usually commitments. ISO 27001 asks what your interested parties require. A SOC 2 description asks you to state what you have promised customers, in words that match your contracts. We recommend starting from your standard customer agreement and data processing terms, then writing the system requirements that make each promise true.

## How does a SOC 2 system description change for a Type 2 report?

For a Type 2 report, the SOC 2 system description covers a period, not a single date. Incidents are disclosed for the whole period. The description must also add significant changes to the system and controls during it. Each needs enough detail for readers to understand it, such as when it happened.

The criteria expect significant changes to be those likely to matter to the broad range of report readers. Their examples include changes to the services, to key IT and security staff, to system architecture and applications, and to legal or regulatory requirements. On that reading, a migration to a new hosting platform or a new product module in scope would usually qualify. Routine releases would not.

The practical change is timing. A Type 1 description is written once, for one date. A Type 2 description is a record of a period, so it has to be kept as the period runs.

We recommend keeping a short change log alongside the description from the first day of the period. Record each significant change, the date, and the controls applied to it. At the end of the period, the changes disclosure is a summary of that log rather than an exercise in memory.

## What are the most common SOC 2 system description mistakes?

The most common SOC 2 system description mistakes are these: scoping too broadly, describing controls you intend to run rather than ones that operate, copying a template, over-sharing security detail, and leaving the boundary vague. Each one either widens what the auditor must test or creates a mismatch between the description and the evidence.

1. **Scope too broad.** Putting the whole company in scope adds systems, people and suppliers to every test. Start with the service customers are asking about.
2. **Aspirations, not operating controls.** The criteria say a description fails if it implies controls run when they are not performed. Statements that cannot be objectively checked, such as marketing language, fail too.
3. **Copying a template.** Wording lifted from another firm will not match your evidence. Auditors are held to the same test: the AICPA's peer review guidance, reported in the [Journal of Accountancy](https://www.journalofaccountancy.com/issues/2026/may/aicpa-guides-peer-reviewers-to-address-soc-2-risks/), flags audit engagements with identical reports, risk assessments and testing procedures as not responding to each client's risks.
4. **Too much security detail.** Detail that could help an attacker does not belong in a document your customers circulate.
5. **A vague boundary.** If a reader cannot tell whether a function is in or out, the description should say.

A description written from the policy folder describes the firm you mean to be, not the one the auditor will test.

A template describes somebody else's system.

The fix is the same for most of these. Write the description from the evidence you can produce today, and let the auditor's walkthroughs confirm every sentence. Done that way, the description stops being a writing task and becomes the clearest account of your service a customer will read.

## Frequently asked questions

### Who writes the SOC 2 system description?

Management writes it, because management is responsible for the system. The auditor evaluates it against the description criteria and gives an opinion on it. We recommend the security lead drafts it and leadership reviews it, since the commitments section speaks for the business.

### Can we use a SOC 2 system description template?

A template is useful for structure: the order of sections and the questions each one answers. The words must describe your own system. We recommend testing each sentence by naming the evidence behind it, such as a ticket, a log, a policy or a contract clause. A sentence with nothing behind it either comes out or points to a control you still need to build.

### How long should a SOC 2 system description be?

There is no set length. The criteria let the extent of disclosure vary with the size and complexity of the organisation and its services. A focused single-service description for a firm of under 100 people is far shorter than one covering several products, sites and subservice organisations.

### Do we have to disclose every security incident?

No. The description covers incidents that trace back to a control that was poorly designed or did not operate, and incidents that seriously broke a commitment to customers. Management judges which incidents meet that threshold, and the disclosure explains what happened without giving away exploitable detail.

### Can we change the system description after the audit starts?

Yes. Walkthroughs can expose wording that does not match how the system runs, and the description should be corrected. The final description must be accurate for the date or period the report covers. We recommend agreeing a cut-off for changes with your auditor before fieldwork begins.