SOC 2 Readiness Checklist for SaaS Companies: What to Complete Before Your Audit

A SOC 2 readiness checklist should answer one question: if the auditor started testing today, could you show that every in-scope control is designed correctly, operating as described, and supported by evidence?

For many SaaS companies, the answer is unclear. Vanta or Drata may show a high completion percentage, policies may be uploaded, and most automated tests may be green. None of those signals proves that the audit is ready to begin.

This checklist focuses on the work that should be complete before formal testing starts. It is organized around the areas that most often delay an audit: scope, policies, technical controls, evidence, vendors, employees, unresolved gaps, and the handoff to the auditor.

SOC 2 Readiness Checklist at a Glance

Before you begin the audit, confirm that you can check every item below:

• Your product, infrastructure, people, locations, vendors, and Trust Services Criteria are clearly in or out of scope
• Each control has an owner, a defined frequency, and a documented procedure
• Policies describe how your company actually operates and have been approved
• Required cloud, identity, endpoint, application, and operational controls are implemented
• Evidence exists for each control and covers the required audit period
• Vendor inventory and risk reviews are current
• Employee onboarding, training, policy acceptance, and offboarding records are complete
• Failed tests, exceptions, and security gaps have documented resolutions
• Vanta or Drata integrations have been validated, including manual controls the platform cannot test
• Your auditor has the final scope, system description inputs, control list, and organized evidence

If several of these are incomplete, the most efficient next step is a readiness review, not the audit itself. Starting too early turns planned remediation into audit exceptions and creates unnecessary back-and-forth with the CPA firm.

1. Confirm the SOC 2 Scope

Scope determines everything that follows. A control may be perfectly implemented and still irrelevant if it covers a system outside the audit boundary. A critical system may also be missed if the scope was copied from a template instead of mapped to the product.

Define the service and system boundary

• Identify the SaaS product or service covered by the report
• List production cloud accounts, subscriptions, projects, regions, and environments
• Identify databases, storage systems, queues, APIs, repositories, CI/CD systems, and monitoring services that support the product
• Document the identity provider, HR system, endpoint management platform, ticketing system, and other systems used to operate controls
• Identify office locations and remote-work practices relevant to physical or logical access

Select the Trust Services Criteria

Security is included in every SOC 2 examination. The other criteria are optional and should reflect the commitments your SaaS company makes to customers and the risks the report needs to address.

• Security: always included. It covers the common criteria for protecting systems and information against unauthorized access and other security events.
• Availability: choose this when uptime, capacity, recovery, or service-level commitments are material. Do customers rely on a stated SLA, or would an outage prevent them from performing a critical function?
• Confidentiality: choose this when customer or business data is subject to contractual handling and protection restrictions. Do agreements require specific controls over sensitive files, source code, financial data, or other designated confidential information?
• Processing Integrity: choose this when complete, accurate, timely, and authorized processing is central to the service. Does the product calculate transactions, move records between systems, or produce outputs customers depend on being correct?
• Privacy: choose this when the organization collects or processes personal information and customers need the report to cover the privacy lifecycle. Should the examination address how personal information is collected, used, retained, disclosed, and disposed of?

Adding a criterion expands the control set, evidence requirements, audit testing, and cost. Do not add all five by default because they appear more comprehensive. Select the criteria that match actual service commitments, data handling obligations, and customer needs, then confirm the choice with your auditor before implementation is finalized.

Document carve-outs and dependencies

List the subservice organizations your product depends on, such as AWS, Azure, GCP, a payment processor, a managed database provider, or a data center. Confirm whether the report will use the carve-out method and identify the complementary controls customers are expected to operate.

Readiness test: an auditor can look at your scope and understand what service is covered, which systems support it, which criteria apply, and which third parties are dependencies.

2. Assign Owners and Define How Controls Operate

Every control needs more than a title. It needs an owner who is responsible for making it happen, a frequency, a procedure, and a predictable evidence source.

For each control, record:

• Owner: the person accountable for the control
• Operator: the person or system that performs it
• Frequency: continuous, per event, monthly, quarterly, or annually
• Procedure: the actual steps used to perform and review it
• Evidence: the record that proves the control operated
• Exception process: what happens when the control fails or cannot be completed on time

Pay particular attention to controls that sound automatic but still require human review. A vulnerability scanner may run continuously, for example, but someone still needs to review findings, prioritize remediation, document accepted risk, and prove that critical issues were addressed within the stated timeline.

Readiness test: every control has a named owner who can explain how it works and produce the expected evidence without guessing.

3. Approve Policies That Match Actual Operations

Policy templates are useful starting points. They become a liability when they describe processes your company does not follow.

Review the policy set against your environment and confirm that it covers the relevant areas:

