How to write your SOC 2 system description yourself

The system description is the part of a SOC 2 report written by your management, not the auditor. It explains your services, the commitments you make, the parts of the system, and the boundaries. Draft it from facts you can prove, keep it plain, and have the auditor review it.

What goes in it

A system description typically covers the items below. Confirm the exact list against the AICPA description criteria with your auditor:

• The services you provide and who uses them.
• Your principal service commitments and system requirements, such as uptime promises and security terms in contracts.
• The components of the system: infrastructure, software, people, procedures and data.
• The boundaries of the system, meaning what is in and what is out.
• Significant incidents, where relevant.
• The criteria and controls that apply, including any criteria you consider not relevant, with a reason.
• Complementary controls that customers are expected to operate.
• Subservice organizations you rely on.
• For a Type 2 report, significant changes during the period.

The required list can differ between Type 1 and Type 2. Your auditor will tell you which items apply.

Start from what you already have

Most of the material exists in other places. Pull it together rather than writing from a blank page.

• Services and commitments: your terms of service, order forms, and any uptime or security commitments in customer contracts.
• Infrastructure: your cloud account structure and a simple diagram.
• Software: the applications and the main internal tools in scope.
• People: teams with a role in running the system, by function, not by name.
• Procedures: the policies you already follow, referenced by title.
• Data: the data types you handle and where they sit.

A one page data flow diagram does a lot of work. See the asset inventory and data flow diagram guide.

The test the description must pass

A useful test: the description should reflect the system as actually implemented, cover each relevant criterion, and not omit or distort information that report users would likely need. In practice that means no aspirational statements. If you plan to add a control next quarter, it is not in the description yet.

Common drafting mistakes

• Describing the architecture you wish you had.
• Leaving out a tool that handles customer data because it feels minor.
• Forgetting subservice organizations such as your cloud host and payment processor.
• Copying marketing language. Hype in a system description becomes a claim an auditor has to test.
• Writing it once and never updating it when the stack changes.

Review loop

Have an engineer check the technical sections and someone from legal or sales check the commitments. Then send it to the auditor for comments. Expect edits. Treat the final text as something management stands behind, because it does.

Safeguard's compliance and evidence automation can help keep the asset and dependency facts behind the description current, but the description itself is your management's statement.

Quick check

Last reviewed: 19 October 2026.