SOC 2 Readiness Checklist: Preparing for a SOC 2 Type I or Type II Audit

Most SOC 2 problems are found in the first weeks of fieldwork, when it is too late to fix the design and the audit period has already started. A readiness review run against the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022) and the 2018 SOC 2 Description Criteria finds those gaps while they are still cheap. This checklist is a working template for [Organisation] to prepare for a SOC 2 Type 1 or Type 2 examination: eight numbered sections of checks, each usable as-is, followed by guidance on sequencing, timelines and evidence. It is written for security, GRC and engineering leads running a first SOC 2, and for executives who need to know what "ready" means before engaging a CPA firm.

How to use this template

• Replace text in square brackets, such as [Organisation], [System name] and [Control owner], with your own terms.
• Work through the sections in order: scope decisions in section 1 change everything that follows.
• Mark each check as Met, Partly met or Not met, record the evidence location, and assign an owner and due date for every gap.
• Criteria references (CC1 to CC9, A1, C1, PI1, P) point to the AICPA Trust Services Criteria. Confirm detailed wording and points of focus against your licensed copy of the criteria and with your service auditor.
• Re-run the checklist before the Type 1 date and again before the Type 2 period starts.

1. Scope and report type

• [Organisation] has named the system in scope, [System name], as customers buy and experience it, including the applications, infrastructure, data stores, people and locations that support it.
• The trust services categories in scope are agreed. Security (the common criteria) is always included; Availability, Confidentiality, Processing Integrity and Privacy are added only where customer commitments require them.
• The principal service commitments made to customers (contracts, SLAs, security pages) and the system requirements needed to meet them are listed.
• The report type is decided: Type 1 (design and implementation at a date) or Type 2 (operating effectiveness over a period, commonly 6 to 12 months). See the SOC 2 Guide.
• The need for a SOC 1 has been ruled in or out: if customers' financial statement auditors rely on [System name], a SOC 1 may also be required. See the SOC 1 Guide.
• Subservice organisations (cloud hosting, payment processor, email provider) are listed, with a decision on carve-out or inclusive treatment, and their own SOC 2 reports obtained.
• A target report date and audit period start date are set in the [Organisation] Compliance Calendar Template.

2. Governance and control environment (CC1 to CC5)

• An information security policy set is approved by [Executive sponsor] within the last 12 months and acknowledged by all staff and contractors.
• Roles and responsibilities for security, including a named control owner for every control, are documented (CC1).
• Board or management oversight of security is evidenced, for example minutes of a quarterly security review (CC1).
• Background checks, onboarding security training and annual refresher training are performed and recorded (CC1, CC2).
• Security commitments are communicated to customers and internal users, including how to report incidents and concerns (CC2).
• A risk assessment covering fraud risk, changes to the business and third parties is performed at least annually and produces a risk register with treatments (CC3).
• Controls are monitored through internal reviews or continuous monitoring, and deficiencies are tracked to closure (CC4).
• Policies are translated into operating procedures and technology controls, each mapped to the criteria (CC5).

3. System description

• A draft system description exists, structured against the AICPA 2018 SOC 2 Description Criteria, covering services, commitments and system requirements, components (infrastructure, software, people, procedures, data), boundaries and relevant changes.
• Architecture and data flow diagrams match what is actually deployed, including third-party integrations and data stores.
• Complementary user entity controls (CUECs) that customers must perform are listed, for example managing their own users' access and protecting the API keys [Organisation] issues to them.
• Complementary subservice organisation controls (CSOCs) expected of carved-out providers are listed.
• System incidents that were significant during the period, if any, are identified for disclosure.

4. Logical access and non-human identities (CC6)

• Logical access security software, infrastructure and architectures protect in-scope assets (CC6.1): SSO with MFA for all workforce access to production, cloud consoles and source control.
• A joiner, mover and leaver process provisions access on approved request and removes it within [24 hours] of termination, with tickets as evidence.
• Privileged access to production is restricted to named roles, granted just in time where possible, and logged.
• User access reviews of production, cloud accounts, databases and critical SaaS run at least [quarterly], with removals completed and evidenced. See the Access Review Checklist.
• Every non-human identity with access to in-scope systems (service accounts, cloud IAM roles, CI/CD pipeline identities, API keys, OAuth apps, SSH keys, certificates) is in an inventory with owner, purpose, permissions and last rotation date. See the Service Account Inventory Template.
• Non-human identities are included in the same access review population as human users.
• Secrets are held in a secrets manager, not in code, configuration files or CI variables in plain text, and repositories are scanned for leaked secrets. See the Secrets Management Guide.
• Keys and credentials are rotated on a defined schedule and immediately after suspected exposure or the departure of someone who knew them. See the Secrets Rotation Runbook Template.
• Data is encrypted in transit (TLS 1.2 or later) and at rest, and encryption key access is restricted.
• Endpoint protection, disk encryption and screen lock are enforced on staff devices that access the system.
• Physical access to facilities is covered either directly or through the subservice organisation's report.

