How to Write a Cybersecurity Policy for Your Small Business

Why Most Small Business Cybersecurity Policies Fail Before They’re Finished

A cybersecurity policy is not a document you create to pass an audit and then file in a shared drive nobody opens. That version exists at most businesses that have one. It satisfies a checkbox on a cyber insurance questionnaire, gets referenced in a compliance review, and has zero effect on how employees actually behave or how the business responds when something goes wrong.

An effective cybersecurity policy is a short, plain-English document that answers three questions every employee and every external audit will eventually ask:

What are the rules? What is expected of every person who touches business systems, data, and devices?
Who is responsible? Who decides, who enforces, and who responds when something happens?
What happens when something goes wrong? What do employees do when they spot a problem, and what does the business do when there’s a breach?

Everything else — the technical controls, the vendor agreements, the backup strategy — is infrastructure that supports the policy. The policy itself is the human layer: the set of decisions your business has made about how security works, documented so that employees can follow them, auditors can verify them, and insurers can rely on them.

This guide walks through what a cybersecurity policy for a small business should contain, what each section should actually say, and the practical approach to writing one that gets used rather than filed.

The scope of a complete small business security programme typically includes several interrelated policies. This guide covers the master information security policy and the critical sub-policies every small business needs. For a SOC 2 or ISO 27001 audit, you’ll need the full set. For a baseline programme, the master policy plus the policies in this guide is a credible starting point.

What a Cybersecurity Policy Is (and What It Isn’t)

A cybersecurity policy is a written document that defines how your business protects its information, systems, devices, and accounts from cyber threats. It explains what employees, contractors, and administrators are expected to do in day-to-day work and in specific situations like security incidents or device loss.

It is not a technical manual. It doesn’t specify which brand of antivirus to use or the exact configuration of your firewall. Those decisions live in procedures and technical runbooks, not the policy itself. The policy states the decision — all devices must have active endpoint protection — and the procedures explain how that decision is implemented.

It is not a legal document. It should be readable by any employee, not by a lawyer. Plain language is not a weakness in a security policy; it’s what makes the policy functional. A policy written in dense legalese is a policy that employees won’t read and can’t follow.

It is not a one-time exercise. A policy written in 2022 that has never been updated doesn’t reflect your current environment. Every new cloud service you adopted, every remote worker you hired, every AI tool you started using — these all create gaps between the old policy and current reality. Policies require annual review as a minimum.

Before You Write: Three Things to Do First

1. Complete a Basic Data and Systems Inventory

You cannot write an accurate security policy without knowing what you’re protecting. Before drafting anything, document:

What data does your business hold? (Customer data, employee records, financial records, intellectual property)
Where is that data stored? (Cloud services, on-premise servers, employee laptops, external drives)
What systems and tools does the business use? (CRM, email platform, accounting software, cloud storage, communication tools)
Who has access to what? (Which roles, which permissions)

This inventory takes a few hours for a small business and is the foundation of every meaningful security decision the policy will document.

2. Identify Your Highest Risks

Not all risks deserve equal attention. A cybersecurity policy for a 15-person marketing agency looks different from one for a 10-person healthcare practice. The risks that matter most in your context should drive the emphasis in your policy.

For most small businesses in 2026, the highest-priority risks are: credential theft through phishing, ransomware from a malicious email attachment or download, business email compromise (a fake invoice or payment instruction that bypasses technical controls), and data exposure through misconfigured cloud services or a departing employee with lingering access.

3. Decide Who Owns It

Someone at your business must be responsible for the policy — writing it, reviewing it, enforcing it, and updating it. For most small businesses, this is the owner, the most senior operations or IT person, or your IT provider if they manage security actively. Name this person before you write a word of the policy. A policy without a named owner is a document without a home.

The Policy Documents You Need

A complete small business security policy programme consists of a master policy and several supporting sub-policies. Each addresses a specific area in enough detail to be actionable without being a technical manual.

Master Information Security Policy: The top-level document — your organisation’s overall commitment to security, the principles it operates on, and the framework of more specific policies beneath it. Every other policy sits under this one.

Acceptable Use Policy (AUP): What employees can and cannot do with company systems, devices, and data. The policy most employees encounter first.

Access Control Policy: How access to systems and data is granted, reviewed, and revoked.

