ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A SOC 1 system description is management’s written account of the services a service organization provides to user entities, the systems and processes that support them and the controls that address the stated control objectives. It is the core of a SOC 1 report, and the service auditor tests the controls against what the description says.
SOC 1 reports address controls at a service organization that are relevant to its clients’ internal control over financial reporting. They are performed under SSAE 18 in the United States, using attestation section AT-C 320, and under ISAE 3402 internationally. The AICPA describes the purpose at the page linked below.
This guide explains what the description should contain, how to write it and where writers go wrong. It is general guidance and does not replace the professional standards or your auditor’s advice.
Free gap assessment
How much of your SOC 2 report can you already evidence?
Score yourself against the Trust Services Criteria, free, before an auditor charges you to find out.
Run the free SOC 2 gap assessment → or View premium report sample
The description is prepared by the service organization’s management. The service auditor does not write it but evaluates whether it fairly presents the system as designed and implemented, and, in a Type 2 report, tests whether controls operated effectively over a period.
Because management owns the description, it has to be accurate. If the description says a control exists and it does not, the auditor will report an exception or a qualified opinion. If it leaves out an important part of the process, the report may mislead readers.
The audience is primarily user entities and their auditors, who rely on the report to assess the effect on their financial statement audits. Write for that reader: someone who understands financial reporting and controls but does not know your systems.
Start with the services the report covers, the user entities they serve and how those services affect user entities’ financial reporting, such as payroll processing, claims administration, loan servicing or transaction processing. Give the period covered and the locations and systems included.
Be explicit about what is excluded. If a business line, location or application is outside the scope, say so, so readers do not assume coverage. The broader reporting landscape is covered in SOC 1 report, and the reporting standards are explained in SSAE 18 and ISAE 3402.
A short overview diagram of how transactions flow from the user entity to your systems and back helps readers orient themselves.
| Section | What to cover | Common pitfall |
|---|---|---|
| Services and scope | Services provided that affect user entities’ financial reporting | Including services that are out of scope |
| Systems and processes | Infrastructure, software, people, procedures, data | Generic text that does not match practice |
| Control objectives and controls | Objectives and the controls that achieve them | Controls that do not map to objectives |
| Complementary controls | User entity controls assumed to be in place | Missing or vague CUECs |
| Subservice organizations | Carve-out or inclusive approach and their controls | Unclear responsibilities |
| Changes and incidents | Relevant changes during the period | Omitting significant events |
Cover the components of the system: infrastructure, software, people, procedures and data. For each significant process, explain the steps from initiation to reporting, including how transactions are authorized, processed, recorded and reported to the user entity.
Include the IT environment where it supports the services, for example hosting, access management, change management and backup. Explain how problems and exceptions are handled, how data is transmitted and how records are retained.
Avoid marketing language and unsupported claims. The description should be factual, in the present or past tense as appropriate for the period, and consistent with documented procedures.
The description must state the control objectives, which are outcomes the controls are designed to achieve, such as transactions being processed completely and accurately or logical access being restricted to authorized users. Then it lists the controls that address each objective.
Good control objectives are tied to the risks that could affect user entities’ financial statements. Keep them specific to your services. The guidance in SOC 1 control objectives shows how to write them and how many you might need.
Make sure each control maps to an objective and each objective has enough controls. Gaps in either direction cause auditor comments. A control that cannot be tested in practice should be revised before the examination begins.
Some control objectives can only be achieved if user entities perform certain controls on their side, for example reviewing output reports or authorizing users. These are complementary user entity controls, often called CUECs. The description must list them clearly so that user entities know what they are expected to do.
Write them as actions that the user entity performs, in plain language. “User entities are responsible for reviewing transaction reports within five business days” is better than “user entities should have adequate controls”.
Do not use CUECs to shift responsibility that belongs to you. Auditors look at whether the listed CUECs are reasonable and needed, and readers will compare them with their own processes.
If you rely on other organizations that perform part of the service, such as a hosting provider or a payment processor, the description must explain how you treat them. Under the carve-out method, the subservice organization’s controls are excluded and the description identifies them and the controls you expect them to perform. Under the inclusive method, their controls are included in the description and testing.
Explain how you monitor these vendors, for example by reviewing their assurance reports and performance. More detail is in SOC 1 subservice organization.
Be consistent between the description and your contracts. If you say a vendor is responsible for a control, your agreement should reflect that.
Decide whether you need a Type 1 report, which covers the design of controls at a point in time, or a Type 2 report, which also tests operating effectiveness over a period. User entities and their auditors usually prefer Type 2. The differences are explained in SOC 1 Type 2 vs Type 1.
Management also provides a written assertion that the description fairly presents the system and that controls were suitably designed and, for Type 2, operated effectively. After the period ends, some organizations issue a bridge letter to cover the gap to the user entity’s year end; see SOC 1 bridge letter.
If you are comparing report types, see SOC 1 vs SOC 2, since the two serve different purposes.
A payroll processor documents its service: it receives employee data from clients, calculates pay and taxes, creates payment files and sends reports. The description explains the application, the infrastructure, the teams and the main steps in the process. Control objectives include accurate calculation, authorized changes to employee data and restricted access to payroll files.
For the objective on authorized changes, controls include client-approved change forms, segregation between data entry and approval and a daily exception report. The description lists CUECs, such as clients reviewing the payroll register before approving payment. The example is invented, but it shows how each part of the SOC 1 system description builds the picture for the reader.
The auditor then tests whether the controls existed and, for Type 2, operated over the period.
Auditors often comment on descriptions that are too generic, that do not match actual practice, that omit changes during the period or that list controls without clear owners. They may also question objectives that are not linked to financial reporting risk.
Avoid these by walking through each process with the people who perform it, checking screenshots and documents, and updating the description when procedures change. Have someone outside the project read the draft and ask if it makes sense.
Plan time for review. A draft SOC 1 system description circulated early, with comments from process owners, avoids last-minute rewrites. Costs and timing are discussed in SOC 1 audit cost, and readiness is covered in SOC 1 audit checklist.
Writing the description, control objectives, CUEC register and assertion from scratch is time-consuming. A prepared template set gives you structure and prompts for each required element.
The SOC 1 Toolkit provides 87 editable templates built on AT-C section 320, including the system description in every required section, control objectives with risks and illustrative controls, CUEC and subservice organization registers, assertions and the representation letter checklist. Adapt the illustrative content to your real processes.
Whatever you use, make sure every statement in the description can be supported by evidence. The AICPA overview at AICPA SOC 1 overview is a good place to confirm the purpose and scope of the report.
Management of the service organization writes it. The service auditor evaluates whether it is fairly presented but does not author it.
The services, the system components, the control objectives and controls, complementary user entity controls, subservice organization treatment and relevant changes during the period.
Complementary user entity controls are controls that user entities must perform for the service organization’s control objectives to be achieved.
Under carve-out, subservice organization controls are excluded from the description, while under the inclusive method they are included and tested.
No. SOC 1 addresses controls relevant to user entities’ financial reporting, while SOC 2 addresses security and related trust services criteria.
October 1, 2026
