Information security policy for SOC 2

What a SOC 2 information security policy must do before the auditor arrives

When a customer or contract now asks for SOC 2 and the policy set is thin or missing, the first job is the information security policy. It is a management-owned document that sets expectations for security, assigns authorities and accountability, and gives the rest of the control set something to point back to. Under the 2017 Trust Services Criteria, the control environment criteria in CC1 to CC5 expect that policies exist and are approved, and CC5.3 is the anchor: the organization deploys control activities through policies that set expectations and procedures that carry them out. Your leadership team owns the policy, approves it and must be able to show that it was reviewed. An implementation partner can help draft it, map its statements to the criteria and prepare the evidence of approval, but the organization still decides what the company commits to. Only the independent CPA firm issues the SOC 2 report.

Before the auditor arrives, the policy has to do four things in plain language. It must set standards of conduct and say how adherence is evaluated and how deviations are addressed, which maps to the CC1.1 points of focus. It must name roles, reporting lines and the authorities each role holds, including who may accept risk and who may approve exceptions, which maps to CC1.3. It must describe how risks are identified and how threats from vendors and business partners are considered, which maps to CC3.2. And it must state how security information reaches staff and the board, including how incidents are reported, which maps to CC2.2. Confirm with your auditor how they want these mapped before drafting, because the mapping is a judgment about your environment, not a fixed template.

The policy's cost is mainly internal time: leaders reviewing scope and authorities, the security owner drafting, and HR and legal checking employment terms. Expect the length and detail to depend on your scope and headcount. A small team may need a few pages, while a company with several products and subservice organizations will need more cross-references. Ask any partner for a written scope covering the number of policies, review rounds, approval evidence and whether they will align the text to your actual tools and owners. Keep the policy short enough that people follow it, and make sure every statement in it can be shown to be true in the review period.

Sections a short SOC 2 security policy should contain

This part states what every person with access to the system must do and must not do. An auditor looks for a clear, approved expectation that applies to employees, contractors and vendor staff, plus evidence that people acknowledged it. This supports CC1.1, which covers setting the tone at the top, establishing standards of conduct, and addressing deviations in a timely manner. The policy should name the principles (protect customer data, use approved devices and accounts, report suspected incidents) and point to the detailed policies for how to comply.

Scope of people: state that the rules apply to employees, contractors and vendor personnel with system access.
Core expectations: a short list of duties, such as protecting credentials and reporting suspected incidents.
Consequences: a statement that deviations lead to a defined response, without listing disciplinary steps in detail.
Acknowledgment: a requirement that each person accepts the policy at hire and when it changes.
Pointers: links to the access, acceptable use and incident response policies.

Leave out tool configuration, password lengths and step-by-step procedures. Confirm with your auditor how they want acknowledgment records kept and sampled.

Who owns, approves and enforces the policy

A SOC 2 auditor reads the information security policy to see who is accountable for it, not only what it says. The cards below set out five roles that connect approval, maintenance, daily use, enforcement and third-party compliance. Each role needs a named person and a documented authority before the auditor's walkthrough.

Board or executive sponsor

The board or a named executive approves the information security policy and receives reports on how it is working. This is the oversight element that CC1.2 looks for, so the approval should appear in board minutes or a signed record with a date. Check that the sponsor has enough standing to direct the security owner and fund the controls the policy requires. An approval by someone with no authority over the security function will weaken the policy in the auditor's eyes.

CISO or security owner

The CISO or security owner maintains the policy, decides when it changes, and tracks exceptions. Write the name into the policy and state how often the owner reviews it. Confirm that the owner has time for this work and can escalate to the sponsor without going through the people whose work they oversee. Where the organization is small, a fractional or part-time security lead can hold the role, but the appointment still has to be written down.

Department heads who apply it

Department heads turn the policy into day-to-day practice for their teams, such as approving access requests, scheduling training and confirming that leavers are removed. The policy should state which decisions each head makes and which must go to the security owner. Auditors often ask a department head to explain how a rule works in practice, so each head should be able to describe it without reading the document aloud.

HR and disciplinary process

HR owns the consequences when someone breaks the policy. CC1.5 looks for accountability through defined authorities and performance measures, so the policy should point to a disciplinary procedure that HR operates and records. Confirm that HR keeps a record of acknowledgements, warnings and outcomes, and that the process applies the same way to senior staff and new hires. Without this link, the standards of conduct have no enforcement behind them.

