Your SOC 2 system description explains the service covered by the report and how it operates. Start with the service a customer actually uses. Then explain the people and systems behind it. A product brochure or a list of security tools will not do that job.
Management owns this description. The auditor evaluates it against the applicable description criteria. The workflow below is a practical starting point, not a substitute for those criteria.
Start with a clear boundary
Before writing pages of detail, agree on a short answer to each question:
- Which service is being examined? Use its actual name.
- Which customers or users does it serve?
- What does the service do with their information?
- Which locations and supporting teams help deliver it?
- What date or period will the report cover?
- Which related products are outside this report?
Treat exclusions as something to explain and check. A separate product may be outside the report while shared support staff or infrastructure still matter to the service being examined.
Build the explanation from real work
A useful drafting method is to follow one ordinary customer interaction. For a document-sharing service, follow an uploaded file from receipt through storage and retrieval. Ask the people responsible to fill in the gaps.
- Product staff explain what the customer can do.
- Engineering explains where the data goes and which systems process it.
- Operations explains hosting and recovery.
- Support explains how staff can access customer information.
- The security owner explains the controls that protect the service.
Use those conversations to assemble one consistent account. Keep a working list of unresolved questions rather than guessing. A simple system diagram can help the team spot a missing connection.
Connect promises to the way the service runs
Collect the relevant customer commitments before describing the controls. Look at the service agreement and the security statements customers receive. Ask which promises the system must support.
For example, a promise to limit staff access needs more than the sentence “we protect customer data.” Explain the actual approval process and how access is removed. Keep implementation details consistent with the records the team can produce.
Our guide to writing control descriptions that match the process covers that smaller task. The system description brings those controls into the wider service story.
Make the handoffs visible
Write down what your company does and what it relies on others to do. Identify relevant service providers and the customer responsibilities assumed by the service. Agree with the auditor how those providers are treated in the report.
Here is a fictional drafting example, not a complete system description:
- The service lets customers upload and retrieve project documents.
- A cloud provider hosts the application and storage.
- Our operations team manages application access and deployment.
- Customer administrators decide which of their users may access each project.
That short example exposes a useful question: who removes a former employee’s access? Resolve the answer before turning the draft into polished prose.
Keep three documents separate
- System description: Explains the system covered by the examination.
- Management’s assertion: States management’s conclusions about the description and controls. Its content depends on the engagement type.
- Representation letter: Gives written confirmations to the auditor. It does not replace the description or other necessary audit evidence.
These distinctions are explained in the AICPA SOC 2 guide, including management responsibilities and written representations.
Review for accuracy before polishing
Ask each owner to review their part. Then read the whole draft as a customer who does not know your company.
- Can they tell what is covered?
- Do supplier and customer responsibilities make sense?
- Do the dates and descriptions reflect what actually operated?
- Have significant changes and other required disclosures been considered with the auditor?
- Does any sentence claim more than the team can support?
Use the AICPA description criteria for the formal preparation and evaluation requirements. When the full report is ready, use our separate draft report review guide.