SOC 2 Readiness Checklist for Small SaaS Companies

Before implementing controls, establish why the company is pursuing SOC 2 and what commercial requirement it must satisfy.

• Identify the customer, contract, investor, partner, or market requirement driving SOC 2.
• Confirm whether the requesting party expects a Type I or Type II report.
• Determine whether the buyer has named required Trust Services Criteria.
• Document any deadline tied to a sale, renewal, procurement process, or board commitment.
• Identify who has authority to approve budget, scope, risk decisions, and timelines.
• Confirm whether interim documentation can support the customer conversation while readiness work continues.
• Avoid promising an examination date before scope and material gaps have been evaluated.
• Define what business outcome will make the readiness project successful.

Is the company pursuing a clearly defined business requirement, or is it beginning SOC 2 work without an agreed outcome?

Poor scoping creates unnecessary work, unreliable evidence, and examination problems.

• Document the SaaS product and services intended to be included.
• Identify the legal entity or entities in scope.
• Identify relevant locations, remote work arrangements, and operating environments.
• Document production infrastructure and cloud environments.
• Identify repositories, deployment systems, identity providers, ticketing systems, and monitoring platforms.
• Identify customer data types processed, stored, transmitted, or accessed.
• Document data flows between the application, infrastructure, personnel, and third parties.
• Identify critical vendors, subprocessors, hosting providers, and support systems.
• Document systems and activities intentionally excluded from scope.
• Confirm exclusions do not contradict customer representations or contractual obligations.
• Draft or validate the system description with the expected examination boundary in mind.
• Review the proposed scope with the independent CPA firm before the examination begins.

The Security category is included in every SOC 2 examination. Additional categories should be selected based on the service, commitments, risks, and customer expectations.

Security

• Document how systems and information are protected against unauthorized access and misuse.
• Define logical and physical access controls.
• Establish monitoring, vulnerability management, incident response, and change controls.
• Document governance, risk management, and communication responsibilities.

Availability

• Confirm whether uptime, resilience, capacity, recovery, or availability commitments are material.
• Define recovery objectives and continuity responsibilities.
• Maintain monitoring, backup, restoration, and recovery-testing evidence.

Confidentiality

• Identify information designated as confidential.
• Define handling, retention, access, transfer, and disposal requirements.
• Confirm contractual confidentiality commitments are reflected in operating practices.

Processing Integrity

• Determine whether completeness, accuracy, timeliness, or authorization of processing is a material customer commitment.
• Document validation, error handling, monitoring, and correction processes.

Privacy

• Determine whether personal information is collected and processed within the examination scope.
• Confirm privacy notices, consent, use, retention, disclosure, access, and disposal practices.
• Coordinate privacy interpretations with qualified legal or privacy counsel.

SOC 2 cannot be owned exclusively by an outside consultant or compliance platform.

• Name an executive sponsor and internal SOC 2 program owner.
• Assign an accountable owner to every control.
• Define who approves policies, evidence, exceptions, risks, and remediation.
• Establish a recurring readiness meeting.
• Maintain a decision log and risk register.
• Document policy approval and review requirements.
• Create a formal exception and risk-acceptance process.
• Define escalation thresholds for overdue or high-risk gaps.
• Confirm management reviews security and compliance performance.
• Document board or leadership oversight where applicable.
• Communicate responsibilities to employees and contractors.

Ownership test

1. Who owns it?
2. What does that person do?
3. How often does it occur?
4. Where is the evidence?
5. Who reviews the result?
6. What happens if the control fails?

Readiness work should be driven by business and system risk, not only by a generic checklist.

• Complete a documented risk assessment.
• Identify relevant threats, vulnerabilities, assets, and business impacts.
• Define a consistent risk-scoring method.
• Assign owners and document risk-treatment decisions.
• Create remediation tasks with owners and target dates.
• Prioritize material risks affecting scope or customer commitments.
• Document risks accepted, transferred, mitigated, or avoided.
• Retain management approval for risk acceptance.
• Review risks when systems, vendors, products, or business conditions change.
• Validate completed remediation rather than merely marking it done.

