The SOC 2 system description: what to write, what to leave out, and what the auditor checks

What the system description is, and who owns it

Every SOC 2 report includes a description of the system, written by the service organisation's management, not the CPA firm. Management asserts in writing that it is presented in accordance with the description criteria, and the CPA firm, as service auditor, gives an opinion on it alongside its opinion on the controls. Client reviewers read it to learn exactly what that opinion covers.

The criteria are the AICPA's 2018 SOC 2 Description Criteria, with implementation guidance revised in 2022, developed by its Assurance Services Executive Committee and often cited as DC 200. The AICPA says they are used both to prepare a description and to evaluate one, so management and auditor share one text, which defines what to disclose rather than a template or a length.

What the description must contain, section by section

In SOC 2 the system is everything used to deliver the service: infrastructure, software, people, procedures and data. The table turns the criteria into a practical layout, with the records the auditor will compare each section with; the order and headings are yours to choose.

Principal commitments are those common to clients as a group, not every negotiated term; system requirements are what the system must do to honour them and the law. Controls are designed and tested against both, so loose wording here weakens the report.

Subservice organisations and user entity controls: carve-out or inclusive

A subservice organisation is a provider whose controls are needed, with yours, to achieve your commitments: usually the cloud platform, sometimes a managed detection service or an outsourced support desk.

Under carve-out, the description states what the provider does, which criteria its controls help meet and the controls you assumed it operates, the complementary subservice organisation controls; its own controls are excluded, and clients read its report for them. Under the inclusive method, its relevant controls are described and tested within your examination, which needs its cooperation and its management's written assertion. Carve-out is the norm for large cloud platforms, which publish their own reports, and inclusive suits a group affiliate. Under carve-out, expect the auditor to test your review of the provider's report and the user entity controls that report assigns to you.

Complementary user entity controls work in reverse: controls you assumed clients would operate, such as administering their users' access, protecting keys you issue and telling you when an authorised contact leaves. Keep them few, specific and consistent with the contract; reviewers read them as responsibilities handed over.

Incidents and changes: the disclosures teams hesitate over

The criteria require disclosure of identified system incidents that resulted from controls not suitably designed or operating effectively, or that otherwise caused a significant failure against a commitment or system requirement, giving each one's nature, timing, effect and disposition. Blocked attacks and routine alerts do not normally qualify. Omitting one that does rarely survives fieldwork: the auditor reads the incident register and client notifications, and notified clients will look for it. A short, factual account with the remediation does far less damage.

A Type 2 description also discloses significant changes during the period, such as a new cloud region, a replacement identity provider or a control introduced part-way through. Date each one: the auditor usually tests the old and new controls for their own parts of the period.

What to leave out

If nobody could evidence a statement, it does not belong.

• Marketing language. Terms such as industry-leading or bank-grade cannot be tested and describe nothing.
• Controls you do not operate. Physical security at a public cloud data centre belongs among the complementary subservice organisation controls, and client duties among the user entity controls. Claimed as yours, either becomes a statement the auditor cannot support.
• Aspirational processes. The description presents the system as designed and implemented at the date or through the period, so a platform due next quarter or an untested recovery plan is not part of it. Plans can go in a separate section of other information, which the auditor reads but gives no opinion on.
• Detail that helps an attacker. The report circulates widely, so omit IP ranges, rule sets, software versions and individuals' names; refer to roles.

How the CPA firm tests the description

The service auditor decides whether the description is fairly presented, which the opinion expresses as presenting the system designed and implemented, at the date or throughout the period, in accordance with the description criteria. Each section faces three questions: is every required disclosure there, is it accurate, and could anything omitted or overstated mislead report users?

The auditor reads the draft against the criteria, walks through processes with the people who run them, and inspects inventories, diagrams, contracts, vendor, incident and change records and configurations. A claim that multi-factor authentication protects every administrative account meets the identity provider's settings; three named subservice organisations meet a vendor register listing five.

Misstatements are raised with management and corrected, often over several drafts. A material one left uncorrected, or uncorrectable because the system did not run as described, produces a modified opinion every reader sees. Share the draft at planning, so boundaries, carve-out choices and user entity controls are agreed before the period starts.

Common defects, and how to avoid them

• Inherited text. Template or last year's wording keeps retired tools and misses new regions; rebuild from current inventories every period.
• Blurred boundaries. The overview covers every product though the report covers one, or an offshore support team with production access is missing.
• Missing or misfiled providers. An outsourced help desk affecting the commitments is absent, or a carved-out provider's controls appear as yours.
• Borrowed user entity controls. They assign clients duties the contract never gives them.
• Silence on incidents and changes. A known outage or mid-period migration goes unmentioned until the auditor finds it.

SOC 2 system description: questions buyers ask