SOC 2 acceptable use policy, minus the filler

Most of a downloaded acceptable use policy is unenforceable decoration. Four clauses in it are real controls, and those are the ones worth arguing about internally.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

An auditor tests four things in your acceptable use policy: that it exists, that every employee and contractor acknowledged it with a date, that its device requirements match what your endpoint management actually enforces, and that it says what happens when someone breaks it. The rest of the document, and in a typical template that is 80% of it, is never sampled. Write those four properly and keep the rest to a page.

This is the policy small companies spend the least time on and the one that most often contains promises nobody checked. It is the only policy in the set that governs people rather than systems, so the wording has to survive Canadian employment and privacy law rather than being lifted from a US handbook.

Which clauses are real and which are filler?

Acknowledgement is the clause that fails audits, not the content. A perfect policy with 34 of 41 people signed is an exception; a plain policy with 41 of 41 is a passed control. The evidence collection page covers what a defensible acknowledgement record looks like when you are tracking it in a spreadsheet rather than a platform.

What to delete from the template

Take a red pen to the downloaded version before anyone approves it. These sections cost you either credibility or a finding.

• Anything about the corporate network, VPN concentrators or office wiring if your staff work from home against cloud services. A policy describing a network you do not have makes an auditor wonder what else is aspirational.
• Blanket monitoring language. "The company monitors all employee communications and internet activity at all times" is a claim you probably cannot support, and in Canada it invites a conversation you do not want. Say what you actually log, which is usually system and application access, and say it plainly.
• Prohibited-content lists running to twenty bullets about gambling, streaming and chain letters. They read as filler and none of it is tested.
• US-specific legal references. A Canadian company citing US federal statutes in its handbook is copying, and reviewers notice.
• Software installation bans you do not enforce. If engineers have local administrator rights, do not write that installation requires IT approval. Write the control you have, which may be an inventory and a review rather than a block.

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.

Where Canadian law changes the wording

Two places, both in the monitoring and personal-use sections. Employee personal information is personal information: in federally regulated workplaces PIPEDA applies to it directly, in Quebec Law 25 applies to it regardless of sector, and Alberta and British Columbia have their own private sector statutes covering employee data. The practical consequence is that surveillance-flavoured clauses need a purpose you can state, and Ontario employers over a threshold have a separate statutory duty to have a written electronic monitoring policy at all. Say what is collected, why, and who sees it.

The second place is the personal-use clause. A flat prohibition on personal use of company devices is unusual in Canadian practice and is generally ignored, which makes it worse than a permissive clause with limits. Write that incidental personal use is permitted, that it must not put company data at risk, and that anything stored on the device may be visible during troubleshooting. Law 25's confidentiality-by-default expectation is easier to meet when the boundary is written honestly than when a rule everyone breaks sits in the file.

Does your draft contain these clauses?

0 of 8 done · Reset

• Scope names contractors and anyone holding a company account, not only employees.
• Device requirements match the settings your endpoint management actually enforces.
• A decision on personal devices, either way, in one sentence.
• Named password manager and a ban on credentials in code or chat.
• Rules on where customer data may be copied, naming real tools.
• A monitoring statement that describes only what you genuinely log.
• A consequences sentence consistent with your employment agreements.
• An acknowledgement mechanism producing a timestamp per person, at hire and annually.

What gets an acceptable use policy turned into a finding?

Three things, in order of how often they happen.

First, incomplete acknowledgement. The auditor takes your full employee and contractor list for the window, samples from it, and asks for the signature and date. A contractor who started in month two and never received the policy produces an exception even though the policy itself is fine. Wire the acknowledgement into onboarding so it cannot be missed.

Second, a device clause that the device inventory contradicts. If the policy requires full disk encryption and your inventory export shows three machines without it, you have handed over the evidence of your own gap. Fix the fleet first, then approve the policy, and never in the other order.

Third, a monitoring or restriction clause that an employee interview contradicts. Auditors do talk to staff. When the policy bans personal cloud storage and an engineer casually mentions the shared personal drive the team uses for design files, that is a control operating ineffectively, which is worse than not having claimed it. The policy templates page makes the same point about the pack as a whole, and the policy checklist will tell you whether your acceptable use content should be a standalone document at all or folded into a broader information security policy.

Common questions