Contractors and vendor staff

Contractors and vendor employees with access to systems or data must follow the same policy, or an equivalent one they have agreed to. CC1.1 includes considering contractors and vendor employees when setting standards of conduct. Check that contracts reference the policy, that contractors sign an acknowledgement before access is granted, and that the organization can show which outside parties were covered during the audit period.

How to draft the policy in order

The sequence turns a blank page into an approved, published and acknowledged policy whose scope, roles and risk references trace back to the system description the auditor will read.

Confirm scope and system boundaries first
Start from the draft system description so the policy covers the same services, infrastructure, data and people that the examination will describe. Record which Trust Services Criteria categories are in scope: security is always included, and availability, processing integrity, confidentiality or privacy are added only when the organization chooses them. Confirm the boundary with the system owner and the auditor's expectations before writing. The output is a short scope statement that names the system, the categories and the excluded components, which every later section refers back to.
Draft roles, responsibilities and authorities
Name the people or roles accountable for information security, for each policy area and for exceptions, and state what each may approve or stop. Keep the structure consistent with the reporting lines in the organization chart, and include the board or executive body that oversees security if one exists. This section draws on the CC1.3 points of focus on reporting lines and on defining, assigning and limiting authorities. The output is a roles table that a reader can check against an org chart, with the owner of the policy named explicitly.
Reference the risk assessment process
Write a short section that points to the organization's risk assessment method and its owner, and states how often risks are reviewed and how changes to systems, vendors or threats trigger a review. The policy does not need the register itself, but it must show that risk identification and analysis are performed, consistent with the CC3.2 points of focus on identifying threats, vulnerabilities and third-party risks. The output is a reference to a dated risk assessment record, which the auditor will request later as evidence.
Write conduct and communication expectations
Set out the standards of conduct that apply to employees, contractors and relevant vendor staff, and describe how staff report incidents, raise security concerns and receive security awareness information. This step responds to the CC2.2 points of focus on communicating responsibilities, incident reporting methods and system changes, and to the CC1.1 expectation that deviations are addressed in a timely manner. Keep each expectation to one testable sentence. The output is a conduct section and a reporting channel that staff can name without looking it up.
Approve the policy through the named authority
Route the draft to the authority named in the roles section, usually an executive or board-level owner, and record the approval with a version number, an effective date and the approver's name. Changes made during review should be tracked so the approved text is the one that was in force. The output is an approved policy version held in a controlled location, with the approval record kept alongside it. Confirm with the auditor whether they expect board minutes or a signed approval page, because the form differs between organizations.
Publish and collect staff acknowledgements
Publish the approved version where employees and contractors can find it, and require each person in scope to acknowledge that they have read and understood it. Use the identity provider, learning platform or document system to capture the date, the person and the policy version, so the acknowledgement record can be sampled. Track who has not acknowledged and follow up through the owner. The output is a dated acknowledgement register that matches the current version and the in-scope population.
Schedule the periodic review
Set the review frequency and the triggers for an unscheduled review, such as a significant system change, a new service commitment or a security incident. Assign the reviewer, and record each review even when no text changes, so the auditor can see that the policy was evaluated over the examination period. The output is a review schedule and a log of completed reviews, which feeds the Type 2 evidence set when the policy must operate across a period.

Why a shorter policy gets followed

An auditor tests what the organization does, not what the policy says it does, so every sentence in the information security policy is a promise that someone must keep for the whole examination period. A long document full of specific tool settings, approval thresholds and review cadences creates exceptions the moment one of those details drifts from practice. Each exception is a finding the team must explain, and a policy nobody applies is worse than a short one everybody follows. The practical rule is to write the top-level policy as principles, roles and references, then push the specifics into standards and procedures that have a named owner and a stated evidence source.

Move detail out of the policy and into documents that a control owner can maintain. For example, a statement that access is reviewed periodically belongs in the policy, but the reviewer list, the review frequency, the export of group memberships and the removal tickets belong in the access review procedure. Before any sentence goes into the policy, ask the owner what record would prove it happened during the period. If no record exists or the owner cannot name one, rewrite the sentence until it describes something that can be shown, or remove it. This also keeps the policy stable, because tool changes and process improvements then update a procedure rather than triggering a formal policy revision.

