The SOC 2 System Description, With an Example Structure

Direct answer: The system description is management's written account of the system being audited, and it forms part of the final report. You write it, your auditor reviews it, and it defines the boundary everything else is tested against. Get it wrong and you either pay to audit things you did not need to, or discover mid-period that something in production was never covered.

What it has to cover

The services you provide and to whom. The infrastructure, software, people, procedures and data that make up the system. The boundary, stated clearly enough that a reader knows what is excluded. Your subservice organisations and how you treat them. The controls that meet the criteria. Any relevant changes during the period.

An example structure

Section 1, overview: what the company does and which product the report covers. Section 2, boundary: the production environment, named regions, named data stores, plus what is explicitly out, such as the corporate website and internal analytics. Section 3, components: infrastructure, applications, the people involved by role, the data handled and its classification. Section 4, subservice organisations: your cloud provider and any processor, with whether you use the carve-out or inclusive method. Section 5, controls: mapped to the criteria. Section 6, changes in the period.

The boundary mistakes

Drawing it too wide is the expensive one. Including the corporate network, every internal tool and the marketing site means auditing all of it. Drawing it too narrow is the dangerous one: if the boundary excludes something customer data actually flows through, a sharp reviewer will notice the report does not cover what they are buying.

The third is leaving it static. Boundaries move when you add a region, a data store or a product, and the description has to move with them.

Carve-out versus inclusive

Almost every startup uses carve-out for its cloud provider: you state that the subservice organisation's controls are excluded and describe the complementary controls you assume they operate. Inclusive means your auditor tests their controls too, which is rarely practical for a hyperscaler and occasionally right for a small critical processor.

Write it before fieldwork

Teams that write it at the end are describing what happened rather than defining what was tested, and it shows. Draft it during scoping, agree it with your auditor, and treat it as the document everything else hangs off.

Scoping the boundary is the first thing we do in SOC 2 in 75 Days, because every other cost in the programme follows from it.

Where the description sits in the finished report

Understanding the anatomy of the report explains why this document carries so much weight. A SOC 2 report has a standard structure. Section I is the service auditor's opinion, written and signed by the CPA firm. Section II is management's assertion, written and signed by you, in which you assert that the description is fairly presented and that the controls were suitably designed and, for a Type II, operated effectively throughout the period. Section III is the system description. Section IV is the controls, the criteria they map to, the auditor's tests and the results. Section V is other information provided by management, which the auditor does not opine on.

Two consequences follow. First, you are signing an assertion about the accuracy of your own document, which is why "we will tidy it up later" is a poor plan. Second, everything the auditor tests in Section IV is bounded by what you wrote in Section III. A control you operate beautifully but never described does not appear in the report, and a system you described but do not control creates an exception. The description is the contract between what you claim and what gets examined.

The description criteria the auditor is marking against

The description is not free-form prose graded on taste. It is assessed against the AICPA description criteria, which set out what must be present for a description to be considered complete and fairly presented. In practice, the ones that cause the most rework are the requirement to state the types of services provided and the principal service commitments and system requirements, the requirement to describe the components of the system including infrastructure, software, people, procedures and data, the requirement to disclose the applicable trust services criteria and the related controls, the requirement to describe subservice organisations and the complementary controls assumed of them, the requirement to describe complementary user entity controls, and the requirement to disclose relevant changes during the period.

Principal service commitments and system requirements is the clause most first-timers skip past. It means stating what you have promised customers, drawn from your contracts, service level agreements, published documentation and privacy notice, plus the internal requirements you set in order to keep those promises. If your master service agreement promises 99.9% availability and 24-hour breach notification, those belong here. This clause is also where descriptions quietly break, because teams write commitments more generous than the controls in Section IV can support, and the auditor is obliged to notice the mismatch.

A worked boundary paragraph

Generic guidance is easy to agree with and hard to apply, so here is the shape of a boundary section that survives auditor review, written for a typical single-product Canadian SaaS running on one cloud provider.

