SOC 2 Policies and Procedures: What You Need and How to Document Them

Policies are the backbone of a SOC 2 control environment. Controls cannot be tested without them. If a control is not documented in a written policy or procedure, CertPro CPA LLC cannot test whether it operated as designed — because there is no documented design to test against.

SOC 2 policies and procedures are not a compliance checkbox. They are the operational specifications of the control environment — the written descriptions of what the organization commits to doing, who is responsible for doing it, how often it must be done, and what constitutes acceptable performance. Every SOC 2 exception that CertPro CPA LLC documents in Section 4 of the SOC 2 report traces back to either a policy gap or a failure to operate in accordance with a documented policy.

This guide from CertPro CPA LLC explains exactly which policies the AICPA’s Trust Services Criteria require, what each policy must contain to support a successful examination, and how to build a policy programme that remains current through annual SOC 2 renewal cycles.

Tl; DR:

Concern: With SOC 2 readiness assessment findings consistently identifying policy documentation as one of the most common gaps, service organizations find it hard to understand which specific policies are required, what each policy must contain, and how auditors assess policy adequacy during the formal examination.
Overview: SOC 2 policies and procedures are the documented governance framework that describes how a service organization’s controls operate — and that CertPro CPA LLC tests for existence, accuracy, completeness, and currency during every SOC 2 audit conducted under AICPA AT-C Section 205.
Solution: Service organizations should understand which policies the Common Criteria and applicable Trust Services Criteria require, what each policy must contain to be testable, how to structure a policy programme that supports annual SOC 2 renewal, and how policy gaps become exceptions in the SOC 2 report.

SOC 2 Policies and Procedures: What You Need and How to Document Them

Policies and procedures form the documentary spine of a SOC 2 control environment. They define what controls exist, how they operate, and who is accountable — and CertPro CPA LLC tests them directly during fieldwork, reviewing them for existence, accuracy, completeness, approval, and currency.

What Makes a SOC 2 Policy Testable

Not every policy document satisfies SOC 2 requirements. CertPro CPA LLC tests policies against four criteria during fieldwork:

Existence — does the policy exist as a formal, written document?

Accuracy — does the policy accurately describe how the control actually operates? A policy that describes a quarterly access review process where the actual process is annual is inaccurate — and the discrepancy is a finding.

Approval and ownership — has the policy been formally approved by an authorized owner, and is that approval documented with a date? Policies without documented approval lack the governance evidence required by the Common Criteria (CC5.3).

Currency — has the policy been reviewed within the required period? Most SOC 2 engagements require annual policy reviews. A policy last reviewed three years ago does not meet the currency requirement regardless of how accurate its content is.

Information Security Policy

Required by: CC1 (Control Environment), CC5 (Control Activities)

The information security policy is the master document that establishes the organization’s overall commitment to security, defines the security governance structure, and sets the framework within which all other security policies operate. It is the first document CertPro CPA LLC reviews and the one whose absence or inadequacy has the broadest impact on the examination.

Required contents: Statement of leadership commitment to information security; scope of the policy — which systems, data, and personnel it covers; information security objectives and principles; roles and responsibilities for information security governance; policy review frequency and ownership; consequences for policy violations; and reference to supporting policies and procedures.

Common gaps: Missing ownership, not reviewed in the past twelve months, scope that does not align with the SOC 2 system description, or absence of explicit leadership sign-off.

Access Management Policy

Required by: CC6 (Logical and Physical Access Controls)

The access management policy defines how access to in-scope systems is provisioned, maintained, reviewed, and removed — and is the foundation of the most commonly tested CC6 controls.

Required contents: Access provisioning process — how access requests are submitted, approved, and implemented; least privilege principle — explicit statement that users receive only the access required for their job function; privileged access requirements — additional controls for administrator and privileged accounts; access review schedule — frequency (typically quarterly) and process; deprovisioning timeline — specific deadlines for removing access following termination; password and authentication requirements — minimum password standards, MFA requirements; and remote access controls.

Common gaps: Deprovisioning timelines not specified, access review frequency not defined, no distinction between standard and privileged access requirements. Gaps in this policy directly produce access review and deprovisioning exceptions — see Common SOC 2 Audit Exceptions.

Change Management Policy

Required by: CC8 (Change Management)

The change management policy defines the process for managing all changes to in-scope systems — ensuring that changes are approved before implementation, tested before deployment to production, and documented in the change management system.

Required contents: Definition of what constitutes a change requiring formal management (including infrastructure changes, configuration changes, and emergency fixes); change request and approval process — who can approve changes and at what level of authority; testing requirements before production deployment; emergency change process — expedited approval path with retroactive documentation requirements; change documentation requirements; and prohibited changes requiring additional approval.

Common gaps: No definition of what constitutes a change (leading to uncontrolled informal changes), no emergency change process, testing requirements not specified, or documentation requirements too vague to produce testable evidence.

Incident Response Policy

Required by: CC7 (System Operations — Incident Response)

The incident response policy defines how the organization detects, classifies, responds to, and recovers from security incidents — and how post-incident reviews are conducted to prevent recurrence.

Required contents: Definition of a security incident — broad enough to capture all relevant events; incident classification — severity levels with defined response timelines; incident response team — roles and responsibilities; detection and reporting process; response steps — containment, eradication, recovery, and communication; post-incident review requirements; breach notification requirements — legal and contractual notification obligations and timelines; and incident logging requirements.

