Section 3
From scattered notes to a Section 3 your auditor can test.
Your CPA firm will read, test and give an opinion on the system description, yet every word of it belongs to you. Most of the effort is not writing. It is collecting facts from a dozen owners, then trimming each sentence until it was true for the whole period and a record can back it up.
Back to SOC 2 services01 · Who holds the pen
Management drafts; the CPA firm evaluates
Keeping those roles apart is what lets the opinion stay independent.
The description is management's representation about its own system, and the management assertion printed beside it says so in writing. The service auditor then decides whether it is fairly presented when measured against the AICPA's description criteria, published as DC 200. A firm that drafted the text would be grading its own homework, so independence rules keep it out of the drafting. An adviser can gather material and edit. The people who sign the assertion own the final wording.
- Management
- Decides what the system is, approves the text and signs the assertion that it is fairly presented.
- Control owners
- Supply the facts for their area and confirm that each sentence about it still holds.
- Readiness adviser
- Structures the draft, asks the awkward questions and checks it against DC 200 before the auditor reads it.
- Service auditor
- Tests the description against DC 200 and the controls against the Trust Services Criteria, then reports.
02 · Gather first
Where the raw material for each item sits
Nine items, many owners. Collect before you draft.
DC 200 names nine things a description must cover where they are relevant, labelled DC1 to DC9. A strong draft begins life as a request list, not a blank page. The table maps each item to where its facts usually sit in a growing software company, and to the person who can vouch for them.
| Item | What it covers | Where the facts usually are | Who confirms |
|---|---|---|---|
| DC1 | The kinds of service the system delivers | Product pages, order forms, the master services agreement | Product lead |
| DC2 | Principal service commitments and the system requirements behind them | Contracts, SLAs, the security addendum, the privacy notice | Legal or commercial lead |
| DC3 | Components: infrastructure, software, people, procedures and data, plus the boundary | Architecture diagrams, cloud account inventory, data-flow maps, the org chart | Engineering lead |
| DC4 | Incidents that came from controls not working, or significant failures | Incident tracker, postmortems, customer notices | Security lead |
| DC5 | The applicable criteria and the controls designed to meet them | The control matrix built during readiness | Compliance owner |
| DC6 | Controls the design expects customers to run (CUECs) | Onboarding guides, admin settings customers manage | Customer success |
| DC7 | Subservice organizations, how each is presented, and controls expected of them (CSOCs) | Vendor register, the vendors' own SOC reports | Vendor risk owner |
| DC8 | Applicable criteria that do not apply, with the reason | The scoping memo | Compliance owner |
| DC9 | For a Type 2, significant changes during the period | Change log, architecture decision records, key hires and exits | Engineering and HR |
How a service auditor measures a description against these items is the subject of our DC 200 guide. This page stays with the job of getting the text written.
03 · Testable claims
Sentences a tester can tie to a record
If nothing could prove a claim, cut it or rebuild it.
The auditor will try to match each claim in the description with evidence. A sentence that names a role, an action, a frequency and a system can be checked. One built on adjectives cannot, and it invites questions nobody can answer. The rewrites below are illustrative.
| Draft sentence | What goes wrong | Rewrite |
|---|---|---|
| We follow industry-leading security practices. | No action, no owner, nothing to sample. | The security lead reviews production firewall rules each quarter and records the review as a ticket. |
| Access is reviewed regularly. | No frequency, so no way to judge whether it ran. | Team leads confirm the user list for each production system every quarter; removals are raised as tickets. |
| Arjun deploys all releases. | Names a person who may leave mid-period. | A platform engineer deploys each release after a second engineer approves the merge. |
| Data is encrypted with the latest algorithms. | Unprovable, and it goes stale. | Customer data in the production database is encrypted at rest through the cloud provider's managed key service. |
- Give the frequency a control truly operates at. The auditor builds the list of expected occurrences from it, so a weekly claim for a monthly habit manufactures misses.
- Prefer roles to names and functions to product versions. Both change inside a twelve-month window.
- Describe only what ran across the entire period. A tool switched on in month five needs its date, and it belongs in the DC9 changes too.
04 · Parts teams soften
Four disclosures drafters tend to water down
Incidents, changes, exclusions and customer duties all need plain words.
- Incidents (DC4). Name the incidents that came from a control failing or from a significant breakdown, and say how you responded. Dropping one because it is awkward risks the description being judged as leaving out something a reader needed.
- Changes (DC9). A migration, a new hosting region, a new identity provider or a new head of security all belong here, each with the date it took effect.
- Criteria you set aside (DC8). When an applicable criterion does not fit, give the reason in a sentence, for example that the service takes no payments and holds no physical media.
- Customer duties (DC6). Keep each CUEC to a task only the customer can perform, such as managing their own users in your admin console. A long list reads as pushing your work onto them.
Our guide to complementary controls shows how to word CUECs and CSOCs so each one can actually be checked.
05 · Review loop
Reviewing the draft before the auditor reads it
Three internal passes and one sign-off catch most problems.
- Owner pass. Each control owner reads only the paragraphs about their area and flags any sentence that is untrue today or was untrue when the period began.
- Evidence pass. Someone outside that team picks a handful of claims and asks for the record behind each. Claims with no record are rewritten or removed.
- Reader pass. A person who knows your customers reads it as a buyer would and asks what is missing: a vendor that touches their data, an outage they remember, a feature the text skips.
- Sign-off. Management approves the final text and the assertion together, so the two documents say the same thing.
The service auditor will still send comments after reading. Treat them as one more evidence pass rather than an editing service: the firm can point at gaps, but closing them is management's job.
Sources: AICPA, DC section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (with revised implementation guidance, 2022); AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy; AICPA, AT-C section 205 (examination engagements).
06 · Go deeper
Go deeper
Dedicated pages on topics this guide only touches.
- DC 200: what a system description is measured againstThe description criteria, and how an auditor tests a description.
- The AICPA attestation standards, mappedHow SSAE 18, the AT-C sections and the SOC suites fit together.
- Complementary controls: what customers and vendors owe the systemCUECs and CSOCs, written so they can actually be checked.
Questions teams ask while drafting
Does the description need to list every control we run?
Only those that address the criteria in scope.
DC5 asks for the controls designed to meet the applicable criteria. Other practices can get a brief mention, but anything you present as a control may be tested, so padding the list adds risk without adding value.
Can we reuse last year's description?
As a starting draft, yes.
Each sentence must hold for the new period. Run the owner and evidence passes again, and rewrite the DC9 section for the changes that happened during this period.
What happens if the auditor finds an inaccuracy?
You will be asked to correct it before the report is issued.
Most issues are fixed in drafting. If a material misstatement in the description stays uncorrected, the firm can modify its opinion on fair presentation.
Should we include diagrams?
They help readers; DC 200 does not demand them.
A boundary or data-flow diagram often explains more than a page of prose. It has to match the text and the system as it ran, or it becomes one more thing to correct.
Get Section 3 drafted against DC 200.
Our SOC 2 readiness assessment produces a working draft of your system description for management to edit, approve and own.