SOC 2 System Description and Control Matrix: What the Standards Require and Where Companies Get It Wrong

If you are preparing for a SOC 2 audit, or trying to understand why your last one produced findings, two documents sit at the center of everything: the SOC 2 system description and the SOC 2 control matrix. Together, they tell your auditor what your system does, how it is controlled, and whether those controls operated as designed across the full audit period.

Get them right, and your audit becomes a confirmation of what you already know. Get them wrong, and you hand your auditor a roadmap to your gaps before fieldwork even begins. This guide covers what each document is, what the AICPA professional standards require under DC Section 200 and AT-C Section 205, and where most companies, including those running GRC platforms, consistently fall short.

The Standards That Govern SOC 2: AT-C Section 205 and DC Section 200

SOC 2 engagements are attestation engagements performed under American Institute of Certified Public Accountants (AICPA) attestation standards. The governing standard is AT-C Section 205, Examination Engagements, updated under SSAE No. 21 to focus on assertion-based examinations. This standard defines the service auditor's responsibilities and, equally important, it defines management's responsibilities, which include management's written assertion that the system description fairly presents the system as designed and implemented, and that the controls described operated effectively throughout the audit period.

AT-C Section 205 places explicit responsibility on the service organization, not just the auditor. Management is responsible for preparing the description, identifying suitable criteria, and evaluating whether controls satisfy those criteria. This is not a formality. If your SOC 2 system description overstates the scope of your controls, or your control matrix maps controls to criteria they do not actually address, management is making a misrepresentation in the report, and auditors treat it that way.

DC Section 200, the AICPA's 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report, specifies what must be included in the system description. These are minimum required elements, not recommendations. The auditor's opinion specifically references whether the description is fairly presented in accordance with DC Section 200. If a required element is missing or materially misstated, the auditor must modify their opinion.

In the current environment, following the 2026 revelations about automated compliance platforms generating SOC 2 reports with thin or fabricated evidence, auditors are scrutinizing the substance of management's representations more rigorously than at any point in the past decade. Understanding what these standards actually require is no longer optional.

What Is a SOC 2 System Description?

A SOC 2 system description is the narrative document in Section 3 of the SOC 2 report. It describes the system being examined: what it does, how it is built, how it is operated, what risks it faces, and how controls are designed to address the applicable Trust Services Criteria (TSC). Under DC Section 200, it must address each of the following components.

The nature of the services provided

The description must explain what your system does and who your customers are. This matters more than most organizations realize. The Trust Services Criteria are evaluated in the context of whether your controls are designed to meet your service commitments to customers, so vague service descriptions create ambiguity throughout the entire report. An auditor reading "we provide cloud-based SaaS services to enterprise customers" has nothing to anchor the criteria to. A description that specifies what data is processed, for which customer segments, through which service tiers, gives the auditor and report users something concrete to evaluate.

Principal service commitments and system requirements

DC Section 200 requires you to identify the commitments you have made to your customers, typically through your terms of service, SLAs, and privacy notices, and the system requirements needed to meet those commitments. This is the mechanism by which the TSC become relevant to your specific organization. Availability criteria matter because you have committed to uptime. Confidentiality criteria matter because you have committed to protecting customer data. If those commitments are not clearly documented, the auditor cannot evaluate whether your controls are designed to meet them, and the report loses much of its value to the customers relying on it.

The five components of the system

DC Section 200 requires the description to address five system components: infrastructure (data centers, networks, hardware, cloud environments), software (applications, operating systems, middleware, third-party tools), people (personnel involved in designing, operating, and monitoring the system), procedures (automated and manual processes), and data (types of data processed, stored, and transmitted, including sensitivity classifications).

This five-component model is mandatory. Each component must be described with enough specificity that a sophisticated reader can understand how the system operates. Generic language like "we use industry-standard cloud infrastructure and modern software development practices" does not meet the DC Section 200 standard and will draw comments from a careful auditor. Name your cloud provider. Describe your deployment architecture. Identify the personnel roles involved in operating the system. Specify the types of data your system handles and how data flows through the environment.

SOC 2 system boundary and scope definition

Perhaps no element causes more problems in practice than system boundaries. The SOC 2 system boundary defines what is inside the scope of the examination and what is outside it. This boundary must be clearly defined and consistently applied across the system description, the control matrix, and the auditor's testing work.

The boundary definition must also address subservice organizations: third-party vendors who perform functions relevant to the security, availability, or confidentiality of your system, such as cloud hosting providers, managed security service providers, or payment processors. For each subservice organization, the service organization must choose between two approaches.

The carve-out method excludes the subservice organization from the scope of the examination, discloses the functions they perform, and references their own SOC report for assurance. The service organization must identify the complementary subservice organization controls (CSOCs) it relies on the subservice organization to operate. The inclusive method includes the subservice organization within the scope of the examination, which requires the auditor to obtain evidence about the subservice organization's controls directly.

