Writing the SOC 2 System Description (Section 3)

By Sam Rivera, Founder, SentinelPanda · May 28, 2026 · 4 min read · SOC 2

A SOC 2 report has four sections. Section 3 — the System Description — is the one written by management, and the one auditors test against. Get it wrong and you earn a qualified opinion.

What Section 3 is for

A SOC 2 report has four sections: the auditor's opinion (Section 1), management's assertion (Section 2), the System Description (Section 3), and the controls, criteria, tests, and results (Section 4). Sections 1 and 2 are short formal statements. Section 4 is the table of controls and what the auditor tested.

Section 3 is the narrative: management's own description of the system that is the subject of the report. The auditor's opinion is conditional on whether Section 3 is fairly stated, so the description has to be honest, complete, and aligned with what Section 4 actually tests.

What it must contain

• A description of the company and the services provided — context for what is being assured.
• The principal service commitments and system requirements — the promises customers can rely on.
• The components of the system: infrastructure, software, people, processes, and data flows.
• The boundaries of the system — what is in scope and, by exclusion, what is not.
• The relevant aspects of the control environment, risk assessment, communication, and monitoring.
• Significant changes to the system during the observation period (Type II only).
• Subservice organisations and the method used — carve-out or inclusive — with complementary user-entity controls if any are required of customers.
• Any complementary subservice organisation controls you assume from your subservice providers.
• Significant events, if any, that affected the system during the period.

Where teams drift

The most common failure is description-control drift: the description says "all production access requires MFA" but the control in Section 4 carves out break-glass accounts; or the description claims daily backup verification but the operational control is weekly. The auditor will catch the drift in fieldwork, and the consequence is either a control gap or a qualified opinion. Treat the description as a contract between management and the auditor, and keep it aligned with the controls you actually operate.

A close second is staleness: the description was written ahead of the first Type I and never updated. By the third Type II, the architecture has changed, components have been added or retired, subservice organisations have moved, and the description no longer matches the system. Version it, treat changes as a release, and surface "description updated" alongside every other release note.

Subservice organisations: carve-out or inclusive

Every SaaS company depends on subservice organisations — your cloud provider, your identity provider, your transactional email service. SOC 2 lets you treat them two ways. Inclusive: you (or your auditor) test their controls and include them in your report. Carve-out: you describe the boundary, state which controls you rely on the subservice for, and document complementary user-entity controls that the subservice expects of you. Almost every modern SOC 2 uses carve-out for the major cloud providers — testing AWS or Azure controls yourself is not realistic.

The description must clearly state which method is in use, list the subservice organisations, and identify the complementary controls you assume from them. If your customers rely on you with the carve-out method, your description should also call out complementary user-entity controls you expect from them.

A few practical drafting rules

• Write in plain English. Auditors and customer-side security reviewers both read this.
• Avoid marketing language. "Bank-grade security" is not testable and weakens the document.
• Match Section 3 wording to the control titles in Section 4 wherever possible — drift hides in vocabulary mismatches.
• Version the document and treat updates like any other release.
• Re-read it before fieldwork starts, with a copy of Section 4 open beside it.

Make it the live document, not the year-end document

A System Description that is updated only at the end of an observation period will diverge from reality every other day of the year. Updating it on the same cadence as architecture decisions, subservice changes, and policy updates is more work in any given month and dramatically less work in audit season — because by the time fieldwork starts, the document already matches the system being tested.