SOC 1 Documentation Pack – SSAE 18 and ISAE 3402 Templates

A SOC 1 report has three parts and management writes two of them. The auditor examines the description of the system and the assertion; it does not draft either. This SOC 1 documentation set produces both, and the evidence underneath them.

On this page:

• Why first SOC 1 examinations stall, and what the documentation has to answer
• What is inside the SOC 1 documentation pack
• The description of the system is the SOC 1 documentation everything else hangs from
• Who the SOC 1 documentation pack is written for
• What the SOC 1 documentation pack does not do
• Frequently asked questions
• Related toolkits

Why first SOC 1 examinations stall, and what the documentation has to answer

The commonest way a first engagement goes wrong is that the service organisation hands the auditor a folder of policies. A folder of policies is not a description of the system, and no amount of good control operation substitutes for one. The description criteria require eight specific elements, plus the changes during the period for a type 2 report, plus the rule that nothing relevant is omitted or distorted.

The second commonest failure is a control objective a user auditor cannot conclude on. An objective has to be relevant to user entities financial-statement assertions, objective, measurable and complete. Objectives written as aspirations fail all four, and the failure is only discovered when the auditor starts testing.

This SOC 1 documentation is organised on the service organisation own obligations under AT-C section 320 (SSAE No. 18, as amended) and ISAE 3402 rather than on a control framework. The crosswalk workbook lists all 82 identifiers – 41 from AT-C 320 and 39 from ISAE 3402 – against the document that answers each.

What is inside the SOC 1 documentation pack

The SOC 1 documentation pack is 87 editable templates – 63 Word documents and 24 Excel workbooks – across 9 sections. Every Word document carries a Requirements-addressed table naming the paragraphs it answers.

• Description of the system – a master template with every required element as a headed section, plus a drafting template for each element individually.
• Transaction processing narrative – initiation through to reporting, with the information the procedures use and the significant events that are not transactions.
• Control objective library – 19 objectives, 11 business-process and 8 IT general control, each tied to the assertions it serves.
• Risk and control matrices – 76 risks with the fraud-relevant ones flagged, and 77 illustrative controls.
• CUEC and CSOC registers – the user entity and subservice organisation dependencies a report has to state rather than quietly absorb.
• Subservice organisations – the carve-out and inclusive methods, with the disclosure each one requires.
• Assertions and representations – management assertion, the representation letter and the bridge letter for the gap between period end and the reader date.
• Operating effectiveness evidence – population and sampling records, exception logs and the remediation trail a type 2 needs.
• Tailoring notes – 7 service organisation types, from payroll processors and fund administrators to claims administrators, payment processors, loan servicers, hosted financial applications and data centres.
• Crosswalk workbook – all 82 identifiers against the document that answers each.

The description of the system is the SOC 1 documentation everything else hangs from

Each of the eight description elements gets its own drafting template: services and classes of transactions; the processing narrative; the information used; significant events other than transactions; report preparation; subservice organisations and the method chosen; the control environment and the other COSO components; and the changes-during-the-period section, built from a change log kept through the year rather than reconstructed in month eleven.

A drafting standard sets the writing rules a user auditor needs – role by title, frequency stated, action on exception named – because a description written in the passive voice cannot be tested. A self-assessment then checks the finished description against every criterion before the auditor sees it, which is the cheapest review in the whole engagement.

The controls are written to the five things a user auditor looks for: frequency, responsible role, activity, information source and action on exception. A reasonableness review with worked rewrites catches the objectives that fail the four attributes, with the rewrite shown rather than described.

Who the SOC 1 documentation pack is written for

• Service organisations preparing for a first SOC 1 type 1 or type 2 examination.
• Organisations that have been through one and were told the description was the weak point.
• Payroll processors, fund administrators, claims administrators, payment processors, loan servicers, hosted financial application providers and data centres.
• User entities that have been sent a SOC 1 report and need to read the CUECs properly rather than file it.

What the SOC 1 documentation pack does not do

It is not an audit and it does not issue a report. Only an independent service auditor can do that, and this pack is the material you hand them.

It does not design your controls for you. It supplies a library written to be testable and the structure to record what you actually operate.

It is not SOC 2. SOC 1 is about controls relevant to user entities financial reporting; SOC 2 is about the trust services criteria. If you need that, the SOC 2 pack is separate and the two often run together.

Frequently asked questions

Is this for a type 1 or a type 2 report?

Both. The type 2 additions – the changes-during-the-period section, the operating effectiveness evidence and the population and sampling records – are included and marked as such.

Does it cover ISAE 3402 as well as SSAE 18?

Yes. The crosswalk carries 41 AT-C 320 identifiers and 39 ISAE 3402 identifiers, so the same SOC 1 documentation serves a US or an international engagement.

Can we use it if we already have a SOC 2 report?

Yes, and the overlap is real at the IT general control layer. The description of the system, the control objectives and the CUEC treatment are specific to SOC 1 and are what this pack adds.

What formats are the files in?

Native Microsoft Word and Excel, fully editable, with every organisation-specific value marked as a placeholder.

Related toolkits

Most service organisations run this alongside the SOC 2 toolkit and the ISO 27001 toolkit, with the COSO internal control toolkit behind the control environment section. The AICPA publishes its guidance on aicpa-cima.com.

Implementing for clients? The Consultant Package licenses all 86 toolkits and assessment tools on this site for unlimited client engagements, under one firm-wide licence. One payment of $1,399, no subscription and no per-client fee.

Delivery, format and licence

The SOC 1 documentation pack downloads immediately after checkout as native Microsoft Word and Excel files. Nothing is locked, nothing is a PDF you cannot edit, and no add-on or portal login is needed to open it. Every organisation-specific value is marked as a placeholder so you can see what still has to be decided.

One payment, no subscription and no annual renewal. The source files behind the SOC 1 documentation pack are yours to adapt for your own organisation for as long as you need them, including future revisions of your own documents.