5. System operations, monitoring and incident response (CC7)

• Vulnerability scanning of infrastructure and applications runs at a defined frequency, with remediation SLAs by severity and evidence of closure.
• An annual penetration test of [System name] is performed, and findings are tracked to remediation.
• Security logs from cloud control planes, identity provider, production hosts and applications are centralised, retained for [12 months], and alert on defined events, including use of dormant or privileged service accounts and anomalous API key activity. See the Cloud Logging and Audit Trail Guide.
• An incident response plan defines severity levels, roles, customer notification and post-incident review, and has been tested by a tabletop exercise in the last 12 months.
• Incidents are recorded in a ticketing system with timeline, root cause and corrective actions.

6. Change management (CC8)

• All changes to production code and infrastructure go through version control with peer review before merge, enforced by branch protection.
• Automated tests run before deployment, and deployment is performed by a pipeline rather than by individuals with standing production access.
• Pipeline identities have only the permissions needed to deploy, use short-lived credentials where the platform supports them, and cannot be used to bypass review.
• Emergency changes follow a documented process with retrospective approval.
• Infrastructure configuration is defined as code or baseline-hardened, and configuration drift is detected.

7. Risk mitigation, vendors and continuity (CC9 and A1)

• Vendors with access to customer data or production are assessed before onboarding and reviewed annually, including their SOC reports. See the Vendor Security Assessment Template.
• Third-party integrations and the OAuth grants or API keys they hold are inventoried and reviewed. See the Third-Party Access Guide.
• Business continuity and disaster recovery plans define recovery time and recovery point objectives, and backups are restored in a test at least annually (A1, if Availability is in scope).
• Capacity is monitored against defined thresholds (A1).
• Cyber insurance and contractual risk transfer are reviewed where relevant to the risk assessment.

8. Evidence, auditor and audit period

• Every control has a defined evidence artefact (ticket, log export, screenshot, report) and a frequency, stored in one repository.
• Population lists the auditor will sample from (new hires, leavers, changes, incidents, service accounts) can be produced completely and with timestamps.
• Evidence collection is automated where possible. See the Compliance Automation Guide.
• A licensed CPA firm is engaged, independence is confirmed, and the scope, categories, period and report date are agreed in the engagement letter.
• A mock audit or internal test of a sample of controls has passed before the period start.
• Management is prepared to respond in writing to any exceptions.

Implementation guidance

Sequencing. A typical first SOC 2 follows this order:

1. Weeks 1 to 2: complete section 1 and confirm scope with leadership and a prospective auditor.
2. Weeks 2 to 6: gap assessment against sections 2 to 8, prioritising CC6 and CC8, which hold most testable controls.
3. Weeks 6 to 14: remediate, write policies, deploy tooling, and build the non-human identity inventory.
4. Week 14 onward: Type 1 as of a date, or start the Type 2 observation period. Run internal spot checks monthly.
5. Period end: fieldwork, exception responses, report issue; then plan the next continuous period with no gap.

If a control fails during the period, do not change it silently: record the failure, fix it, and tell the auditor, because the description must reflect what operated.

Mapping to other frameworks. Much of the evidence is reusable:

Small versus large organisations. A start-up can often be ready in one quarter with a Security-only scope, SSO, a secrets manager and a ticketed change process. Larger organisations usually spend more time on scope boundaries, legacy service accounts and evidence completeness across many teams; an existing ISO 27001 or HITRUST control set can be mapped to share evidence. See the ISO 27001 Certification Guide and the HITRUST CSF Guide.

Metrics to track readiness: percentage of checks Met; open gaps by owner and age; percentage of non-human identities with an owner and rotation date; leaver access removed within SLA; changes with documented peer review; and internal test pass rate before the period starts.

References: AICPA & CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022) · AICPA & CIMA: 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022) · AICPA & CIMA: SOC 2 · Microsoft Learn: SOC 2 Type 2 · NIST: SP 800-53 Rev. 5

This template is provided for guidance and must be adapted to your organisation; it does not replace the judgement of your service auditor. Related NHI Mgmt Group resources: SOC 2 Guide · SOC 1 Guide · Compliance Calendar Template · Third-Party Risk Management Guide · Service Account Security Guide