Guide

Data Retention Policy for SMBs

How to write a data retention policy for a small business: building a retention schedule, deleting data safely, and handling legal holds and privacy.

By SecureBusinessHub Editorial, International cybersecurity desk — · 9 min read

A data retention policy is the written rule that decides, in advance, how long your business keeps each type of information and when it is deleted. It sounds like housekeeping, and in a sense it is — but it is housekeeping with a direct security payoff. Every record you hold is a record that can be stolen in a breach, demanded in a legal dispute, or exposed by mistake. Data you have already deleted cannot be any of those things. A retention policy is how a small business deliberately shrinks the amount of sensitive information it is holding at any given moment, instead of accumulating everything forever by default.

This guide covers what a data retention policy contains, how to build a retention schedule that fits a small business rather than a corporate legal department, and how to handle deletion, legal holds, and the privacy questions clients and regulators ask. It is one of the four foundation documents in our small business security policy guide, and it pairs with your remote work and BYOD policy, which governs the devices that company data ends up scattered across.

Why less data is safer data

The instinct of most businesses is to keep everything. Storage is cheap, deleting feels risky, and "we might need it" is a hard argument to counter in the moment. But data you no longer need is pure liability. It grows the blast radius of any breach — the more customer records, old emails, and stale files you hold, the more an attacker walks away with. It complicates every privacy request, because you have to search everywhere the data might be. And it can turn a minor incident into a reportable one, simply because the information exposed was information you should have deleted years ago.

There is a compliance dimension too. Data-protection laws generally expect you to keep personal data only as long as you have a genuine reason to, a principle usually called storage limitation. A retention policy is how you demonstrate that you take it seriously — you can show a schedule, a deletion process, and evidence that both are followed. We cover the wider obligations in our GDPR guide for small business; the retention policy is the practical mechanism that turns those principles into a routine your business actually runs.

What a data retention policy covers

A retention policy answers three questions for every kind of data you hold: what it is, how long you keep it, and what happens when that period ends. To do that, it needs to cover the categories of data in your business, the retention period for each, the method and timing of deletion, and the exceptions — the situations where you must keep something longer than usual. It should also say who owns the policy and how deletion is actually carried out, because a retention rule that nobody executes is just a document describing data you are still keeping.

  • Data categories — the types of information your business holds, grouped sensibly: customer records, employee records, financial and tax documents, marketing contacts, operational logs, and general correspondence.
  • Retention periods — how long each category is kept, driven by legal requirements, business need, and the storage-limitation principle.
  • Deletion method — how data is actually removed or anonymised when its period ends, across every place it lives.
  • Legal holds — the rule that pauses deletion when data is relevant to a dispute, claim, or investigation.
  • Ownership and review — who is responsible for the schedule and how often it is checked.

Building a retention schedule

The heart of the policy is a retention schedule: a simple table that lists each category of data and the period you keep it. You do not need dozens of rows. Most small businesses can capture the important cases in a single page. Start by listing the categories of personal and business data you actually hold, then set a period for each based on three inputs — any legal minimum, your genuine business need, and the principle of not keeping personal data longer than necessary.

Some periods are dictated for you. Tax and accounting records usually have a legally required minimum retention, and employment records often carry their own timelines; check the specific requirements in your jurisdiction rather than guessing. Others are a judgement call: how long do you really need a former customer's details, or the CV of someone you did not hire? Set a defensible period, write it down, and apply it consistently. A schedule that is roughly right and actually followed beats a perfect one that exists only on paper.

  • List the real categories of data your business holds, not an abstract taxonomy copied from a template.
  • Set each period from the strongest of: legal minimum, genuine business need, and storage limitation.
  • Write the reason next to each period, so a future review can tell whether it still makes sense.
  • Keep the schedule to a page where you can, so it stays readable and gets used.

Deletion, disposal, and legal holds

Setting a retention period is only useful if deletion actually happens at the end of it. Your policy should say how data is removed and, crucially, cover every place it lives — the primary system, backups, exports, spreadsheets, and any personal devices under your remote work and BYOD policy. Deletion can mean genuine erasure or, where you want to keep aggregate insight, anonymising the data so it can no longer identify anyone. Paper records need a disposal method too: shredding rather than the recycling bin. Decide how often deletion runs — many small businesses do it on a quarterly or annual sweep — and record that it happened.

