Cyber Security Policy for Small Businesses

An SME cybersecurity policy that people can use

A cybersecurity policy states the rules, responsibilities and decisions needed to protect the business. It should be short enough to use and specific enough to guide action. Supporting procedures explain how staff and suppliers carry out those rules.

Start with the business services, information and accounts you rely on. A small organisation using cloud services still needs to decide who approves access, manages suppliers, checks recovery and responds when something goes wrong.

Reviewed: 26 October 2026.

Start with a small, usable risk assessment

1. List the business services and information that would cause harm if unavailable, altered or disclosed. Include outsourced services, staff devices and the accounts needed to administer them.
2. Identify credible failure or attack scenarios: an email account taken over, an unpatched remote service, a lost laptop, a supplier outage or an unauthorised payment. Record existing protections and known weaknesses.
3. Discuss likely business consequences and exposure with the service owner. Use a consistent rating method, but keep the reasoning visible instead of relying only on a numerical score.
4. Choose a proportionate response and an accountable owner. Decide what must be prevented, what needs early detection and what must be recoverable.
5. Carry those decisions into rules, procedures and the improvement plan. Review them when the business, technology or supplier changes.

Illustrative risk record: “If the shared finance mailbox is taken over, an attacker could redirect supplier payments. Finance owns the payment process; IT owns account protection. Actions: individual accountable access, suitable MFA, independent bank-detail verification and a rehearsed account-compromise response. Evidence: a simulated supplier change and a tested revocation of access.”

This is more useful than a generic instruction to “be secure”: the team knows the risk, the control, the owner and the check. Where specialist, contractual or legal requirements apply, map them explicitly rather than treating the example as a substitute.

Use a simple policy structure

Use direct language: “Report a lost work device to [role/channel] immediately” is more useful than “Users should maintain cyber vigilance”. Replace placeholders with routes staff can actually reach.

Cover the minimum practical topics

Add requirements specific to your work, such as development, customer data, payment processing or physical premises. Do not include rules nobody can implement or monitor.

Example clause: account access

Illustrative wording to adapt: “Access to company services must be approved by the service owner and limited to the user’s role. Administrators must use separate privileged accounts. The IT owner must remove access when employment or the business need ends. Exceptions require recorded approval, safeguards and an expiry date.”

The supporting procedure should then identify the request form, approver, IT action, completion check and emergency route. For a leaver, include cloud accounts, shared credentials, devices, API keys and supplier access where relevant.

This example is a starting point, not evidence of compliance. The final rule must match your environment, obligations and ability to operate it.

Make the five policy pillars practical

1. Baseline technical protection

Define who inventories assets, selects secure defaults, approves software and maintains updates, firewall rules and malware protection. The procedure should describe how failures are found and resolved, including a device that has been offline or a supplier-managed system. Refer to the applicable Cyber Essentials guidance where that scheme is being adopted, while keeping broader business controls in the policy.

2. Access control and information handling

Specify who approves account creation, role changes, administrator access and removal. Cover remote working, personal devices, shared information and service-provider access. Explain where business data may be stored and how it should be shared or deleted. Keep emergency access available through a controlled procedure rather than an undocumented shared password.

3. Incident response and recovery

Name a lead and deputy, a trusted reporting route and the people who may authorise containment or business disruption. Keep essential contacts accessible if normal email or the office is unavailable. The first procedure should tell staff how to report a suspected incident, record relevant facts and avoid making uncoordinated changes.

Prepare procedures for technical investigation, supplier coordination, evidence protection, communications and service recovery. Assign assessment of legal, contractual and insurance notification duties to the appropriate people. Exercise a plausible scenario and record decisions that cannot currently be made quickly.

4. Review, audit and evidence

Create a proportionate review schedule tied to risks and obligations. Sample whether approved access changes happened, updates completed, alerts were handled and restores worked. A small firm may use a simple action register and provider reports; it does not automatically need an enterprise governance platform or a dedicated monitoring centre.

Have someone with sufficient independence challenge important conclusions. Track the corrective action, owner and evidence of completion. Repeatedly accepting the same expired exception is a signal to revisit the underlying constraint.

5. Role-specific learning and reporting

Explain decisions through real tasks: finance verifies changed bank details, HR handles recruitment information, administrators protect privileged access and everyone knows how to report. Include induction and brief refreshers after relevant changes. Make instructions accessible to remote and temporary staff.

Measure whether people can use the procedure and receive timely help. Use feedback and supportive exercises to improve it. Staff acknowledgement or training attendance alone does not show that the organisation can prevent, detect or recover from an incident.

Turn approval into everyday practice

1. Ask service owners and staff where unclear decisions currently cause risk or delays.
2. Draft the core rules and link concise procedures; avoid copying a large enterprise manual wholesale.
3. Have management approve responsibilities and resources, not just the wording.
4. Explain role-specific actions using examples and make the current version easy to find.
5. Configure technical controls and confirm supplier responsibilities so compliance does not depend entirely on memory.
6. Sample real records and scenarios to check that the process works.

Manage exceptions without losing control

An exception should state the affected service, reason, risk, alternative safeguards, accountable approver and review or expiry date. Escalate exceptions that conflict with a legal, contractual or certification requirement; internal acceptance does not remove that obligation.

For example, if an essential application cannot yet be updated, record the migration owner and plan, restrict access where appropriate and review the remaining exposure. Do not let “temporary” become an indefinite undocumented default.

Maintain a small exception register and review expired or repeatedly renewed items with management.

Check understanding and effectiveness

Review after incidents, significant changes and at a planned interval suitable for the business. Keep a version history and retire superseded copies. Avoid judging effectiveness solely by staff signing that they have read the document.

Keep a small operational pack behind the policy

Keep the pack in an approved, access-controlled location and retain an appropriate way to reach essential response information during an outage. Remove superseded versions. Ask your IT provider to demonstrate its part of the procedure; a contract saying “security included” is not enough to establish who performs each action.

Common questions

How long should the policy be?

As long as needed to state meaningful rules clearly. Keep detailed technical settings and step-by-step instructions in linked procedures so the main document remains usable.

Can our IT provider own the policy?

The provider can help implement controls, but your management remains responsible for business decisions, risk acceptance and supplier oversight.

Does a template make us compliant?

No. Tailor it, implement the controls and retain evidence. Certification and legal obligations have their own scope and requirements.

Useful supporting guidance

Cyber Essentials technical baseline · Independent verification of risky requests · Prioritising improvements

Use NCSC’s Small Business Guide for practical baseline actions. A policy-development engagement should leave your team with owned rules, procedures and a way to check implementation.

Discuss policy ownership and implementation support.