A Data Retention Policy That Holds Up

Storage got cheap, so businesses stopped deciding. Keep everything, sort it out later, later never comes. It feels prudent — right up until the moment you have to explain to a regulator, or a client lawyer, exactly what was in the 400GB of files an attacker just copied.

Data you do not need is not neutral. It costs money to store, slows every search and migration, and expands the blast radius of every future breach. The safest data is the data you deleted three years ago because you had a rule.

The two legal forces pulling in opposite directions

A retention policy lives in the tension between two obligations, and understanding both is what stops the policy being arbitrary.

Pulling towards keeping: Australian law sets minimum retention periods. The ATO requires most business and tax records to be kept for five years from when they were prepared or the transaction completed. The Corporations Act requires company financial records to be kept for seven years. Fair Work requires employee records for seven years. Industry regulators add their own — health records in NSW, for instance, run far longer, and for children longer again.

Pulling towards deleting: Australian Privacy Principle 11.2 requires that where you hold personal information you no longer need for any permitted purpose, and you are not legally required to retain it, you must take reasonable steps to destroy or de-identify it. Holding personal data indefinitely is not caution. It is a compliance gap with a storage bill attached.

A good policy names the longer of the applicable minimums, then deletes promptly once it passes.

Start by finding out what you actually have

Most retention policies fail because they are written before anyone has looked. You cannot set rules for data you have not located.

Map it roughly — this does not need to be a six-month project:

• Email. Usually the biggest and worst-governed store in the business. Attachments, contracts, personal information, all of it searchable.
• File storage. SharePoint, OneDrive, the old file server nobody has opened since the migration.
• Line-of-business systems. Accounting, CRM, payroll, practice management.
• Backups. The copy people forget. If your policy says delete after five years but your backups keep it for ten, your policy is fiction.
• Everything else. Shared drives, USB disks in drawers, the personal OneDrive of someone who left.

For each store, note what categories it holds, roughly how much, and who owns it. The owner matters — a policy with no named owner per category will not survive contact with a busy year.

Write the schedule, keep it short

A retention schedule that runs to forty pages will be ignored. One page with clear categories works. A workable starting point for a small Australian business:

• Financial and tax records — 7 years (covers both the ATO five and the Corporations Act seven).
• Employee records — 7 years after employment ends.
• Client contracts — 7 years after the contract ends, longer where a limitation period or professional indemnity requirement applies.
• Job or matter files — per industry norms; often 7 years after completion.
• Recruitment records for unsuccessful applicants — 6 to 12 months, then delete. This is personal information with no ongoing purpose, and it is routinely kept forever.
• General correspondence — 2 to 3 years unless it belongs to a matter file.
• CCTV and access logs — 30 to 90 days.
• Marketing lists — until consent is withdrawn, reviewed annually.

Check your own industry obligations before adopting these. The point is the shape: a named category, a defined period, a trigger event that starts the clock.

Make the system do it, not a person

A policy enforced by human diligence is a policy that works for about five weeks. The categories above should be implemented as retention labels and policies in Microsoft 365, so deletion happens automatically when the clock runs out.

Two implementation details save real pain:

Retention beats deletion by default. If two policies apply to the same item, Microsoft 365 keeps it for the longer period. That is the safe default and it means overlapping rules will not destroy something early.

Legal hold overrides everything. The moment litigation or an investigation is reasonably anticipated, relevant data must be preserved regardless of the schedule. Destroying data subject to a hold is a far more serious problem than keeping it too long, so build the hold process before you build the automation.

Deleting properly

Deletion has to reach every copy, which is where most policies quietly fail. Removing a file from SharePoint while it persists in a backup set for another seven years satisfies nobody.

Align backup retention with the schedule. For hardware, certified destruction with a certificate — cryptographic erasure or physical destruction, not a quick format. And keep the evidence: what was destroyed, when, by whom, under which rule. If you are ever asked to demonstrate compliance, the log is the answer.

The breach argument, which is the one that persuades people

Under the Notifiable Data Breaches scheme, the severity of a breach — and whether it is notifiable at all — depends heavily on what was exposed. A business holding three years of client data has a materially smaller incident than one holding fifteen, simply because there is less to lose.

Deletion is therefore a security control, not just housekeeping. It is the only control that reduces the consequences of a breach you have not had yet, and it costs nothing but discipline.

Our IT audit covers the data mapping step, and managed backup is where the retention alignment actually gets enforced. If you want the policy written and implemented rather than filed, our virtual CIO service handles that end to end.

Local IT and cyber security support across NSW

Chewing IT runs managed IT and cyber security for small and mid-sized businesses from our Wyong and Hornsby offices, covering the Central Coast, Newcastle, Lake Macquarie and Hornsby.

Holding data you cannot justify? Ask us for a retention review and we will map what you have before writing rules for it.