Blog · July 5, 2026

SOC 2 readiness checklist: steps before your first audit

A practical SOC 2 readiness checklist for startups. Learn what readiness means, scoping, policies, evidence collection, and when to engage an auditor.

What SOC 2 readiness actually means

SOC 2 readiness is not about passing an audit on your first try. It means your organization has the foundational controls, documentation, and evidence in place so that when you engage a CPA firm to audit you, the auditor finds a coherent control environment rather than scrambling to retrofit policies and evidence retroactively.

A "ready" startup has:

• A documented scope: which systems, people, and processes the audit will cover
• Written policies and procedures that actually describe how your team operates
• Evidence that those controls are running: logs, screenshots, attestations, access reviews
• Identified control owners: people who are responsible for each control
• A realistic timeline: you understand how long evidence collection takes

Readiness is not perfection. Auditors expect startups to have gaps. What they do not expect is to discover that your only access-control policy is a Slack message from six months ago, or that nobody can produce a single piece of evidence that you ever reviewed who has admin access.

Step 1: Define your audit scope

Before you write a single policy, decide what you are actually auditing. SOC 2 scope is narrower than "the whole company." It is the systems and processes that matter to your customers' trust.

Typical scope for a SaaS startup:

• Your application and its infrastructure (cloud servers, databases, load balancers)
• Your identity and access management (who can log in, how you grant access)
• Your change-management process (how code and config get deployed)
• Your incident-response process (how you detect and respond to security events)
• Your data-handling practices (encryption, backups, retention)

Scope does NOT usually include:

• Your office WiFi or employee laptops (unless you process customer data on them)
• Your marketing website (unless it is the product itself)
• HR systems or payroll (unless they touch customer data)

Write down your scope in one page. Name the systems, the teams involved, and the data types you handle. This becomes the anchor for everything that follows.

Step 2: Map controls to the AICPA Trust Service Criteria

SOC 2 is built on the AICPA Trust Service Criteria (TSC), a framework of control categories. The main ones are:

• CC (Common Criteria): security governance, risk management, access control, change management
• A (Availability): your systems are available when customers need them
• C (Confidentiality): customer data is not disclosed to unauthorized people
• I (Integrity): customer data is accurate and not tampered with
• P (Privacy): you handle personal data according to your privacy policy

You do not need to implement every criterion. You scope to the ones that matter for your business. A data-processing SaaS cares deeply about Confidentiality and Integrity. A status-page tool cares about Availability. A B2B tool that does not store personal data may skip Privacy.

For each criterion in scope, list the controls you already have (or need to build). For example, under "CC6.1 (Logical access)" you might have:

• Multi-factor authentication for all production access
• Role-based access control (RBAC) in your application
• Quarterly access reviews
• Automated deprovisioning when someone leaves

Write these down. You do not need a fancy matrix yet; a simple list per criterion is enough.

Step 3: Document your policies and procedures

Policies are the "what" and "why." Procedures are the "how."

Core policies every startup needs:

• Access Control Policy: who can access what, how you grant and revoke access, how often you review it
• Change Management Policy: how code and infrastructure changes are tested, approved, and deployed
• Incident Response Policy: how you detect, investigate, and respond to security incidents
• Data Protection Policy: how you encrypt, back up, and retain customer data
• Password Policy: minimum complexity, rotation, storage (if applicable)
• Vendor Management Policy: how you vet third-party tools and services

Do not write a 50-page policy manual. Write a one-page policy per topic that describes what you actually do. If your process is "we use GitHub branch protection and require two approvals," write that down. If it is "the CTO reviews and approves all changes," write that down. Auditors want to see that your controls match your reality, not that you have copied a template from the internet.

For each policy, assign an owner: the person responsible for maintaining it and ensuring the team follows it.

Step 4: Collect evidence

Evidence is the proof that your controls are real and running. Start collecting it now, not the week before your audit.

For each control, identify what evidence you need:

• Access reviews: export a list of who has access to each system, signed off by a manager quarterly
• Change logs: git commits, deployment records, approval comments
• Incident tickets: a log of security incidents you detected and how you responded
• Training records: proof that your team completed security training
• Vendor assessments: security questionnaires you sent to third-party tools, their responses
• Architecture diagrams: how data flows through your systems
• Backup test results: proof that you can restore from backups
• Penetration test or security audit: an external assessment of your systems

Set up a shared folder (Google Drive, Notion, or a spreadsheet) where you organize evidence by control. As you collect it, drop it in. Do this for at least three to six months before you engage an auditor; auditors want to see a track record, not a single snapshot.

Step 5: Assign control owners and run reviews

Each control needs an owner: the person who is responsible for it day-to-day.

For example:

• Access Control: your VP of Engineering or a senior engineer
• Change Management: your DevOps or infrastructure lead
• Incident Response: your security lead or CTO
• Data Protection: your CTO or a database administrator

Control owners do not need to be security experts. They need to understand the control, run it consistently, and collect evidence. Meet with each owner quarterly to review:

• Is the control still working the way we documented it?
• Do we have evidence that it ran this quarter?
• Are there any gaps or incidents we need to address?

Document these reviews. Auditors will ask to see them.

Step 6: Identify and address gaps

As you collect evidence and run reviews, you will find gaps. That is normal and expected.

Common gaps:

• No formal access-review process (fix: schedule a quarterly review, document it)
• No change-approval log (fix: add a checklist to your deployment process)
• No incident-response playbook (fix: write a one-page playbook, test it once)
• No encryption for data in transit or at rest (fix: enable TLS and database encryption)
• No vendor assessments (fix: send a security questionnaire to your key vendors)

For each gap, decide: is this a real risk we need to fix, or is it acceptable? Document your decision. Auditors understand that startups have constraints; they want to see that you have thought about the risks and made intentional choices.

Timeline expectations

SOC 2 readiness is not a sprint. Expect a qualitative timeline:

• Months 1 to 2: Define scope, map controls, write policies
• Months 2 to 4: Implement controls, start collecting evidence
• Months 4 to 6: Run reviews, identify and address gaps, build a track record
• Month 6+: Engage an auditor for a Type I audit (point-in-time snapshot)

A Type II audit (which most customers ask for) requires 6 to 12 months of evidence, so plan accordingly.

Where a readiness tool fits

A self-hosted readiness tool like Scorifya Controls can accelerate this process. It runs 38 automated checks across your cloud infrastructure (AWS, GCP, Azure, GitHub) and maps each one to the AICPA Trust Service Criteria. Instead of manually reviewing your access controls or change logs, the tool does it for you and flags gaps.

Controls also includes 28 manual controls with an attestation workflow, so you can record evidence and sign off on controls without building a spreadsheet. The tool generates an audit report that your CPA firm can review, saving weeks of back-and-forth.

You still need to write policies, assign owners, and run reviews. But a readiness tool eliminates the tedious evidence-collection work and gives you a clear picture of where you stand.

Next steps

Start with your scope: write down which systems and processes matter to your customers. Then pick one control (access management is a good start) and document how you actually do it. Collect evidence for three months. Once you have a track record, you will be ready to engage an auditor.

If you want to accelerate the process, run a readiness check on your infrastructure today. A tool can show you which controls are already in place and which ones need work.

Try a scan on scorifya.com, read how we score, or see Pro for unlimited scans and exports.