Policies and procedures required by ISO 27001: a practical guide for UK SMEs

If you are trying to build an ISO 27001-aligned information security management system, the first question is usually not about technology. It is about paperwork, ownership, and how much effort the business will need to keep things running.

For many UK SMEs, the real risk is not that they lack a policy document. It is that they have too many documents, too little clarity, and no practical way to keep them current. That creates wasted time, confused staff, and weak control over the things that matter most, such as access to systems, handling incidents, and working with suppliers.

This guide explains the policies, procedures, and records that are usually needed, in plain English. It is written for business owners and managers who want a sensible, proportionate approach rather than a pile of templates.

What people usually mean by ISO 27001 policies and procedures

The difference between a policy, a procedure, and a record

A policy sets the rule or expectation. It says what the business intends to do and why. A procedure explains how people should carry out that rule in day-to-day work. A record is the evidence that something happened, such as a training log, an incident report, or a backup test result.

For example, your policy might say that staff access must be removed promptly when someone leaves. The procedure explains who tells IT, who approves the change, and how quickly it must happen. The record shows that the account was actually closed.

Why small businesses do not need to overcomplicate the paperwork

ISO 27001 is not asking small businesses to behave like large enterprises. It is asking for a system that is clear, consistent, and suitable for the risks you face. If a document does not help staff make better decisions or help managers check that work is being done properly, it is probably too complicated.

That is why a short, well-used policy is usually better than a long one that nobody reads. The aim is control, not volume.

What ISO 27001 is trying to achieve

How an information security management system supports business risk control

An information security management system is the organised way a business manages information security. In practice, that means deciding what information matters, what could go wrong, what controls are needed, and how the business will keep those controls working.

For an SME, this is about reducing avoidable disruption. Good policies and procedures help prevent common problems such as unauthorised access, lost data, slow incident response, and supplier failures. They also make it easier to show customers and partners that security is managed rather than left to chance.

Why the standard focuses on consistency, accountability, and improvement

One-off actions are rarely enough. A business may lock down access after a scare, but if there is no policy or procedure behind that action, the improvement often fades. ISO 27001 is built around repeatable practice. It expects the business to define responsibilities, follow agreed steps, and review whether those steps still work.

That is why documentation matters. Not because paperwork is the goal, but because clear documents make consistent behaviour possible.

The core policies most SMEs should expect to have

Information security policy

This is the top-level policy. It states the business’s commitment to protecting information and sets the overall direction. It should be short, clear, and signed off by senior management.

It normally covers:

• What the business is trying to protect
• Why information security matters to the business
• Who is responsible for managing it
• How the policy is reviewed

Access control policy

This policy explains who can access systems and data, and under what conditions. It should cover staff, contractors, and any third parties who need access.

For SMEs, the main point is to make sure access is given only when needed, reviewed regularly, and removed promptly when no longer required. Weak access control is one of the fastest ways for a small business to lose control of sensitive information.

Acceptable use policy

This policy tells staff what they may and may not do with company devices, accounts, and data. It should be practical rather than punitive.

It often includes rules on:

• Using company devices for work only, or for limited personal use
• Not sharing passwords
• Not installing unapproved software
• Handling email, messaging, and removable media carefully

Incident response policy

This policy explains how the business will identify, report, assess, and respond to security incidents. It should be understandable to non-specialists, because the first person to spot a problem is often not in IT.

It should make clear what counts as an incident, who must be informed, and what the business will do first. If you want a deeper view of the practical steps involved, our article on preparing your organisation for security incidents is a useful companion.

Backup and recovery policy

This policy sets expectations for how important data is backed up, how often backups are taken, where they are stored, and how recovery is checked. A backup that has never been tested is only an assumption.

For SMEs, the policy should reflect what the business can realistically restore within an acceptable time. If a system is critical to trading, the policy should say so clearly.

Supplier and third-party security policy

Most SMEs rely on suppliers for cloud services, payroll, software support, payment processing, or outsourced IT. That means your security depends partly on how those suppliers behave.

This policy should explain how suppliers are assessed before use, what security expectations are included in contracts or service terms, and how supplier performance is reviewed over time. If this is a major concern in your business, our guide to third-party cyber risk assessments for SMEs may help you shape a sensible process.

The procedures that usually sit behind those policies

Joiner, mover, and leaver process for staff access

This is the process for giving access to new starters, changing access when someone changes role, and removing access when they leave. It is one of the most important procedures in a small business.

A good process should answer:

• Who requests the change
• Who approves it
• Who carries it out
• How quickly it must happen
• How the business checks it was done

Without this process, access often lingers long after it is needed, which increases the chance of misuse or accidental exposure.

How incidents are reported and handled

The procedure behind the incident response policy should be simple enough for staff to follow under pressure. It should tell people where to report a phishing email, a lost laptop, a suspicious login, or a system outage that may have a security cause.

It should also define the basic response steps: contain the issue, preserve useful evidence, assess the impact, decide who needs to know, and record what happened. For a practical overview of how businesses can organise this, see our article on incident response fundamentals for SMEs.

How backups are tested and restored

Backups are only useful if they can be restored. The procedure should say how often restore tests are done, who performs them, what is tested, and how failures are recorded and fixed.

For many SMEs, a simple monthly or quarterly restore test on a small but meaningful sample of data is enough to prove the process works. The key is to test the kind of recovery the business would actually need in a real incident.

How changes are approved and recorded

Change control does not have to be bureaucratic. It simply means that important changes to systems, configurations, or suppliers are reviewed before they are made, so the business understands the impact.

The procedure should cover who can approve changes, what counts as a significant change, and how emergency changes are handled. This helps avoid accidental outages, broken controls, and undocumented risk.

How suppliers are reviewed before and during the relationship

