How to get SOC 2 Type 1 yourself: the complete step by step plan

To get a SOC 2 Type 1 yourself, define your system and criteria, close control gaps, write policies that match reality, collect evidence of design, then engage an independent CPA firm to examine it. A Type 1 report describes the design of controls at a point in time and gives no opinion on operating effectiveness.

What are you actually buying?

A SOC 2 report is not a certificate. It is an attestation report written by an independent CPA firm about your system and controls. In the AICPA criteria, Type 1 covers design at a single date. Type 2 covers a period and includes tests of operating effectiveness. Many teams use Type 1 to unblock a deal, then run a Type 2 behind it.

Step 1: set the scope

Decide which product or service is in scope and which systems support it: cloud accounts, code host, CI, identity provider, ticketing, HR tools. Then pick the Trust Services Categories. Security is the base. Availability, Confidentiality, Processing Integrity and Privacy are optional. Add only what customers ask for, because every extra category adds controls to prove.

Step 2: assign owners

Name an executive sponsor, a program owner, and one owner per control area: engineering, IT, HR, legal. Without named owners the work stalls at the first hard question.

Step 3: run a gap check against the criteria

Walk the Common Criteria, CC1 through CC9, and note for each criterion what you do today. The AICPA text is free to read and includes points of focus that show what auditors look for. Mark each gap as policy, process or technical.

Step 4: fix the technical gaps that matter most

Typical first fixes: SSO and MFA, least privilege roles, encrypted storage and transit, logging and alerting, branch protection and reviewed changes (CC8), vulnerability scanning with a fix process, backups and a restore test. Pick the fixes you can finish and prove, not the longest wish list.

Step 5: write policies people will follow

Cover information security, access control, change management, incident response, risk management, vendor management, business continuity and acceptable use. Keep each short. A policy you do not follow becomes an exception in your report, so write what you really do, or do what you wrote.

Step 6: run the risk assessment and vendor review

CC3 expects you to identify and assess risks and changes. Keep a risk register with owners and treatments. Keep a vendor list with what data each holds and a record of review, such as collecting their reports.

Step 7: collect design evidence

For each control, keep a screenshot or export that shows how it is set, a policy that describes it, and, where easy, one real example such as a reviewed pull request or an offboarding ticket. Date everything.

Step 8: choose the CPA firm and agree the description

Ask for the firm's process, what it needs from you, and how it handles the system description and management assertion. You write the description of your system. The firm examines it and your controls. Do this before your evidence work is finished, so you collect what they actually want.

Step 9: examination and report

Expect questions, requests for samples, and a draft report. Read exceptions carefully and respond with facts. Do not argue scope after the fact.

Mistakes to avoid

• Scoping too wide, then proving controls on systems nobody uses.
• Buying tooling before deciding owners and scope.
• Copying a template policy full of controls you do not run.
• Treating Type 1 as the end. Customers will often ask about Type 2 next.

What to do

1. Pick the product scope and the categories.
2. Name the sponsor and control owners.
3. Gap check against CC1 to CC9.
4. Close the technical gaps in priority order.
5. Write and approve policies.
6. Complete a risk assessment and vendor review.
7. Gather dated evidence per control.
8. Engage a CPA firm and finalize the system description.
9. Respond to the examination and review the draft report.

Quick check

How Safeguard helps automate this

The slowest parts of a Type 1 are evidence collection and keeping it current while the auditor works. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring keeps running between audits. Your team keeps its time for the build work.

For the change management and vulnerability criteria, technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. The examination is performed by an independent CPA firm. Safeguard helps you prepare and keep evidence ready, and does not guarantee a result.

Want to see it on your own stack? Book a call.

Sources

• AICPA, 2017 Trust Services Criteria with revised points of focus (2022)

Last reviewed: 18 October 2026.