SOC 2 Policies and Procedures: What You Need to Document

Policies are the foundation of every SOC 2 audit. They document what your organization commits to doing, and auditors test whether you actually do it. There is no shortcut here — without well-written, enforceable policies, your SOC 2 report will either fail or be so qualified that it loses value with customers.

SaaS companies often underestimate the policy effort. They assume SOC 2 is primarily a technical exercise — configure MFA, encrypt data, set up monitoring. Those controls matter, but they exist to implement your policies. An auditor’s first step is to read your policies. Their second step is to check whether your operations match what the policies say. If there’s a gap between the two, you have a finding.

This guide covers every policy and procedure a SaaS company needs for SOC 2, what makes each one audit-ready, and the mistakes that cause the most pain during audit season.

Policies vs. Procedures vs. Standards

Before diving into the list, understand the hierarchy. These three document types serve different purposes, and your auditor expects to see the distinctions clearly.

Policies define what your organization will do and why. They state commitments, assign ownership, and set expectations. A policy is approved by leadership and applies broadly across the organization. Example: “All user access will follow the principle of least privilege.”

Standards define the specific benchmarks your organization must meet. They translate policy commitments into measurable thresholds. Example: “Passwords must be at least 14 characters and rotated every 90 days.”

Procedures define how something is done, step by step. They are operational instructions that employees follow to implement policies and meet standards. Example: “To provision a new user account, submit a request in Jira using the Access Request template, obtain manager approval, and configure the account in Okta with the role specified in the ticket.”

A well-structured compliance program layers all three: policies set direction, standards set the bar, and procedures tell people exactly what to do. When auditors see this structure, it signals maturity.

Core Required Policies

Every SOC 2 report — regardless of which Trust Service Criteria you include — requires a set of foundational policies. Here are the ten policies SaaS companies should have documented and enforced.

1. Information Security Policy

This is your overarching security document. It establishes the scope of your security program, defines roles and responsibilities, and articulates your organization’s commitment to protecting information assets.

What it covers: Security program objectives, scope (which systems, data, and personnel are included), executive sponsorship, roles (CISO, security team, engineering leads), and the relationship between this policy and all subordinate policies.

In practice: Your information security policy is the parent document. Every other security policy should reference it. Auditors use it to understand the boundaries of your SOC 2 scope, so be precise about what’s included and what’s not.

SaaS example: Your policy states that all production systems hosted on AWS, all employee endpoints, and all third-party integrations that process customer data fall within the scope of the security program. Internal tools that don’t touch customer data are explicitly out of scope.

2. Access Control Policy

Access control is one of the most heavily tested areas in any SOC 2 audit. This policy defines how your organization manages user access throughout its lifecycle.

What it covers: User provisioning and deprovisioning, role-based access control (RBAC), least privilege, multi-factor authentication (MFA) requirements, privileged access management, service account governance, and periodic access reviews.

In practice: Auditors will pull your user access lists and cross-reference them against this policy. They’ll check that terminated employees were deprovisioned within the timeframe your policy specifies. They’ll verify that MFA is enforced where you say it is. Every claim in this policy becomes testable.

SaaS example: Your policy requires MFA for all production system access, quarterly access reviews with documented remediation, and deprovisioning within 24 hours of employee termination.

3. Change Management Policy

Change management governs how modifications to your systems — code, infrastructure, configurations — are proposed, reviewed, approved, and deployed. For SaaS companies shipping code daily, this policy must reflect your actual development workflow.

What it covers: Code review requirements, deployment processes, testing requirements, approval workflows, emergency change procedures, rollback procedures, and change documentation.

In practice: Auditors will sample pull requests and deployments from your observation period. They’ll check that code reviews happened before merge, that deployments followed your documented process, and that emergency changes were retroactively documented and approved.

SaaS example: Your policy requires all production changes to go through a pull request with at least one peer review, pass CI/CD pipeline tests, and be deployed through your automated deployment system. Emergency hotfixes may bypass the standard review but require post-deployment review within 48 hours and a documented justification.

4. Incident Response Policy

Your incident response policy defines how your organization detects, responds to, and recovers from security incidents. This is one of the most scrutinized policies because it directly affects customer data protection. For a deep dive into building an effective incident response capability, see our Incident Response guide.

What it covers: Incident classification and severity levels, detection mechanisms, escalation procedures, containment and eradication steps, recovery procedures, communication protocols (internal and external), post-incident review process, and evidence preservation.

In practice: Auditors will ask for incident logs from the observation period. If you had incidents, they’ll trace your response against this policy. If you had zero incidents, they’ll test your detection capabilities to confirm you’d actually catch one.

SaaS example: Your policy defines four severity levels (P1-P4), requires a P1 incident war room within 15 minutes of detection, mandates customer notification within 72 hours for data breaches, and requires a written post-mortem for all P1 and P2 incidents within five business days.

5. Risk Assessment Policy

