SOC 2 policy templates, and how to edit them

A template set is a structure, not a policy. The work is not finding one, it is editing it down to what your company will actually do before an auditor tests every promise in it.

Last reviewed 2026-08-27Written by Jacob Masse, TrazTech Inc.

SOC 2 policy templates are freely available and most of them are adequate as a starting structure. Free sets come with compliance platforms and from a few open sources, and paid packs from Canadian consultancies run roughly $1,000 to $6,000 CAD. None of that is the hard part. The hard part is that every commitment in a policy becomes a control your auditor tests, so an unedited template is a list of promises somebody else made on your behalf.

Four of the policies auditors reject most often have their own page, with what each must contain and the wording that fails review: access control, acceptable use, risk assessment and secure development.

If you are not sure which documents you need in the first place, the policy checklist works that out from your criteria and the data you hold.

Where the sets come from

The two ends of that table produce the best outcomes and the middle produces the most audits with self-inflicted exceptions. A set written for you is accurate because somebody asked how you work. A set you wrote is accurate for the same reason. A set you downloaded and skimmed is accurate about nothing in particular.

What actually goes wrong with a downloaded set

Cadences nobody will keep. Templates default to quarterly access reviews, annual penetration tests, monthly vulnerability scans and annual training. Every one of those is now a control, and a company that manages two access reviews a year against a policy promising four has produced an exception in its own report. Set the cadence you will keep and raise it deliberately once the habit exists.

Roles that do not exist. A template referring to the security team, the change advisory board, the data protection officer and the asset owner describes a company of four hundred people. In a company of thirty, name real roles. An auditor asking who performs the quarterly review needs a person, and a policy pointing at a committee that has never met is a finding waiting to be found.

Systems you do not run. Physical security sections written for a data centre, network segmentation for hardware you do not own, and asset tagging for laptops nobody tags. If the control is genuinely not applicable, say so in the system description rather than keeping the paragraph.

American law. Published sets reference United States breach notification, and a Canadian company inherits obligations they do not describe. PIPEDA requires reporting breaches that create a real risk of significant harm and keeping a record of every breach for 24 months whether reportable or not. Quebec's Law 25 requires a person in charge of the protection of personal information by title and a privacy impact assessment before certain projects. Neither appears in an American template, and neither is discharged by a clean SOC 2 report. The full Quebec picture, including the seven documents Law 25 asks for that SOC 2 never mentions, is on SOC 2 and Law 25.

No approval and no acknowledgement. A document with no version, no approver and no date is not testable, so it cannot pass. This is the most common defect and the cheapest to fix.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

The edit pass, in order

Budget a day per five documents for a first pass. Work in this order, because the first two decisions change wording throughout the rest. Tick items off as you go: the state is kept in this browser on this device, and printing the page gives you empty boxes to tick by hand.

0 of 6 done · Reset this list

• Fix the cadences first. Go through every document and find every frequency. Change each one to what you will actually do. Write them into a single list as you go, because that list becomes your calendar of periodic controls and your evidence schedule.
• Replace every role with a real one. Job title or name, and if the same person holds four roles, say so. Small companies concentrate roles and auditors know it. What they cannot accept is a role nobody fills.
• Delete what does not apply, and record why. Removal beats keeping a paragraph you will fail. Keep a short note of what you removed and the reason, because your auditor will ask why physical security is absent, and the answer that you have no premises is a complete answer.
• Add the Canadian obligations. The breach record, the notification duties, the accountability role under PIPEDA, and if Quebec personal information is in scope, the Law 25 items. If you hold health information for a clinic or hospital, read the agreement with the custodian first, because your obligations there come from it as much as from the statute.
• Reconcile against reality. Read each finished document beside what your systems do. Where they disagree, either change the system or change the document. Doing neither is the state most first-time companies are in on the day the audit starts.
• Approve and acknowledge. Version number, approver and approval date on every document. Then a timestamped acknowledgement from every person, and a recurring calendar entry for the review your policy commits you to.

Per document, what has to be true before fieldwork

Run this list against each finished document rather than against the set.

0 of 7 done · Reset this list

• Version number on the document itself, not only in a file name.
• Named approver, by role or by person, and the date they approved it.
• Every frequency in the text matches an entry on somebody's calendar.
• Every role named in the text is held by a person who knows they hold it.
• Timestamped acknowledgement from every current employee and contractor.
• An acknowledgement step inside onboarding, so new hires are covered without anyone remembering.
• A dated annual review entry, at the cadence the document itself commits to.

How many documents, and combining them

SOC 2 requires no specific number of policies, because it publishes criteria and your auditor judges whether your documents address them. A first audit against the security criterion usually lands at ten to fourteen documents, and a small team is better off combining aggressively into five or six. Every separate file is a separate approval, a separate version history and a separate annual review to evidence, and an auditor has no preference either way.

What fails is missing a topic entirely. The three that go missing most often are vendor management, data classification and retention, and risk assessment, because they are the topics a company under fifty people has never been asked about before.

Getting a set that fits your scope

The policy checklist tool builds your document list from the criteria in scope, the data you hold and how you run the product, and separates the SOC 2 documents from the ones Canadian law requires on top. It gives you the list and what each document has to contain on screen. If you want the drafting notes as well, clause by clause and with the commitments to avoid making, that is the one thing it asks for an address before sending.

Once the policies are drafted, the readiness scorecard covers whether the controls behind them are actually running, which is the question the policies cannot answer.

Common questions