Build in one deliberate exception: the legal hold. When data becomes relevant to a live dispute, claim, investigation, or regulatory request, its normal deletion is paused until the matter is resolved. Deleting data on schedule is good practice; deleting data you knew was relevant to a legal matter is not, and can look like destruction of evidence. State plainly who can place a legal hold, how it is recorded, and how it is lifted, so the exception is controlled rather than ad hoc.

Adopting and maintaining the policy

Adopt the retention policy like any other: assign an owner, have relevant staff read and acknowledge it, and store it where the team can find it. Because retention touches so many systems, the owner's most important job is the periodic check — confirming that deletion is actually running, that new categories of data have been added to the schedule as the business changed, and that the retention periods still make sense. Review it at least once a year, and sooner if you adopt a major new system that starts collecting a new kind of data. A retention policy that is reviewed and enforced is one of the clearest signals to a client or regulator that you handle their data with genuine care.

A worked example of a retention schedule

A retention schedule is easier to grasp with a concrete example, so here is what a simple one might look like for a small business. Customer records tied to an active relationship are kept for the life of the relationship and then a defined period after it ends — say two years — to cover follow-up and warranty questions, after which they are deleted or anonymised. Financial and tax records are kept for the minimum your jurisdiction requires, which is often several years, and no longer. Job applications from candidates you did not hire are kept for a short, stated window — six to twelve months is common — then deleted. Marketing contacts are kept only while consent is valid and removed promptly on request. Operational logs are kept long enough to investigate problems, then rotated out.

Notice what the schedule is doing: for each category it names a period and a reason, so that anyone reviewing it later can tell whether the rule still makes sense. You do not need to get every number exactly right on the first pass. A schedule that is roughly reasonable, written down, and actually applied puts you far ahead of the common alternative, which is keeping everything indefinitely because no one ever decided otherwise. Treat the first version as a starting point you refine at each annual review.

One detail trips up almost every small business: backups. Data you have diligently deleted from your live systems often lives on for months inside backup snapshots, which is both a hidden risk and a complication for privacy requests. You do not usually need to surgically erase individual records from every historical backup — that can be impractical and can undermine the backup's integrity — but your policy should acknowledge backups explicitly, set a sensible rotation so old snapshots are eventually overwritten, and note that data restored from a backup is re-subject to the retention schedule. Ignoring backups is how businesses end up believing data is gone when it quietly is not.

Deletion requests and data in other people's systems

A retention policy also has to cope with data leaving on demand, not just on schedule. Under most privacy regimes, individuals can ask you to delete the personal data you hold about them, and your ability to honour that quickly depends entirely on knowing where their data lives. This is the practical payoff of a good schedule: if you have already mapped which systems hold customer records, a deletion request becomes a defined checklist rather than a frantic hunt. Your policy should name who handles such requests, the timeframe you aim to meet, and the narrow, legitimate reasons you might have to retain some data despite a request — an unresolved dispute or a legal retention requirement, for instance.

Do not forget the data you have handed to other companies. Most small businesses run on third-party services — cloud storage, email providers, accounting tools, marketing platforms — and personal data ends up spread across all of them. Your retention rules have to account for that data too, which means knowing what each provider stores, how long they keep it, and how deletion works on their side. When you stop using a vendor, closing the account is not the same as deleting your data from it; check their process and confirm the data is actually removed. A retention policy that governs only your own servers while ignoring a dozen cloud services is describing a fraction of the risk you actually carry.

Where the data retention policy fits

The data retention policy is one of the four foundations in our small business security policy framework, works closely with your remote work and BYOD policy to control where data ends up, and supports the wider obligations in our GDPR guide for small business. If you would rather adapt a ready-made document than build the schedule from scratch, our editable policy template pack includes a data retention policy and schedule sized for small businesses — a structured starting point you fill in with the categories of data you actually hold and the periods that apply where you operate.

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.

Related reading