SOC 2 Policy Templates

Purpose

This policy describes how [Company Name] protects information used to deliver [Product Name]. It is a starting point for how the company intends to operate — not a certificate and not legal advice.

Scope

Applies to employees, contractors, and systems that process [Company Name] or customer data for the in-scope product, including [Production environment / cloud account] and [Primary collaboration tools].

Roles and responsibilities

[Policy Owner] owns this document. [Approved By] approves material changes. Everyone with access to in-scope systems is expected to follow it and report suspected issues to [Security contact].

Policy statements

Security work is part of delivering the product. The company does not treat it as an optional side project once customer data is in play.

• Access is granted on least privilege and removed when the person or vendor no longer needs it.
• Company and customer data are stored only in approved systems ([System / Tool Name]).
• Laptops and production access use [MFA method] where the system supports it.
• Suspected incidents are reported promptly — silence is not a process.

Procedures / requirements

Day to day, [Policy Owner] keeps an inventory of in-scope systems, confirms new tools before they hold customer data, and makes sure access reviews and training happen on the cadence below.

• New production access: request, approval, provision, record.
• Assets: company-managed devices where practical; disk encryption on.
• Risks that would affect customers are written down, even if the list is short.
• Incidents follow the Incident Response Policy once someone declares one.

Exceptions

Exceptions are written, time-bounded, and approved by [Policy Owner]. “We always skip MFA for this one box” is not an exception — it is a gap.

Review and approval

Reviewed at least [Review Frequency] or after a material change (new product surface, acquisition, major vendor). Version [Version] effective [Effective Date], approved by [Approved By].

Purpose

This policy sets how [Company Name] grants, reviews, and removes access to systems that can affect [Product Name] or customer data.

Scope

Covers identity providers, production cloud, source control, customer-support tools, and any app listed in [System inventory]. Personal shadow accounts for production are out of policy.

Roles and responsibilities

[Policy Owner] owns the process. Hiring managers request access. [Engineering lead] approves production and admin roles. [Approved By] signs material exceptions.

Policy statements

• Least privilege: people get the smallest role that lets them do the job.
• Unique accounts: no shared production logins except a documented break-glass path.
• MFA is required on [IdP / SSO] and on production consoles that support it.
• Privileged access (admin, root, owner) is limited, logged, and reviewed.
• Access is reviewed on a defined cadence — not only when someone remembers.

Procedures / requirements

Provisioning: ticket or form → manager approval → grant in [IdP / tool] → record the role.

Deprovisioning: last day (or earlier) → disable IdP → revoke production, git, and vendor admin → confirm in the offboarding checklist.

Periodic review: [Policy Owner] exports access from [System / Tool Name] at least [Review Frequency], notes adds/removes, and keeps the export as evidence.

Exceptions

Break-glass credentials are stored in [Secret store], dual-controlled if possible, rotated after use, and never used as daily logins.

Review and approval

Reviewed [Review Frequency]. Effective [Effective Date]. Approved by [Approved By].

Purpose

This policy tells [Company Name] how to detect, declare, contain, and learn from security incidents that could affect [Product Name], customer data, or availability of in-scope services.

Scope

Confirmed or suspected confidentiality, integrity, or availability events involving in-scope systems. Product bugs that do not affect security still get a ticket — they are not automatically incidents.

Roles and responsibilities

Anyone may report. [Incident commander role] triages and declares. [Policy Owner] owns the record. [Customer communications owner] talks to customers when [Approved By] agrees notice is needed.

Policy statements

Incidents are declared in writing (ticket, channel, or form). Informal Slack jokes are not the record.

• Identify: logs, alerts, customer reports, employee reports.
• Report: [Security contact] or [On-call channel] without waiting for perfect certainty.
• Triage: severity (Sev-1 customer impact vs Sev-3 contained internal).
• Contain, then remediate, then recover — in that order unless delay itself causes harm.
• Document timeline, decisions, and evidence as you go.

Procedures / requirements

Open an incident ticket in [System / Tool Name]. Assign a commander. Capture start time, systems, data at risk, and current containment. After recovery, run a short post-incident review: what happened, what we change, who owns the change. Keep the ticket.

Exceptions

If declaring an incident would itself create legal exposure, still record facts internally and involve [Approved By]. Do not delete logs to “keep it quiet.”

Review and approval

Tabletop or live-fire test at least [Review Frequency] if the company is small — even a 45-minute walkthrough counts. Policy reviewed [Review Frequency]. Effective [Effective Date].

Purpose

This policy covers how [Company Name] selects, reviews, and exits vendors that can access [Product Name] systems or customer data.

Scope

Cloud infrastructure, identity, email, support, analytics, and subprocessors listed for customers. A one-off SaaS tool with no customer data may be tracked lightly — it is still on the inventory if it can become a subprocessor.

Roles and responsibilities

