A backup is only useful if the right version of the right data is still available when your business needs it. If a member of staff deletes a key folder, ransomware sits unnoticed for weeks, or a supplier dispute requires an old record, a short retention window can turn a recoverable incident into a costly interruption. This business backup retention policy guide explains how SMEs can set practical rules that protect operations without storing data indefinitely.

What a backup retention policy should decide

A backup retention policy sets out what data is backed up, how often copies are created, where they are stored, how long each copy is kept, and who can restore or delete it. It should also explain how the business will verify that backups can be recovered.

Retention is different from backup frequency. You may back up a finance system every hour but retain most hourly versions for only a few days. Conversely, you may keep a month-end copy for years because it supports accounting, tax, contractual or legal requirements. The right answer is rarely one retention period for everything.

For SME leaders, the policy should connect technical decisions to business priorities. Ask two straightforward questions: how much data can we afford to lose, and how long can each system be unavailable? These are commonly known as recovery point objective and recovery time objective. A payroll platform, customer database and shared files will usually need tighter targets than an old marketing archive.

Business backup retention policy guide: assess the risk first

Start by mapping the information and systems that keep your organisation trading. Do not limit this exercise to the server cupboard. Many businesses now rely on cloud productivity platforms, accounting applications, hosted line-of-business systems, staff laptops and VoIP configuration as much as on on-site equipment.

Consider the consequence of losing each category, the likely time before anyone notices an issue, and whether a historic version may be needed. A ransomware attack can be particularly instructive here. If malicious activity is discovered 21 days after it began, retaining backups for only 14 days may leave no clean recovery point.

The following categories usually deserve separate retention decisions:

• Financial records, payroll data and tax documentation
• Customer, supplier and operational databases
• Microsoft 365 or other cloud collaboration data, including email and shared files
• Core systems and configurations, such as servers, firewalls, virtual machines and telephone settings
• Less critical working files, such as draft materials and temporary project data

This assessment should involve finance, operations and the people responsible for data protection, not just IT. A technical team can confirm what is possible; the business must decide what disruption is acceptable.

Retention rules must support, not replace, record keeping

Backups are designed for recovery. They are not always an appropriate long-term archive or records management system. Holding personal data longer than necessary can create unnecessary data protection risk, while deleting business records too early can create financial and legal problems.

For Irish businesses, retention periods should be aligned with applicable tax, employment, contractual and GDPR obligations. Those requirements vary by record type and circumstance, so seek legal or compliance advice where necessary. Your backup policy should state that a legal hold, investigation or contractual obligation overrides the routine deletion schedule.

Build a schedule that fits your business

A tiered schedule is usually more sensible than keeping every backup for the same length of time. It gives staff a useful choice of restore points while controlling storage costs and administrative overhead.

A practical starting point might retain daily backups for 30 days, weekly backups for 12 weeks, monthly backups for 12 months and year-end copies for a longer period where business or statutory requirements justify it. This is a starting framework, not a universal rule. A busy database may require more frequent short-term copies, while a document archive may need monthly versions for longer.

Be precise about what each timeframe means. “Keep backups for one year” can be interpreted differently by different platforms. Define whether the policy requires 12 monthly restore points, every daily backup for 365 days, or an annual archive copy. The storage requirement and recovery options are very different.

Cloud data needs the same discipline. Native recycle bins and version histories are helpful, but they may be limited in duration and scope. They can also be affected by account compromise or malicious deletion. Independent backups of email, OneDrive, SharePoint and other business cloud data provide a separate recovery route.

Use the 3-2-1 principle as a baseline

A reliable policy should account for where copies live, not only how long they remain. The 3-2-1 approach remains a practical baseline: maintain at least three copies of important data, on two different types of storage, with one copy kept off-site.

For many SMEs, this means a production copy, a local backup that can support fast recovery, and an encrypted cloud or data-centre copy for resilience against fire, theft or site failure. Where ransomware is a significant concern, include an immutable or otherwise protected copy that cannot be changed or deleted during its retention period.

There are trade-offs. Longer retention and immutable storage can increase cost, while local copies can restore quickly but may be vulnerable to a physical incident at the office. A managed approach can balance both, with recovery options matched to the value and urgency of each workload.

Protect the backups themselves

Backup data often contains the same sensitive information as live systems. Treat it as a high-value asset. Encrypt backups in transit and at rest, restrict access through named accounts and multi-factor authentication, and separate backup administration from everyday user administration where possible.

Avoid using a single privileged account across your business systems and backup platform. If that account is compromised, an attacker may be able to delete live data and the recovery copies in one action. Access controls should allow authorised staff or your IT partner to restore data without giving broad deletion rights to everyone.

Your policy should identify an owner. In a smaller business, this may be the operations manager working with a managed IT provider. The owner is responsible for reviewing reports, approving material changes, ensuring leavers lose access promptly and escalating failed backups. Responsibility should be clear even when the technical work is outsourced.

Test recovery, not just backup success

A green backup report confirms that data was copied. It does not prove that the copy is complete, clean or capable of being restored within the required timeframe. Recovery testing is where a retention policy becomes a business continuity measure.

Test a range of scenarios throughout the year: restoring a single file, recovering a mailbox, retrieving a historical database version and rebuilding a critical system in an isolated environment. Record how long each test takes, what information was missing and whether the restored data meets the needs of the relevant team.

Testing also reveals whether your chosen retention periods are long enough. If staff regularly need documents older than the available restore points, that is evidence to adjust the schedule. If recovery takes longer than the business can tolerate, consider faster local recovery options, better system documentation or a different backup design.

Review after business changes

A retention policy should be reviewed at least annually and after significant change. New cloud platforms, acquisitions, office moves, remote-working arrangements, changes in data volume and new regulatory duties can all alter what needs protection.

Common weaknesses include assuming cloud providers retain everything forever, retaining only the latest backup, leaving failed jobs unresolved, and keeping backups that no one has tried to restore. Another frequent problem is protecting data but overlooking the configuration needed to run the business: firewall settings, software licences, server builds, network diagrams and telephone system details.

A written policy does not need to be lengthy. It needs to be understood, approved and followed. For each critical system, document the backup method, frequency, retention schedule, storage location, recovery target, responsible person and test date. That gives decision-makers a clear view of risk rather than a vague assurance that “backups are in place”.

For businesses that need help turning these decisions into a working recovery plan, Host-It can assess existing backup arrangements alongside security, cloud and day-to-day IT support. The aim is not to retain data forever. It is to ensure that, when disruption happens, your team has a clean and usable route back to work.