Two documents decide how your fieldwork goes
The system description and the control matrix sit at the center of every SOC 2 engagement. Auditors read them first, and any inconsistency between what the description claims and what the matrix evidences hands them findings before fieldwork begins.
We write or rewrite both so they agree with each other, with your architecture, and with the evidence you can actually produce.
What is included
- ✓A Section 3 system description covering every element the AICPA description criteria require.
- ✓A defensible boundary: products, environments, entities, and subservice organizations, with carve-out or inclusive method handled explicitly.
- ✓A control matrix mapping each Trust Services criterion to its control, owner, frequency, and evidence artifact.
- ✓Complementary user entity and subservice controls stated properly, not buried.
- ✓A consistency review against your policies and your platform configuration.
Written to be tested, not to be read
A description that reads well but claims controls you cannot evidence is worse than no description. Every assertion we write is one we have traced to an artifact, so the document holds when the auditor samples against it.
Most descriptions fail in the same place: they describe the company they want to be, not the system the auditor will test.
SOC 2 system description, answered
Can you write Section 3 from scratch?
Yes. We draft it from interviews, architecture review, and your existing documentation, then align the control matrix to it.
Do you review a description we already have?
Yes. A review against the description criteria, with an inconsistency log and rewritten sections where needed.
Does this include the audit?
No. We provide readiness work only. An independent CPA firm performs the examination and issues the report.