[Policy Owner] keeps the inventory. The person buying the tool requests onboarding. [Approved By] signs high-risk vendors (production data, auth, backups).

Policy statements

• No new high-risk vendor without a named owner and a review.
• Risk class: high (production / customer data), medium (business data), low (no sensitive data).
• High-risk vendors: security page, SOC report or equivalent if they have one, DPA where needed — recorded, not merely bookmarked.
• Periodic review for high-risk vendors at [Review Frequency].
• Offboarding: access removed, data deletion requested where the contract requires it.

Procedures / requirements

Add the vendor to [System / Tool Name] inventory with class, owner, and data types. Store the review notes and any report PDF in the vault. On exit, revoke SSO/API keys and keep the offboarding note as evidence.

Exceptions

Emergency use of a vendor during an incident is allowed if [Policy Owner] is notified the same day and a retroactive review is completed within [Exception window].

Review and approval

Inventory reviewed [Review Frequency]. Policy effective [Effective Date], approved by [Approved By].

Purpose

This policy describes how [Company Name] changes in-scope production systems for [Product Name] so changes are reviewable, reversible, and evidenced.

Scope

Application deploys, infrastructure-as-code, identity/config changes, and other production mutations in [Production environment]. Local laptops are out of scope.

Roles and responsibilities

Author proposes. Reviewer who is not the sole author reviews (even on a two-person team: second pair of eyes or delayed self-review with a recorded exception). [Engineering lead] owns emergency changes after the fact.

Policy statements

• Standard changes go through [VCS / PR tool]: description, review, CI, merge, deploy.
• Testing happens before production when the change can break customers — automated tests and/or a staging check.
• Approval is the review + passing checks, not a separate PDF for every commit.
• Emergency changes may skip the happy path; they cannot skip the write-up.
• Rollback: previous artifact or revert PR is the default recovery.

Procedures / requirements

Keep PRs, CI logs, and deploy records in [System / Tool Name] for the audit window. For emergencies: deploy, stabilize, open a follow-up PR or ticket the same day describing why, who, and how you verified.

Exceptions

Single-engineer companies document the exception (no second reviewer available) and compensate with logging, small diffs, and post-deploy checks. That is honest. Pretending there were two reviewers is not.

Review and approval

Reviewed [Review Frequency]. Effective [Effective Date]. Approved by [Approved By].

Purpose

This policy explains how [Company Name] finds, ranks, treats, and reviews information-security risks that matter to [Product Name] and customer data.

Scope

Risks to confidentiality, integrity, and availability of in-scope systems. It is not a 400-row enterprise GRC catalog. If a risk cannot affect customers or the in-scope product, keep it out of the SOC 2 register.

Roles and responsibilities

Anyone may raise a risk. [Policy Owner] maintains the register. A named owner exists for every open item. [Approved By] accepts residual risk that will not be fully treated.

Policy statements

• Identify: new vendors, new product surfaces, incidents, pentest findings, and “we have always done it this way.”
• Assess: likelihood and impact in plain language (high / medium / low is enough if you define the words).
• Treat: mitigate, transfer, avoid, or accept — with a date.
• Acceptance is a decision recorded by [Approved By], not a missing row.
• The register lives in [System / Tool Name] and is reviewed [Review Frequency].

Procedures / requirements

Each row: description, owner, rating, treatment, due date, status. Close items when the treatment is done or the risk is gone. Keep snapshots if you replace the spreadsheet.

Exceptions

Urgent production incidents are handled under Incident Response first; a risk row is added after if the condition can recur.

Review and approval

Register reviewed [Review Frequency]. Policy effective [Effective Date], approved by [Approved By].

Purpose

This policy describes how [Company Name] keeps [Product Name] recoverable when infrastructure, a region, or a key vendor fails.

Scope

In-scope production services, data stores, and the identity path customers use to sign in. Office Wi-Fi outages are not a disaster unless they are the only way to reach production.

Roles and responsibilities

[Engineering lead] owns restore runbooks. [Policy Owner] owns this policy and test records. [Customer communications owner] updates status/[status page] when customers are affected.

Policy statements

• Critical services are listed: [API], [Database], [Auth], [Object storage].
• Backups exist for data you cannot rebuild from git. Encrypted, access-controlled, in [Backup system].
• Recovery objectives: [RTO] and [RPO] are targets for this product stage — write the numbers you can defend, not marketing numbers.
• A restore test happens at least [Review Frequency] (file restore or staging replay counts).
• Communications: internal channel first, then customers if the outage is user-visible.

Procedures / requirements

Keep the runbook next to the policy: how to fail over, who has cloud admin, where backups live. After a test or real incident, store the ticket and outcome as evidence.

Exceptions

If a dependency has no backup (a third-party SaaS), document that residual risk in the risk register instead of inventing a restore you cannot perform.

Review and approval

Test and policy reviewed [Review Frequency]. Effective [Effective Date]. Approved by [Approved By].