DC Section 200 requires that this choice be disclosed in the description, that the CSOCs be clearly identified, and that the description explain what the service organization cannot do without those subservice organization controls operating effectively.

Getting scope wrong is expensive. A boundary that is too broad draws in systems and controls that are not actually being tested, creating gaps when evidence is collected. A boundary that is too narrow excludes critical systems and raises questions from customers about what the report actually covers. Misaligned boundaries create problems that surface during fieldwork, not before it.

The applicable Trust Services Criteria

The description must identify which of the five TSC categories are in scope: Security (CC), Availability (A), Confidentiality (C), Processing Integrity (PI), and Privacy (P). Security is always included. The others are added based on the service organization's commitments to customers and the nature of the data it handles.

The criteria are defined in the AICPA's Trust Services Criteria (TSP Section 100, 2017 edition), aligned with the COSO 2013 Internal Control framework. Each criterion maps to one or more points of focus, and your controls must address those points of focus in a specific, testable way. Selecting criteria that are not actually supported by your control environment, because a sales team wants a comprehensive-looking report, creates a mismatch that surfaces directly in fieldwork.

Risk assessment and control design

The description must also address the risks that could prevent the system from meeting its service commitments, and how the service organization has designed controls to respond to those risks. This section is frequently reduced to boilerplate, but DC Section 200 treats it as substantive. A well-written SOC 2 system description explains the threat environment specific to the organization, identifies the risks that are most material, and connects those risks to specific controls in the control matrix. This is where the description and the control matrix begin to function as a unified document rather than two separate artifacts.

What Auditors Evaluate in the System Description

Under AT-C Section 205, the auditor evaluates whether the system description is fairly presented in all material respects in accordance with DC Section 200. Fairly presented means the description does not omit or distort information that would affect a user's understanding of the system and its controls.

Common findings that result in qualified opinions or management letter comments include: system boundaries that do not match the controls actually described; references to subservice organizations without identifying the CSOCs the service organization relies upon; descriptions of the five system components that are too generic to be useful; service commitments that do not align with the criteria in scope; and risk narratives that are disconnected from the control environment. All of these are preventable with careful drafting and a reconciliation step before the audit begins.

How to Write a SOC 2 System Description: A Practical Starting Point

If you are looking for help with your SOC 2 system description, the following steps reflect what a well-prepared service organization works through before an auditor ever sees the document.

Start with your service boundary. Before writing a word, define precisely what is in scope, which products, environments, and infrastructure components, and document that boundary in a way that matches the controls you actually operate and the evidence you can produce. If your boundary and your controls do not line up, the description will conflict with the control matrix, and auditors will find it.

Document the five system components with specificity. For each of the five DC Section 200 components, write with enough detail that someone unfamiliar with your environment can understand how your system works. Name your cloud provider and hosting architecture. Identify the software layers involved in your service. Describe the personnel roles that operate and monitor the system.

Identify your subservice organizations and make the carve-out or inclusive decision. List every third-party vendor that performs a function relevant to your in-scope Trust Services Criteria. For each one, document whether you are using the carve-out or inclusive method, and list the CSOCs you rely on them to operate.

Map your service commitments to your TSC selection. Review your terms of service, SLAs, and privacy notices and confirm that the Trust Services Criteria you have selected actually correspond to commitments you have made. Adding Availability or Confidentiality criteria because they look comprehensive, without commitments that anchor them, creates a mismatch that surfaces during fieldwork.

Write the risk narrative to match your control matrix. If a risk is named in the description, there should be a control in the matrix that addresses it. If there is a control in the matrix with no corresponding risk in the description, either the risk is undocumented or the control is unnecessary.

Reconcile the description against the matrix before the audit begins. This single step eliminates most of the inconsistencies that generate auditor findings. Every frequency, owner, and criteria mapping in the control matrix should match what is stated in the description.

If your organization needs hands-on help building or reviewing its SOC 2 system description, the Ledger Audits Gap Sprint covers exactly this: a complete gap assessment, scope review, and evidence-requirements map delivered before your audit window opens.

What Is a SOC 2 Control Matrix?

A SOC 2 control matrix is a structured document that maps each control your organization operates to the specific Trust Services Criteria it satisfies. It is the operational backbone of the SOC 2 engagement: the auditor uses it to plan and execute testing, and report users and their own auditors use it to understand exactly what was tested, by whom, how often, and with what evidence.

The control matrix is sometimes called the controls mapping document, controls table, or risk and controls matrix. Whatever you call it, the function is the same: it connects what your system does, described in the system description, to how your organization demonstrates it is controlled, evidenced through the control matrix.