Risk assessment is foundational to SOC 2 — the Common Criteria explicitly require a formal, repeatable process for identifying and evaluating risk. For a complete walkthrough of the risk assessment process, see our Risk Assessment guide.

What it covers: Risk assessment methodology (qualitative, quantitative, or hybrid), assessment frequency (at least annually), risk identification approach, likelihood and impact scoring criteria, risk acceptance thresholds, risk treatment options (mitigate, transfer, accept, avoid), and roles responsible for risk ownership.

In practice: Auditors want to see a documented methodology, a completed risk assessment within the observation period, and evidence that identified risks were tracked and treated. A risk assessment that sits on a shelf untouched for 11 months is a finding.

6. Vendor Management Policy

Your SOC 2 report is only as strong as your vendor ecosystem. This policy governs how you evaluate, onboard, monitor, and offboard third parties. For the full vendor management framework, see our Vendor Management guide.

What it covers: Vendor classification by risk level, due diligence requirements (SOC 2 report review, security questionnaires), contractual security requirements, ongoing monitoring cadence, sub-processor management, and vendor offboarding procedures.

In practice: Auditors will review your vendor inventory, check that critical vendors have been assessed, and verify that you reviewed their SOC 2 reports during the observation period.

7. Data Classification Policy

Data classification defines how your organization categorizes information based on sensitivity and the handling requirements for each category. This policy drives encryption, access, retention, and disposal decisions across your entire stack.

What it covers: Classification levels (e.g., Public, Internal, Confidential, Restricted), criteria for assigning classifications, handling requirements per level (storage, transmission, access, disposal), data labeling expectations, and who has authority to classify data.

SaaS example: Customer data in your production database is classified as Confidential, requiring encryption at rest and in transit, access restricted to authorized services and personnel, and secure deletion upon contract termination. Internal documentation is classified as Internal, requiring authentication but not encryption at rest.

8. Acceptable Use Policy

The acceptable use policy defines employee responsibilities when using company systems, networks, and data. It sets behavioral expectations and establishes the basis for disciplinary action when those expectations are violated.

What it covers: Permitted and prohibited uses of company systems, personal device policies, internet and email usage, social media guidelines, data handling responsibilities, software installation rules, and consequences for violations.

In practice: Every employee should sign this policy during onboarding. Auditors will check for acknowledgment records. This policy also serves as the foundation for disciplinary procedures related to security violations.

9. Business Continuity and Disaster Recovery Policy

If you include the Availability criterion in your SOC 2 scope — and most SaaS companies do — you need a documented BC/DR policy. Even without Availability, the Security criterion’s Common Criteria touch on system recovery.

What it covers: Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for critical systems, backup procedures and verification, failover mechanisms, disaster recovery testing frequency and methodology, communication plans during outages, and roles and responsibilities during a disaster event.

SaaS example: Your policy sets an RTO of 4 hours and RPO of 1 hour for your production application. Backups run every hour to a separate AWS region. DR failover is tested quarterly with documented results, and the last successful test restored full service in 2.5 hours.

10. Human Resources Security Policy

People are a critical control layer. This policy covers the security aspects of the employee lifecycle from pre-hire to post-termination.

What it covers: Background check requirements, security training during onboarding (and annually thereafter), confidentiality and non-disclosure agreements, role-based security responsibilities, offboarding procedures (access revocation, asset return, exit interviews), and disciplinary process for security violations.

In practice: Auditors will sample employee files to verify background checks were completed, training records exist, and terminated employees were properly offboarded. If your policy says background checks are completed before start date, they’ll check the dates.

What Makes a Policy Audit-Ready

Writing a policy isn’t enough — it has to meet specific quality standards that auditors evaluate. Here’s what separates a policy that passes from one that generates findings.

Version control and approval dates. Every policy must show when it was created, last reviewed, approved, and by whom. Auditors look at the approval date relative to the observation period. A policy approved three years ago with no evidence of review is a problem.

Clear ownership. Each policy needs a designated owner responsible for its content, enforcement, and review. “The security team” is not specific enough. Name the role: “The CISO is responsible for the Information Security Policy.”

Specific, measurable requirements. “Access should be reviewed regularly” fails. “Access reviews are conducted quarterly, with remediation completed within 14 business days” passes. Every commitment in a policy becomes a testable assertion.

Regular review cadence. Policies must be reviewed at least annually. Document the review date, who conducted it, and what changes were made (or explicitly state “no changes required”). Auditors will verify this happened during the observation period.

Employee acknowledgment. Employees should formally acknowledge key policies — at minimum the Information Security Policy and Acceptable Use Policy. Track acknowledgments with dates and retain the records.

Alignment with actual practice. This is the most important criterion and the one that causes the most audit findings. If your policy says something, you must do it. Auditors will test the policy against operational reality. An aspirational policy that doesn’t match your operations is worse than no policy at all, because it demonstrates a control failure.

Common Policy Mistakes

After working with hundreds of SaaS companies, these are the policy mistakes we see most frequently.