• Information security
• Access control and account management
• Acceptable use
• Asset management
• Change management and secure development
• Data classification, retention, and disposal
• Encryption and key management
• Incident response
• Business continuity and disaster recovery
• Risk management
• Vendor management
• Vulnerability management
• Human resources security

Then compare the language to reality. If a policy says access reviews happen quarterly, there should be completed quarterly reviews. If it says production changes require approval, the GitHub and deployment workflow should preserve that approval. If it requires annual recovery testing, there should be a test result and follow-up record.

Policies should have an owner, approval date, version, review cadence, and acceptance record where required. Avoid commitments that are stricter than the business needs or can consistently meet.

Readiness test: policies are approved, distributed, and aligned with the control procedures and technical configuration the auditor will examine.

4. Complete the Technical Control Baseline

Technical controls are where a readiness dashboard most often exposes real engineering work. The exact requirements depend on scope, but most SaaS environments should validate the following areas.

Identity and access

• MFA is enforced for cloud consoles, source control, identity providers, and other critical systems
• Production access is restricted by role and business need
• Shared accounts are removed or tightly controlled and documented
• Administrative access is separated from normal user access where appropriate
• User access is reviewed on the stated cadence
• Joiner, mover, and leaver workflows are documented and produce records
• Service accounts, API keys, and secrets have owners and appropriate rotation controls

Cloud and network security

• Cloud audit logging is enabled across all in-scope accounts and regions
• Logs are centralized, protected from modification, retained for the required period, and monitored
• Security groups, firewall rules, and public endpoints have been reviewed
• Data is encrypted in transit and at rest using approved configurations
• Threat detection and security alerting are enabled with a documented response path
• Production and non-production environments are appropriately separated
• Backups are configured, monitored, and tested for restoration

Application and delivery controls

• Code changes require review before production deployment
• CI/CD permissions and deployment credentials follow least privilege
• Vulnerability scanning covers dependencies, applications, infrastructure, and endpoints as applicable
• Findings are triaged and remediated within documented timelines
• Production changes can be traced to an approved pull request, ticket, or equivalent record
• Security incidents and operational alerts create retained investigation records

Endpoint and workforce systems

• In-scope employee devices are inventoried and managed
• Disk encryption, screen locking, operating system updates, and endpoint protection are enforced
• Lost or compromised devices can be disabled or wiped
• Exceptions for unmanaged devices are documented and approved

Readiness test: technical controls are enabled throughout the full in-scope population, not just on a sample account or a recently created production resource.

5. Build an Evidence Map Before the Audit

An auditor does not test whether a task is marked complete in your project plan. The auditor tests evidence. Build a simple evidence map that connects each control to the system or record that proves it operated.

Common evidence sources include:

• Configuration exports and integration snapshots from Vanta or Drata
• Cloud audit logs and security configuration reports
• Pull requests, approvals, deployment logs, and change tickets
• Access review exports and remediation records
• Training completion and policy acceptance records
• Vendor reviews, risk decisions, and supporting reports
• Incident response exercises and actual incident tickets
• Backup restoration and disaster recovery test results
• Risk assessment and risk treatment records
• Vulnerability reports and remediation tickets

Check the date range on every record. For a Type II audit, evidence must cover the observation period and demonstrate that recurring controls operated at the promised frequency. A quarterly control needs each applicable quarter, not one recent example collected just before fieldwork.

Also confirm completeness. If an access review covers 18 of 20 in-scope systems, the missing two systems are still a gap. If an automated integration cannot see one AWS account, the green checks from the other accounts do not solve that problem.

Readiness test: every control maps to complete, readable, correctly dated evidence that covers the in-scope population and required period.

6. Complete Vendor Management

Start with a complete vendor inventory. Include third parties that store, process, transmit, secure, or materially support customer data and the in-scope service.

For each relevant vendor, document:

• Service provided and business owner
• Data accessed or processed
• Risk tier and review frequency
• Security review date and result
• SOC report, ISO certificate, security documentation, or questionnaire reviewed
• Contractual security and incident notification terms where applicable
• Identified risks, compensating controls, and approval decisions

Do not limit the list to vendors connected to the compliance portal. Vanta and Drata can help organize vendor records, but they cannot determine whether the inventory is complete or make the risk decision for you.

Readiness test: the vendor list is current, critical vendors have completed reviews, and outstanding risks have documented owners and decisions.

7. Verify Employee Controls

Employee evidence is frequently scattered across an HR system, identity provider, training platform, signed agreements, and manual onboarding or offboarding tickets. Reconcile those systems before the auditor requests samples.

