What Is a SOC 2 System Description?

The system description is the section of a SOC 2® report where your organization describes the system being examined — what the service does, where its boundaries sit, what it runs on, who operates it, which third parties it depends on, and which controls are in place. In a finished report it usually appears as Section 3, after the auditor's opinion and management's assertion.

Two facts about it surprise most first-time teams. First, you write it, not your auditor. Second, the auditor forms an opinion on it — on whether the description is fairly presented in accordance with the AICPA's description criteria — separately from their opinion on whether your controls were suitably designed and operating effectively. So it is simultaneously the most self-authored part of the report and one of the easiest places to earn a qualified opinion.

Why It Matters More Than Teams Expect

Everyone focuses on the controls. But when a prospect's security team receives your report, the description is what they actually read — it is the only section written in plain prose about what you do. Their reviewers use it to answer one question: does this report cover the thing we are buying?

A description that never clearly names your product, or that draws its boundary so loosely nobody can tell what's included, fails that test even when every control passed. We wrote about this from the other side of the table in how to read a vendor's SOC 2 report — the description is where an experienced buyer starts.

What Goes In It

The AICPA publishes description criteria that the content is assessed against. In practice, a complete description covers:

• The types of services provided. What you actually sell, in the words your customers would use.
• Principal service commitments and system requirements. What you promise customers — availability targets, confidentiality undertakings, contractual and regulatory obligations — and the requirements your system must meet to keep those promises.
• The components of the system. Conventionally five: infrastructure, software, people, procedures, and data. This is where you name your cloud environment, your application, the teams that operate it, the processes they follow, and the data classes you handle.
• The boundaries of the system. What is in, and what is out.
• Relevant aspects of the control environment — governance, risk assessment, information and communication, and monitoring activities.
• Subservice organizations you rely on, and how they are treated.
• Complementary user entity controls — what your customers must do on their side.
• The applicable trust services criteria and the controls you have in place to meet them.
• Significant changes during the period, and any incidents relevant to the criteria.

That last one catches people out on Type II reports. If you migrated regions, changed identity providers, or restructured the team mid-period, the description has to say so — the report covers a window of time, not a moment.

Subservice Organizations: Carve-Out or Inclusive

Almost every startup depends on a cloud provider, and the description has to explain how those dependencies are handled. There are two methods.

With the carve-out method — by far the more common — the subservice organization's controls are excluded from your description and your auditor's testing. You still have to identify the provider, describe the services it performs, and state the complementary subservice organization controls you assume it operates. You're saying, in effect: our controls work provided our host does its part, and here is that part.

With the inclusive method, the subservice organization's relevant controls are pulled into your description and tested as part of your examination. It produces a more complete picture and is considerably harder to arrange, since it requires the provider's cooperation.

Pick carve-out unless you have a specific reason not to, and make sure your vendor register and your description agree about who you depend on — see vendor and third-party risk management.

Complementary User Entity Controls

Complementary user entity controls, or CUECs, are the controls your customers must implement for your controls to achieve the criteria. Typical examples: the customer is responsible for provisioning and deprovisioning its own users, for enforcing MFA on its accounts, for configuring its own data retention settings, for reviewing its own audit logs.

They deserve deliberate thought for two reasons. Written well, they set an honest boundary of responsibility — genuinely useful for both sides. Written lazily, they read as an attempt to offload your obligations onto the customer, and a sharp reviewer will notice. Keep them to things a customer really does control, and make sure your product documentation actually tells them how.

Where Descriptions Go Wrong

• Describing the company instead of the system. A description that reads like an About page tells the auditor nothing about boundaries. Name the system.
• Aspirational controls. The description must reflect what genuinely operated during the period. Describing a quarterly access review you ran twice is how a clean control set turns into a qualified opinion — the controls may be fine, but the description is not fairly presented.
• Boundary drift. The description says one product; the evidence covers a different environment. Reconcile it before fieldwork, not during.
• Template residue. Copy-pasted descriptions mention data centres you don't have, or roles nobody holds. Auditors read a lot of these and spot the seams quickly.
• Going stale. A description is written for a period. Reusing last year's without revisiting changes is one of the more common Type II problems.
• Silence on incidents. If something relevant happened, saying so plainly is far better than an auditor discovering it independently.

How to Actually Produce One

The practical order matters. The description is downstream of your control work, not a document to draft first: settle your scope, get your controls genuinely operating, collect the evidence that proves it, and then describe what exists. Teams who write the description early end up describing intentions and rewriting it after their readiness assessment.

This is one of the places where a compliance platform earns its keep, because almost every input already lives in one. AuditBadger generates the description section by section once your controls are in place — pulling the system components, the control set mapped to the applicable criteria, your subservice organizations and vendor register, and your policies out of the platform, so each section starts from what is actually implemented rather than a blank page or someone else's template.

It is deliberately semi-automatic. Management asserts the description in the report, so a generated draft is a starting point you review, correct, and sign off — not something to submit unread. What it removes is the blank page and the drift between the description and reality, which is where most of the pain lives.

The Takeaway

The system description is the one section of your SOC 2® report you fully author, the first thing buyers read, and a document your auditor issues an opinion on. Write it about the system rather than the company, keep the boundary tight and honest, be explicit about what your cloud provider does and what your customers must do, and describe only what genuinely operated during the period. Everything else in the report is evidence; this is the part that explains what the evidence is about.

Next: the complete SOC 2 guide for founders for the framework end to end, Type I vs Type II for how the period affects what you describe, or when a startup actually needs SOC 2 if you're still deciding.