Password and Authentication Policy: Password requirements and MFA obligations.

Incident Response Policy: What to do when something goes wrong.

Data Classification and Handling Policy: How different types of data are categorised and what protection each category requires.

Remote Work and BYOD Policy: Security requirements for employees working outside the office or using personal devices.

Vendor and Third-Party Policy: Security requirements for external parties with access to your systems or data.

Backup and Recovery Policy: How data is backed up, how long it’s retained, and how recovery is verified.

Each of these can be a standalone document or a section within a single master policy document. For a small business with under 20 employees, a single document covering all areas clearly is often more practical than a set of separate policies that never get read. For a business pursuing SOC 2 or ISO 27001, separate named policy documents are expected.

Writing Each Policy Section: What to Include

Section 1: Purpose and Scope

Every policy starts with a brief statement of why it exists and who it applies to.

Purpose: This policy establishes [Business Name]’s requirements for protecting the confidentiality, integrity, and availability of information and information systems against cyber threats.

Scope: This policy applies to all employees, contractors, temporary staff, and any other individuals authorised to access [Business Name]’s systems, devices, or data. It covers all company-owned devices, approved cloud services, business accounts, remote work environments, and personal devices used for business purposes.

Keep this section short — two paragraphs is enough. The purpose should explain what the policy achieves; the scope should be unambiguous about who it covers. The common mistake is writing a scope that only covers “employees” while contractors and IT providers also have access to your systems. Make the scope match reality.

Section 2: Roles and Responsibilities

Name the people responsible for security and describe what they’re responsible for. Vague policies that say “management is responsible for security” don’t create accountability. Specific policies name who does what.

Security Owner / Policy Owner: [Name or role] is responsible for maintaining this policy, ensuring security controls are in place, and responding to security incidents. This person is the first point of contact for any security question or concern.

All Employees and Contractors: Responsible for reading and following this policy, completing security training, and promptly reporting suspected security incidents or policy violations.

IT Provider (if applicable): [Name of IT provider] is responsible for managing technical security controls including endpoint protection, patch management, and backup, in accordance with the Service Agreement and applicable policies.

For a small business, this section may be half a page. The goal is that any employee reading the policy can identify who to contact with a security concern, who is responsible for making security decisions, and what their own obligations are.

Section 3: Acceptable Use Policy

The AUP defines what employees can and cannot do with business systems and data. It is the policy most employees will read and reference in daily work.

Company equipment: Company devices are provided for business purposes. Reasonable personal use is permitted provided it does not compromise security, consume excessive bandwidth, or access prohibited content.

Prohibited activities: The following are prohibited on company systems and equipment:

Accessing, downloading, or transmitting illegal content
Installing unauthorised software without approval from [Security Owner]
Attempting to access systems or data you are not authorised to access
Sharing account credentials with others
Using company systems for personal financial gain outside your employment

Data handling: Company data must not be stored on personal devices or personal cloud accounts unless specifically authorised. Sensitive data (customer records, financial data, employee records) must be stored only in approved business systems.

Personal devices: Personal devices may be used to access business email and approved cloud services provided they meet the minimum security requirements in the Remote Work and BYOD Policy.

Social media and public communications: Do not share confidential business information, customer data, or sensitive operational information on personal social media accounts or in public forums.

The AUP should be written in language employees will actually understand and remember. Avoid legal language. “Do not install unauthorised software” is better than “End users are prohibited from installing applications not sanctioned by the Technology Governance Committee.”

Section 4: Access Control Policy

Access controls determine who can access which systems and data — and how that access is managed over the employment lifecycle.

Minimum necessary access: Employees are granted access only to the systems and data required to perform their specific job functions. Access is not granted based on seniority or convenience alone.

Account creation: New employee accounts are created by [Security Owner / IT Provider] upon commencement of employment. Accounts must be unique to each individual — shared accounts are prohibited.

Multi-factor authentication: MFA must be enabled on all accounts that access company data, including email, cloud storage, the CRM, accounting software, and any other system containing customer or financial data. MFA must not be disabled or bypassed.

Privileged access: Administrative accounts — with elevated permissions to manage systems, add users, or change security configurations — must be separate from standard user accounts and used only for administrative tasks, not for general work such as email or browsing.

