📑 Table of Contents

    In most companies, backup is not a policy but a habit: someone set something up, it works, nobody touches it. The problem surfaces when that person leaves, or when the bad day arrives. A written policy takes backup out of one person's hands.

    The headings below are a skeleton you can use. Under each one I've written what you need to decide .

    1. Scope — what are we backing up?

    List them one by one; "our website" is not a sufficient definition. Cover at least these three separately:

    • Files: the web root, uploaded documents and images, customised theme files.
    • Database: content, users, orders, settings.
    • Email: corporate mailboxes — the item most policies forget.

    Also write down what you leave out of scope. A sentence like "the server operating system is not backed up; it is reinstalled" ends arguments in a crisis.

    2. Frequency — how much data loss can we accept?

    The technical name for this question is RPO: the maximum acceptable data loss. The answer sets your frequency directly.

    • Brochure site → weekly or daily
    • Blog or news site → daily
    • E-commerce → hourly
    • Busy store → more often than hourly

    Giving components separate frequencies both improves protection and lowers cost: files change rarely, the database constantly. For a detailed treatment see our disaster recovery plan page.

    3. Retention — how far back must we be able to go?

    This is a separate decision from frequency and is usually skipped. The decisive question is: how late might we notice a problem?

    Silent corruption (a plugin slowly damaging data, an attack that goes unnoticed) can surface weeks later. If your retention is short, every backup you hold already contains the damaged state. The practical approach is to keep several copies of each type and extend the period according to how critical the work is.

    If you process personal data, add an upper bound too: data protection law requires you not to keep data longer than the purpose of processing. You define that period in your retention and disposal policy and enforce it on the backup side with automatic cleanup rules.

    📍 The short answer to "where should backups be stored?"

    At least one copy must sit somewhere independent of the system you are backing up. A backup on the same server is lost with that server. This is the most basic — and most frequently broken — rule of backups; for the details see the 3-2-1 rule.

    4. Location and access — where is it, and who can open it?

    • Where do the backups sit physically and logically? Which provider, which region?
    • Who has access? Is that access logged?
    • Is encryption used, who holds the key and where is it backed up?

    That last item is vital: if your encryption key only exists on the server you lost, your encrypted backup is lost too. Keep the key somewhere independent of the system.

    5. Responsibility — who does what, and when?

    • Who owns the backup setup? (Write a role , not a person.)
    • Who receives the alerts? And who receives them while that person is on leave?
    • Who decides to restore?
    • Whose responsibility is customer communication during a crisis?

    6. Testing — does the policy actually work?

    Without this item a policy is just a wish. Define at least: how often a restore is attempted, who attempts it, where the result is recorded and what happens when a test fails.

    Distinguish these: a backup having been taken, its integrity having been verified and its restorability having been tried are three different things. Your policy should cover all three — see backup verification.

    7. Cost — how much should we spend?

    The right question is not "how much does backup cost" but "how much would one day of data loss cost us" . Work the second one out: lost order revenue, the labour cost of recreating content, customer trust and possible legal liabilities.

    Next to that figure, the cost of backups is usually small. There are legitimate ways to lower it, too: incremental backup reduces both transferred data and storage use, and per-component frequency settings mean you only pay where you need to.

    8. Review

    Record when the policy was last updated and set a review interval. Systems change: a new application is added, a server is moved, a component is removed. An out-of-date policy gives false confidence.

    In summary: the minimum working policy

    Scope written down · a frequency set for every component · retention defined · at least one copy independent of the system · the encryption key kept elsewhere · a responsible role named · a test schedule that exists and whose results are recorded. A single page meeting these seven points is better than what most companies have today.

    Frequently Asked Questions

    What should a backup policy contain?

    At least these seven headings: scope (what is backed up and what is not), backup frequency for every component, retention period, the location of the backups and access rights, encryption and key management, responsibility roles, and a test schedule. A policy with no testing clause is an unverified wish.

    Where should backups be stored?

    At least one copy must sit somewhere independent of the system you are backing up. A backup on the same server or in the same hosting account is lost when the server is lost, the account is suspended or ransomware encrypts the disk. This is the most basic rule of backups.

    How much should backups cost?

    The right comparison is not with the backup fee but with the cost of one day of data loss: lost order revenue, the labour of recreating content, customer trust and possible legal liabilities. Next to that figure, the cost of backups is small for most businesses. Incremental backup and per-component frequency settings are legitimate ways to reduce it.

    How should I set the retention period?

    The decisive question is: how late might we notice a problem? Silent corruption and unnoticed attacks can surface weeks later; if your retention is short, every backup you hold already contains the damaged state. If you process personal data you must also, by law, not keep it longer than the purpose of processing requires.

    Does a small business need a written policy too?

    Yes — but not a long document. Even a single page takes backup out of one person's hands. The real risk isn't the absence of a policy but its living in one person's head; when that person leaves or can't be reached during a crisis, the system is left with no owner.