Checklist
SOC 2 Compliance Checklist: The Nine Common Criteria and the Evidence Behind Each
A SOC 2 checklist is the list of controls and evidence an auditor tests against the AICPA Trust Services Criteria. The nine common criteria, CC1 to CC9, are always in scope. Availability, confidentiality, processing integrity and privacy are added only if you choose them. Each row below names the evidence an auditor samples.
Who is writing this
SecureRoot Risk Advisory LLP prepares Indian SaaS and IT services companies for SOC 2 audits. SecureRoot is not a CPA firm and does not issue SOC 2 reports; a licensed CPA firm does. This checklist is the readiness side of that line, criterion by criterion, with nothing gated behind a form.
The basics
What is a SOC 2 compliance checklist?
It is a working list of the controls and evidence an auditor will test, arranged by the AICPA Trust Services Criteria. SOC 2 itself is an attestation against those criteria, not a checklist. The criteria are principles. The controls that meet them are yours to choose, and the auditor judges whether they work.
A checklist tells your team what an auditor will ask for before anyone is in the room. It cannot decide whether a control is good enough; that is the auditor’s judgement. So each row below names evidence, not a tick box.
Before the controls
Three decisions: scope, criteria and report type
Every row depends on these. Settle them first, in writing.
- The system boundary. Which product, infrastructure, people and data the report covers. Everything inside it needs evidence; everything outside it is out of the auditor's sample. Defining it is the first phase of our SOC 2 compliance service.
- The criteria. Security, the common criteria, always. The other four only where a customer or contract asks for them. Which to add is answered on the SOC 2 hub; the table further down shows only what each adds in evidence.
- The report type. Type 1 tests design on one date. Type 2 tests operation across a window, usually three to twelve months. Which to start with is set out in SOC 2 Type 1 vs Type 2.
The common criteria
What is the SOC 2 common criteria list? CC1 to CC9
| Series | What the auditor asks | Typical controls | Evidence an auditor samples |
|---|---|---|---|
| CC1 Control environment | Does leadership set integrity standards, oversee security and hold people accountable? | Code of conduct, management oversight of security, defined roles, background checks | Signed conduct acknowledgements, oversight minutes, background checks for sampled hires |
| CC2 Communication and information | Does the right information reach staff and outside parties? | Approved policies, awareness training, published security commitments, a reporting channel | Policy acknowledgements, training records, customer-facing security terms |
| CC3 Risk assessment | Do you identify risks, fraud included, and reassess when things change? | A periodic risk assessment, a risk register with owners | The dated assessment, the register, treatment decisions signed off |
| CC4 Monitoring activities | Do you check that controls work, and report deficiencies to someone who can fix them? | Control reviews, vulnerability scans, penetration tests, deficiency tracking | Review, scan and test reports, deficiency tickets with closure dates |
| CC5 Control activities | Have you chosen controls that reduce your risks, and written them into policy? | A control matrix mapped to risks, policies with named owners | The control matrix, approved policies with version history |
| CC6 Logical and physical access | Who can reach systems and data, and are access, devices and data movement controlled? | Single sign-on and MFA, role-based access, joiner and leaver process, encryption, endpoint protection | Access review sign-offs, access tickets, MFA and encryption settings, your cloud provider's SOC 2 |
| CC7 System operations | Do you detect anomalies, evaluate security events, respond to incidents and recover? | Central logging and alerting, vulnerability management, an incident response plan | Alert samples, incident tickets with timelines, the plan's last test |
| CC8 Change management | Are changes authorised, tested, approved and recorded before release? | Pull-request review, automated tests, restricted deploy rights, patching | Sampled changes with approval and test results, deployment logs |
| CC9 Risk mitigation | Do you mitigate disruption, and manage risk from vendors and partners? | Continuity and recovery plans, a vendor inventory, vendor due diligence | The continuity plan and its test, vendor list with risk ratings, vendor reviews |
Series labels are the AICPA's. The rest is our paraphrase and common practice, not criteria text. Your auditor decides what evidence is sufficient.
Reading the common criteria
CC1 to CC5 follow the five components of the COSO 2013 internal control framework, principle by principle. CC6 to CC9 are the AICPA’s additions for access, operations, change and vendors, where most engineering work lands.
No criterion requires a penetration test; the 2022 points of focus under CC4.1 list it as one example of a control evaluation. Auditors still expect a recent one as evidence for monitoring and vulnerability management. That shapes how SOC 2 penetration testing should be scoped and timed. If you also hold or plan ISO 27001, most of these controls overlap, and ISO 27001 vs SOC 2 shows where. SecureRoot is not an accredited ISO certification body; certificates come from one.
The optional four
Availability, confidentiality, processing integrity and privacy: what each adds
| Category | Series | Usually added when | Extra evidence |
|---|---|---|---|
| Availability | A1.1 to A1.3 | You sell on an uptime commitment | Capacity monitoring, backups, a recovery plan with dated test results |
| Confidentiality | C1.1 and C1.2 | Contracts restrict how you hold customer information | Classification, a retention schedule, disposal records |
| Processing integrity | PI1.1 to PI1.5 | Correct processing is the product, as in payments or payroll | Input validation, error logs, reconciliations, output review |
| Privacy | P1 to P8 | You make commitments to the individuals whose data you collect | Privacy notice, consent records, access requests, breach notification records |
P1 to P8 cover notice, consent, collection, use and retention, access, disclosure, quality, and monitoring.
Choosing the optional categories
Each category adds its own series on top of CC1 to CC9, never instead of them. Whether you need any of them is answered on the SOC 2 compliance services page. Privacy overlaps with work you may already be doing for the DPDP Act, which our DPDP Act compliance service covers.
The report
What documents are required for a SOC 2 audit?
| Document | Who prepares it | What it contains |
|---|---|---|
| Management's assertion | Your management, signed | That the description is fair and the controls were suitably designed, and for Type 2 operated effectively |
| System description | Your management, against DC 200 | Services, boundaries, infrastructure, people, data, commitments and subservice organisations |
| Controls and tests | You list controls; the auditor records tests | Each control mapped to criteria, and in a Type 2 the results and exceptions |
| The auditor's opinion | A licensed CPA firm | The opinion on the description and the controls |
| Policy set | You | Security, access, change, incident, vendor, continuity and retention policies |
| Population lists | You, from your systems | Every joiner, leaver, change, incident and vendor in the period, for sampling |
The first four make up the report. The last two never appear in it, yet the audit cannot start without them.
Preparing the documents
The system description takes longest, because it must match what the auditor finds. It follows the AICPA’s 2018 Description Criteria (DC 200). It also names the controls your customers must run, and the subservice organisations you rely on, such as your cloud provider.
Population lists are the quiet dependency. No sampling starts until your ticketing and HR systems can export a complete list for the period.
Type 2 evidence
The Type 2 checklist: evidence that has to exist inside the window
| Recurring control | Common cadence | What proves it ran |
|---|---|---|
| User access review | Quarterly | The signed review and the tickets that removed access |
| Joiners and leavers | Every event | Approval before access; removal within your policy's deadline |
| Change approval | Every change | Peer review and test results recorded before release |
| Vulnerability scanning | Monthly, or as policy sets | Scan reports and fix tickets closed within your deadlines |
| Penetration test | Annually and after major change | The report, and the retest showing findings closed |
| Backup restore test | At least annually | A dated restore record |
| Security awareness training | At joining and annually | Completion records for everyone in scope |
| Vendor review | Annually for critical vendors | Their SOC 2 report or questionnaire, with your note |
| Incident response test | Annually | The tabletop record and the actions it produced |
Every record must be dated when it happened. A review signed in month six cannot evidence month two.
Running the observation window
A Type 2 observation period is usually three to twelve months; the SOC 2 hub explains how long yours should be. A Type 1 never tests this table. Each row needs a dated record for every cycle inside the window, and a missed quarter stays an exception in the report.
Cadences here are common practice, not AICPA rules. The auditor tests you against your own policies, so promise only a cadence you will keep.
India
The India layer: CERT-In and DPDP rules that sit alongside SOC 2
No Indian law requires SOC 2; the SOC 2 hub explains when the commercial case does. Indian law does set duties on the same controls, so build them in once.
The CERT-In Directions of 28 April 2022 already reach every body corporate. The DPDP Rules 2025 add security and breach duties from 13 May 2027. Logging detail for cloud estates is in our AWS cloud security audit checklist.
SecureRoot is not CERT-In empanelled. The mapping below is our reading as practitioners, not a CERT-In or AICPA publication. Where a regulator or tender needs an empanelled auditor, that auditor signs.
India
Indian rules that touch the same controls
| Indian rule | Sits beside | Add to the checklist |
|---|---|---|
| CERT-In Directions, 28 April 2022, (ii): report listed incidents within 6 hours | CC7.3, CC7.4 | A six-hour CERT-In step, with an owner, in the incident plan |
| CERT-In (iv): keep ICT system logs for 180 days, within India | CC7.2 | Retention settings and a storage location you can show |
| CERT-In (i) and (iii): sync clocks to NIC or NPL time; name a Point of Contact | CC7.2, CC2.3 | Time source configuration; the named contact on record |
| DPDP Rules 2025, rule 6: security safeguards, logs kept one year, processor contracts | CC6, CC7, CC9.2; P4 and P6.4 if privacy is in scope | A one-year log rule and a security clause check in vendor reviews |
| DPDP Rules 2025, rule 7: breach intimation to individuals and the Board | CC7.4; P6.6 if privacy is in scope | Breach steps, including the Board's detailed report within 72 hours |
The mapping is ours, as practitioners. It is not a CERT-In or AICPA publication. Rules 6 and 7 apply from 13 May 2027.
Mistakes
What are the most common mistakes in SOC 2 preparation?
The exceptions below come from habits, not missing technology.
- Evidence produced after the fact. Auditors check dates and timestamps. A review written up in month six to cover month two becomes an exception.
- Controls with no named owner. A control owned by "engineering" is owned by nobody. Each row of the matrix needs one person.
- A system description that does not match reality. A tool, region or team it omits, or one it lists that you retired, is a finding.
- Forgetting inherited controls. Collect your cloud provider's SOC 2 report, and run the customer-side controls it says you must.
- Treating the dashboard as the audit. A green dashboard shows automated tests pass. It does not show a control is well designed.
Can SOC 2 compliance be automated?
Evidence collection can, and for a Type 2 it should be. Compliance automation platforms pull configuration, access and training records continuously. Control design cannot be automated, nor can the system description or the auditor’s judgement. A platform tells you a test passed. It does not tell you the control was the right one.
How SecureRoot helps
From this checklist to a report your customer accepts
Our SOC 2 compliance service runs in six phases. We scope the system and select criteria. A gap assessment measures you against this list. We design and remediate controls, automate evidence collection, support you through the observation window and represent you through the auditor’s fieldwork.
You receive a readiness assessment report, a control matrix mapped to the criteria and a remediation plan. You also get an evidence collection setup and audit support through fieldwork. SecureRoot is not a CPA firm and does not issue SOC 2 reports; a licensed CPA firm does, independent of our readiness work. We introduce our partner CPA firms during scoping, and you choose between them.
A redacted sample of our readiness report and the engagement lead are available on request on the scoping call. We do not publish them. What the engagement costs is in our SOC 2 cost guide. How the audit runs end to end is in SOC 2 services in India. How to compare firms is in choosing a SOC 2 consultant.
Questions
Frequently asked questions
How long is a SOC 2 report valid?
The standard sets no expiry date, so validity is decided by the customers who read it. In practice, customers usually treat a report as current for about twelve months after the period it covers ends. That is why companies move to an annual Type 2, with windows that run back to back. When a customer asks between reports, management can give a bridge letter stating that nothing material has changed since the period ended. That letter is yours, not the auditor's, and it carries no opinion. Plan the next window before the current report ages out, because its evidence has to start accumulating on the first day. Only a licensed CPA firm can issue the report that resets the clock. SecureRoot is not a CPA firm and does not issue SOC 2 reports; a licensed CPA firm does, independently of our readiness work.
How long does SOC 2 compliance take?
Our SOC 2 service page publishes two figures. A Type 1 report takes about eight to twelve weeks, and a first Type 2 six to nine months. The second figure assumes a three-month observation window. That window cannot be compressed, because the auditor needs evidence dated across all of it. What decides where you land is your starting point. A company that already runs single sign-on, code review and a written incident process is mostly documenting what exists. A company without them is building controls first, and remediation is the phase with the widest spread. This checklist helps you estimate that before anyone quotes. Count the rows in the common criteria table where you cannot yet produce the evidence: those rows are your remediation list. Firm dates follow a gap assessment, once the real size of that list is known.
Does a checklist replace a readiness assessment?
No. A checklist tells you what an auditor tests. A readiness assessment tells you which of those things you would fail today, and why. The difference is judgement. A checklist row says access reviews must happen. An assessor asks for last quarter's review. They check that it covered every system in scope, that each leaver was removed and that someone signed it. Then each gap is ranked by its audit impact and the effort to close it. Use this page to brief your team and to run a first pass yourself. Bring in an assessor when the first pass shows gaps you cannot size, or when a customer has set a date. How a readiness assessment runs, and what it produces, is covered in our guide to SOC 2 services in India. The output you want from it is a ranked list of gaps, not a score.
Is a Type 1 checklist different from a Type 2 checklist?
The controls are the same; the evidence is not. For a Type 1, the auditor checks that each control is designed to meet its criterion and existed on one date. A policy, a configuration record and a walkthrough usually suffice. For a Type 2, the auditor samples the control's operation across the whole observation window, usually three to twelve months. A quarterly access review then needs every quarter's review inside the window, signed and dated when it happened. A change control needs approvals on whichever changes the auditor picks from the full list. That is why the recurring evidence table on this page exists. A company that passes a Type 1 has proved its design. It has not yet proved operation, and operation is what a customer's security team weighs most heavily when it reads the report.
Did the 2022 revision change the SOC 2 criteria?
No. In 2022 the AICPA revised the points of focus under each criterion, and the implementation guidance for the Description Criteria. The 2017 criteria themselves were not changed, and the AICPA says the new points of focus do not alter them. The revisions still matter for a checklist. They ask you to consider data flows, asset inventory and information classification; threats, vulnerabilities and residual risk in the risk assessment; access across every account type, including vendor and service accounts; patching and resilience in change management; and threats to data recovery under availability. Points of focus are not a list every company must satisfy, and your auditor judges which apply. The AICPA has also published proposed criteria for 2027. Until those are final, the 2017 criteria with the 2022 points of focus are what a report is written against.
Primary Sources
Where the Figures on This Page Come From
Criteria numbering, the 2022 revision and the CERT-In and DPDP deadlines come from the documents below; EY and Barr Advisory are secondary sources for the 2022 change. Timelines are SecureRoot's published figures, and evidence cadences are common practice.
- 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022)
AICPA and CIMA · Link checked 2026-11-10
- System and Organization Controls: the SOC suite of services, and the proposed 2027 criteria
AICPA and CIMA · Link checked 2026-11-10
- To the Point: AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria (2 November 2022)
EY · Link checked 2026-11-10
- What's new with SOC 2? An overview of the revised security points of focus
Barr Advisory · Link checked 2026-11-10
- Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 (No. 20(3)/2022-CERT-In, 28 April 2022)
CERT-In · Link checked 2026-11-10
- The Digital Personal Data Protection Act, 2023
Gazette of India · Link checked 2026-11-10
- Digital Personal Data Protection Rules, 2025 (rules 6 and 7)
Gazette of India · Link checked 2026-11-10
Bring this checklist to the scoping call, and we will mark it up for your system
Tell us who is asking for the report and by when. You get a written scope and a straight answer on the rows you would fail today.