• All in-scope personnel completed background checks where required by policy and law
• Confidentiality and acceptable-use obligations are documented
• Required security training is current
• Policy acknowledgments are complete
• New hires received access through an approved onboarding process
• Terminated personnel had access removed within the documented timeframe
• Role changes triggered appropriate access changes
• Contractors are included where they have in-scope access

Run a reconciliation between the HR roster, identity provider, source control, cloud access, and compliance platform. Differences often reveal stale accounts, missing employees, or contractors who were never included in the control process.

Readiness test: the personnel population is complete and every sampled person will have a consistent trail from onboarding through current access or termination.

8. Resolve Gaps and Document Exceptions

A failed automated test is not automatically an audit exception. It may be a false positive, an out-of-scope resource, a missing integration permission, or a legitimate control failure. Each one needs a disposition.

Use a remediation tracker with:

• The affected control and system
• Root cause
• Risk and audit impact
• Remediation owner and due date
• Fix or compensating control
• Validation evidence
• Formal risk acceptance when remediation is not practical

After a fix, retest it. Updating a configuration is only half the work; you also need proof that the intended control now operates and, for Type II, a plan for monitoring it through the observation period.

Readiness test: there are no unresolved high-impact gaps, and every accepted exception has a defensible rationale, owner, approval, and treatment plan.

9. Validate Vanta or Drata Instead of Trusting the Score

Vanta and Drata are valuable systems of record for a SOC 2 program. Use them to centralize controls, integrations, evidence, policies, personnel tasks, vendors, and auditor requests. Then validate what the platform is telling you.

• Confirm every in-scope account, repository, identity provider, device platform, and HR source is connected
• Review integration permissions and make sure evidence collection is not partial
• Resolve stale, muted, or incorrectly scoped tests
• Assign owners to manual controls and upload the required evidence
• Check that custom controls and evidence requests are mapped correctly
• Reconcile the platform populations against source systems
• Review policy versions, approvals, and acceptance status
• Confirm auditor access exposes the intended evidence without unnecessary sensitive data

A 95% score can hide one serious access or logging gap. A lower score can include irrelevant tests that should be scoped out. The objective is not a perfect dashboard. It is a defensible control environment.

For a deeper explanation of the work that remains after purchasing a platform, read what Vanta and Drata automate and what still has to be implemented.

10. Prepare the Auditor Handoff

The handoff should be a controlled transition into testing, not the first time the auditor sees the program.

Before fieldwork, prepare:

• Final audit scope and Trust Services Criteria
• System description inputs, including infrastructure, software, people, data, and procedures
• Final control matrix with owners and frequencies
• Approved policy set
• Evidence map and complete evidence for the audit period
• Population exports for users, employees, changes, incidents, vendors, and other sampled areas
• List of known exceptions, remediation, and risk decisions
• Availability for control walkthroughs and technical follow-up

Ask the auditor to confirm scope, period, sample expectations, portal workflow, and deadlines before testing begins. Clarify who should answer requests and who can approve additional evidence. This prevents duplicate work and keeps implementation questions from bouncing between the auditor and internal owners.

Readiness test: the auditor can begin testing with a stable control set, complete populations, organized evidence, and clear points of contact.

Type I vs Type II: How the Checklist Changes

A Type I report evaluates whether controls are suitably designed and implemented as of a specified date. Your readiness work should prove that the control exists, matches the written process, and can operate as intended.

A Type II report evaluates operating effectiveness over a period of time. In addition to design and implementation, you need consistent evidence throughout the observation period. That means recurring access reviews, vulnerability remediation, change approvals, vendor reviews, training, incident handling, and other controls must happen on schedule.

If Type II is the goal, design the evidence process before the period begins. Reconstructing months of missing evidence at the end is unreliable and may not satisfy the auditor.

When to Run the Final Readiness Review

Run a final review after remediation is substantially complete and before the auditor selects samples. Walk through every control, inspect the evidence source, verify the population, and confirm that the owner can describe the process.

The result should be a short list of specific fixes, not a new discovery phase. If the review uncovers major scoping, access, logging, policy, or evidence problems, move the audit start date and resolve them first.

For an idea of the implementation sequence leading up to this point, see our week-by-week SOC 2 implementation guide. To understand the full budget, including platform, implementation, and CPA fees, see the SOC 2 cost breakdown for 2026.

Get a Clear Answer Before the Audit

The best time to find a control gap is before it becomes part of the audit record. A readiness review gives you room to correct the process, collect clean evidence, and begin testing with confidence.

Cavanex handles SOC 2 implementation end to end, including scope, policies, technical remediation, evidence preparation, and audit support. We work directly inside Vanta or Drata and help move the program from an incomplete checklist to an audit-ready control environment.

Take the SOC 2 readiness assessment to identify the areas that may still need work before your audit.