Copy-pasting templates without customization. Generic templates use language like “the organization shall maintain physical access controls to server rooms.” If you’re a cloud-native SaaS company running on AWS, you don’t have server rooms. Auditors will immediately flag policies that don’t reflect your actual environment. Templates are a starting point, not a finished product.

Writing aspirational policies. Your policy says access reviews happen monthly. Your access review evidence shows they happen quarterly — sometimes. This creates a control failure that’s worse than having a quarterly policy, because you’ve now demonstrated that you don’t follow your own commitments. Write policies that match what you actually do, then improve iteratively.

Missing review and approval metadata. A policy without an approval date, version number, or named approver is incomplete. Some organizations write excellent policy content but forget the administrative framework around it. Auditors check metadata first.

Overly complex policies nobody reads. A 40-page information security policy that covers every conceivable scenario is technically comprehensive and practically useless. If your engineers can’t quickly find the requirements relevant to their work, the policy isn’t serving its purpose. Keep policies focused and readable. Move detailed instructions into procedures.

Not updating after organizational changes. You migrated from AWS to GCP, promoted a new CISO, or restructured your engineering team. If your policies still reference the old environment, the old CISO, or the old team structure, auditors will notice the inconsistency.

Procedures: The Operational Details

Procedures are where policies become operational. While a policy states “user access will be reviewed quarterly,” the procedure defines exactly how that review is conducted, who does it, what tools are used, and how remediation is tracked.

Key Procedures for SaaS Companies

User access review procedure. Step-by-step instructions for conducting quarterly access reviews: who pulls the access lists, which systems are reviewed, how discrepancies are documented, how remediation is assigned and tracked, and how the completed review is stored as evidence.

Change deployment procedure. The detailed workflow for getting code from a developer’s branch to production: branch naming conventions, PR template requirements, reviewer assignment, CI/CD pipeline stages, staging verification steps, production deployment process, and smoke test requirements.

Vulnerability management procedure. How vulnerabilities are identified (scanning tools, frequency), triaged (severity classification), assigned to owners, remediated within SLA (critical: 7 days, high: 30 days, medium: 90 days), and verified as resolved. Include the process for exceptions and accepted risks.

Backup and restore procedure. Detailed steps for configuring backups, verifying backup integrity (automated and manual verification cadence), performing a restore, and documenting the results. Include the schedule for restore testing.

Incident response procedure. The step-by-step playbook for each incident severity level: who is notified and how, what communication channels are used, how the war room is set up, containment steps by incident type, evidence preservation requirements, customer communication templates, and post-mortem template and timeline.

Each procedure should explicitly reference the parent policy it implements. This traceability is something auditors look for — it demonstrates that your operational details are governed by approved commitments.

Evidence of Policy Compliance

Auditors don’t take your word for it. They test whether your operations match your policies by examining evidence across the entire observation period. For a comprehensive guide to evidence collection, see our Evidence Collection guide.

Access control evidence: Quarterly access review reports showing who reviewed what, discrepancies found, and remediation taken. MFA enforcement configurations. Deprovisioning tickets with timestamps showing compliance with your SLA.

Change management evidence: Pull request history showing code reviews before merge. Deployment logs matching your documented process. Emergency change tickets with retrospective approvals.

Incident response evidence: Incident tickets with timestamps showing detection, response, and resolution. Post-mortem reports for significant incidents. Communication records showing customer notifications where required.

Training evidence: Training completion records with dates. Policy acknowledgment logs. New-hire onboarding records showing security training was completed within the required timeframe.

Risk assessment evidence: Completed risk assessment documents dated within the observation period. Risk register showing treatment plans and status updates. Meeting minutes from risk review sessions.

The most common gap between policy and practice is timing. Your policy says access reviews happen quarterly. You completed three reviews during a 12-month observation period instead of four. That’s a finding — not because your reviews were inadequate, but because you didn’t meet your own stated frequency. This is why writing realistic policies matters so much.

How GRCTrail Helps

GRCTrail gives SaaS teams a structured approach to building and maintaining the policy framework that SOC 2 requires.

• Policy templates aligned with SOC 2 Common Criteria that cover every required policy area, written specifically for SaaS companies so you’re not editing out references to physical data centers
• Version-controlled policy management with built-in approval workflows, review tracking, and change history that auditors can verify independently
• Employee acknowledgment tracking that records when each team member reviewed and accepted policies, with automated reminders for new hires and policy updates
• Policy review reminders that trigger before your annual review deadline, ensuring you never miss a review cycle during your observation period
• Linked evidence collection that connects policies to the controls that implement them and the evidence that proves compliance — so you always know if there’s a gap between what you committed to and what you’re actually doing

Get started with GRCTrail →

Related Guides

• What Is SOC 2? A Practical Guide for SaaS Companies
• SOC 2 Evidence Collection: What Auditors Actually Look For
• SOC 2 Risk Assessment Guide
• SOC 2 Common Criteria Explained