SOC 2 policy templates

Purpose

Sets the objectives of the security programme, who owns it and how the other policies hang together.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• [Company] maintains an information security programme owned by [role], who reports on it to [leadership body] at least [annually].
• All staff and contractors must read and accept this policy and the policies listed in [appendix] on joining and [annually].
• Exceptions to any security policy are approved by [role], recorded, and expire after [period].

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC1.1, CC1.3, CC2.2, CC5.3.

Purpose

Who gets access to what, how it is approved, how it is reviewed and how it ends.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Access is granted on least privilege, by role, after approval by [system owner or manager].
• Multi-factor authentication is required for [all systems in scope / production, cloud consoles, source control and email].
• Access is removed within [N hours or days] of a leave date or role change.
• System owners review user access to [in-scope systems] every [quarter] and record the result.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC6.1, CC6.2, CC6.3.

Purpose

What staff may and may not do with company systems, devices and data.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Company devices must have [disk encryption, screen lock after N minutes, endpoint protection] enabled.
• Customer data may only be stored in [approved systems] and never on personal devices or accounts.
• Suspected security incidents and lost devices are reported to [channel] immediately.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC1.1, CC2.2.

Purpose

Keeping an inventory of systems and devices, with an owner for each.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• [Role] maintains an inventory of [devices, cloud resources and applications] in scope, reconciled every [period].
• Each asset has a named owner responsible for its security.
• Retired devices and media are wiped or destroyed, and the disposal is recorded.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC6.1, CC6.5.

Purpose

How changes to code, infrastructure and configuration reach production.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Every production change is reviewed and approved by someone other than its author before release.
• Automated tests run before merge; the main branch is protected so the review cannot be bypassed.
• Emergency changes may skip prior approval only if approved by [role] within [N days] after release.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC8.1.

Purpose

How risks to the service are identified, rated and treated.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• [Role] runs a risk assessment over the system in scope at least [annually] and after significant change.
• Each risk is rated for likelihood and impact using [method], and has an owner and a treatment decision.
• The assessment includes fraud and misuse scenarios and risks from vendors.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC3.1, CC3.2, CC3.3, CC3.4, CC9.1.

Purpose

Assessing vendors before onboarding and reviewing the critical ones over time.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• [Role] keeps an inventory of vendors with the data and systems each one can reach.
• Vendors are tiered by risk; [critical and high] vendors are assessed before onboarding and reviewed every [year].
• Contracts with vendors that handle customer data include [security, confidentiality and breach notification terms].

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC9.2.

Purpose

Detecting, handling, communicating and learning from security incidents.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Security events are classified using [severity criteria]; incidents are handled under the incident response plan owned by [role].
• Affected customers are notified within [timeframe or contractual commitment].
• The plan is tested at least [annually], and every significant incident gets a post-incident review.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC7.3, CC7.4, CC7.5, CC2.3.

Purpose

Keeping the service running, and restoring it after a failure.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Recovery objectives for the service are [RTO] and [RPO].
• Backups of [in-scope data stores] run every [period] and failures alert [team].
• Restores and the recovery plan are tested every [period], and the results are recorded.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC7.5, CC9.1, A1.2, A1.3.

Purpose

Labelling data by sensitivity, and keeping it only as long as needed.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Data is classified as [public, internal, confidential, restricted] and handled according to [handling standard].
• Customer data is retained for [period or contract term] and deleted within [N days] of contract end or a valid request.
• Deletion and disposal are recorded.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: C1.1, C1.2, CC6.5.

Purpose

Protecting data with encryption, and controlling the keys.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Customer data is encrypted at rest using [standard] and in transit using [TLS version or later].
• Encryption keys are managed in [key management service]; access is limited to [roles] and reviewed every [period].

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC6.1, CC6.7.

Purpose

Screening, training and accountability for the people who run the system.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Candidates are screened according to [screening standard] where the law allows, before access is granted.
• Everyone completes security awareness training on joining and [annually].
• Breaches of security policy are handled through the disciplinary process.

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC1.4, CC1.5, CC2.2.

Purpose

Finding weaknesses and suspicious activity, and fixing them on time.

Scope

This policy applies to [all employees and contractors] and to [the systems and data in scope of the SOC 2 report].

Policy

• Audit logging is enabled on [in-scope systems] and retained for [period].
• Alerts for [defined events] are routed to [team] and triaged within [timeframe].
• Vulnerabilities are remediated within [critical: N days, high: N days, medium: N days]; a penetration test runs every [year].

Criteria supported

For your own mapping; remove before publishing internally.

SOC 2: CC4.1, CC7.1, CC7.2.