Quarterly access review: [Security Owner] reviews access to all key systems quarterly, confirming that active accounts belong to current staff with appropriate roles. Any access that is no longer required is removed.

Account termination: When an employee or contractor leaves the organisation, all system access is revoked within 24 hours of their departure. A departure checklist documents all systems from which access was removed and confirms the completion date.

This section should directly reflect what you do operationally. If quarterly reviews are genuinely achievable, write quarterly. If they’re not, write a realistic cadence and hold to it. A policy that specifies monthly reviews that never happen is worse than one that specifies realistic annual reviews that do.

Section 5: Password and Authentication Policy

Password requirements: All business account passwords must:

Be at least 12 characters in length
Not be reused across multiple accounts
Not include the business name, personal names, or easily guessable information
Be stored in a company-approved password manager, not in browsers or text files

Password manager: [Business Name] provides [named password manager] for all employees. All business account credentials must be stored in the password manager. Sharing passwords through email, messaging apps, or written notes is prohibited.

MFA requirement: Multi-factor authentication must be enabled on all accounts where it is available, with no exceptions. The use of an authenticator app (rather than SMS where possible) is strongly preferred.

Password changes: Passwords must be changed immediately if compromise is suspected. Routine periodic password changes are not required where MFA is in place and the password meets the length and complexity requirements above.

Default credentials: Default passwords on any device or system (routers, software, administrative accounts) must be changed before the device or system is placed in service.

Keep this section practical. Many small businesses still require 90-day mandatory password rotations based on outdated guidance — NIST and NCSC have both updated their guidance to recommend against mandatory periodic changes in favour of longer passwords with MFA. Update your policy to match current best practice.

Section 6: Incident Response Policy

This section tells employees what to do when something goes wrong and describes the business’s response process. It is most valuable when an incident is actually happening — so it must be clear enough to follow under pressure.

What counts as a security incident: A security incident includes, but is not limited to:

A suspected phishing email (whether clicked or not)
A device that is lost or stolen
Unexpected login activity on a business account
Ransomware or malware on a device
An email sent to the wrong recipient containing sensitive data
Unauthorised access to systems or data
Any situation where you are uncertain whether a security problem has occurred

Reporting: Any suspected security incident must be reported to [Security Owner / named contact] immediately — the same day. Do not wait to investigate or confirm before reporting. Early reporting enables faster containment. Employees will not face negative consequences for reporting a suspected incident in good faith, even if it turns out to be a false alarm.

Contact: Report incidents to [email/phone of Security Owner]. For out-of-hours emergencies involving ransomware or active data compromise, contact [emergency contact details].

Initial response steps for employees:

Stop what you are doing on the affected device.
Do not attempt to resolve the situation yourself.
Contact [Security Owner] immediately.
Preserve evidence — do not delete files, emails, or messages related to the suspected incident.
Do not discuss the incident outside the organisation until advised.

Security Owner response:

Assess the nature and scope of the incident.
Isolate affected devices from the network if appropriate.
Engage the IT provider and any relevant specialists.
Determine whether breach notification is required (GDPR 72-hour notification, ICO notification, customer notification).
Document the incident, response actions, and outcome in the incident register.
Conduct a post-incident review to identify improvements.

This section should be the most specific in the policy. Employees need to know exactly who to call and what to do. The Security Owner needs a defined process to follow when something goes wrong at 10pm on a Friday. Vague guidance (“escalate appropriately”) is not a plan.

Section 7: Data Classification and Handling Policy

Not all data requires the same level of protection. A classification system lets employees make consistent decisions about how to handle different types of information without asking a question every time.

A simple three-tier classification works for most small businesses:

Confidential: Information that, if disclosed, could cause significant harm to the business, its customers, or employees. Examples: customer personal data (names, contact details, financial information), employee records, financial accounts and payment data, business contracts, intellectual property, authentication credentials.

Required handling: Stored only in approved business systems. Encrypted when stored on portable media or devices. Shared only on a need-to-know basis. Not transmitted via unencrypted email. Not stored in personal cloud accounts.

Internal: Information intended for use within the business that is not public but is not highly sensitive. Examples: internal procedures, business plans, operational communications, meeting notes, internal reports.

Required handling: Stored in business systems. Not shared publicly. May be shared between employees in the course of normal business.