The AICPA does not prescribe a specific format for the control matrix, but its content requirements flow directly from the TSP 100 criteria and from AT-C Section 205's requirement that the service auditor test whether controls are suitably designed and operating effectively. A complete SOC 2 control matrix should contain, at minimum: a unique control identifier; a control description specific enough to be testable; the Trust Services Criteria mapping to the specific criterion (CC6.2, not just "CC6"); the control owner responsible for operating it; the control frequency (daily, weekly, monthly, quarterly, or event-driven); the control type (preventive or detective, automated or manual); and the evidence source that demonstrates the control operated.

Mapping controls to Trust Services Criteria

The relationship between controls and criteria is not one-to-one. A single control can address multiple criteria, and a single criterion typically requires multiple controls working together to be fully satisfied. Doing this mapping work properly is where organizations either perform the intellectual work or cut corners in ways that surface during fieldwork.

CC6 (Logical and Physical Access Controls) is one of the most heavily tested criteria in a SOC 2 Type II examination. Satisfying CC6 requires specific, discrete controls for access provisioning, periodic access reviews, multi-factor authentication, privileged access management, and access termination upon separation. Mapping a single "access review policy" to every CC6 sub-criterion, without individual controls for each requirement, will not satisfy the auditor. The auditor tests each control independently, requests evidence of operation for sampled instances across the audit period, and evaluates whether the control's design would, if operating as described, prevent or detect the failure it is designed to address.

Controls must be testable

This is the most important principle in control design, and it is the one that automated compliance platforms consistently undermine. A control described as "management reviews access logs monthly and documents exceptions" is testable. The auditor can request the review artifacts for each month of the period, verify that the appropriate person performed the review, confirm that exceptions were documented and remediated, and form a view on operating effectiveness. A control described as "the organization implements appropriate access controls in accordance with its security policy" is not testable. It is a policy reference, not a control, and auditors are trained to recognize the difference.

Yet this kind of language appears constantly in GRC platform-generated control libraries, and it creates a gap between what the service organization believes it has documented and what an auditor can actually examine.

SOC 2 operating effectiveness evidence

For a SOC 2 Type II engagement, the audit period is typically twelve months. Every control in the matrix must have operated throughout that period, and evidence of operation must be available for each control across the full period. Controls implemented in month ten of a twelve-month period cannot be reported as having operated effectively for the full period; they can only be reported as operating effectively from their implementation date forward, and that change must be disclosed in the system description.

This means evidence collection is not an end-of-audit activity. It is a continuous operation throughout the period. The control matrix should include, or link to, the evidence repository structure, with period-tagged artifacts, named owners, and a clear chain of custody for each artifact. GRC platform exports from Sprinto, Drata, Vanta, or similar tools are a starting point, but every automated artifact should be human-verified before fieldwork begins. Automated tools can fail, produce incomplete outputs, or pull evidence from outside the correct sampling window. Catching those failures on your watch, before the auditor does, is the purpose of pre-fieldwork evidence review, and it is the standing discipline behind the Evidence Engine.

Complementary user entity controls (CUECs) and CSOCs

CUECs are controls that your customers must implement for your controls to be effective. If your service organization relies on customers to configure their own access policies, enforce MFA on their end, or manage their own user provisioning, those are CUECs. CSOCs are the controls you rely on your subservice organizations to operate. Both must be identified in the control matrix and disclosed in the system description. Omitting them is a material gap under DC Section 200 and AT-C Section 205.

How the System Description and Control Matrix Work Together

The SOC 2 system description and the control matrix are not independent documents. The system description tells the reader what the system does, what risks it faces, and what controls are designed to address those risks. The control matrix tells the auditor how those controls are structured, who owns them, how they operate, and what evidence demonstrates their operation.

Inconsistencies between the two are a serious problem. If the system description states that logical access is reviewed quarterly and the control matrix records a monthly review frequency, the auditor has two documents that contradict each other, and neither can be relied upon without clarification. If the system description describes a data encryption control as addressing CC6.7 and the control matrix maps the same control only to CC9.1, the mismatch raises questions about whether management understands its own control environment.

These inconsistencies appear more often than they should, almost always because the two documents were prepared separately by different people without a reconciliation step. The best practice, consistent with AICPA guidance, is to treat both documents as a unified system of documentation: prepared in parallel, reviewed together, and updated together whenever controls change.

The Mock Fieldwork Dry Run

One of the most effective and underused practices in SOC 2 readiness is the mock fieldwork dry run: reviewing your system description and control matrix as an auditor would, before the real auditor does. This means going through the control matrix control by control, requesting the evidence that would demonstrate each control's operation for the full audit period, evaluating whether that evidence is complete and period-appropriate, and testing whether the control as described matches the control as actually operated.

