SOC 2 System Description: Criteria, Boundaries, and Controls

A SOC 2 system description is the section of a SOC 2 report where management explains what the system does, how it’s built, and what controls protect it, written to the nine criteria in the AICPA’s DC Section 200.¹ It is management’s own statement, not the auditor’s, and the auditor tests against it. If the description is inaccurate or incomplete, the entire report loses value: the auditor can issue a qualified opinion, and every customer who reads the report sees the qualification before anything else.

The Nine Criteria You Have to Cover

DC Section 200 breaks the description into nine elements, usually labeled DC1 through DC9. Every SOC 2 system description has to address each one. Depth varies with the complexity of the service, but skipping a criterion gives the auditor grounds to flag the description as incomplete.¹

DC1, types of services provided: a plain statement of what the organization actually does for customers.
DC2, principal service commitments and system requirements: the promises made to customers (uptime targets, data-handling guarantees) and the system requirements that support them.
DC3, system components: infrastructure, software, people, procedures, and data.
DC4, system incidents: incidents during the audit period (or as of the report date, for a Type 1) that resulted from poorly designed or ineffective controls, or that caused a significant failure to meet service commitments.
DC5, trust services criteria and related controls: the criteria being evaluated and the controls designed to satisfy them.
DC6, complementary user entity controls: controls customers must implement on their end for the system to work as intended.
DC7, subservice organization controls: how third-party vendors fit in, and whether their controls are included in or carved out of the audit.
DC8, relevant changes to the system during the period covered.
DC9, other relevant disclosures needed for the description not to be misleading.

Work through these in order when you draft. Group controls under DC5 by trust services category so the mapping is easy to follow.

System Components: The Five Building Blocks

DC3 is the largest single writing job. The description has to cover all five component categories; none is optional.

Infrastructure. Physical and virtual foundation: data center facilities, cloud hosting environments, network equipment such as firewalls and load balancers, and the physical or virtual servers that run the service. Name co-located data centers or cloud providers and identify the geographic locations involved.

Software. Operating systems, database platforms, middleware, and the applications that deliver the service. Name the actual technologies. “A relational database” tells a reader less than the platform’s real name.

People. Organizational roles and responsibilities: who manages infrastructure, who reviews access logs, who responds to security incidents, and how reporting lines are structured. The section should show the separation of duties that keeps any single person from having unchecked control over critical systems.

Procedures. Automated and manual processes that keep the system running: monitoring scripts, change management workflows, backup schedules, incident response playbooks. Say who performs each action and how often.

Data. The types of information the system captures, stores, processes, and transmits. If the system handles sensitive categories such as protected health information or financial records, say so explicitly. This is what lets readers judge whether the controls in the report match the sensitivity of the information at stake.

Drawing System Boundaries

The most consequential decision in the description is where you draw the line around what is in scope. Everything inside the boundary gets tested. Everything outside does not.

Physical boundaries cover data center locations, office sites, and any facility where system components live. Logical boundaries cover the digital side: network segments, application environments, data pipelines, and access control perimeters. External interfaces (third-party APIs, cloud services, vendor integrations) need to be mapped and tied to specific controls.

Boundaries drawn too narrowly are a common failure. If a critical component sits outside the stated scope but clearly affects data security, the auditor will flag the gap. Boundaries drawn too broadly inflate the audit scope, testing timeline, and cost. The working goal is to capture every component that could meaningfully affect whether the organization meets its service commitments and the applicable trust services criteria.

Trust Services Criteria and Control Mapping

Security is always in scope for a SOC 2 engagement. Beyond that, management chooses whether to include availability, processing integrity, confidentiality, and privacy based on the nature of the service and what customers expect.²

Under DC5 the description identifies which categories are in scope and maps each to the controls designed to satisfy it. A SaaS company promising 99.9% uptime would typically add availability. A company processing payment card data would likely add confidentiality. Categories that don’t match your service commitments bloat the audit; categories your customers care about shouldn’t be omitted. The description should also explain how the organization identifies and addresses risks tied to the selected criteria, which is where risk assessment, vulnerability management, and monitoring belong.

Subservice Organizations: Carve-Out or Inclusive

Almost every service organization relies on third parties for some piece of its operations: cloud hosting, payment processing, managed security. DC7 requires the description to disclose these subservice organizations and explain how their controls fit into the overall picture. Two methods exist, and the choice changes what the report covers.

Carve-Out Method

Under carve-out, the subservice organization’s controls are excluded from the audit scope. The description names the subservice organization, explains what it provides, and identifies which trust services criteria are intended to be met by controls at that organization. The auditor does not test those controls directly. The report notes they were carved out and typically references the subservice organization’s own SOC 2 report.

This is the more common approach, especially when the subservice organization already maintains its own SOC report. The service organization is still expected to monitor the subservice organization, usually by reviewing its SOC report annually and watching for control gaps that could affect its own system.

Inclusive Method

