Writing the SOC 1 description a client's auditor can work from.

• Services provided. What you do for clients, and the classes of transactions you process: pay runs, invoices, trades, loan payments.
• Infrastructure and software. The applications, databases and hosting that process and store the transactions, at a level that shows where the numbers live.
• People. The teams that run the service and their roles in the processes described, without an org chart for its own sake.
• Procedures. How transactions are initiated, authorized, recorded, processed, corrected and reported, automated and manual.
• Records and data. The accounting records, supporting information and files involved, including what you send clients.
• Reports for clients. How reports and files clients rely on for their own books are prepared.
• Non-transaction events. How significant events other than transactions, such as a failed batch or a system outage, are handled.
• Control objectives and controls. Each objective with the controls designed to achieve it.
• User entity controls. Controls your clients have to run so that your objectives hold.
• Subservice organizations. Vendors whose services are relevant, the method used (carve-out or inclusive) and, for a carve-out, the controls assumed of them.
• Control environment and monitoring. The relevant pieces of governance, how risks are assessed, how information is communicated and how monitoring is carried out.
• Changes during the period. For a Type 2, significant changes to the system or controls within the period.

1. Read it against the objectives. Does each process the objectives mention appear in the narrative, and the reverse?
2. Walk through transactions. The firm follows a sample from receipt to output and compares each step with the text.
3. Inspect what is referenced. Reports, screens, logs and procedures named in the description should exist and look as described.
4. Ask the people involved. Process owners describe their work; differences from the text become questions.
5. Check the period. For a Type 2, the description must hold for the whole window, so changes must be dated and disclosed.

No standard sets a page count. The useful test is a reader one: could a client's auditor, who has never seen your system, trace a transaction through it and see where each control acts? A short description that fails that test is too short. A long one padded with security policy, product marketing or company history makes the useful parts harder to find.

Write one sub-section per class of transactions and keep IT controls in their own section. Diagrams of data flows help, as long as the text says the same thing.

• The manual workaround left out. A spreadsheet used when the system cannot handle a case is part of the process. Omitting it hides a place where errors enter.
• The future state described. Writing the process as it will be after a planned upgrade, rather than as it ran in the period.
• A vendor that disappears. A payment processor or data centre relevant to the service, with no mention of it or the controls assumed of it.
• A mid-period change smoothed over. A platform migration in month five, described as if the new system ran all year.
• Controls nobody runs. Generic controls copied from a template, which the firm then cannot test because they do not exist.

Sources: AICPA SSAE No. 18, AT-C section 320; AICPA SOC 1 guide; AICPA DC section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (for the contrast only). Examples are illustrative.