Most small business "IT security policies" I have read fall into two categories. Either they are a 40-page Word doc copy-pasted from a 2012 SANS template that nobody has opened since the auditor left, or they are an email from the founder that says "please use strong passwords, thanks." Neither one survives a real incident, and neither one is what an insurance underwriter or a B2B customer is actually asking for when they say "send us your security policy."
A useful policy for a 10 to 200 person company is short, specific, and matches what you actually do. If your policy says "all production access requires hardware tokens" and your CFO logs into QuickBooks Online with a six-character password, you have created legal liability for yourself, not security.
Start with what you are protecting and from whom
One paragraph. What data do you handle (customer PII, payment data, PHI, source code, board minutes)? What regulatory regimes touch you (HIPAA, PCI DSS, state privacy laws, your customers' DPA clauses)? Who realistically wants this data (commodity ransomware crews, business email compromise actors, the occasional nosy ex-employee)?
If you cannot answer those questions in plain English, the rest of the policy is decoration.
The sections that actually matter
Skip the philosophy. Write the things people will reference when something goes wrong:
- Acceptable use. What devices are allowed to touch company data. BYOD or company-issued. Whether personal Dropbox accounts are a fireable offense (they should be).
- Access control. Who provisions accounts, who revokes them, and the SLA for offboarding. The day someone is fired, their M365 and VPN should die before they leave the parking lot. Most SMBs take three to ten days. That gap is where a lot of bad things happen.
- Authentication. Phishing-resistant MFA required for email, finance systems, and any admin role. Password manager mandated (1Password Business or Bitwarden). No shared logins, ever. Yes, even for the social media account.
- Data classification. Two or three tiers is plenty. Public, Internal, Confidential. Tell people which one customer data falls into and what they are allowed to do with each.
- Incident response. Who do you call at 11 p.m. on a Saturday when the file server starts encrypting itself? Phone numbers, not just email addresses. Your cyber insurance carrier's hotline goes here too.
- Vendor and SaaS approval. Anything new that processes company data goes through a one-page review. Otherwise Shadow IT is your security program.
- Backups and recovery. What is backed up, where, immutability requirements, and how often you test restores. "We have backups" is not a recovery plan.
Things to leave out
Generic "we comply with all applicable laws" boilerplate. Aspirational controls you are not actually doing. Anything you copied from a template without reading. An auditor will flag this faster than you think, and a lawyer will use it against you in discovery.
Make it living, not laminated
Review annually, plus any time you adopt a major new system. The third call I get every January is from a CFO whose policy still references the on-prem Exchange server they retired in 2022. If you adopt Slack, the policy needs a Slack section. If you start using AI tools, the policy needs to say something about what data employees can paste into ChatGPT (the answer is usually "less than they currently do").
Get the doc signed by every employee at hire and again whenever it materially changes. Keep the signed copies. Boring, but it is the difference between a policy that protects you and a policy that just exists.
If you want a starting template that is not a 40-page monstrosity, Syncritech keeps a short, edit-it-in-an-afternoon version we share with SMB clients.