"The system comprises the production environment supporting the [Product] platform, hosted in [Provider] region ca-central-1. In scope: the application services running in the production account, the primary relational database and its replicas, the object storage buckets holding customer-uploaded documents, the message queue and background workers, the production identity and access management configuration, the logging and monitoring pipeline serving production, the source code repositories and CI/CD pipeline used to deploy production changes, and the corporate identity provider used to authenticate personnel to those systems. Personnel in scope are the engineering, infrastructure, security and customer support functions, and the executive team to the extent of governance responsibilities. Data in scope is customer-submitted content, customer account and user records, and system-generated logs. Excluded from the system: the corporate marketing website and its content management system, the internal business applications used for finance and human resources, the sales customer relationship management platform, and the separate development and staging environments, which contain no customer production data."

Read that last sentence and notice how much work it does. It excludes staging on a stated factual basis. If somebody restores a production backup into staging to debug an issue, the exclusion is no longer true, the description is misstated, and you have created an exception. Every exclusion you write is a commitment about how the organisation behaves, and it needs someone who knows whether it is true.

Complementary controls, in both directions

Two categories cause confusion because the names are similar and the audiences are opposite. Complementary subservice organisation controls are the controls you assume your cloud provider or processor operates, stated because you carved them out. Complementary user entity controls are the controls you assume your customers operate in order for your controls to be effective, such as managing their own users, configuring single sign-on properly, protecting their API credentials, and reviewing their own audit logs.

The failure mode is writing too many user entity controls in the hope of transferring responsibility. A description listing twenty-five things the customer must do reads as an attempt to shift risk, and reviewers at enterprise buyers do read them. Worse, each one is a statement that your control environment depends on someone else, which is not the impression you want to leave with the buyer whose security team is deciding whether to approve you. Keep them to the handful that are genuinely true and genuinely under the customer's control. On the subservice side, keep the assumed controls specific enough to be checkable against the provider's own SOC 2 report, since a mature reviewer may line them up.

Type I and Type II wording, and the mid-period change problem

A Type I description is written as of a date. A Type II description is written for a period, and the tense matters throughout: the system as it operated from a start date to an end date, not the system as it stands today. That distinction becomes real the moment something changes mid-period, which on any active engineering team it will.

Adding a region, migrating a database, replacing an identity provider, launching a second product or acquiring a team all change the system inside the window. The description has to describe that change and the date it happened, and Section IV has to reflect that some controls operated in one configuration for part of the period and another configuration for the rest. Auditors handle this routinely as long as you tell them early. The way it goes wrong is the team completing the migration in month seven, nobody telling the auditor, and the evidence for months one to six describing infrastructure that no longer exists. Put a standing item on your engineering leadership agenda: does anything we shipped this month change the description. Ninety seconds a month prevents the most expensive conversation in the entire audit.

Incidents and known deficiencies

The description criteria require disclosure of relevant details of any identified security incidents during the period that were disclosed to affected customers, and the description should also address known deficiencies where they are material to a reader's understanding. Founders reliably want to omit this, and reliably should not.

Handled well, a disclosed incident strengthens the report rather than weakening it. State what class of incident occurred, when it was identified, how it was contained, who was notified, and what changed as a result. What damages you is a customer discovering an incident through another channel and then reading a report that did not mention it, because that turns a contained operational event into a credibility problem across the whole document. The same logic applies to control exceptions in Section IV. Reports containing exceptions with a clear management response are normal, and buyers who read a lot of reports know it.

The edits your auditor will ask for

Descriptions come back from first review with a predictable set of comments, and knowing them saves a round trip. Marketing language gets struck, so "bank-grade security" and "military-grade encryption" are replaced with the algorithm and key management approach. Absolute claims get qualified, because "all data is encrypted" is rarely literally true once you consider logs, backups and caches, and the auditor will ask you to prove the absolute version. Vague ownership gets named, so "the team reviews access quarterly" becomes a role. Commitments that overshoot the controls get pulled back to what Section IV supports.