Test the finished policy against what happens in your environment, not against a generic template bought online. Walk through each principle with the people who run the controls and ask whether they recognize it in their daily work. Confirm with your chosen auditor which documents they expect to read first and how they plan to sample the period, since the review dates, approval records and version history of each document will be checked against actual operation. The question to answer before fieldwork is simple: can every commitment in the policy be traced to a named owner and a record from the examination period?

Policy mistakes that cause exceptions in the report

A SOC 2 auditor tests whether the policies describe the system that actually runs and whether people follow them. The four mistakes below look like paperwork problems, but each one tends to surface as an exception when the auditor compares the written policy with the evidence from the observation period.

Generic vendor template

A policy copied from a template often names systems, tools and data flows the company does not use, and omits the ones it does. The auditor compares the policy with the system description and the control matrix, so every mismatch is a finding waiting to happen. Rewrite the scope section around your actual production environment, hosting accounts, identity provider and data stores. Check each policy statement against a real system or record you can show. Evidence that this is resolved: a version-controlled policy with an approval history, and a system description that names the same components.

Roles nobody holds

Policies often assign duties to a Chief Information Security Officer, a risk committee or a security owner who was never appointed or who has left. Under CC1.3, the policy should define authorities and reporting lines that match the people actually doing the work. Confirm each named role with a current appointment record, a job description or a board or management minute. Where the company is small, state which person covers several roles and who backs them up. Evidence that this is resolved: a dated role assignment that matches the org chart and the access review reviewers.

Review cycles the team skips

A policy that says it is reviewed annually but shows no review record since its last revision is an easy exception to find. Auditors test whether the stated review frequency was followed during the period, not whether the team intended to follow it. Choose a review interval the owner can realistically meet, put it on a shared calendar, and record each review with a reviewer, a date and any changes made. Avoid promising reviews more often than the team can sustain. Evidence that this is resolved: a revision history showing each scheduled review completed on time, even when the outcome is no change.

Missing acknowledgement records

Most SOC 2 programs require staff to acknowledge the information security policy when they join and when it changes, and contractors often fall outside that routine. Auditors sample new hires and contractors from the period and ask for the signed or electronically recorded acknowledgement. A missing record for one sampled person can become an exception, so the joiner process should not finish until acknowledgement is captured. Check contractor agreements too, since they need to reference the same policy. Evidence that this is resolved: an acknowledgement log that covers every sampled joiner and contractor, with dates that fall before or near their first access.

Questions buyers ask about the SOC 2 security policy

Does SOC 2 require one information security policy or several separate policies?

SOC 2 does not prescribe a number of documents. The criteria ask for policies that set expectations and procedures that carry them out, so one top-level information security policy can work alongside supporting policies for access, change, incident response, vendor management and retention. Most auditors read the information security policy first because it states the standards of conduct, roles and authorities that the rest of the control set depends on. The practical test is whether every control in your control matrix traces back to a written rule that someone owns. Confirm with your CPA firm how it expects the policy set to be organized before you draft, since some firms ask to see specific documents by name.

Who has to sign the SOC 2 information security policy?

The policy should be approved by someone with authority over the system, usually the CEO, a board-level sponsor or the executive accountable for security, and the approval should be dated and recorded. Auditors look for evidence that management endorsed the policy and that the people who must follow it have acknowledged it. Acknowledgment is commonly collected from employees and, where contractors work on the system, from them as well. Ask your CPA firm whether it expects board approval, how it wants acknowledgments recorded, and whether the sign-off must be visible in your document system during the examination period.

How much internal time does drafting the policy take, and what drives it?

No researched figure exists for drafting time, so treat any number you hear with caution. The effort depends mainly on how many systems and teams the policy must cover, how much of your environment is already documented, and how many people must review the draft. Teams with an existing engineering handbook, a defined asset inventory and named system owners usually move faster than teams drafting roles from scratch. Expect iteration with legal, engineering leadership and the executive approver. Before committing time, ask your auditor or consultant what a complete draft must include and which items they will test against it, and confirm whether the policy will be reviewed before fieldwork begins.

Can a consultant write the SOC 2 security policy for us?

