Learn · SOC 2 Reporting
Writing the SOC 2
System Description
Section 3 is the longest prose section of a SOC 2 report and the longer of the two sections management is responsible for authoring — the other being its own assertion. It is governed by the AICPA description criteria in DC section 200, nine criteria running DC1 through DC9, and it is where first-time engagements lose weeks.
The standard is not completeness. A description is presented in accordance with the criteria when it describes the system actually implemented, addresses each relevant criterion, and does not inadvertently or intentionally omit or distort information likely to be relevant to report users’ decisions. Everything difficult about drafting lives in that last clause.
Written for management authors · DC section 200 (2018 criteria, guidance revised 2022) · Last reviewed August 2026
The SOC 2 system description is written by service organization management, not by the auditor, and it must disclose information about each of nine criteria in DC section 200: the types of services provided; the principal service commitments and system requirements; the components of the system across infrastructure, software, people, procedures and data; identified system incidents; the applicable trust services criteria and related controls; complementary user entity controls; subservice organizations and the inclusive or carve-out treatment; any criteria that are not relevant, with reasons; and, for a Type 2, significant changes made during the period. A SOC 2 examination is an attestation performed under AT-C sections 105 and 205 by a licensed CPA firm, and a Type 2 examination has three subject matters — the description, the suitability of design of the controls, and their operating effectiveness. The controls are two of them; the description is the third. A Type 1 has two, the description and the suitability of design. Either way, a description problem can modify an opinion even where every control tested cleanly. For the reader’s view of the same document, see how to read a SOC 2 report.
Whose document this is
Management writes it. Not the auditor
DC section 200 states the premise plainly: because management is ultimately responsible for developing, implementing and operating the system, it is also responsible for developing and presenting the description of that system in the report. The service auditor applies the same criteria from the other side, to evaluate what management wrote. The description is conventionally presented as Section 3 of a five-section report — the numbering is market convention rather than a requirement of DC 200 or AT-C 205, and some reports place management’s assertion first or order the sections differently. The convention is near universal, and this page uses it.
That has a consequence teams underestimate. Under the AICPA’s independence rules a service auditor may not assume management’s responsibilities, so the firm that will opine on the description cannot be the party that authors it. Firms review a draft and flag an unaddressed criterion; they will not write your Section 3. Drafting falls to management or to an independent readiness partner — the role we play. The opinion is issued by the licensed CPA firm, and only by them.
“There is no prescribed format for the description.”
— DC section 200. Organize Section 3 by the components of internal control, by the five system components, or by another logical grouping.
DC1 through DC9
What the criteria actually require
The section-by-section checklist. The criteria specify what must be disclosed, never how many pages it takes: the extent of disclosure varies with the size and complexity of the organization, and the description need not address every aspect of the system.
DC1
Types of services provided
The services that are the focus of the examination — and, where privacy is in scope, the role you perform over personal information: processor, controller, or both.
Checklist testCould a reader who has never seen your product tell what the report covers?
DC2
Principal service commitments and system requirements
What you promise customers through contracts, SLAs or published policies — no particular form is required — and the specifications the system must meet to keep those promises. Only the principal ones.
Checklist testCan every commitment be traced to a contract clause, an SLA or a regulation?
DC3
Components: infrastructure, software, people, procedures, data
The five components, plus the boundary: where a reader might be confused about whether a function sits inside the system, say what is outside it.
Checklist testDo the diagram, the asset inventory and this narrative describe the same system?
DC4
Identified system incidents
For incidents caused by controls that were not suitably designed or operating effectively, or that otherwise caused a significant failure to achieve commitments: nature, timing, and extent or effect and disposition.
Checklist testDo the incident register, the status page and this paragraph agree?
DC5
Applicable trust services criteria and related controls
Information about each criterion in the categories in scope, and the controls designed to meet your commitments based on them. Descriptions conventionally also set out how management identifies and assesses the risks threatening those commitments, because a control listing is hard to read without it.
Checklist testDoes every control Section 4 will test appear in, or follow from, Section 3?
DC6
Complementary user entity controls (CUECs)
Controls you assumed user entities would implement that are necessary in combination with yours. The criterion is met when CUECs are complete, accurately described and relevant.
Checklist testIf the customer never did this, could you still meet the commitment?
DC7
Subservice organizations and the method used
Inclusive: the nature of the service, the provider’s controls necessary alongside yours, the relevant aspects of its five components, and the portions of the system attributable to it. Carve-out: the nature of the service, each criterion intended to be met there, and the types of controls assumed — the CSOCs.
Checklist testDoes it say commitments can be achieved only if those CSOCs operate effectively?
DC8
Criteria that are not relevant, and why
The reason any applicable criterion is not relevant. A policy prohibiting an activity does not make a criterion inapplicable, and a criterion stays relevant even where every supporting component is outsourced.
Checklist testIs the reason a fact about the system, or a preference?
DC9
Significant changes during the period (Type 2)
Changes relevant to your commitments, with the date and how the system differed before and after — services, personnel, architecture, regulatory requirements, legal entity.
Checklist testCan a reader tell what operated in month one as distinct from month nine?
The real constraint
Omit or distort
Teams arrive expecting a completeness test and try to write everything down. The criteria ask for something narrower: a description is ordinarily presented in accordance with them when it describes the system the organization has implemented — placed in operation — includes information about each criterion to the extent relevant, and does not inadvertently or intentionally omit or distort information likely to be relevant to report users’ decisions. Detail should balance the reader’s need to understand the risks against a hostile party using the same information to find vulnerabilities.
Three failures are named outright. A description is not presented in accordance with the criteria if it states or implies that IT components exist when they do not; if it implies that processes and controls have been implemented when they are not being performed; or if it contains statements that cannot be objectively evaluated — what the guidance calls advertising puffery. Nearly every serious review comment traces to one of those three.
Materiality is qualitative: whether a misstatement or omission has a substantial likelihood of influencing the judgments of the report’s specified parties. One listed factor matters while drafting — whether identified deficiencies in the design or operation of controls contradict what the description says about them. If Section 4 will show an exception, Section 3 must not read as though it could not have happened. The counterweight: the description meets the common needs of a broad range of parties, not every aspect an individual reader might want.
The shape of the document
What Section 3 actually looks like
One workable organization, not a required one — DC 200 prescribes no format, as quoted above. This ordering follows the criteria closely enough that a reviewer can tick DC1 through DC9 against your headings, which is the cheapest way to shorten a review cycle. The numbering is ours. The sample sentences are illustrative, written at the altitude the next section argues for.
3.1
DC1 · DC3
Overview of services and the system boundary
Two or three paragraphs: what the service does, who buys it, how it is delivered, and — stated positively — what is inside the system and what is deliberately outside it.
Sample sentenceThe system comprises the platform, the production infrastructure in two cloud regions that supports it, the identity, logging and monitoring services used to administer it, and the personnel and procedures used to operate it. The corporate IT environment, the marketing website and the legacy on-premises connector are outside the boundaries of the system.
3.2
DC2
Principal service commitments and system requirements
Each principal commitment traced to a contract clause, a published SLA or a regulation, followed by the system requirements derived from it. Requirements are how the commitment becomes testable.
Sample sentenceThrough its master services agreement the company commits that customer data is encrypted in transit and at rest, and through its published service level agreement that the production API will be available for 99.9% of each calendar month, measured as described in that agreement.
3.3
DC3
Components: infrastructure, software, people, procedures, data
One subsection each. Infrastructure and software describe function and trust boundaries rather than versions; people describes roles, reporting lines and segregation of duties; procedures describes the operating processes; data describes what the system holds and how it is classified and retained.
Sample sentenceCustomer data comprises the records that user entities upload or generate through the platform together with the audit logs of activity within it. Data is classified in three tiers and retained in accordance with the retention schedule referenced in the customer agreement.
3.4
DC5
Relevant aspects of the control environment, risk assessment, information and communication, and monitoring
The narrative that gives the control listing its context — governance bodies and their cadence, how risks to the commitments are identified and assessed, how policy and incident information reaches the people who act on it, and how management monitors that controls are still operating.
Sample sentenceManagement performs a documented risk assessment at least annually and on significant change, identifying threats to the service commitments and system requirements, rating them, and recording the controls that address each. Results are reviewed by the governance committee described above.
3.5
DC5
Trust services criteria and related controls
Either the control listing itself or a cross-reference to the mapping in Section 4. Placing the matrix in Section 4 and cross-referencing it is market practice, not a requirement — but whichever you choose, every control Section 4 tests has to be traceable to a statement here.
3.6
DC6
Complementary user entity controls
A short table. Each CUEC written so a customer could hand it to an engineer, and limited to controls genuinely necessary in combination with yours.
Sample sentenceUser entities are responsible for configuring single sign-on and multi-factor authentication for their own users in the administrative console, and for reviewing the administrator accounts they have designated at least annually.
3.7
DC7
Subservice organizations and complementary subservice organization controls
For each provider: the nature of the service consumed, the method applied to it, the criteria intended to be met by its controls, the types of controls assumed, and the statement that the related commitments can be achieved only if those controls are suitably designed and operating effectively.
3.8
DC8
Applicable criteria that are not relevant, and the reasons
Short and specific. The reason has to be a fact about the system, not a preference — and outsourcing the components behind a criterion is not a reason, because the commitment stays yours.
Sample sentenceThe criteria addressing the transmission of customer data to parties other than the subservice organizations identified in section 3.7 are not relevant to the system, because the platform transmits customer data to no other party.
3.9
DC4
Identified system incidents
Nature, timing, and extent or effect and disposition for each incident meeting the threshold — or an explicit statement that none did, with the threshold you applied stated so the reader can see what was measured.
Sample sentenceNo incidents occurred during the period that were caused by controls that were not suitably designed or operating effectively, or that otherwise resulted in a significant failure to achieve the service commitments and system requirements.
3.10
DC9
Significant changes during the period
Type 2 only. Each change relevant to the commitments, with its date and a before-and-after: what the system was, what it became, and from when the new arrangement operated.
A first Type 2 description built on this outline usually runs between 2,500 and 6,000 words. That range is an observation about the engagements we support, not a target: the criteria say the extent of disclosure varies with the size and complexity of the organization, and a short description that addresses every relevant criterion beats a long one that pads DC3 and skips DC8.
Altitude
Specific enough to mean something, general enough to survive
The working rule is that every sentence should be true for the whole period, and that material changes between period end and the day the report is issued are handled as subsequent-event disclosures rather than silent edits. Too high and a reviewer can do nothing with it; too low and a routine configuration change makes a signed report inaccurate.
Production access
Too high
Access to production systems is granted appropriately and reviewed periodically.
“Appropriately” and “periodically” cannot be objectively evaluated.
Too low
Engineers request access in Jira project ACCESS-2, which routes to the Director of Platform; access is granted through the Okta group prod-admins-v3.
Implementation details and a job title that will all change mid-period.
Right altitude
Production access is requested through the company’s ticketing system and approved by the engineering manager responsible for the environment and by the security lead before it is provisioned through the central identity provider. System owners review production access at least quarterly, and access is removed as part of workforce offboarding.
Roles, control points and a testable frequency. It survives a tool migration.
People
Too high
The company employs qualified and experienced security personnel.
Not evaluable, and silent on who may approve what.
Too low
The security team consists of Arun (Head of Security), two analysts and one contractor.
Named individuals leave; the description is then wrong for the rest of the period.
Right altitude
Security operations are the responsibility of a dedicated security function reporting to the Chief Technology Officer, comprising a security lead, security engineers and an on-call analyst rota. Segregation of duties is maintained between personnel who develop application code and those who approve production deployments.
Roles and separation of duties carry the assurance; the roster stays in the evidence file.
The boundary
Too high
The system includes the platform and its supporting infrastructure.
A buyer cannot tell whether the product they are purchasing is covered.
Too low
The system comprises the fourteen microservices listed in Appendix B.
A service list is a moving target; the appendix becomes a change log.
Right altitude
The system comprises the platform, the production infrastructure in two cloud regions that supports it, the identity, logging and monitoring services used to administer it, and the personnel and procedures used to operate it. The corporate IT environment, the marketing website and the legacy on-premises connector are outside the boundaries of the system.
It names what is in and — because a reader could be confused — what is out.
One exception cuts against the rule: where a specific standard is itself a contractual commitment — an encryption algorithm named in the contract, a stated availability percentage — name it, because a commitment has to be stated as made.
Complementary user entity controls
A CUEC section that is honest rather than defensive
Every requirement pushed into the CUEC table is one you do not have to evidence, so first drafts arrive with fourteen or twenty entries. Reviewers know the pattern, and so do enterprise buyers — the CUEC list is one of the few parts of a report that lands on the customer’s own compliance backlog. The criterion is met when CUECs are complete, accurately described and relevant. Padding fails all three.
The implementation guidance works an example that settles most arguments. Criterion CC6.2 requires the entity to register and authorize new internal and external users before issuing credentials, and to remove credentials when access is no longer authorized — for users whose access the entity administers. If a customer supplies a list of authorized users that mistakenly includes someone who should not have access, the service organization has still met CC6.2. So identifying authorized users and sending you that list is not a CUEC: it is a user entity responsibility, ordinarily communicated through user manuals rather than the description.
1. If the customer never did this, could we still meet the commitment?
If yes, it is not necessary in combination with your controls. Most deletions happen here.
2. Does the customer have a practical means of doing it?
A CUEC the customer cannot operate is a design gap dressed as a disclosure; the control belongs on your side of the line.
Written well, a CUEC is operable: “User entities are responsible for configuring single sign-on and multi-factor authentication for their own users in the administrative console, and for reviewing the administrator accounts they have designated at least annually.” Written badly it reads as “user entities are responsible for the security of their environment” — which assigns nothing. More in CUECs and CSOCs explained.
Subservice organizations
Carve-out, inclusive, or both
The choice is made per provider, not once for the report, and it is decided by four practical questions rather than by preference. Under the inclusive method the relevant aspects of the provider’s five components become part of your system, are described, and its controls are tested alongside yours. Under carve-out they are excluded from both the description and the testing, replaced by the nature of the service, the criteria intended to be met there, and the types of controls you assume — the CSOCs.
Question
Answer
Method that follows
Does the provider have its own SOC 2 report covering a period that overlaps yours?
Yes
Carve-out is workable and your monitoring control is the inspection of that report, with a bridge letter covering the gap between the provider’s period end and yours. Where the answer is no, the choice narrows to the inclusive method or a carve-out whose monitoring control is something other than reading a report you cannot get.
Will the provider sign its own management assertion and give your service auditor access to its controls?
No
The inclusive method is off the table, whatever you would have preferred. Carve-out is the only remaining treatment, and the work moves into describing CSOCs precisely and evidencing the monitoring control you actually operate.
Does the provider perform a control you could not compensate for — one where a criterion is met only by its activity?
Yes
Its CSOCs are load-bearing rather than boilerplate. They must be criterion-specific, limited to the services your system consumes, and accompanied by the statement that the related commitments can be achieved only if those controls are suitably designed and operating effectively during the period.
Is the provider an affiliate under common control, sharing your governance, personnel or policies?
Yes
Inclusive is the usual treatment: the assertion and the auditor access are obtainable because the same group controls both entities, and carving out a sister company reads to buyers as an evasion rather than a scoping decision.
Three details decide whether a carve-out passes review. CSOCs must be specific to the services your system actually consumes, which rules out the pasted list covering everything the provider sells. The description must indicate that the related commitments can be achieved only if those CSOCs are suitably designed and operating effectively during the period. And regardless of method, it discloses the controls you use to monitor the provider — reconciling output reports, service-level reviews, inspecting its Type 2 report and the bridge letter covering any gap. A carve-out with no monitoring control described is the version reviewers send back.
Naming a carved-out provider is optional under the criteria, and buyers now expect it anyway. You need not pick one method for everything: an organization may carve out some providers and include others in the same description. Which vendors are subservice organizations at all is a scoping question — subservice organizations and carve-out vs inclusive work it through.
Exclusions, incidents and changes
The three disclosures teams try to skip
Criteria that are not relevant. A policy prohibiting an activity does not make the related criterion inapplicable — describe the controls that prevent or detect the activity instead. The guidance’s own example runs the other way and is worth reading closely: a service organization whose infrastructure provider physically destroys decommissioned storage media still treats CC6.5 as relevant — the criterion on discontinuing logical and physical protections over physical assets only once the ability to read or recover data from them has been diminished — even with that provider carved out, because the commitment to protect customer information remains its own.
Incidents. The guidance lists prompts for the judgment — disclosure required by law, fines or sanctions, theft of sensitive information, a ransom demand, public knowledge — and a timing trap: a breach occurring six months before the period began but not fully remediated during it would likely still be disclosed. Where nothing meets the threshold, management may say so.
Significant changes. The failure mode is silent overwriting: a description finalized in month twelve describing only the end state, which no reader can reconcile with test results drawn from month two. See mid-period changes and choosing your observation period.
Evidence
What the CPA firm actually asks for
Section 3 is not evaluated by reading it. The service auditor reads it against everything else it knows about the system — inquiry, observation, inspection, and walkthroughs tracing a statement in the narrative to a system that does the thing.
What the description claims
What the firm requests
What gets sent back
Hosted in two cloud regions.
Cloud account and region inventory export, and a dated architecture diagram that reconciles to it.
An undated diagram; an inventory showing production in a third region the description never mentions.
We commit to 99.9% monthly availability.
The contract or SLA clause, the published SLA page, and the definition of downtime used to measure it.
A commitment that exists only in marketing copy; a figure that differs between contract and description.
Access is reviewed at least quarterly by system owners.
The artifact for every occurrence — reviewer, date, population, actions taken — plus records showing removals were executed.
One review in month five presented as a quarterly cadence; no evidence of what was removed.
No significant system incidents occurred.
Incident register export, tickets filtered by severity, status-page history, and your written severity definitions.
A “no incidents” statement beside a Severity 1 ticket; severity definitions changed mid-period.
Our hosting provider is carved out.
Vendor register entry, the subservice determination, the provider’s SOC 2 report covering your period or overlapping it with a bridge letter for any gap, and evidence someone reviewed it.
A carve-out with no CSOCs; CSOCs pasted from a template; a report obtained but never read.
What the description’s frequency does to the population
This is where description work and testing work meet, and it is the part most first-time authors do not see coming. Every frequency stated in Section 3 defines a population for Section 4. The table below assumes a six-month observation period. The counts in the third column are firm methodology — market practice derived from the AICPA’s audit sampling guidance — not requirements: neither AT-C 105 nor AT-C 205 prescribes a sample size, and different firms land in different places on the same population.
Frequency stated in Section 3
Population over six months
What the firm examines
Where it goes wrong
Annual
One occurrence — or none, if the run date fell outside the window.
The single occurrence, in full. Nothing is sampled and no extension exists, so a single deviation is a failure of the whole population — there is no smaller rate available.
A control described as annual that last ran fourteen months ago has no occurrence inside the period. The description promises something the period cannot evidence.
Quarterly
Two.
Both. Sampling saves nothing at a population of two.
Both reviews clustered in the same month. The cadence written in Section 3 is not the cadence the evidence shows.
Monthly
Six.
Commonly two to four of the six at zero expected deviations; some firms take all six where the control is the only one addressing a criterion.
The most common self-inflicted wound. Writing “monthly” for a control that runs when someone remembers converts a wording choice into six separate chances to fail.
Weekly
About twenty-six.
Typically five to nine, selected across the whole period rather than clustered in one month.
Selections that only exist from month four onward. That is a DC9 significant change disclosure, not a sampling problem.
Daily
About 125 business days — or about 180 if the description says every day.
Typically fifteen to twenty-five.
Writing “daily” for a control that runs on business days only. The auditor builds a larger population than the one you can evidence, and the gaps read as deviations.
Event-driven — 480 production releases
The complete change log for the period, reconciled to the deployment system.
Typically twenty-five to forty items, spread across the whole period rather than one convenient month.
A change log that omits hotfixes, infrastructure-as-code changes or a second deployment path. The population fails completeness and selection never starts.
Onboarding and offboarding
Every joiner and every leaver in the window, from the HR system.
All of them where the list is short — below roughly twenty-five items sampling saves no effort — and typically twenty-five where it is longer.
An export that omits contractors and interns, or people who transferred between teams and kept the access the old role carried.
The population is defined by the sentence management wrote, which is why a description that says “monthly” for a control that in fact runs when someone remembers converts a wording choice into six potential exceptions. Writing the frequency the control genuinely operates at — or describing it as event-driven, if that is what it is — costs nothing at drafting time and removes the exception entirely.
The second thing to know is that the firm does not accept the population you hand over on trust. It reconciles your export to an independent source — the HR system for joiners and leavers, the deployment or version-control system for changes, the ticketing export for approvals — before a single item is selected, because a sample drawn from an incomplete population supports no conclusion about the population. An incomplete population is rejected before sampling starts, and the fix is always the same: rebuild the export with the filter visible. The mechanics are in SOC 2 sampling and sample sizes and SOC 2 evidence collection.
Worked example
One description, start to finish
An illustrative composite — not a client — of a first Type 2 at a 62-person data platform company, over a six-month observation period.
January 2026
Boundary decided
One product in scope. The marketing website, corporate IT and a legacy on-premises connector are excluded — and named as excluded, because customers buy the connector too.
February 2026
First draft, 2,900 words
Eleven review comments: four soft frequencies, two components in the diagram that no longer exist, one “enterprise-grade” to delete, fourteen CUECs flagged as excessive.
March 2026
Redraft
Every commitment traced to the services agreement or published SLA. CUECs cut from fourteen to six. Two of the four soft frequencies are rewritten downward — a “monthly” log review that genuinely ran weekly stays weekly, and a “monthly” vendor check that ran twice a year becomes semi-annual, removing four future exceptions.
1 April 2026
Period opens
The description is frozen as the baseline. Everything after this date is a change to be tracked, not an edit to absorb.
June 2026
A third region, a small acquisition
Both are significant changes: the date, the architecture before, the architecture after. The acquired environment stays outside the boundary, and says so.
August 2026
A four-hour availability incident
Root cause was a failover control that did not operate as designed, so it meets the threshold. Nature, timing, extent and disposition in one paragraph — no exploit path. Because the control was replaced rather than repaired, it is also a DC9 change.
30 September 2026
Period closes
Disclosures reconciled to the incident register and change log. The change population comes back at 480 releases and the firm selects 30 across all six months. Two of four described roles have new occupants — and because nobody was named, nothing needs amending.
One sentence from that engagement. Before: “Our platform is hosted on enterprise-grade cloud infrastructure with industry-leading security controls, monitored 24/7.” And after: “The production environment is hosted on infrastructure provided by a cloud infrastructure provider, treated as a subservice organization under the carve-out method. Security events are forwarded to a centralized logging service and reviewed by the on-call analyst rota, which operates continuously.” Barely longer — but it names the treatment, the mechanism and the role, and a reviewer can ask for evidence of each.
Review comments
What comes back from the CPA firm
Five comments we see on almost every first draft. Pre-empting them is the cheapest week you will spend on the engagement.
Define “periodically”.
Use the frequency the control actually runs at. A control described as quarterly but evidenced twice over a twelve-month period becomes an exception in Section 4, not a wording problem in Section 3.
Remove “industry-leading”, “best-in-class”, “military-grade”.
The criteria exclude statements that cannot be objectively evaluated. A description resting on them is not presented in accordance with the criteria.
This control is in Section 4 but not in Section 3.
Reconcile the two line by line. The opinion addresses the controls stated in the description, so a control living only in the matrix claims credit the description never asked for.
Was this operating from the first day of the period?
The present tense hides implementation dates. A control that went live in month three is disclosed as a significant change, or it does not belong here.
Several CUECs are your responsibility, not the customer’s.
You cannot move a criterion to the customer by writing it into the CUEC table. Delete anything you could meet without them.
Where this gets contested
The edge cases that generate the arguments
Which legal entity operates the system
Groups with a delivery entity in one country and a contracting entity in another have to say which entity operates the system, because the assertion is signed by the management of a specific organization and the commitments are made by a specific counterparty. Say how affiliate personnel fit the people component: staff seconded to work under your direction are your people, while an affiliate delivering a distinct outsourced service under its own management is a subservice organization and takes DC7 treatment. Enterprise buyers check the entity named here against the entity on their contract.
An acquisition or a new region mid-period
Either the new environment is inside the boundary and its arrival is disclosed as a significant change — the date, the architecture before, the architecture after, and from when controls operated in it — or it is outside the boundary and the description says so explicitly, because customers who read the announcement will look for it. What fails is a description written at period end that describes only the end state, leaving Section 4 results drawn from month two with no system to attach to.
A provider that will not give you a report
Carve-out does not need the provider to cooperate: you can describe the nature of the service and the types of controls you assume without its permission. What carve-out does need is CSOCs you can state honestly and a monitoring control you can evidence. If the only monitoring activity described is inspecting a report you cannot obtain, the control fails on the first sample. Describe what you actually do instead — the completed security questionnaire on file, the service-level review, the reconciliation of output you perform, the contractual audit right you exercised.
How much architecture detail is too much
The criteria state the tension plainly: balance the reader’s need to understand the risks against a hostile party using the same detail to find vulnerabilities. Function, trust boundaries and data flow are the workable line. Hostnames, IP ranges, firewall rule sets, library versions and the internal names of security tooling are not, and a reviewer who wants them can have an architecture briefing under NDA. The failure in the other direction is more common: a boundary so abstract that a buyer cannot tell whether the product they are buying sits inside it.
A description generated by a compliance automation platform
A platform-generated narrative describes the tool’s model of your system — the integrations it can see and the checks it runs — rather than the system you implemented, and the criteria ask for the second. Where the two diverge, the divergence surfaces in the walkthrough: the narrative says access is provisioned through the identity provider, and the walkthrough finds a second path through a legacy admin console the platform never connected to. Treat the output as a usable first draft and a poor final one, and delete every sentence describing a control the platform infers rather than one you perform.
Adding the Privacy or Confidentiality category
Adding either category changes what the description has to cover, not just how many controls Section 4 lists. Confidentiality pulls in how confidential information is identified, protected, retained and disposed of, and what the retention commitments actually promise. Privacy pulls in the whole personal-information lifecycle — collection, use, retention, disclosure and disposal — the notice and choice commitments, and the role DC1 already asks you to state: controller, processor, or both for different data sets. Teams add Privacy for one enterprise deal and find the description work larger than the control work.
A control that failed and was replaced mid-period
This is usually both disclosures rather than a choice between them. Replacing the control is a significant change under DC9 — the date, what operated before, what operates after. Whether the failure is also an identified system incident under DC4 turns on effect: a control that was not operating effectively and caused a significant failure to meet a commitment is disclosed there too. The drafting consequence is tense. A description written entirely in the present tense about the replacement reads as though the month-two exception in Section 4 could not have happened, which is precisely the contradiction materiality is aimed at.
Two of those have their own pages, because the mechanics run past what a paragraph holds: changes that land inside the observation period and what Confidentiality and Privacy actually add. Where a judgment is significant — what you treat as a security event, for instance — the criteria contemplate disclosing the interpretation itself, alongside subsequent events where their significance warrants it. Saying how you decided beats hoping nobody asks.
Objection handling
What buyers push back on, and the answer
“Your description is too vague for us to assess.”
Usually a boundary problem rather than a detail problem. Point to the paragraph stating what is in and out of scope, and to the control-to-criteria mapping. Where a reviewer needs more, an architecture briefing under NDA answers it without putting a hostname in the report.
“Why do you have fourteen CUECs?”
A long CUEC list reads as risk transfer, and reviewers treat it that way. The criterion asks for CUECs that are complete, accurately described and necessary in combination with your controls — not a catalog of things customers ought to do.
“Your cloud provider is carved out, so who is accountable?”
Carve-out is the ordinary treatment for a hyperscaler, not a gap. The answer is the CSOCs you describe, the monitoring control you operate, and evidence that you reviewed the provider’s report for an overlapping period, bridged where the periods do not line up.
“You say no incidents, but we saw the outage on your status page.”
The threshold is not every degradation; it is incidents caused by controls that were not suitably designed or operating effectively, or that caused a significant failure to meet commitments. The defensible position is a written severity definition applied consistently.
Consequences
How the description constrains the opinion
In a Type 2 examination the service auditor opines on three things: whether the description is presented in accordance with the description criteria; whether the controls were suitably designed; and whether they operated effectively over the period. In a Type 1 the third drops away. The description is the first of the three — not scaffolding around the subject matter but part of it.
Three consequences follow. A description that omits or distorts something material can produce a modified opinion even where testing was clean, so the exceptions in Section 4 are only one route to a qualified report. The opinion addresses the controls stated in the description, so a control that never appears in Section 3 earns no credit. And management’s assertion is a claim about the description — if the description is wrong, the assertion is wrong too.
An opinion can be modified three ways — qualified, adverse, or disclaimed — and a description problem modifies the first subject matter while the opinions on design and operating effectiveness can remain unmodified. On the page that looks like a separate basis-for-qualified-opinion paragraph naming the specific description matter: a subservice organization treated as carved out but never disclosed, a stated control that was not being performed, a boundary that excluded a product customers reasonably assumed was covered. It sits immediately above an opinion that is otherwise clean on design and on operating effectiveness. Nobody skims that paragraph. The buyer’s reviewer reads it first, then asks what has changed since — which makes the remediation story, not the qualification, the thing you have to be ready to tell.
Section 3 decides what the other four sections are permitted to say. For the short signed statement that sits on top of it, see management’s assertion; for the scoping decisions that precede drafting, see SOC 2 scope and system boundary.
Frequently Asked Questions
Who writes the SOC 2 system description?
Service organization management. The criteria are explicit: because management is responsible for developing, implementing and operating the system, it is also responsible for developing and presenting the description in the report. The service auditor applies the same criteria from the other direction, to evaluate it. In practice the draft comes from whoever owns the system, often with an independent readiness partner assembling the evidence behind each claim.
What is DC section 200?
DC section 200 is the AICPA’s description criteria for a description of a service organization’s system in a SOC 2 report — the 2018 criteria, reissued with revised implementation guidance in 2022. It contains nine criteria, DC1 through DC9, plus guidance on how much to disclose under each. Management uses them to prepare the description; the service auditor uses them to evaluate it. A SOC 1 description is governed by AT-C section 320 instead.
What is the difference between the system description and the management assertion?
The description is the subject matter; the assertion is management’s short signed statement about it. In a Type 2 the assertion says that the description is presented in accordance with the description criteria in DC section 200, that the controls stated in it were suitably designed, and that they operated effectively throughout the period. The assertion runs to a page or less and carries a signature; the description runs to thousands of words and carries the detail. The relationship is one-directional — if the description is wrong, the assertion is wrong, because the assertion asserts the description. That is why a review comment about a soft frequency in Section 3 has consequences in Section 2.
How long should a SOC 2 system description be?
There is no prescribed length or format, and length is a poor proxy for quality. The criteria say the extent of disclosure varies with the size and complexity of the organization, and that the description need not address every aspect of the system — billing processes are the guidance’s own example of something unlikely to matter to report users. First Type 2 descriptions in our experience run roughly 2,500 to 6,000 words, but what matters is that every relevant criterion is addressed and each sentence ties to something real.
Can our auditor write the system description for us?
No, and be wary of one that offers. The AICPA’s independence rules prohibit a practitioner from assuming management’s responsibilities for an attest client, and preparing the subject matter you will then opine on is exactly that. Firms will review a draft, flag an unaddressed criterion and mark up wording that cannot be objectively evaluated. The drafting itself must come from management, or from a readiness partner who is not the firm signing the report.
Can we reuse last year’s system description?
As a starting point, yes — most year-two descriptions begin as last year’s document marked up. What cannot be carried forward is anything period-specific, and that is more of the document than teams expect. The significant changes under DC9 restart at zero for the new period. The identified incidents under DC4 have to be re-derived from the new register. The CUEC and CSOC lists have to be re-checked against how the product and the vendor stack actually changed. And every stated frequency has to be confirmed against what the control did this period, not last. A description carried forward unchanged is the single most common source of a stated control that quietly stopped operating.
What is the omit-or-distort standard?
It is the test at the center of the criteria. A description is ordinarily presented in accordance with them when it describes the system actually implemented, includes information about each criterion to the extent relevant, and does not inadvertently or intentionally omit or distort information likely to be relevant to report users’ decisions. Materiality is qualitative: whether an omission has a substantial likelihood of influencing the judgments of the report’s specified parties.
Should we name individuals in the system description?
Generally no. The people component asks for information about the personnel involved in governance, management, operations and security and about system users — roles, reporting lines and segregation of duties, not a staff directory. Named individuals date badly: someone changes team in month four and a sentence in a signed report stops being true. Name governance bodies rather than their members, and describe a role by title where its independence matters.
How many CUECs should a SOC 2 report have?
As many as are genuinely necessary in combination with your controls, and no more. The criterion is satisfied when CUECs are complete, accurately described and relevant to achieving your service commitments — not when the list is long. Apply two tests: if the customer never performed it, could you still meet the commitment; and does the customer have a practical means of performing it. Identifying authorized users is not a CUEC.
Do we have to name our subservice organizations?
The criteria do not require the identity of a carved-out subservice organization to be disclosed; the guidance notes that naming it may be useful to customers who want information about that provider. In current market practice enterprise buyers expect the name, and withholding it generates more questions than it prevents. What is required is the nature of the service, each criterion intended to be met there, and the types of controls assumed.
Related reading: anatomy of a SOC 2 report, the management assertion, scope and system boundary, CUECs and CSOCs, subservice organizations, sampling and sample sizes, the Trust Services Criteria, and opinions and exceptions.
Written By Expert Auditors
Keep Exploring
Related Reading
Anatomy of a SOC 2 Report
An interactive, annotated Type II example — click every element to see what it means.
Read moreSOC 2 Scope & System Boundary
What may legitimately be excluded, and the DC 200 test that stops a boundary flattering the vendor.
Read moreCUECs & CSOCs Explained
The controls a SOC report assumes of you and of carved-out vendors.
Read moreThe Management Assertion (Section 2)
Your statement, not the auditor’s — what signing it commits you to, clause by clause.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreCarve-Out vs Inclusive Method
How subservice organisations are described and tested — and what carve-out does not let you avoid.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours