How to Write a Data Loss Prevention Policy

A data loss prevention policy has two halves that people constantly confuse: the written document that says what staff may do with company data, and the technical rules in Microsoft 365 or Sophos that enforce it. You need both, and the document should come first, because a technical rule you cannot explain to an employee is a rule you will end up switching off. This is how to write both for an Australian SME, without buying a template that was drafted for a US bank.

Key facts

• A workable SME DLP policy document runs to three or four pages, not thirty, and names the data types, the approved channels and the consequences.
• Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference, loss and unauthorised disclosure, and a documented policy is part of demonstrating those steps.
• Human error caused 194 of the 670 data breaches notified to the OAIC between July and December 2025, so the policy should be written around accidents rather than around espionage.
• Every rule needs a named action of monitor, warn or block, and most rules in a first rollout should be monitor or warn.
• Set an instance threshold on content rules, for example ten or more matches, so a single stray number does not generate an alert.
• The policy needs a named owner and a review date, otherwise the alert queue is unowned within a fortnight.

What goes in the written policy?

Keep it to six sections and write it so a new starter can read it in five minutes.

1. What we consider sensitive. Name the actual data: client financial records, tax file numbers, health information, identity documents, pricing, the client database, payroll. Generic wording such as "confidential information" gives staff nothing to act on.
2. Where it is allowed to live. Approved systems by name. SharePoint and the practice management system, yes. A personal OneDrive, a home NAS, a USB stick in a drawer, no.
3. How it may be shared. Internal sharing, external sharing, and what has to happen first, for example a second check on the recipient address for anything containing bank details.
4. What is never allowed. A short, specific list. Forwarding company data to personal email is the one worth stating explicitly, because plenty of people do it with no sense that it is a problem.
5. What we monitor. Say it out loud. Staff should know that outbound email and file transfers are checked against rules, and why.
6. Who owns this and when it is reviewed. A name and a date, reviewed annually or when the business changes.

That last point about monitoring matters legally and culturally. In New South Wales, workplace surveillance of computers requires notice to employees under the Workplace Surveillance Act 2005, and separately, a policy staff have never seen is not much of a defence if something goes wrong. Put it in the induction pack.

How do you turn the policy into technical rules?

Work channel by channel, because that is how the tooling is organised.

Email is where most accidents happen, so start there. A rule scoped to external recipients that detects financial or identity data, and shows the sender a warning with an override, catches the mis-addressed email without blocking legitimate work. In Microsoft 365 that is an Exchange location policy in Purview. If you run Sophos Email, it is a data control policy.

Cloud storage comes next. Policies on SharePoint and OneDrive catch sensitive content shared with an "anyone" link, which is a quiet and very common exposure.

The device is last and it is the one that costs money. Endpoint DLP in Microsoft 365 needs E5 or the Purview Suite add-on, while Sophos includes endpoint DLP in Sophos Endpoint with no extra licence. Either way, the rules to start with are removable storage and uploads to unapproved cloud services.

What should the first three rules be?

If you do nothing else, do these. They are the ones that would have prevented most of what we have been called in to clean up.

1. Bulk personal information leaving by email. Ten or more instances of an Australian identity or financial data type, to an external recipient, warn with override.
2. Client database or export to removable storage. Database and bulk export file types copied to USB or external drives, block.
3. Sensitive content shared with an anyone-with-the-link URL. In SharePoint and OneDrive, block the link type and alert.

Notice that the first one warns rather than blocks. In our experience the warning prompt does more work than the block does, because it interrupts the person at the moment of the mistake, and the ones who are doing something legitimate can proceed and be logged.

How do you roll it out without a mutiny?

Tell people before you turn anything on. A short all-staff message explaining that the business is putting checks on sensitive data, what they will see, and who to contact if something is blocked wrongly, converts the whole thing from surveillance into housekeeping. We have watched the difference between doing this and not doing it, and it is the difference between a two week rollout and a three month argument.

Then run everything in monitor or simulation mode for four to six weeks. Review the alerts weekly and treat each one as a question, not a verdict. Roughly half of what fires in the first fortnight turns out to be a legitimate business process nobody documented, and the other half is genuinely interesting.

Only after that do you move rules to enforcement, and only the ones you are confident about. There is no prize for enforcing everything at once.

Frequently asked questions

Do we legally need a data loss prevention policy in Australia?

There is no law that names a DLP policy specifically. Australian Privacy Principle 11 does require reasonable steps to protect personal information from misuse and unauthorised disclosure, and a documented policy with technical controls behind it is one of the clearest ways to demonstrate those steps if the OAIC ever asks. Insurers increasingly ask too.

Can we just download a DLP policy template?

You can start from one, but most templates online are drafted for US regulations and reference HIPAA, SOX or CCPA, none of which apply here. The sections that matter, which data types you hold and which systems are approved, are specific to your business and cannot be templated anyway.

Who should own the DLP policy in a small business?

Someone in the business, not your IT provider. We can write the rules, tune them and run the alert queue, but the decision about what is sensitive and who may share it is a business decision. In most SMEs we work with it sits with the practice manager, the operations manager or a director.

How often should the policy be reviewed?

Annually as a minimum, and immediately after any of these: a new system holding client data, a change to what data you collect, an office move or a shift in how people work, or any incident. A policy that has not been looked at in three years is usually describing a business that no longer exists.

What happens when a rule blocks something legitimate?

The person contacts the named owner, the exception is assessed, and either the rule is adjusted or a documented exception is granted. Build that path into the policy from day one. Rules that block with no route to a human are the ones that get disabled.

If you want a DLP policy that fits your business and rules that actually enforce it, we do both: the document, the technical build, and the alert review afterwards.