Governance
The SOC 2 policy library is maintained with policy owners, effective dates, approval authority, publication, review cadence, exception handling, and evidence of approval.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Security and compliance policies remain approved, current, available to the right people, and traceable through changes, exceptions, and periodic reviews.
First SOC 2 program
Use one controlled document repository, name an owner and approver on every policy, and maintain a simple review calendar. The founder or security lead should approve changes in writing and keep prior versions rather than replacing them without history.
As the company scales
Move policy inventory, review reminders, approval workflows, personnel communication, and exception tracking into coordinated systems, with change triggers for new products, regulations, incidents, and material technology changes.
List each policy, its purpose, owner, approver, audience, effective date, current version, and next review date in one authoritative index.
You should end up with: A policy register that links to every current approved document.
Place the owner, approver, version, effective date, review cadence, and change history in each policy and restrict who can alter approved content.
You should end up with: Versioned policies with complete ownership and approval metadata.
Ask the policy owner to compare documented requirements with actual processes, recent incidents, risk decisions, system changes, and current customer commitments.
You should end up with: Review notes showing what was considered and whether changes were needed.
Route material revisions to the designated authority, record approval before the effective date, publish the approved version, and archive the superseded version.
You should end up with: A dated approval record, current published policy, and retrievable prior version.
Notify affected personnel of changes and collect acknowledgment or training completion when the change alters their responsibilities.
You should end up with: A distribution record and, where appropriate, completion records tied to the changed version.
Require policy deviations to state scope, reason, risk, compensating measures, approver, owner, and expiration, then review them before expiry.
You should end up with: An exception register linked to approval and closure or renewal records.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The policy set in force is complete, accessible, formally approved, and identifies the owners, scope, requirements, and effective versions management expects teams to follow.
Include this context
policy title and identifier
Include this context
owner and approver
Include this context
current version
Include this context
effective date
Include this context
next review date
Include this context
approved document link
Weak evidence to avoid
A folder of policy files with inconsistent names and no authoritative index showing which versions are current, approved, or due for review.
Confirm what the record proves
Policy changes are traceable over time and prior requirements can be reconstructed for the dates on which they applied.
Include this context
policy identifier
Include this context
old and new version
Include this context
change date
Include this context
change summary
Include this context
editor and approver
Weak evidence to avoid
A current policy with a footer reading version 3.0 but no preserved earlier versions or record of what changed and who authorized it.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Each policy owner periodically compared documented requirements with current risks, systems, processes, incidents, and commitments and recorded the review result.
Include this context
policy identifier and version
Include this context
review date
Include this context
reviewer
Include this context
inputs or changes considered
Include this context
change-needed decision
Include this context
next review date
Weak evidence to avoid
A bulk status update marking every policy reviewed on December 31 with no named reviewers, inputs considered, or policy-specific decision.
Confirm what the record proves
The designated authority approved the exact policy version before it became effective or was republished.
Include this context
policy identifier
Include this context
version approved
Include this context
approver and authority
Include this context
approval timestamp
Include this context
effective date
Weak evidence to avoid
A chat reaction from a security team member that does not identify the policy version, approval authority, or effective date.
Confirm what the record proves
Known departures from policy requirements are scoped, risk-assessed, approved, time-bounded, monitored, and closed or renewed deliberately.
Include this context
exception identifier and policy requirement
Include this context
scope and business reason
Include this context
risk and compensating measures
Include this context
owner and approver
Include this context
start and expiration dates
Include this context
status and closure evidence
Weak evidence to avoid
A ticket allowing a policy bypass until further notice with no affected requirement, risk analysis, compensating measure, expiration, or accountable approver.
Type 1
The authoritative policy index, all current approved policies, document-control settings, current open exception register, and a recent policy approval trail as of the examination date.
Type 2
Every policy scheduled for periodic review, newly issued, materially revised, retired, or granted an exception during the review period, including policies whose review concluded with no change.
Reconcile policies in the repository to the authoritative index, compare scheduled review dates with completed review records, and trace every policy exception ticket to the central exception register and approval history.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Security and compliance policies remain approved, current, available to the right people, and traceable through changes, exceptions, and periodic reviews.
Compare the documented owner with the intended role (CISO / Security Compliance Owner), then compare dated records with the stated cadence: At least annually and upon material change.
Reconcile policies in the repository to the authoritative index, compare scheduled review dates with completed review records, and trace every policy exception ticket to the central exception register and approval history.
The authoritative policy index, all current approved policies, document-control settings, current open exception register, and a recent policy approval trail as of the examination date.
Every policy scheduled for periodic review, newly issued, materially revised, retired, or granted an exception during the review period, including policies whose review concluded with no change.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The policy set in force is complete, accessible, formally approved, and identifies the owners, scope, requirements, and effective versions management expects teams to follow.
For each selected record, confirm it demonstrates Policy changes are traceable over time and prior requirements can be reconstructed for the dates on which they applied.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Each policy owner periodically compared documented requirements with current risks, systems, processes, incidents, and commitments and recorded the review result.
For each selected record, confirm it demonstrates The designated authority approved the exact policy version before it became effective or was republished.
For each selected record, confirm it demonstrates Known departures from policy requirements are scoped, risk-assessed, approved, time-bounded, monitored, and closed or renewed deliberately.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.