Opinions and test tables mean little without context, and the system description supplies all of it: what the service does, which systems sit in scope, where the boundary runs, which subservice organizations the service leans on, what customers must handle themselves as CUECs, and how the control environment hangs together. Management writes it — not the auditor — and the auditor then tests whether it is fairly presented, which makes overstatement an audit risk of its own.
A strong description is specific enough that a stranger could sketch your architecture and daily operations from it, yet careful enough that every NDA’d reader isn’t handed a secrets dossier. Most run ten to twenty-five pages, and they go stale as the product evolves, so each renewal should begin with a refresh. For the required elements, an annotated outline, who writes it, and how auditors judge fairness of presentation, see the full guide to the SOC 2 system description.