Public: Information approved for external distribution. Examples: marketing materials, published pricing, public website content, press releases.

Required handling: No special restrictions. Ensure accuracy before publication.

Data retention and deletion: Data is retained only for as long as necessary for its original purpose or as required by law. [Security Owner] maintains a retention schedule identifying how long each category of data is kept and the method of secure deletion when the retention period expires.

Section 8: Remote Work and BYOD Policy

Remote work: Employees working outside the office must maintain the same security standards as in-office work. Specifically:

Use a secure home Wi-Fi connection with a strong password. Do not use public Wi-Fi for business work unless connected through a VPN.
Keep devices locked when not in use.
Position screens so that business information cannot be viewed by others in public or shared spaces.
Report device loss or theft immediately, regardless of location.

Personal devices (BYOD): Personal devices may access business email and approved cloud services provided that:

A screen lock is enabled
Full-disk encryption is enabled on the device
The operating system and applications are kept updated
The device is not shared with other household members for business purposes
The device can be remotely wiped of business data if reported lost or stolen

Personal devices must not be used to store confidential business data locally. Confidential data should be accessed through browser or app interfaces in approved cloud services, not downloaded to the device.

Section 9: Vendor and Third-Party Policy

Before granting access: Any external vendor, contractor, or service provider who requires access to company systems or data must be approved by [Security Owner]. Access is granted on a minimum-necessary basis and limited to the specific systems and data required.

Vendor agreements: All vendors who access business data must have a signed agreement in place before access is granted. The agreement must require the vendor to maintain appropriate security measures, notify the business of any security incidents, and delete business data at the end of the relationship. Where required by applicable law (GDPR, HIPAA), this must be a Data Processing Agreement.

Third-party software: New software or cloud services must be approved by [Security Owner] before business data is entered or connected. Shadow IT — employees using unapproved tools that access business data — is prohibited.

Annual vendor review: [Security Owner] reviews active vendor relationships annually to confirm that agreements are current and that access is still required and appropriate.

Section 10: Backup and Recovery Policy

Backup requirements: All business-critical data must be backed up using the 3-2-1 rule:

3 copies of the data
2 on different storage media or systems
1 copy stored off-site (either a separate physical location or a cloud backup service)

Backup frequency: Critical data (customer records, financial records, active project files) must be backed up at minimum daily. The specific backup schedule is documented in the IT Operations procedure maintained by [Security Owner / IT Provider].

Backup security: All backup copies must be encrypted. Backup media stored off-site must be kept in a secure location. Cloud backup services must have a signed Data Processing Agreement in place.

Recovery testing: Backup restoration must be tested at least annually. The test must verify that data can actually be recovered from the backup — not just that the backup process appears to be running. Test results and restoration times must be documented.

Ransomware protection: At least one backup copy must be kept in a location that is not continuously connected to the main business network or accessible with the same credentials. A ransomware attack that encrypts live data must not be able to reach and encrypt the backup simultaneously.

Section 11: Security Training and Awareness

Induction training: All new employees and contractors must complete security awareness training within their first week. Training covers phishing recognition, password hygiene, acceptable use, incident reporting, and data handling.

Annual training: All employees complete annual security refresher training. Completion is documented. Training content is updated annually to reflect current threats.

Phishing simulations: [Business Name] conducts simulated phishing tests periodically. Employees who click on simulated phishing emails are enrolled in targeted training. Results are reviewed by [Security Owner] to identify patterns and address areas of risk.

Ongoing awareness: [Security Owner] shares brief security updates with all staff when significant new threats emerge that affect the business’s risk profile.

Section 12: Policy Review and Compliance

Annual review: This policy is reviewed annually by [Security Owner] and updated to reflect changes to the business environment, new threats, regulatory changes, and lessons from any security incidents during the year.

Trigger reviews: The policy is also reviewed immediately following: a significant security incident, a major change to the IT environment, a regulatory change affecting the business, or when a new material risk is identified.

Compliance: All employees and contractors are expected to comply with this policy as a condition of their access to company systems. Violations are addressed in proportion to their severity and intent:

Unintentional violations resulting in no harm: Reminder, mandatory training, documented conversation.
Careless violations or repeated disregard: Formal disciplinary action per the employee handbook.
Intentional violations or actions causing material harm: Potential termination of employment or contract. Criminal violations referred to appropriate authorities.

