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 is housekeeping, but housekeeping with a direct security payoff. Every record you hold can be stolen in a breach, demanded in a legal dispute, or exposed by mistake, and data you have already deleted cannot be. A retention policy lets a small business deliberately shrink the amount of sensitive information it holds 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

Keeping everything is the easy default. 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 a 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. It can also turn a minor incident into a reportable one, because the information exposed was information you should have deleted years ago.

There is a compliance side too. Data-protection laws generally expect you to keep personal data only as long as you have a real reason to, a principle usually called storage limitation. A retention policy is how you show you take it seriously: you can produce 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 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, meaning the situations where you must keep something longer than usual. It should also say who owns the policy and how deletion is carried out, because a retention rule that nobody executes only describes data you are still keeping.

  • Data categories: the types of information your business holds, grouped sensibly into 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 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 core 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; a single page can usually capture the important cases. Start by listing the categories of personal and business data you hold, then set a period for each from three inputs: any legal minimum, your real 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 followed is worth more than a perfect one nobody applies.

  • List the categories of data your business really holds, instead of an abstract taxonomy copied from a template.
  • Set each period from the strongest of: legal minimum, real 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 happens at the end of it. Your policy should say how data is removed and 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 full 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, not the recycling bin. Decide how often deletion runs (many small businesses do it as 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 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. Clients and regulators notice a retention policy that is reviewed and enforced.

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 for 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.

For each category, the schedule names a period and a reason, so 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 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 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 erase individual records from every historical backup, which can be impractical and can undermine the backup's integrity. Your policy should still mention backups explicitly, set a sensible rotation so old snapshots are eventually overwritten, and note that data restored from a backup falls under the retention schedule again.

Deletion requests and data in other people's systems

A retention policy also has to cope with data leaving on request as well as on schedule. Under most privacy regimes, individuals can ask you to delete the personal data you hold about them, and how quickly you can do that depends on knowing where their data lives. This is where a good schedule pays off: 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, such as an unresolved dispute or a legal retention requirement.

Do not forget the data you have handed to other companies. Small businesses run on third-party services such as cloud storage, email providers, accounting tools, and marketing platforms, and personal data ends up spread across all of them. Your retention rules have to cover 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 has been removed. A retention policy that covers your own servers and ignores a dozen cloud services covers only part of the risk you 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, ready for you to fill in with the categories of data you 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. Under that size rule, a ten-person company is usually not regulated by the directive at all. The requirements can still reach you, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and in practice that expectation arrives 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. A smaller business falls outside its direct scope unless a member state has specifically designated it or it sits 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. A small business that meets none of those tests is 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 with what you do now 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