SOC 2 Type II readiness checklist (Trust Services Criteria)

Structure (8 sections)

1. 1. Scoping and selecting Trust Services Criteria categories

   Two decisions drive every downstream cost. First, who the report covers: the whole entity, a subsidiary or division, or a specific system or service. Chinese vendors commonly cover only the service line sold overseas, but scoping too narrowly invites the objection that the report does not cover what the customer bought — it must match the service boundary your sales side asserts. Second, which criteria categories: Security is the common criteria and appears in essentially every report, while Availability, Processing Integrity, Confidentiality and Privacy are added according to contractual commitments and the nature of the business. Choose categories by walking the security exhibits of signed customer contracts — if you have committed to an uptime figure, consider Availability; if to confidentiality and destruction, consider Confidentiality. Also settle the system boundary and how subservice organisations such as public cloud are treated (inclusive or carve-out method), because that choice directly shapes how customers read residual risk.

   Evidence to attach

   • · Scope statement (entity/system boundary, products and deployment models covered, geography)
   • · Basis for criteria category selection, mapped to customer contractual commitments
   • · Subservice organisation list and the inclusive/carve-out decision note
   • · Management approval of the scoping decision

   Common pitfalls

   • · Scoping to the development environment rather than production operations, so the report persuades nobody
   • · Committing to uptime contractually but omitting the Availability category, prompting the customer to demand a redo
   • · Using the carve-out method without explaining reliance on the cloud provider’s controls and your complementary monitoring, leaving residual risk unclear

2. 2. Writing the system description

   The system description is the part of the report customers actually read. It describes the nature of the service, the system components (infrastructure, software, people, procedures, data), the service commitments and system requirements, and the subservice organisations relied upon together with the complementary user entity controls. Write the full path of data through the system in language customers can follow; list explicitly the controls assumed to sit with the customer (complementary user entity controls, such as managing their own administrator accounts and configuration); and describe faithfully any significant changes during the period (architecture migration, acquisitions, major incidents). A Chinese vendor should be specific about people and geography: which teams sit in the PRC, what data they can reach, and the access controls that apply — omitting this leaves customers to guess, and the guess is usually worse.

   Evidence to attach

   • · Draft system description with internal review comments
   • · System component inventory, architecture diagram and data flow diagram
   • · Service commitments and system requirements list mapped to contracts and SLAs
   • · List of complementary user entity controls
   • · Record of significant changes during the period

   Common pitfalls

   • · Letting the firm draft the system description with no internal review, so it does not match operations
   • · Omitting complementary user entity controls, leaving customers to assume the vendor carries every responsibility
   • · Deliberately hiding the access capability of PRC-based teams, which a later customer audit uncovers

3. 3. Control matrix: mapping criteria to controls to evidence

   Build a three-column mapping: criterion → your control description → evidence type and generation frequency. For each control record the objective, the performer, the frequency (per change, daily, quarterly), whether it is automated or manual, and the system from which evidence comes. Rule of thumb: design controls so that evidence is produced automatically wherever possible (ticketing systems, CI/CD pipelines, cloud audit logs), because a Type II examines every execution across the coverage period and manual controls are the ones that show gaps under sampling. Cross-map the matrix to ISO/IEC 27001 Annex A and to the Cloud Controls Matrix so one control set serves several demands — the cheapest way to address North American and European/Asian customers at the same time.

   Evidence to attach

   • · Control matrix (criterion, control description, performer, frequency, automated/manual, evidence source)
   • · Cross-map to ISO/IEC 27001 Annex A and the CCM
   • · Control design review record and gap analysis conclusions
   • · Configuration note for automated evidence collection

   Common pitfalls

   • · Control descriptions copied from a template that do not match actual process, failing testing en masse
   • · Too many controls at too fine a grain to be sustained across the coverage period
   • · A key control performed manually by one person, leaving an evidence gap whenever they are on leave

4. 4. Readiness assessment and remediation (complete before the coverage period starts)

   Run a readiness assessment before the formal coverage period begins (by the firm’s advisory team or an independent third party — note the independence constraints on the firm that will issue the report), testing control design and operation item by item and producing a gap list and remediation plan. Remediation must land before the period starts: a control implemented mid-period shows in the report as covering only part of the period, which usually prompts the customer to wait for the next cycle. This is also when the coverage period length is fixed; a common first-year approach is a shorter Type II to obtain a deliverable report sooner and then extend to a full year, but the actual length should be confirmed with the firm and against the requirements of your main customer contracts rather than assumed from market lore.

   Evidence to attach

   • · Readiness assessment report and gap list
   • · Remediation plan (item, owner, deadline) and completion evidence
   • · Decision record for the coverage period start and end dates, checked against customer contract requirements
   • · Independence confirmation covering the relationship between the readiness assessor and the reporting firm

   Common pitfalls

   • · Running remediation in parallel with the coverage period, so the report is full of "control implemented mid-period" language
   • · Setting the coverage period by hearsay rather than to the requirement in the main customer contracts (such as covering the trailing twelve months)
   • · Skipping the readiness assessment to save cost and discovering systemic gaps only at period end

