Information Security Policy for a Small Business: Outline and Examples

Start with this core set, and add more only when a customer, regulator or auditor asks:

• Information security policy. The umbrella: purpose, ownership and how the others fit.
• Acceptable use. What employees may and may not do with company devices and accounts.
• Access control. Who gets access, how it's approved, reviewed and removed.
• Data classification and handling. Which data is sensitive and how to store, share and delete it.
• Incident response. What counts as an incident, who leads and when customers are told.
• Change management. How code and infrastructure changes are reviewed and approved.
• Vendor management. How you evaluate suppliers that handle your data.
• Backup and recovery. What is backed up, how often and how restores are tested.

A compliance platform such as Vanta or Drata may include starter policy sets (confirm in a demo), but edit each one until it describes your business.

Use one structure so policies are easy to write and audit:

1. Purpose. One or two sentences on why the policy exists.
2. Scope. Which people, systems and data it covers.
3. Roles. Who owns it and who carries out each duty.
4. Requirements. The actual rules, written as short statements you can check.
5. Exceptions. How to request one, who approves it and how it's recorded.
6. Enforcement. What happens when the policy isn't followed.
7. Review. How often it's reviewed and the date of the last review.

The requirements section carries the value. Each line should be something an auditor could test: 'Access is reviewed every quarter and the review is recorded' beats 'Access is managed appropriately.'

These sample statements show the right level of specificity. Change them to match your reality before adopting any of them:

• All employees sign in to company systems with single sign-on and multi-factor authentication.
• Company laptops use full-disk encryption and lock after a short period of inactivity. Whether you also need endpoint detection is covered in does a small business need EDR.
• Access to production is limited to named engineers, and each grant has an approved ticket.
• Access is removed from every system on an employee's last day.
• Customer data isn't copied to personal devices or used in development environments.
• Production changes require a reviewed pull request and passing automated checks.

For vulnerabilities, set your own deadlines by severity. As a reference point, CISA's federal directives required agencies to fix critical vulnerabilities on internet-facing systems within 15 days¹, so choose numbers your team can meet and record them in the policy.

Policies decay when nobody reads them. Make them part of normal operations:

• Assign one owner per policy, with a review date on the calendar.
• Require acknowledgment when someone joins and after material changes.
• Link each requirement to a system setting or task, such as an identity provider rule or a recurring ticket.
• Test them. Run a tabletop exercise for the incident policy and try a restore for the backup policy.
• Log exceptions so you can see which rules the team keeps breaking. Frequent exceptions mean the rule is wrong or the tooling is missing.

This is how the same documents support customers' security questionnaires and a later audit, since your answers can point directly to policy language.

Some circumstances add policy content. If you handle patient information, your risk analysis and safeguards need to reflect health-privacy rules, so ask a qualified adviser to review them. If engineers use AI coding tools, add rules about what code and data may be shared with them; the AI coding assistant policy template covers that. If you run on-call rotations, tie the incident policy to the on-call schedule.

For legal obligations such as breach notification, employment law or industry rules, have an attorney review the relevant sections. Policies are a working document, not a legal opinion, and requirements differ by jurisdiction and industry.