Acknowledgement: All employees and contractors must sign an acknowledgement confirming they have read, understood, and agree to comply with this policy. Acknowledgements are retained for the duration of employment plus [two years / as required by applicable law].

The Policy Template: A Bare-Bones Starting Point

Below is the skeleton structure you can use to start your own policy. Fill each section with content specific to your business. Every placeholder in brackets is a decision you need to make and document.

[BUSINESS NAME] INFORMATION SECURITY POLICY

Version: [X.X] Date: [DD/MM/YYYY] Owner: [Name / Role] Next review: [DD/MM/YYYY]

1. PURPOSE AND SCOPE

This policy establishes [Business Name]’s requirements for protecting information and systems from cyber threats. It applies to all employees, contractors, and third parties authorised to access [Business Name]’s systems, devices, or data.

2. ROLES AND RESPONSIBILITIES

Security Owner: [Name/Role] — [responsibilities] Employees and Contractors: Read, follow, and report suspected violations of this policy. IT Provider: [Name] — [technical responsibility scope]

3. ACCEPTABLE USE

[What employees may and may not do with company systems and data]

4. ACCESS CONTROL

Minimum necessary access principle
Unique accounts required — no shared credentials
MFA required on all accounts with access to company data
Access revocation within 24 hours of departure
Quarterly access review

5. PASSWORD AND AUTHENTICATION

Minimum 12-character passwords
Password manager required: [Product name]
MFA required on all accounts where available
Default credentials changed before any system goes live

6. INCIDENT RESPONSE

What counts as an incident: [examples relevant to your business] How to report: Contact [Name] at [email/phone] immediately. Employee steps on suspected incident: Stop — Report — Preserve Security Owner response: [assessment → containment → notification assessment → documentation]

7. DATA CLASSIFICATION AND HANDLING

Confidential: [definition and handling requirements]
Internal: [definition and handling requirements]
Public: [definition and handling requirements]
Retention periods: [reference to retention schedule]

8. REMOTE WORK AND BYOD

[Requirements for remote work. BYOD minimum requirements: screen lock, encryption, updated OS, no local confidential data storage]

9. VENDORS AND THIRD PARTIES

[Approval process, agreement requirements, annual review]

10. BACKUP AND RECOVERY

3-2-1 rule. Daily backup of critical data. Annual restoration test. Off-network backup copy.

11. TRAINING

Induction training within first week. Annual refresher. Documented completion.

12. REVIEW AND COMPLIANCE

Annual review. Consequences for violations. Signed acknowledgement required.

Signatures and acknowledgement section here

Common Mistakes to Avoid

Writing a policy that doesn’t reflect reality. The most common policy failure. If your policy says passwords must be 16 characters but your systems only support 12, every user is automatically non-compliant. If your policy says access reviews happen monthly but you have no process to do that, the policy is documenting aspiration rather than practice. Write what you actually do and intend to do — then close the gap between the policy and practice, not the other way around.

Using a template unchanged. Generic policy templates downloaded from the internet describe a generic business, not yours. A template is a starting point. Every section needs to be reviewed against your actual systems, your actual data, your actual team structure. The business name changing is not adaptation.

Skipping the training and acknowledgement step. A policy employees haven’t read is not a policy they can follow. Require every employee and contractor to read the policy and sign an acknowledgement. Store those acknowledgements. In a breach investigation, “we have a policy and all employees acknowledged it” is significantly better than “we have a policy.”

Writing it once and forgetting it. Technology changes. Staff changes. Threats change. A cybersecurity policy from two years ago that hasn’t been reviewed doesn’t reflect your current environment — it reflects a business that no longer exists. Schedule the annual review before you finish writing the first version.

Making it too long. A 60-page policy document is a document nobody reads. Employees need to be able to find the answer to a specific question quickly. If your policy requires navigating 40 pages to find the incident reporting contact, it will be useless at 10pm when ransomware is running. Keep the core document concise. Add appendices and detailed procedures separately.

What Comes After the Policy

A cybersecurity policy documents your decisions. It doesn’t implement them. After the policy is written:

