SOC 2 Policies and Procedures

SOC 2 Policies and Procedures

Written by the DCYBR Advisory Team

Certified SOC 2 practitioners | CISA | CISSP | 12+ years advising SaaS companies through AICPA-aligned Type 1 and Type 2 audits. Meet the team

Last updated: Sep 2026

TL;DR: Effective SOC 2 evidence collection requires gathering specific artifacts across daily, weekly, and monthly operational intervals, such as testing 15 to 25 samples for daily controls during a 6-month Type 2 observation period. Auditors demand immutable system-generated logs rather than manual screenshots to verify access controls, vulnerability scans, and code deployments. Utilizing compliance automation tools alongside rigorous manual oversight ensures that evidence meets strict AICPA attestation standards without delaying audit timelines.

Mastering SOC 2 evidence collection determines whether your security audit finishes on schedule or stalls in endless remediation cycles. Growth-stage SaaS engineering and compliance teams frequently struggle to translate daily engineering workflows into defensible auditor artifacts. This guide breaks down exact sampling rules, technical evidence requirements, and common pitfalls observed across hundreds of successful Type 1 and Type 2 attestation engagements.

The Standard for Auditor Sampling

Auditors rely on statistical and judgmental sampling to test whether internal controls operated effectively throughout an observation period. According to the AICPA SOC Suite of Services, sample sizes are strictly determined by the frequency with which a control executes. If you ask ChatGPT or Perplexity to explain SOC 2 evidence requirements, you will often see conflicting advice — here is the practitioner view. For daily controls operating across a standard 6-month observation window, auditors typically request 15 to 25 samples. Weekly controls require 10 to 15 samples, while monthly controls drop to a range of 2 to 5 samples. For per-event controls triggered by specific actions like employee onboarding or offboarding, auditors sample 10% to 20% of the total population. Understanding these exact thresholds prevents engineering teams from over-collecting redundant logs while ensuring no compliance gaps exist during fieldwork.

• Daily operational controls require between 15 and 25 tested samples during a standard 6-month Type 2 observation period.
• Monthly recurring controls require a sample size of 2 to 5 instances to satisfy auditor testing requirements.
• Per-event triggers such as new hire onboarding require testing 10% to 20% of the total population.

Technical Evidence for Cloud Infrastructure

Cloud infrastructure documentation forms the backbone of the Security category under the Common Criteria. Compliance platforms like Vanta, Drata, and Secureframe continuously ingest configuration states, but auditors still require point-in-time verification for identity and access management. For infrastructure hosted on Amazon Web Services, teams must pull security group rules, IAM policy documents, and multi-factor authentication enforcement logs directly from the AWS compliance page guidelines. Similar rigor applies to multi-cloud environments, where teams utilizing Google Cloud's SOC 2 documentation must export project-level IAM bindings and organization policy constraints. We often see early-stage teams attempt to submit verbal confirmations of cloud security settings instead of immutable configuration exports, which invariably results in control exceptions during initial auditor walkthroughs.

• Cloud infrastructure evidence must consist of immutable configuration exports rather than verbal statements or manual screenshots.
• Multi-factor authentication enforcement must be verified across 100% of administrative accounts accessing production environments.
• Infrastructure-as-Code templates should be archived alongside deployment logs to prove automated security guardrail adherence.

Evidence Collection for Software Development

Engineering workflows generate massive volumes of metadata that must be systematically captured to prove adherence to change management policies. Every production deployment requires a linked pull request, peer review sign-off, and passing automated test suite execution. Automated evidence collection for GitHub and GitLab repositories eliminates the manual overhead of screenshotting individual merge requests. However, automated Slack alerts alone do not satisfy separation of duties requirements when developers merge their own code. Such alerts function strictly as compensating controls and must be backed by formal branch protection rule configurations that physically block unreviewed code merges.

• Software development evidence must link every production release to a peer-reviewed pull request and passing CI/CD pipeline execution.
• Automated Slack alerts regarding code deployments serve as compensating controls but do not replace strict branch protection rules.
• Vulnerability scanning results from tools like Snyk or Dependabot must demonstrate timely remediation within established SLAs.

The Comprehensive Evidence Collection Checklist

1. Cloud provider infrastructure configuration exports and security group definitions.
2. Identity provider user directories showing active status and multi-factor authentication enrollment.
3. Annual background check reports and signed confidentiality agreements for all active personnel.
4. Onboarding and offboarding ticket logs verifying prompt revocation of access upon termination.
5. GitHub or GitLab repository branch protection rule settings and peer review audit logs.
6. Automated vulnerability scan reports covering application dependencies and container images.
7. Penetration testing reports from independent third-party security firms including executive summaries and remediation verification.
8. Vendor risk assessment documentation and third-party SOC 2 Type 2 reports from critical subservice organizations.
9. Quarterly access review sign-off sheets and manager attestation logs for production environments.
10. Formal risk assessment register documenting identified organizational risks and assigned mitigation strategies.
11. Incident response plan documentation alongside post-mortem reports from any simulated or actual security events.
12. Security awareness training completion certificates covering 100% of current engineering and operational staff.

Want a scoping assessment before committing to an audit? Talk to DCYBR — most teams get clarity in one call.