Copied text gets found. Descriptions assembled from another company's report or a template carry architecture that does not match your diagrams, and it is obvious to a reviewer who has read the same template. Length is worth calibrating too: a single-product SaaS description usually runs somewhere between eight and twenty pages. Much shorter and it is probably missing a description criterion. Much longer and it usually means the boundary is too wide, which costs money in every other line of the project.

The description as a sales asset

Once written, this document does more work than any other artefact in the programme. Your trust centre content, your questionnaire answers about architecture and data flows, your subprocessor disclosures and your data residency statements should all be consistent with it, because the buyer receiving both your questionnaire response and your report will compare them. Inconsistency between the two is one of the more common reasons a security review stalls, and it is entirely self-inflicted.

Treat the description as the source of truth and derive the other answers from it rather than maintaining parallel narratives. Keeping the description, the asset inventory, the vendor register and the control set in one place makes that far easier, which is how the free Workspace is arranged. The alternative, which we see constantly, is a description in a document, a trust centre written by marketing, and questionnaire answers written by whoever was free that week, all drifting apart across a year.

Cost drivers hiding inside the description

Every scoping decision in this document translates into money elsewhere. Each additional system in the boundary adds evidence collection, adds population for sampling, and adds auditor hours. Each additional trust services category beyond Security adds criteria, controls and testing, and availability and confidentiality are cheap additions when the controls already exist while processing integrity is expensive and rarely required by buyers. Each subservice organisation treated as inclusive rather than carved out adds testing you have to coordinate at another company.

The pattern that reliably wastes money is a wide first-year boundary chosen out of caution. Narrowing it later is possible but awkward, because a buyer comparing this year's report with last year's will ask why the scope shrank, and the honest answer sounds worse than it is. Getting the boundary right the first time is the highest-leverage hour in the programme, which is why boundary definition is the opening work in our compliance engagements rather than something handled after the policies are written.

When you should write it yourself, and when not to do it at all

If you have chosen an auditor, they have given you a description template, your architecture is one product on one cloud provider, and you have somebody internally who can write clearly and knows the infrastructure properly, write it yourself. It will take that person two to four days spread over a fortnight, and it will be better than an outsourced version because the exclusions will reflect what actually happens. Send the draft to the auditor early and expect one round of edits. Paying a consultancy several thousand dollars to interview you and write down your own architecture is a poor trade in that situation.

Get help when the boundary is genuinely contested: multiple products sharing infrastructure, a recent acquisition, an on-premises deployment alongside the SaaS, or a subservice organisation you may need to treat as inclusive. Those are judgement calls where a wrong answer costs more than the advice. Get help too if a signed customer contract already commits you to a delivery date, since the boundary decision and the observation period have to be worked backwards from it.

And be willing to conclude that the report is not the right purchase yet. If one prospect is asking and they would accept a completed questionnaire, a current penetration test attestation and a documented roadmap with dates, then supplying those is a fraction of the cost and closes the same deal. SOC 2 becomes the right answer when several buyers ask, when a contract requires it, or when your sales cycle is repeatedly stalling in security review. Writing a beautiful system description for a report nobody asked for is a lot of effort spent on an artefact that sits unread. If you are unsure which position you are in, tell us who is asking and what they said, because the answer usually takes one conversation rather than a project.

Maintaining it between audits

The description is an annual document that most teams treat as a one-off, which is why year two costs more than it should. Keep it in version control alongside your architecture diagrams rather than in a document that gets emailed around, so each year's version is a reviewable diff. Attach the review to a trigger rather than a date: any new region, any new data store holding customer content, any new subprocessor, any change to how personnel authenticate to production, any new product surface. Those five triggers cover almost every change that has ever forced a mid-period amendment in engagements we have run.

When the next observation period opens, start from last year's description, mark the changes, and send it to the auditor before fieldwork rather than during it. Teams that do this spend a day on the description in year two. Teams that start fresh spend the same three or four days they spent the first time, plus the arguments about exclusions they already settled once. The document is also the natural place to record why an exclusion exists, in a comment or an internal annex, because the person who knows why staging was excluded may not be there next year and the reasoning is what an auditor asks for when they push on it.