Deploy the controls. MFA on everything, a password manager, endpoint protection, patch management, tested backup, and DNS filtering are the foundational technical controls the policy should already reference. If they’re not in place, the policy is ahead of the reality. Close that gap.

Train every employee. Walk your team through the policy at the next all-hands meeting. Cover the most important sections: acceptable use, what to report, and how. Don’t just distribute a PDF. People follow rules they understand; they ignore ones they don’t.

Test the incident response process. Run a brief tabletop exercise — walk through a hypothetical ransomware scenario — and verify that everyone knows what to do, who to call, and in what order. The first time your team tests the incident response plan should not be during an actual incident.

Review annually. Set a calendar reminder now. The annual review is a one-to-two-hour exercise if you’re reviewing rather than rewriting. Add it to the schedule before you close the policy document.

Final Verdict

A cybersecurity policy is one of the few security investments that costs only time and pays back in insurance credibility, audit readiness, employee clarity, and incident resilience. Every other security investment — the firewall, the endpoint protection, the MFA — is more effective when employees understand why it’s in place and what they’re supposed to do.

The policy doesn’t have to be perfect on the first draft. It has to be honest, specific enough to be actionable, short enough that people read it, and owned by someone who will keep it current. Start with the 12 sections above. Adapt every line to reflect how your business actually operates. Get every employee to sign it. Review it in 12 months.

That process — not a perfect document — is what an effective cybersecurity policy looks like.

Frequently Asked Questions

Does a small business legally need a cybersecurity policy?

It depends on your regulatory context. Under GDPR, Article 32 requires organisations to implement appropriate technical and organisational measures to protect personal data — a written security policy is part of demonstrating those measures are in place. Under HIPAA, documented security policies are required. Under NIS2, documented risk management policies are required for covered entities. For businesses with cyber insurance, most insurers ask about written security policies and documented procedures during underwriting and claims processes. For businesses with no regulatory obligations and no insurance, there is no universal legal mandate — but the practical benefits of having a written policy (employee clarity, incident response capability, vendor credibility) exist regardless of regulatory obligation.

How long should a small business cybersecurity policy be?

For a small business with 5–50 employees, a policy covering all 12 sections in this guide should be 4–8 pages when written clearly and concisely. Shorter is generally better, provided the essential content is present. A 3-page policy that employees actually read and follow is more valuable than a 40-page document that nobody opens. If specific areas require more detail — incident response procedures, data classification examples, BYOD requirements — consider keeping the policy itself concise and adding supporting appendices.

Should I write the policy myself or hire someone?

For most small businesses, writing it yourself is the right approach — with this guide as a starting point. You know your business, your systems, your team, and your risks better than any external writer does. The policy must reflect your actual environment, and that requires your input regardless of who drafts it. Where professional help is valuable: if your business is subject to HIPAA, NIS2, or other regulated frameworks with specific policy requirements, having a compliance professional review your draft policy against those requirements before it goes live is worth the investment. If you are pursuing SOC 2 or ISO 27001, your auditor or implementation partner will typically review and advise on your policy set.

How often should a cybersecurity policy be reviewed?

At minimum, annually. Additionally following: any significant security incident, any significant change to the IT environment (new major cloud service, new remote work arrangement, new business line with new data types), any regulatory change that affects your obligations, and when the business hires significantly (policies written for a 5-person business may not reflect a 25-person business’s needs adequately). The annual review is typically a 1–2 hour exercise checking whether each section still reflects current practice. Major rewrites are needed only when the business or its environment has changed significantly.

Can I use the same policy for GDPR and HIPAA compliance?

No — the same information security policy can form part of compliance with multiple frameworks, but GDPR and HIPAA each have specific policy requirements that a generic security policy alone does not satisfy. GDPR requires a data protection framework including documented lawful bases for processing, privacy notices, data subject rights processes, and Data Processing Agreements with vendors. HIPAA requires specific administrative, physical, and technical safeguard policies including a documented Security Risk Analysis. A good information security policy covers foundational controls that support both frameworks, but must be supplemented with framework-specific documentation for each.

For free cybersecurity policy templates and resources for small businesses, see CISA’s Small Business Resources. For UK businesses, the NCSC’s Small Business Guide provides practical free guidance on all elements covered in this article.

Related reading on SmallBiz Defense: