Writing the system description for SOC 2 and ISAE 3402: structure, pitfalls and practical tips

Organizations starting a SOC 2 or ISAE 3402 engagement tend to focus on controls and evidence. But there is one part of the report the service organization has to write itself: the system description. The auditor evaluates that description and explicitly addresses it in the opinion. A weak description leads to delays, debate with the auditor and, in the worst case, a modified opinion. This article covers the structure, the requirements and the mistakes we encounter most often in practice.

What is the system description and why does it matter?

A SOC 2 or ISAE 3402 report consists of roughly three parts: the auditor's opinion, management's description of the system, and the overview of controls with the auditor's tests and results. The system description is not an appendix but a core part of the report, and it is the part for which management carries responsibility. That responsibility is formally confirmed in the management assertion that accompanies the report.

The auditor does not express an opinion on whether your service is good. The auditor expresses an opinion on three things: whether the description fairly presents the system as designed and implemented, whether the controls are suitably designed to meet the objectives or criteria, and (for Type II) whether those controls operated effectively throughout the period. The description is the reference point for everything that follows: what is not in it falls outside the audit, and what is in it must be accurate and demonstrable.

What must it contain?

For SOC 2, the AICPA has description criteria prescribing which topics must be addressed. ISAE 3402 has comparable requirements. In practice it comes down to the following elements.

The services and the boundaries of the system. Which services do you provide, to what kind of customers, and where does the system end? This delineation matters more than many organizations think. A SaaS provider that scopes only its production platform must say so explicitly, otherwise the reader will assume internal operations or adjacent products are covered too.

The components of the system. The description covers infrastructure, software, people, procedures and data. Think of the cloud platform you run on, the architecture at a high level, the teams that deliver and operate the service, the key processes (change management, incident management, access management, backup and recovery) and the data flows through the system.

Service commitments and system requirements. For SOC 2 you describe the commitments you make to customers (for example availability, confidentiality, security level) and the requirements the system must meet to fulfil them. The Trust Services Criteria are then applied against those commitments.

Subservice organizations. If suppliers perform a relevant part of the service, such as a cloud provider or data center, you describe for each subservice organization whether you apply the carve-out or inclusive method, and which controls you expect that party to operate.

Complementary user entity controls. Virtually every service relies on measures the customer must take, such as managing its own user accounts or configuring integrations correctly. These CUECs belong explicitly in the description, because the auditor's opinion assumes the customer has implemented them.

Relevant changes and incidents. For a Type II report you describe significant changes to the system during the review period. Significant incidents that occurred during the period can also be relevant to the reader and then belong in the description.

The five mistakes we see most often

First: the description as a brochure. Marketing language does not belong in it. The auditor must be able to verify every statement, and every superlative you cannot substantiate generates review comments.

Second: describing what should exist instead of what does. Basing the description on policy documents rather than actual practice results in controls that do not exist or work differently. Testing exposes that, leading to exceptions or a description that has to be rewritten mid-audit.

Third: unclear boundaries. If it is not sharp which systems, environments and locations are in scope, discussions arise with the auditor about the extent of testing, and with customers about what the report actually covers.

Fourth: forgotten CUECs and subservice organizations. A description without CUECs suggests the service organization covers everything itself. That is almost never true, and an auditor will probe it. The same applies to cloud providers that are not mentioned anywhere while the entire service runs on them.

Fifth: not maintaining the description. After year one, the description is often reused without an update, while the system has changed: new components, modified processes, different suppliers. An outdated description is by definition no longer fairly presented.

A practical approach to writing it

Start early, preferably during the readiness phase and well before the review period begins. Appoint one owner, usually the security officer or compliance manager, but have the content supplied by the people who really know the system: engineering, operations and HR. Use the description criteria as a checklist so you do not miss a mandatory element. Write factually and at the right level of abstraction: detailed enough to be meaningful, but without configuration details that change every month. And show the draft to your auditor early; a short upfront review prevents rewriting during the audit.

Also plan a fixed annual moment to update the description, for example tied to the start of the new review period. Changes in architecture, suppliers or processes are then processed in a structured way, and the management assertion you sign remains defensible.

Conclusion

The system description is not a formality but the foundation of the report: it defines the scope of the audit, it is the part management itself accounts for, and it is what customers and their auditors read first. Keeping the description factual, complete and current prevents debate during the audit and delivers a report your customers can actually use. Need help writing or reviewing a system description? We are happy to assist.