Before a SOC 2 Type 1, walk through nine groups of criteria and answer one question per item: can I show a document or a system setting, dated on or before the report date, that proves this control exists? A Type 1 report covers design at a point in time, with no opinion on operating effectiveness.
How to use the checklist
Mark each line Ready, Partly or Missing. For Ready, name the proof and where it lives. Anything marked Partly or Missing becomes a task with an owner. Aim to have no Missing items six weeks before the report date.
CC1: control environment
- Leadership has approved a security policy set, with dates and names. (CC5.3 also expects policies to be deployed.)
- Roles and responsibilities for security are written down. (CC1.3)
- Someone outside the security owner reviews security at leadership level. (CC1.2)
- Hiring includes the checks your policy promises, and staff have signed the policies. (CC1.4, CC1.5)
CC2: communication
- Staff have completed security awareness training. (CC2.2)
- There is a channel for staff and customers to report problems, and a way to tell customers about changes. (CC2.3)
- You have a description of the system that matches reality. (CC2.1)
CC3: risk assessment
- A dated risk assessment with scoring, owners and treatments. (CC3.1, CC3.2)
- Fraud considered. (CC3.3)
- A trigger list for changes that require a new assessment. (CC3.4)
CC4: monitoring
- A plan to evaluate controls on a schedule, and a place where deficiencies are recorded. (CC4.1, CC4.2)
CC5: control activities
- Controls are mapped to risks. (CC5.1)
- Technology controls such as access and change management are defined. (CC5.2)
CC6: access
- Single sign on or a user list per system, with multi factor authentication enforced. (CC6.1)
- A request and approval trail for new access, and a removal process. (CC6.2, CC6.3)
- Encryption in transit and at rest for confidential data. (CC6.1, CC6.7)
- Physical access rules, even if you only inherit them from a cloud provider. (CC6.4)
- Endpoint protection and a malware defence. (CC6.8)
CC7: operations
- Vulnerability scanning and monitoring in place. (CC7.1)
- Logging and alerting that someone reads. (CC7.2)
- An incident response plan with severity levels and roles. (CC7.3, CC7.4, CC7.5)
CC8: change management
- Code reviews required in source control, with tests and approval before release. (CC8.1)
CC9: risk mitigation and vendors
- A vendor list, a review for each vendor handling data and the contracts in place. (CC9.2)
- Business continuity and backups described. (CC9.1)
If you add Availability, Confidentiality or Privacy, add the matching criteria to the list.
Why self audit first?
Type 1 failures are almost always design gaps that were visible. A policy that is unsigned, a vendor list that omits the main database provider, or a production system that does not enforce multi factor authentication. Each takes an hour to find and a week to fix, but you only get the week if you find it early.
Mistakes to avoid
- Counting a draft policy as Ready.
- Treating proof as a screenshot of a settings page with no date. Use exports with timestamps.
- Forgetting that a Type 1 date is a point in time. Every control must exist by that date.
- Leaving the system description until last.
What to do
- Copy the list into a spreadsheet and add columns for status, proof, owner and due date.
- Score every line honestly with someone who does not own that area.
- Turn each Partly or Missing into a ticket with a date before the report date.
- Collect proof into one folder per criteria group.
- Write the system description from the finished controls.
- Re-score at four weeks and at one week before fieldwork.
Quick check
Do we need to have operated the controls for months before a Type 1?
No. A Type 1 report describes the design of controls at a point in time. A Type 2 report covers a period and tests operation.
Is a self audit the same as a readiness assessment by an auditor?
No. A readiness assessment by an outside party gives an independent view. A self audit is your own check and cannot replace it.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so much of this checklist can be backed by evidence collected from connected systems and code instead of screenshots. Continuous monitoring keeps running between audits, which frees time for other work. The technical rows, such as vulnerability scanning and change management, draw on your real code and dependencies, including scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you pick which categories run automatically. Safeguard helps you prepare evidence. The auditor delivers the report. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): the CC criteria IDs above, paraphrased.
- AICPA description of Type 1 and Type 2 reports.
Last reviewed: 18 October 2026.
