Who writes the SOC 2 system description?

Formally, the system description belongs to management: it is Section III of the report, it sits under the signed management assertion, and the audit firm’s independence rules bar them from authoring the thing they then attest to. Your auditor will hand you a template and mark up drafts, but they cannot write it — and a firm offering to should worry you.

In practice, the pen moves with company size. At a seed-stage startup the CTO or a founding engineer drafts it, usually twice — the first pass describes the architecture, and the rework recasts it in the terms the report requires: system boundaries, the five components (infrastructure, software, people, procedures, data), subservice organizations, and CUECs. Companies with a compliance manager hand it there. A large share outsource the drafting to a managed team and keep review, approval, and signature in-house — the one part that can’t be delegated.

Two sign-offs matter regardless of who drafts. An executive signs the management assertion that the description is fairly presented, and the people who actually run the systems fact-check the narrative line by line — the auditor will walk the description against reality, and mismatches surface as findings. The full anatomy, required content, and an annotated outline live on the SOC 2 system description page.

The auditor’s job is to conclude the description is fairly presented: they interview owners, walk through processes, and compare the narrative to configurations they can observe. Overstate anything — a disaster-recovery site you don’t have, a review cadence you don’t keep — and they will require revisions before issuing. Accuracy beats polish; describe the system you actually run.