Yes, a consultant or implementation partner can draft the policy, map it to the Trust Services Criteria and prepare the supporting evidence. The organization still owns the policy: the statements must describe how your business actually operates, and management must approve and enforce them. A consultant cannot make the policy binding, decide your risk appetite on your behalf, or issue the assessment itself. Only the independent CPA firm performs the examination and issues the report. A useful split is that the consultant drafts and the executives review, challenge and sign. If you use DeployOpen for this work, the scope and deliverables are agreed in writing before work starts, and the report still comes from your auditor.

How often does the SOC 2 information security policy need to be reviewed?

SOC 2 does not set a fixed review interval in the criteria summarized here, so the answer depends on your own commitments and your auditor's expectations. Most organizations schedule an annual review and also update the policy after significant changes such as a new system, a new subservice provider, a material incident or a change in regulatory obligations. The auditor will look for a documented review, the date it happened, who performed it and what changed. Because a Type 2 report covers an observation period, a policy that changes mid-period needs a clear record of when each version took effect. Confirm the review cadence and version-control expectations with your CPA firm early.

Does a written information security policy alone satisfy CC5.3?

No. CC5.3 restates COSO Principle 12, which expects the organization to deploy control activities through policies that set expectations and procedures that carry them out. A policy supplies the expectation, but the auditor also needs the procedures and the records showing they run. For example, a policy requiring access reviews is only supported when review tickets, reviewer sign-offs and removal records exist for the period. Auditors commonly test whether each policy statement has a matching control, an owner and evidence. Use your control matrix to confirm that every policy commitment links to something that can be observed, and ask your CPA firm which procedures it expects to see alongside the policy.

Checks before hiring help with the policy

A partner can draft a policy quickly, but the policy has to fit your system, your team and the auditor's reading of it. The four checks below test whether outside help will produce a policy your organization owns and can defend in an examination.

Confirm the CPA firm's view

Ask the CPA firm that will examine you how it expects the policy set to look before anyone drafts a word. Ask whether it wants one top-level information security policy or several, which criteria it will sample against, and how it treats policies that reference separate standards. Get the answer in writing. A policy drafted to one firm's expectations can fail review at another, so this check prevents a rewrite after fieldwork has started.

Ask for criteria-mapped examples

Ask the partner to show how it links policy statements to criteria such as CC1.1, CC1.3 and CC3.2, using a past engagement with names and client details removed. A credible partner can explain why a roles section supports the authority points of focus under CC1.3 and why a risk statement references vendor threats under CC3.2. If the examples look like a generic template with a logo changed, expect the policy to read well and fail when the auditor asks how a specific sentence is tested.

Confirm the partner won't attest

Confirm in the statement of work that the partner prepares the policy and its supporting evidence but does not sign, approve on management's behalf or attest to the policy's adequacy. Under the attestation framework, management is responsible for its assertions and the independent service auditor issues the opinion. Management should approve and own the policy in its own name. A partner that offers to sign off on the document or promises a result has taken on a role the auditor must keep independent.

Ask who keeps the document

Ask who holds the master copy, who can approve changes, and how the policy is reviewed after handover. Name a document owner inside your organization, set a review date, and record approvals in your own repository, not in the partner's drafting tool. Confirm what happens to edit rights and archived versions when the engagement ends. If the policy lives only in a consultant's account, the team may not be able to show an approval history at the next audit period.

How DeployOpen prepares policy and evidence for the audit

DeployOpen works on the information security policy as part of the wider control set the SOC 2 examination tests. We help the organization decide what the policy must say, how it connects to the criteria in scope, and how the team will show it is followed. The organization owns the policy and its approval, and an independent CPA firm decides whether the controls meet the criteria.

How we scope

We confirm which Trust Services Criteria categories are in scope before drafting any policy text.
We map the systems, teams, contractors and vendors the information security policy must govern.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We draft the policy around roles, authorities, standards of conduct and risk communication, in plain language.
We link each policy statement to the control activities and owners that carry it out in your environment.
We review the draft with your leadership so the stated accountabilities match how the business actually runs.

How we hand over

We deliver the approved policy with a short control matrix showing which criteria each statement supports.
We document the review cycle, approval record and version history the auditor will ask to see.
We walk your owners through the evidence each policy statement produces, so the team knows what to keep.

How we support

Ongoing support is available as a retainer for policy updates after platform, vendor or structure changes.
We can prepare the policy set for the next review period so the records stay consistent across the audit window.
Questions about the auditor's evidence requests can be routed to us, while the CPA firm makes its own determinations.

Writing an information security policy for SOC 2