Policies should describe actual operating expectations. Procedures and evidence should demonstrate that those expectations are followed.

Documentation quality test

• Owner and approval record
• Effective date and review date
• Version history and defined scope
• Clear responsibilities
• A process that reflects actual operations

• Maintain an accurate inventory of workforce and service accounts.
• Require unique user identities and MFA for business-critical and production systems.
• Restrict administrative and privileged access.
• Document access-request and approval workflows.
• Establish role-based or least-privilege access.
• Review access when employees change roles and remove access promptly during offboarding.
• Conduct recurring user and privileged-access reviews.
• Review dormant, shared, emergency, and service accounts.
• Protect and rotate secrets, tokens, and credentials.
• Document authentication and password requirements.
• Retain evidence of approvals, changes, reviews, and terminations.

Common evidence

• Identity provider exports
• MFA enforcement configurations
• Access approvals
• Quarterly reviews
• Offboarding tickets
• Privileged account inventories
• Service account reviews

• Maintain current hardware, software, and cloud-service inventories.
• Define approved device and software standards.
• Require full-disk encryption on managed endpoints.
• Deploy endpoint protection and patch operating systems and applications.
• Control local administrator rights.
• Enforce screen lock and authentication requirements.
• Establish mobile device and BYOD requirements.
• Monitor endpoint health and security status.
• Define lost or stolen device procedures.
• Control installation of unauthorized software.
• Document secure disposal and equipment-return practices.
• Retain deployment, configuration, patching, and monitoring evidence.

• Document the production architecture and cloud account inventory.
• Restrict production access and require MFA for privileged access.
• Review IAM permissions regularly.
• Secure network boundaries and administrative interfaces.
• Enable encryption in transit and at rest where required.
• Protect encryption keys and secrets.
• Enable appropriate logs and retain them according to defined requirements.
• Configure monitoring and alerting.
• Establish vulnerability scanning and remediation tracking.
• Maintain secure baseline configurations.
• Review infrastructure changes.
• Test backup coverage and restoration.
• Document capacity, availability, and recovery controls where relevant.

• Document the software development lifecycle and secure coding expectations.
• Require peer review for material code changes.
• Protect branches and production repositories.
• Restrict deployment privileges and separate environments where appropriate.
• Require documented approval for production changes.
• Retain pull request, review, testing, and deployment records.
• Scan code, dependencies, containers, or infrastructure as appropriate.
• Track vulnerabilities and remediation.
• Protect secrets from source code and build logs.
• Review emergency changes after implementation.
• Establish rollback procedures.
• Review third-party and open-source dependencies.
• Document release and change records.

• Identify systems that must generate security and operational logs.
• Define log retention requirements and protect logs from alteration.
• Configure monitoring for relevant security and availability events.
• Define alert severity and escalation rules.
• Assign responsibility for reviewing alerts.
• Document handling of false positives and repeated alerts.
• Retain evidence of alert review and response.
• Review monitoring coverage after system changes.
• Test whether critical alerts reach the correct personnel.
• Establish a process for declaring and escalating incidents.

• Maintain a documented vulnerability-management process.
• Conduct recurring vulnerability scans where appropriate.
• Review application, infrastructure, endpoint, and dependency findings.
• Define severity and remediation timelines.
• Assign findings to accountable owners.
• Retest material findings after remediation.
• Document approved risk acceptance for unresolved findings.
• Conduct penetration testing based on scope, risk, and customer expectations.
• Review third-party test results.
• Track findings through closure.
• Report overdue or high-risk findings to management.
• Retain scan reports, tickets, approvals, and retest evidence.

• Maintain an incident response plan and define what qualifies as an incident.
• Establish severity levels, roles, and escalation paths.
• Maintain contact information for internal and external responders.
• Define customer, insurer, regulator, and legal notification decision paths.
• Preserve investigation and decision records.
• Conduct a tabletop exercise and document results.
• Maintain incident tickets and timelines.
• Conduct post-incident reviews and track corrective actions.
• Review the plan after significant organizational or system changes.