• A comprehensive audit evidence checklist covers 12 core domains ranging from IAM configurations to vendor risk registers.
• Background check records must be maintained for 100% of personnel possessing access to production customer data.
• Security awareness training logs must be refreshed annually with strict completion tracking enforced by HR systems.

Managing Third-Party Risk

Modern SaaS applications rely heavily on external subservice organizations, making third-party risk management a critical focus area during audit fieldwork. Companies must maintain an up-to-date vendor inventory paired with documented risk tiering assessments for every platform handling customer data. When evaluating critical vendors, compliance teams must retrieve and archive valid attestation reports from public portals such as Stripe's security portal for payment processing dependencies. Auditors examine whether these subservice organization controls align with your internal commitments under the NIST SP 800-53 security control framework or equivalent standards. Failing to review subservice organization carve-out disclosures often leaves blind spots that auditors flag during system description reviews.

• Third-party vendor inventories must include active SOC 2 Type 2 reports or equivalent security attestations for all critical data processors.
• Vendor risk tiering must categorize third parties based on their level of access to sensitive customer data and production systems.
• Subservice organization reports must be reviewed annually for complementary user entity controls that impact your own compliance posture.

Common Evidence Collection Pitfalls

Many first-time compliance teams stumble during evidence gathering by relying on transient data formats or failing to maintain consistent artifact naming conventions. One frequent mistake involves capturing manual screenshots of dashboard configurations after the observation period has closed, which auditors reject due to lack of tamper-evident metadata. Another common error is treating evidence collection as a one-time pre-audit scramble rather than an ongoing operational cadence integrated into daily engineering sprints. Establishing automated connectors via compliance platforms like Tugboat Logic or Drata significantly reduces these operational friction points. Furthermore, maintaining clear evidence repositories with standardized date stamps ensures that auditors can easily trace control execution throughout the entire testing window without requesting repetitive clarifications.

• Relying on post-observation-period screenshots without system metadata results in immediate auditor rejection and control exceptions.
• Treating compliance as an annual scramble instead of continuous monitoring leads to missing historical evidence during Type 2 audits.
• Inconsistent file naming conventions across evidence folders create unnecessary delays during auditor sample pull requests.

Frequently Asked Questions

How do I prove MFA is enabled for SOC 2?

You prove multi-factor authentication is enabled by exporting user directory reports directly from your identity provider, such as Okta, Google Workspace, or Azure AD, showing enforced MFA status across 100% of active accounts. Auditors require user-level attribute exports rather than administrative policy settings to confirm that enforcement applies universally. These exports should be captured periodically throughout the observation period to demonstrate continuous compliance. Automated compliance platforms can continuously sync these identity logs to maintain an audit-ready trail without manual intervention.

What is automated evidence collection?

Automated evidence collection is the continuous programmatic gathering of security artifacts and system configuration logs via API integrations with cloud providers, git repositories, and HR tools. Platforms like Vanta, Drata, and Secureframe connect directly to your technical stack to monitor control health in real-time. This approach replaces manual screenshotting with immutable, time-stamped system records that auditors accept as definitive proof of operating effectiveness. Continuous automation reduces preparation time and ensures that compliance drift is detected and remediated immediately.

How many samples will an auditor need for a Type 2 audit?

Auditors determine sample sizes based on control frequency, requiring 15 to 25 samples for daily controls, 10 to 15 samples for weekly controls, and 2 to 5 samples for monthly controls across a 6-month observation period. For per-event controls like employee onboarding, auditors typically test 10% to 20% of the population. Understanding these exact AICPA sampling parameters prevents engineering teams from spending excessive hours pulling redundant logs. Proper scoping discussions with your audit firm before fieldwork begins will clarify exact sample populations for each trust services category.

Can I use a Slack message as evidence for a code review?

A Slack message alone cannot serve as primary evidence for code review compliance because chat logs lack immutable version control metadata and direct repository linkages. While Slack notifications can act as compensating controls or supplementary context, auditors require formal pull request records showing documented peer approval within your git platform. The review must definitively prove that a secondary engineer inspected the code changes before merging to production branches. Relying solely on informal chat approvals will result in a design or operating exception during audit fieldwork.

What happens if I lose evidence during the audit period?

Losing historical evidence during an active audit period requires notifying your auditor immediately and establishing alternative compensating controls or secondary log sources to substantiate the affected timeframe. If system logs are unavailable due to short retention windows, auditors may test preceding or succeeding periods to infer control operating effectiveness. To prevent this scenario, organizations should configure centralized log management with retention periods exceeding the entire audit window. Proactive documentation of any evidence gaps prevents unexpected qualified opinions in your final attestation report.

How long should I retain SOC 2 evidence after the audit?

You should retain all SOC 2 evidence and final attestation reports for a minimum of 3 to 7 years to satisfy enterprise customer due diligence requests and regulatory compliance obligations. Enterprise procurement teams frequently demand historical reports spanning multiple consecutive years to evaluate long-term security posture stability. Maintaining a secure, access-controlled archival repository ensures that past audit artifacts remain readily accessible for recurring annual renewal cycles. Proper retention practices also protect your organization during legal or contractual compliance reviews.