Guide

Privacy Policy Template for Small Business: What to Include

What a small business privacy policy needs to contain, section by section, and why a generated template usually needs editing before it describes what your business actually does with data.

By SecureBusinessHub Editorial, International cybersecurity desk — 2026-07-28 · 7 min read

A privacy policy is the document that tells the people whose data you hold what you collect, why you have it, who else sees it, how long you keep it, and what they can ask you to do about it. Most small businesses get theirs from a generator, paste it onto the website, and never read it again. That is usually where the problem starts, because a template describes a generic business and yours is not one. This guide goes through the sections a small business privacy policy needs and, more usefully, the parts of a template that almost always need rewriting before the document describes anything true.

This is about the document. If what you want is an overview of the privacy rules themselves and how they have been changing, read our guide to data privacy regulations for small business instead, and for how the major European regimes reach a smaller business at all, see NIS2 requirements and GDPR for small business. Nothing here is legal advice; requirements vary by where you operate and who your customers are, and a policy that carries real consequences deserves a review by someone qualified in your jurisdiction.

What a template can and cannot do for you

A good template saves you from a blank page and stops you forgetting a section entirely, which is worth a great deal. What it cannot do is know your business. The generated text will confidently describe data you do not collect, name categories of recipient you have never used, and stay silent about the one system that actually holds your customer records. A policy that describes a business other than yours is not much better than no policy at all: it is a public statement about your practices, and being wrong in public is a poor position to be in if anyone ever checks.

The practical approach is to take a template as a checklist of sections, then work through each one against what your business genuinely does. That exercise usually takes an afternoon and turns up things worth knowing regardless of the document, such as an old form still emailing submissions to an inbox nobody monitors, or an analytics tag placed years ago by someone who has left.

The sections to include

The list below reflects what transparency rules under the European model expect a policy to cover, and it is a sound structure to work from more broadly, since most regimes ask for a similar set of disclosures in a similar order. If you sell to customers in places with their own regimes, such as several US states, expect to add specific sections those laws require on top of this base.

Who you are: legal entity name, address, and a contact point for privacy questions. Include a data protection officer's details only if you have actually appointed one.
What personal data you collect, in concrete categories: contact details, order history, website analytics, job applications, CCTV footage if you have cameras.
Where it comes from, if not directly from the person: a partner, a public register, a lead list.
Why you have it, purpose by purpose, and the legal basis you rely on for each. Where the basis is legitimate interests, say what that interest is.
Who else sees it: the categories of recipient, and, in practice, name the significant processors rather than hiding behind "our service providers".
Whether data goes outside your country or region, and the safeguard relied on if it does.
How long you keep each category, or the criteria you use to decide.
The rights people have: access, correction, deletion, restriction, objection, portability, and withdrawing consent where consent is the basis.
How to exercise those rights, and the right to complain to a supervisory authority.
Whether providing the data is required, and what happens if someone declines.
Any automated decision-making or profiling that produces significant effects.
The date the policy was last updated.

The section templates always get wrong

The recipients section is where generated policies are least accurate and where accuracy matters most. Every business has a short list of third parties that genuinely hold customer data: the email platform, the payment processor, the booking or e-commerce system, the accountant, the CRM, the cloud storage. A template will not know any of them. Write the list yourself, working from the invoices you pay each month rather than from memory, and describe categories at a level a reader can actually understand. If you already went through this exercise for a vendor risk assessment, you have the list to hand.

The second reliably wrong section is the collection list, because it is written from the website and forgets everything else. A small business collects data through a contact form, but also through email, phone calls that get logged, in-person sign-up sheets, a WhatsApp number, job applications, and a supplier or customer spreadsheet somebody maintains locally. Walk the actual journey a customer takes with your business and write down every point at which you learn something about them. The policy should describe that, not just the parts that happen in a browser.

Retention: the answer people avoid writing

Templates default to vague retention language because specific answers are hard, and "we keep your data for as long as necessary" reads as though it means something. It rarely survives contact with a direct question. Setting genuine retention periods, per category, is the difficult half of this document, and it is the half that shapes what you do rather than what you say. Our guide to writing a data retention policy for a small business covers how to build the underlying schedule; the privacy policy then summarises it in language a customer can follow.

Rights requests, and the address you publish

Whatever contact route the policy gives, someone will eventually use it, and the request will arrive on a day that suits nobody. Publish an address that a real person monitors and decide in advance who handles a request to see or delete someone's data, where that data would have to be gathered from, and roughly how long you have to respond under the rules that apply to you. A policy inviting people to contact an inbox that was abandoned two years ago is worse than one that gives a phone number, because it creates an obligation you have quietly made yourself unable to meet.

Publishing it and keeping it true

Link the policy from the website footer, from every form that collects personal data, and from the point where someone creates an account or places an order. Date it, and treat it as a document that changes: a new booking system, a new marketing tool, a new country of customers, or a new category of data collected are all reasons to revisit it. Review it at least once a year even if nothing obvious has changed, since tools accumulate quietly. If a change is significant and affects how you use data people have already given you, tell them rather than silently swapping the page.

A worked example

A nine-person veterinary practice has a privacy policy generated three years ago when the website was built. Working through it section by section, the owner finds it mentions a mailing list they no longer run, omits the online booking system that now holds every client's contact details and pet records, describes recipients as "trusted partners" without naming any, and says nothing about the CCTV camera in the waiting room. The retention section says data is kept as long as necessary, which turns out to mean nothing had ever been deleted.

The rewrite takes an afternoon and a follow-up conversation with the practice manager. The recipients section ends up naming five processors, all identifiable from the monthly invoices. The collection section gains the booking system, the phone log, and the camera. Retention gains real numbers, taken from the professional record-keeping requirements the practice already follows for clinical notes. The document roughly doubles in length and, for the first time, describes the practice. It is also now the thing they hand to a corporate client's procurement team when asked, instead of hoping nobody asks.

Where this fits

A privacy policy is what you tell people before anything goes wrong; what you have to tell them afterwards is covered in our guide to data breach notification requirements. The regulatory background sits in data privacy regulations for small business and NIS2 requirements and GDPR for small business, and the retention schedule this policy summarises is in our data retention policy guide. If you would rather adapt structured documents than start from a generator, our editable policy template pack includes a core policy pack with data retention and data handling policies written for small businesses to fill in.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.