• Identify critical systems and business processes.
• Define recovery time and recovery point objectives where appropriate.
• Document backup scope and frequency.
• Protect backups against unauthorized access and alteration.
• Monitor backup success and failures.
• Test restoration and document results.
• Maintain disaster recovery and business continuity plans.
• Identify critical vendors and dependencies.
• Define communication and escalation procedures.
• Test recovery or continuity procedures.
• Record lessons learned and remediation.
• Review plans when products, infrastructure, or vendors change.

• Document role descriptions and security responsibilities.
• Complete screening appropriate to each role and jurisdiction.
• Require confidentiality and acceptable-use acknowledgements.
• Deliver security awareness and role-based training.
• Track training completion.
• Define disciplinary or sanction processes.
• Establish onboarding, role-change, and termination procedures.
• Recover company assets and remove access promptly during offboarding.
• Review contractor access and responsibilities.
• Retain acknowledgements, training records, approvals, and offboarding evidence.

• Maintain a complete vendor and subprocessor inventory.
• Classify vendors by risk and criticality.
• Identify what data and systems each vendor can access.
• Complete security due diligence before approval.
• Review contracts for security, confidentiality, incident, and data-handling terms.
• Collect relevant assurance documentation.
• Review critical vendors periodically.
• Track identified vendor risks and document approvals.
• Monitor material vendor changes.
• Maintain an offboarding process for terminated vendors.
• Confirm public subprocessor disclosures are accurate where applicable.

Evidence must demonstrate that the control operated, who performed it, when it occurred, and what result was produced.

• Map every control to expected evidence and identify its source system.
• Assign an evidence owner and define evidence frequency.
• Record collection date and relevant period.
• Retain approvals and reviewer identity.
• Preserve original exports where practical.
• Add context to screenshots and manually generated records.
• Track stale, missing, duplicated, or conflicting evidence.
• Restrict access to sensitive evidence.
• Maintain evidence provenance.
• Test sample periods before the examination.
• Confirm evidence matches control wording and the system description.
• Retain remediation evidence for failed controls.
• Maintain an auditor request tracker.

For a category-by-category evidence inventory, use the SOC 2 Evidence Collection Checklist.

Before committing to an examination period, test whether the program can withstand review.

• Review every control for design adequacy and ownership.
• Confirm control frequency matches actual practice.
• Sample evidence across relevant periods.
• Identify missed recurring activities.
• Review access changes, offboarding, production changes, vulnerabilities, vendors, training, incidents, and recovery testing.
• Identify contradictions between policies, system descriptions, and actual operations.
• Document deficiencies and corrective actions.
• Retest corrected controls.
• Obtain management approval before beginning the examination.

Smart Biz iT can support readiness and implementation. The SOC 2 examination and report must be performed by an independent CPA firm.

• Select an appropriately qualified CPA firm.
• Confirm report type, examination period, and Trust Services Criteria.
• Review the proposed system boundary.
• Understand the auditor’s information-request process.
• Confirm the expected system description and required management representations.
• Establish secure evidence-transfer methods.
• Confirm primary contacts and escalation procedures.
• Avoid allowing readiness support to blur independent auditor responsibilities.
• Coordinate the examination only after material readiness issues are understood.
• Maintain a tracker for requests, owners, due dates, and responses.

Do not begin the examination simply because a customer deadline is approaching.

• Scope is documented and approved.
• Relevant criteria have been selected.
• Control owners understand their responsibilities.
• Policies reflect actual operations.
• Technical controls are implemented.
• Recurring controls have operated consistently.
• Evidence is available for the intended period.
• Material gaps have been remediated or formally addressed.
• The risk register is current.
• Access, vendor, incident, change, and vulnerability records are available.
• The system description is accurate.
• Management has reviewed readiness.
• The CPA firm has confirmed scope and timing.
• Personnel are available to support examination requests.
• Customer communications do not overstate status or completion.