What cyber security policies should a small business have?

A small business needs a documented set of cyber security policies that turns broad security expectations into specific, repeatable rules. The policies should reflect the organisation’s systems, information, legal obligations, suppliers and working practices, rather than copying a generic template. A practical policy framework normally includes the following documents and supporting procedures.

1. Information security policy

This is the top-level document. It should state the organisation’s security objectives, the types of information it must protect and the responsibilities of directors, managers, employees, contractors and IT providers. It should also explain how security decisions are approved, how breaches of policy are handled and where staff can report a concern.

The policy should define its scope clearly. For example, it may apply to company-owned devices, personally owned devices used for work, cloud services, paper records, offices, home working locations and third parties handling company information. A named owner should be responsible for maintaining it, with a recorded approval date and review date.

2. Acceptable use policy

This sets boundaries for using company technology and information. It should cover business email, internet access, messaging platforms, cloud storage, removable media, software installation and the use of personal accounts for work. It should make clear that users must not bypass security controls, share accounts, access inappropriate material using business systems or install unapproved applications.

The policy should address practical situations rather than relying on general wording. It can specify whether staff may use work devices for limited personal activity, whether company data may be copied to personal storage and what users must do when a device is shared with another person.

3. Identity and access control policy

This policy should define how access is granted, changed and removed. Access should be based on a person’s role and limited to the information and systems needed for their duties. It should cover joiners, movers and leavers, temporary access, administrator accounts, privileged actions and periodic reviews of user permissions.

Where multi-factor authentication is available, the policy should state which accounts and services must use it, how authentication devices are protected and what process applies if a user loses a device or cannot complete authentication. Shared accounts should be prohibited or tightly controlled because they make individual accountability difficult.

4. Data handling and classification policy

Not all information requires the same safeguards. A classification policy can separate public, internal, confidential and highly sensitive information, with handling rules for each category. The rules should cover storage, transmission, printing, disposal and access. Examples might include customer records, financial information, employee data, intellectual property, credentials and contractual documents.

The policy should also define retention and deletion requirements. Keeping information indefinitely increases the amount available to an attacker and can create unnecessary compliance obligations. Retention periods should be based on business need, contracts and applicable law, with secure disposal methods for both electronic and physical records.

5. Device and software security policy

This document should set the minimum standard for laptops, desktops, mobiles, servers and other devices. It can cover supported operating systems, security updates, anti-malware controls, screen locking, encryption, approved software, local administrator rights and the use of removable storage.

It should explain what happens when equipment is lost, stolen, damaged or transferred to another user. A disposal process should ensure that company information is removed securely before a device is sold, recycled or returned to a supplier.

6. Email, messaging and phishing policy

Staff should have clear rules for handling unexpected attachments, links, payment requests, confidential information and messages that appear to come from senior colleagues or suppliers. The policy should require users to verify unusual requests through a trusted channel and provide a simple route for reporting suspicious messages.

Technical controls such as email filtering and sender authentication support this policy, but they do not replace it. The document should explain that a user must report a suspected mistake promptly, without attempting to conceal it or delete potential evidence.

7. Remote working and mobile access policy

This policy should cover work performed from home, customer premises, public locations and while travelling. It should address the security of wireless networks, private conversations, screen visibility, printing, device storage and the use of public computers. It should also state when access through an approved secure connection is required and prohibit the transfer of business information to unauthorised personal services.

Physical security matters as much as technical configuration. Staff should know how to prevent unauthorised people from viewing screens or overhearing calls, and what to do if a device is left unattended or lost.

8. Backup and recovery policy

A backup policy should identify which systems and data are backed up, where copies are held, how access to backups is restricted and how restoration is tested. Backups should be protected from unauthorised alteration, including the risk that an attacker could reach them through compromised administrator credentials.

The policy should distinguish between backing up data and restoring business services. It should record who can authorise recovery, which systems have priority and how restoration results are documented. Testing is essential because an untested backup cannot be treated as a dependable recovery control.

9. Incident response policy

This policy should define what counts as a security incident and set out the route from initial report to investigation, containment, recovery and review. Examples include suspected account compromise, ransomware, lost equipment, accidental disclosure, malicious software and unusual financial activity.

It should assign decision-making responsibilities and identify who may need to be informed, such as senior management, insurers, legal advisers, affected customers, regulators or law enforcement. The policy should preserve relevant logs and other evidence, record decisions and include a method for assessing whether notification duties apply. A separate response plan can provide detailed playbooks for particular scenarios.

10. Vulnerability, patching and change policy

Systems should be kept within their supported lifecycle, with security updates assessed and applied through a controlled process. The policy should explain how vulnerabilities are identified, prioritised and tracked, including who may accept a risk temporarily and how that decision is recorded.

Changes to firewalls, cloud settings, applications and infrastructure should be authorised, tested where appropriate and documented. Emergency changes may need a faster route, but they should still be recorded and reviewed afterwards. This reduces the risk that an urgent fix creates a new weakness or leaves the environment in an unknown state.

11. Supplier and third-party access policy

Suppliers that access systems or process information should be assessed before access is provided. Contracts should address confidentiality, security responsibilities, access restrictions, incident notification, data handling, subcontractors and the secure return or deletion of information when the relationship ends.

Third-party accounts should be named where possible, limited to the required systems and disabled when no longer needed. Reviews should consider whether the supplier’s access remains necessary and whether the service has changed in a way that introduces additional risk.

12. Security awareness policy

This should define the security knowledge expected from staff and the points at which training is provided, such as during induction, after a role change or following a significant incident. Training should cover phishing, password and authentication safety, data handling, device security, reporting routes and the consequences of ignoring controls.

Policies only work when people can understand and follow them. Each document should use plain language, identify the required behaviour, explain exceptions and link to a practical procedure where more detail is needed.

How to manage the policy set

Keep policies separate from technical procedures. A policy states what must happen and who is accountable; a procedure explains how the requirement is carried out; a standard defines the minimum technical configuration. This structure makes it easier to update a process without rewriting the whole policy.

Every document should have an owner, version number, approval record, effective date and review date. Reviews should also be triggered by a major system change, new supplier, serious incident, change in legal requirements or a significant change in the organisation’s risk profile. Evidence such as access reviews, backup tests, training records, patch reports and incident logs helps demonstrate that the written policy is being applied.

For a small business, a concise and actively maintained policy set is more useful than a large library that nobody reads. The essential test is whether a member of staff can use each document to make the correct decision, whether management can see who is accountable and whether the business can produce evidence that its controls are operating as intended.