A supplier review procedure should explain how the business checks a supplier before onboarding, what evidence is requested, and how often the supplier is reviewed afterwards.

For example, you may decide to review a supplier’s security questionnaire, contract terms, incident notification commitments, and service performance. The level of checking should match the risk. A payroll provider deserves more scrutiny than a low-risk office supply service.

Documents that are often needed to make the system work

Risk assessment and risk treatment records

These records show what could go wrong, how serious it would be, and what the business has decided to do about it. They are central to an ISO 27001-aligned approach because they connect the paperwork to real business risk.

If you want a plain-English explanation of this part of the system, our article on risk assessment and treatment under ISO 27001 is a good place to start.

Statement of Applicability explained in plain English

The Statement of Applicability is a document that lists the security controls the business has chosen to use, and explains why. It also notes any controls that are not used and why that decision was made.

For SMEs, this document should be understandable to management, not just security specialists. It is essentially the bridge between your risks and the controls you have chosen. We have a separate Statement of Applicability walkthrough for first-time implementers if you want more detail.

Training and awareness records

Policies only work if people know they exist and understand what they mean. Training records show that staff have been briefed on the rules that matter to them, such as password handling, phishing awareness, incident reporting, and data handling.

You do not need elaborate training programmes. You do need a way to show that people have been told what is expected and that refresher training happens when needed.

Internal audit records and management review notes

These records show that the business checks whether the system is working and that senior leaders review the results. They are important because they turn security from a one-time project into an ongoing management activity.

Our article on internal audits under ISO 27001 explains what SMEs should look at, while our guide to continuous improvement and management review in an ISMS covers how to keep the system moving in the right direction.

How to decide what your business actually needs

Start with your scope, risks, and legal or customer obligations

The right document set depends on what your business does, what information it handles, and what commitments it has made to customers or partners. A software company, a professional services firm, and a manufacturer will not need exactly the same documents.

Start by asking:

• Which parts of the business are in scope?
• What information would hurt us most if it were lost, changed, or exposed?
• What do our customers, contracts, or regulators expect from us?
• Which processes are most likely to fail if they are not written down?

Keep the document set proportionate to the size and complexity of the business

Proportionate means suitable for the scale of the business. A ten-person firm does not need the same depth of documentation as a multinational group. But it still needs clarity on who does what, how decisions are made, and how the business proves that controls are in place.

A useful test is this: if a document does not help someone make a decision, carry out a task, or check that a task was done, it may not be worth keeping.

A simple way to structure each policy

Purpose, scope, responsibilities, and review date

Most policies can follow the same simple structure:

• Purpose: why the policy exists
• Scope: who and what it applies to
• Responsibilities: who owns it and who must follow it
• Rules: what people must do
• Exceptions: how special cases are handled
• Review date: when it will be checked again

This structure keeps documents consistent and easy to maintain. It also makes it easier for staff to find the part that matters to them.

What good looks like in day-to-day operations

A good policy is visible in daily work. Staff know how to report an issue. Managers know who approves access. IT knows how to test backups. Procurement knows what to ask suppliers. If the policy does not change behaviour, it is not doing its job.

Common mistakes SMEs make with ISO 27001 documentation

Writing policies that nobody uses

The most common mistake is creating documents for the sake of having documents. If staff cannot understand them, they will not follow them. If managers do not review them, they will drift out of date.

Copying generic templates without tailoring them

Templates can be a helpful starting point, but they are not a finished answer. A copied policy often contains rules that do not match the business, which creates confusion and weakens trust in the whole system.

Having procedures that do not match real working practices

If the procedure says one thing and the business does another, people will follow the real process, not the written one. That gap is where mistakes happen. Good documentation reflects how the business actually works, while still improving it where needed.

A practical checklist for getting started

Identify the documents you already have

Many SMEs already have useful material in place, even if it is scattered across HR, IT, procurement, and operations. Start by collecting what already exists, such as staff handbooks, supplier checks, incident forms, and backup notes.

Fill the gaps that matter most to your risks

Do not try to write everything at once. Focus first on the areas that would cause the most business disruption if they failed. For most SMEs, that means access control, incident handling, backups, and supplier management.

Assign owners and review dates

Every important document should have an owner. That person is responsible for keeping it current and making sure it is reviewed. Add a review date so the document does not quietly become outdated.

When to get help

If you are unsure what is mandatory versus useful

It is easy to over-interpret the standard and create more documentation than you need. It is also easy to miss a document that is important for your risks. If you are not sure where the line is, a short review with an experienced consultant can save time and reduce rework.

If you want a proportionate document set that fits your business

Many SMEs benefit from a practical gap assessment, a document review, or help turning existing working practices into a simple, usable set of policies and procedures. The goal is not to make the business more bureaucratic. It is to make it more consistent, resilient, and easier to manage.

If you would like support shaping a sensible ISO 27001 document set for your organisation, speak to a consultant.

Frequently asked questions

What is the ISO 27001 policy format?

There is no single required format, but most policies work best when they include purpose, scope, responsibilities, the rules to follow, exceptions, and a review date. Keep the language plain and the document short enough for staff to use.

What are the 3 P’s of ISO 27001?

People, process, and technology are often used to describe the main ingredients of a workable security system. For SMEs, that means staff understand their role, procedures are clear, and technology supports the rules rather than replacing them.

What are ISO 27001 requirements?

At a practical level, ISO 27001 expects you to define your scope, assess your risks, choose suitable controls, document the way your system works, keep records, and review performance over time. The exact documents you need depend on your business and risk profile.

What are the requirements of an ISMS policy?

An information security management system policy should set direction, show senior support, define responsibilities, and give staff a clear basis for action. It should be approved, communicated, and reviewed regularly so it remains relevant.