The inclusive method pulls the subservice organization’s controls into the audit scope. The auditor tests them alongside the service organization’s own controls, and the results appear in the same report. The description has to include relevant details about the subservice organization’s infrastructure, people, processes, and data.

Organizations use this approach when the subservice organization has no SOC report of its own, or when the two systems are so tightly intertwined that separating them would be artificial. The tradeoff is a much larger audit scope and higher costs, since the subservice organization has to cooperate fully, provide a formal assertion, and submit a representation letter covering its own controls.

Complementary User Entity Controls

Some controls that protect the system live at the customer, not the service organization. DC6 requires the description to list these complementary user entity controls, or CUECs.

Common examples: requiring customers to enable multi-factor authentication for their users, disabling former employee accounts promptly, keeping endpoint protection current on devices that access the service, and periodically reviewing user permissions. The system is designed on the assumption these controls are in place. If a customer ignores them, the service organization’s controls alone may not be enough to meet the stated commitments.

Write the CUECs list clearly enough that a customer’s compliance team can act on it without guessing. This is often the most practically useful section of the whole description for user entities, and auditors rely on it to understand which parts of the control environment fall outside the service organization’s responsibility.

Incident Disclosure

DC4 requires the description to disclose system incidents that resulted from controls that were poorly designed or not operating effectively, or that otherwise caused a significant failure to meet a service commitment. For a Type 2 report, this covers the entire audit period. For a Type 1, it covers incidents as of the report date.¹

Include the nature of each incident, its timing, and its effect or disposition. Organizations sometimes want to leave qualifying incidents out. Omitting one doesn’t make it disappear; the auditor will find it during testing, and the omission itself becomes a problem for the description’s accuracy. Honest disclosure with a clear account of remediation reads better than a gap the auditor has to call out.

How Type 1 and Type 2 Descriptions Differ

A Type 1 report evaluates whether controls were suitably designed as of a single date. The description captures a snapshot: what the system looked like on that specific day. A Type 2 report evaluates both the design and the operating effectiveness of controls over a period, typically three to twelve months. The description has to cover the full duration, including changes that occurred along the way (DC8).

The incident requirement under DC4 reinforces the split: a Type 1 description addresses incidents only as of the report date, while a Type 2 description accounts for incidents across the entire audit window. Most customers ask for a Type 2, because it shows controls actually worked over time rather than existing on paper on one particular afternoon.

Gathering the Material Before You Write

The description touches every department that touches the system, and the source material rarely sits in one place. Assemble it before drafting.

Infrastructure and engineering supply architecture diagrams, network maps, server inventories, and configuration standards. Diagrams should show data entry and exit points, internal segmentation, and where external integrations connect. Security supplies access control policies, vulnerability scan results, penetration testing reports, and incident response logs. HR supplies background check procedures, onboarding workflows, security awareness training records, and termination protocols. Compliance and legal supply internal policy manuals, risk assessments, and vendor management records.

Auditors will eventually request specific evidence to verify what the description says: user access lists showing disabled accounts for terminated employees, background check confirmations for new hires, disaster recovery test results, encryption configurations, records of annual policy reviews. Organizing this before drafting starts avoids a scramble later.

Writing It So the Auditor Can Test It

The description should read as a clear narrative, not a compliance checklist. Management prepares it, and the CPA performing the examination uses it as the basis for testing.¹

Start with the system boundaries: services, locations, and infrastructure included. Then work through the DC Section 200 criteria in order. Group related controls under trust services categories so the flow is logical. For every control, say who performs the action, how often, and whether it’s automated or manual. “An automated script runs nightly and results are reviewed by a systems administrator each morning” is far more useful than “the system is monitored regularly.”

Name specific technologies rather than generic categories. Use active voice. State the disclosure method chosen for each subservice organization (carve-out or inclusive) and provide the required details. List CUECs so a customer’s compliance team can act on them without guessing. Descriptions typically run 20 to 50 pages depending on service complexity and the number of trust services categories in scope.

p>Alongside the description, management submits a separate assertion: a formal statement affirming that the description fairly represents the system, that controls were suitably designed, and, for a Type 2, that controls operated effectively throughout the period.

What Happens When the Description Is Wrong

An inaccurate or incomplete description can derail the engagement. If the auditor finds statements that can’t be objectively verified, facts implied but not true, or material information omitted, they will flag it. The first step is usually asking management to amend the text.

If management refuses to correct, the auditor may issue a qualified opinion. That opinion is a serious outcome. Prospective customers and partners reviewing the report notice it immediately, and it often raises more questions than the underlying issue would have raised if simply disclosed and corrected.

Discrepancies also expand testing. If the description says access is restricted one way but evidence suggests otherwise, the auditor digs deeper into access controls, detective monitoring, and compensating controls to assess the real risk. That extra testing extends timelines and increases audit costs. The single most effective way to keep an engagement on schedule is to get the description right the first time: boundaries clearly drawn, components documented, CUECs identified, subservice organizations properly disclosed, and incidents honestly reported.