This step surfaces the gaps that matter: controls that exist in the matrix but are not consistently operated, evidence that exists but is stored in ways that make retrieval difficult, controls whose descriptions do not match actual practice, and criteria that are addressed in the matrix but have no corresponding narrative in the system description. Finding these gaps internally, before fieldwork, is the difference between a clean report and one with exceptions.

What the 2026 Compliance Automation Scandals Clarified

The 2026 revelations about automated compliance platforms confirmed what experienced practitioners already knew: a SOC 2 system description that describes a system that does not exist, combined with a control matrix populated with controls that are never actually tested, produces a SOC 2 report that is worse than no report at all. It gives customers false assurance, it leaves the service organization exposed to the very risks the report is supposed to demonstrate are managed, and it puts the organization in a difficult position when a sophisticated buyer's auditor asks follow-up questions.

DC Section 200 and AT-C Section 205 exist precisely to prevent this. They impose minimum standards on what must be documented, how it must be presented, and what management is asserting when it signs off on the report. The standards have not changed. What has changed is that the market now understands the difference between compliance theater and evidence that holds up.

Frequently Asked Questions

What is a SOC 2 system description?

A SOC 2 system description is the narrative document in Section 3 of the SOC 2 report. It describes the system being examined, covering the services provided, service commitments, the five system components (infrastructure, software, people, procedures, data), system boundaries, subservice organizations, applicable Trust Services Criteria, and the risks the organization faces. Management is responsible for preparing it, and it must meet the AICPA's DC Section 200 requirements.

How do I write a SOC 2 system description, and where do I start?

Start by defining your system boundary and identifying which products and environments are in scope. Then document the five DC Section 200 system components with specificity, list your subservice organizations, map your Trust Services Criteria to your actual service commitments, and write a risk narrative that connects directly to the controls in your control matrix. Reconcile the description against the control matrix before the audit. If you need structured help, a readiness assessment from an independent firm can identify gaps before your audit window opens.

What does DC Section 200 require?

DC Section 200 requires the system description to address: the nature of services provided, principal service commitments and system requirements, the five system components (infrastructure, software, people, procedures, data), the system boundary including subservice organizations, the Trust Services Criteria in scope, and the risks that could prevent the system from meeting its commitments along with how controls address those risks.

What is a SOC 2 control matrix?

A SOC 2 control matrix is the document that maps each control operated by the service organization to the specific Trust Services Criteria it addresses. It should include the control description, criteria mapping, control owner, frequency, type (automated or manual, preventive or detective), and the evidence source that demonstrates operation. The auditor uses the control matrix to plan and execute testing.

How does AT-C Section 205 affect SOC 2 audits?

AT-C Section 205 governs SOC 2 examination engagements under SSAE No. 21. It requires the service auditor to evaluate whether controls are suitably designed and operating effectively, and it requires management to provide a written assertion that the system description is fairly presented and that controls met the applicable criteria. Management's assertion is a legal representation, not a formality.

What are CUECs in a SOC 2 report?

Complementary user entity controls (CUECs) are controls that the service organization's customers must implement for the service organization's own controls to be effective. If your platform relies on customers to configure their own role-based access policies, that is a CUEC. CUECs must be identified in the system description and disclosed to report users so they understand the shared responsibility model.

What is the difference between the carve-out and inclusive methods for subservice organizations?

Under the carve-out method, the subservice organization is excluded from the scope of the SOC 2 examination. The service organization discloses the functions they perform, identifies the CSOCs it relies on them to operate, and references the subservice organization's own SOC report for assurance. Under the inclusive method, the subservice organization is within scope and the auditor obtains evidence about their controls directly.

Why do SOC 2 audits fail?

The most common reasons SOC 2 audits produce exceptions are: controls that exist on paper but are not consistently operated; evidence that is incomplete, missing, or outside the correct sampling window; system descriptions that do not accurately reflect the system as it operates; control matrices that map controls to criteria they do not substantively address; and subservice organizations or CUECs that are not properly identified. Most of these failures are preventable with a pre-fieldwork mock dry run.

The Bottom Line

A SOC 2 system description is management's representation, under AICPA attestation standards, of how a system works and how it is controlled. A SOC 2 control matrix is the operational document that connects those controls to the Trust Services Criteria they address and demonstrates that they operated throughout the audit period. Both must be accurate, internally consistent, and grounded in what is actually happening in the organization.

DC Section 200 and AT-C Section 205 set a high bar. Meeting that bar requires real work: defining scope carefully, describing the system with specificity, mapping controls to criteria with intellectual honesty, collecting operating effectiveness evidence continuously throughout the period, and reviewing the whole package before the auditor arrives. Companies that do this produce reports that hold up under scrutiny. Companies that do not are finding out, in the current environment, that sophisticated buyers and their auditors know the difference.