Common gaps: Definition of “incident” too narrow (capturing only security breaches but not availability or integrity events), no post-incident review requirement, breach notification obligations not specified, or logging requirements not defined.

Risk Assessment Policy

Required by: CC3 (Risk Assessment)

The risk assessment policy defines how the organization identifies, analyzes, and responds to risks that could affect the security of the in-scope system.

Required contents: Risk assessment methodology — how risks are identified, scored, and prioritized; risk assessment frequency — how often the full risk assessment is conducted (typically annually, with updates triggered by significant changes); risk treatment options — accept, mitigate, transfer, or avoid; risk acceptance process — who can accept identified risks, under what conditions, and with what documentation; risk register management — who maintains the risk register and how it is updated; and integration with change management — how risk assessment updates are triggered by system changes.

Common gaps: No formal methodology, risk register not updated during the observation period, no defined risk acceptance process, or risk assessment outputs not connected to the control environment.

Vendor Management Policy

Required by: CC9 (Risk Mitigation — Vendor Management)

The vendor management policy defines how the organization assesses, onboards, monitors, and offboards third-party vendors that perform functions relevant to the in-scope system.

Required contents: Vendor inventory requirements — maintaining a current list of all relevant vendors with risk classifications; vendor onboarding assessment process — what security review is required before a new vendor is approved; periodic re-assessment requirements — how often existing vendor assessments must be renewed; vendor security requirements — minimum security standards required of vendors handling in-scope data; contractual requirements — security and data protection clauses required in vendor contracts; vendor offboarding process; and subservice organization identification — process for identifying and documenting vendors that are subservice organizations for SOC 2 purposes.

Common gaps: No periodic re-assessment requirement (assessments conducted only at onboarding), no vendor inventory, security requirements not specified in vendor contracts, or subservice organizations not identified.

Business Continuity and Disaster Recovery Policy

Required by: CC9 (Risk Mitigation — Business Continuity)

The business continuity and disaster recovery (BCDR) policy defines how the organization maintains or rapidly restores in-scope services following a significant disruption.

Required contents: Recovery objectives — Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each in-scope service; business continuity plan — procedures for maintaining operations during a disruption; disaster recovery plan — procedures for restoring systems and services following a complete failure; BCDR testing requirements — frequency and format of testing; BCDR team roles and responsibilities; communication procedures during a disruption — internal and customer-facing; and plan review and update frequency.

Common gaps: RTO and RPO not defined, testing not conducted or not documented, plan not updated to reflect current infrastructure, or no customer communication procedures.

Security Awareness Training Policy

Required by: CC1 (Commitment to Competence)

The security awareness training policy defines the organization’s programme for ensuring that all personnel with access to in-scope systems understand their security responsibilities and the threats relevant to their roles.

Required contents: Training programme scope — which personnel are required to complete training; training frequency — how often training must be completed (typically annually); new hire training requirements — timeline for completing onboarding security training; training content requirements — topics that must be covered (phishing awareness, password security, data handling, incident reporting); training completion tracking — how completion is recorded and monitored; and consequences for non-completion.

Common gaps: No completion deadline for new hires, completion tracking not producing testable records, content requirements not specified, or no consequences for non-completion.

Physical Security Policy

Required by: CC6 (Logical and Physical Access Controls — CC6.4)

The physical security policy defines how access to facilities containing in-scope systems is controlled, monitored, and reviewed.

Required contents: Physical access control mechanisms — badge access systems, visitor management, data center access procedures; visitor management requirements — registration, escorting, and logging of visitors to secure areas; physical access review requirements — frequency of reviews of physical access rights; secure area designation — which areas require physical access controls and at what security level; and physical security incident reporting.

Common gaps: No visitor log maintained, physical access reviews not conducted, secure areas not formally designated in the policy.

How to Structure a SOC 2 Policy Programme

The most sustainable SOC 2 policy programme is one that integrates policy management into the organization’s operational rhythm — not one that treats policy review as a pre-audit activity conducted once a year under pressure.

Version control — every policy must have a version number, an effective date, and a revision history. This allows CertPro CPA LLC to verify that the policy in place during the observation period was the approved version in effect at the relevant time.

Annual review cycle — build policy reviews into the compliance calendar, assign owners to each policy, and track review completion. Policies not reviewed during the observation period are a finding regardless of their content.

Ownership assignment — every policy must have a named owner who is responsible for its content, its accuracy, and its annual review. Ownerless policies are not maintained.

Communication records — policies must be communicated to the personnel responsible for operating the controls they describe. Maintain communication records — acknowledgment signatures, training completion records, or distribution logs — as evidence that personnel are aware of their policy obligations.

Alignment with operations — review policies against actual practice whenever significant operational changes occur — new systems, new products, personnel changes, or infrastructure migrations. A policy that accurately described operations twelve months ago but does not reflect current practice generates exceptions, not clean evidence.

Begin Your SOC 2 Policy Development with CertPro CPA LLC

CertPro CPA LLC is a licensed CPA firm that conducts SOC 2 examinations under AICPA AT-C Section 205. Our readiness assessment process reviews your existing policy documentation against all applicable Trust Services Criteria requirements — identifying gaps and providing specific guidance on what each policy must contain to support a clean examination outcome.

Explore the full SOC 2 hub for detailed guidance on every aspect of the SOC 2 process.

Ready to begin? Contact CertPro CPA LLC to scope your SOC 2 engagement.

FAQ