5. 5. Running evidence generation across the coverage period

   A Type II examines operating effectiveness across a period, so this section is really about letting evidence accumulate naturally. Establish three things: (1) an evidence calendar — the execution month, owner and reminder for every periodic control (access review, backup restore exercise, supplier assessment, security awareness training, risk assessment); (2) an evidence storage standard — one directory structure, naming convention, retention location and access control, with nothing left in personal chats or mailboxes; and (3) a monthly self-check confirming that last month’s expected evidence exists, remediating gaps immediately rather than at audit. A common trap for PRC teams is evidence produced in Chinese against an English report: set bilingual requirements for key fields, or a standard translation workflow, in the evidence standard so that a mass translation effort is not needed during fieldwork.

   Evidence to attach

   • · Evidence calendar (control, frequency, owner, execution month, status)
   • · Evidence storage standard and directory structure
   • · Monthly self-check records and the gap remediation log
   • · Bilingual or translation workflow note for evidence

   Common pitfalls

   • · Missing a quarterly control in one quarter, which invalidates that control for the entire period
   • · Evidence screenshots without timestamps or operator identity, which cannot prove when the control ran
   • · A departing employee taking the only copy of the evidence store with them

6. 6. Selecting the firm and agreeing the engagement

   A SOC 2 report must be issued by a licensed CPA firm. Confirm at least four things when selecting: the firm’s licence and peer review status; whether its reports are in fact accepted by your target customers (ask key customers before signing); whether the team has experience with a similar technology stack and cross-border operations; and, in the engagement letter, the timetable, sampling approach, exception handling and issuance deadline. Be wary of bundled "compliance tool plus partner auditor" offers promising certification at very low cost and very short timelines — the AICPA has publicly flagged risks around such arrangements, and a report your customers reject costs far more than the audit fee saved. The engagement should also state who is responsible for drafting the system description and how subsequent annual cycles will be handled.

   Evidence to attach

   • · Check record on the firm’s licence and peer review status
   • · Confirmation from key customers that they accept the proposed firm’s reports
   • · Engagement letter (timetable, sampling, exception handling, issuance deadline, renewal arrangements)
   • · Budget for fees and internal preparation cost, with the source of any industry estimate cited

   Common pitfalls

   • · Choosing the cheapest firm and having the issued report rejected by a major customer on the firm’s credentials
   • · An engagement letter with no issuance deadline, so a months-long delay after period end breaches a customer contract
   • · Budgeting the audit fee only and ignoring internal preparation effort, leaving the project under-resourced mid-way

7. 7. Exceptions and management responses

   Almost no first-year report is exception-free; what matters is how the exceptions read. For each, prepare: the facts (what happened, how many samples), root cause analysis, impact assessment (does it affect service commitments or customer data), the remediation already taken and when it completed, and the mechanism preventing recurrence. Management responses should be specific, dated and free of excuses — a customer’s third-party risk team reads exceptions to learn how the company handles problems, and a candid response with a closed loop often builds more trust than no exceptions at all. Prepare a customer-facing exception summary as well so that sales explain the report consistently rather than each giving a different account.

   Evidence to attach

   • · Exception register (facts, sample count, root cause, impact, remediation, completion date)
   • · Management response text and approval record
   • · Design and validation record for the recurrence prevention mechanism
   • · Customer-facing exception summary for consistent messaging

   Common pitfalls

   • · A management response that says "the impact was minor" with no root cause or timetable, which customers read as weak governance
   • · Sales downplaying an exception in a customer meeting inconsistently with the report text
   • · The same exception recurring in consecutive years with the response text unchanged

8. 8. Report delivery, bridge letters and the annual cycle

   A report covers a defined period and is issued after that period ends, so customers ask for a bridge letter covering the gap — a management statement that no significant control changes occurred since period end. Confirm before signing customer contracts that you can produce bridge letters on schedule, and pre-build the issuance workflow, signatory and template. On the delivery side, establish a distribution register (who received which version and when, usually under NDA), a consistent line for answering customer questions about the report, and the schedule for next year’s coverage period so that it joins up with this one and leaves no gap. Put the renewal schedule in the compliance calendar and reserve the fee in the annual budget.

   Evidence to attach

   • · Report distribution register (recipient, version, date, NDA status)
   • · Bridge letter template, signatory authority and past bridge letters
   • · Next-year coverage period schedule and budget
   • · Agreed response lines for customer questions about the report

   Common pitfalls

   • · Contracting to provide an annual report covering the trailing twelve months while the actual schedule leaves a coverage gap
   • · Bridge letters drafted and signed by sales without management authority
   • · The report forwarded by a customer to a third party outside any confidentiality obligation, leaking sensitive architecture detail