Personal data protection policy template for Word (free download)

Personal data protection policy template for Word (free download)

A personal data protection policy is the document in which a company explains, in its own words, what information it collects about people, what it uses that information for, who may look at it, how long it keeps it and how someone can ask to have it corrected or removed. It answers one very plain question: once a person hands over a piece of information, what happens to it afterwards?

The template you can download on this page is a Word file with the full structure of that policy: a document control table, purpose, scope, definitions, principles, purposes of processing, rights of the data subject, the channel for exercising them, security measures, processors and third parties, validity period and signatures. It arrives as an organised draft that you adapt to your own operation, not a text to sign without reading.

It is used at two moments in particular. The first is when a company starts putting its information in order: résumés, contracts, contact details of customers and suppliers, access logs, price and staff lists. The second is when somebody asks what happens to their data and there is no written answer. In both cases the sensible move is to have the policy approved before it is needed, rather than drafting it in a rush while a deadline runs.

It is written for small and mid-sized companies, warehouses, distributors and inventory departments where employee, customer and supplier data circulate without anyone having defined common rules. It also serves anyone who must account for that information during an internal audit or for a customer that requires such a document before signing.

What the policy covers and what it does not

The policy covers the ground rules: what information is collected, for what purpose, who may access it, how it is protected, how long it is kept and how a request to correct or remove data is handled. It is a framework document, so it does not go into the operating detail of each area.

It does not cover daily operations, which belong in separate documents: how permissions are assigned by role in the system, how backups are made, what is checked when somebody leaves the company and what is done when there is an incident. Nor does it replace the notice given to each person when their data is collected for a specific purpose, or the agreements with third parties that process information on the company's behalf.

And it does not replace your adviser. The policy sets commitments the company must be able to keep; if it promises more than the company does, the document becomes a liability instead of a defence. Write it with whoever knows the obligations that apply to your business, and review it whenever the operation changes.

What it is useful for

• It puts in writing what information is collected and why, so nobody has to answer from memory when a customer or an employee asks.
• It defines who may see each piece of data and from which role, which reduces informal access to customer lists, prices, suppliers and payroll.
• It sets a single channel for someone to ask to know, update, correct or remove their information, with an identified owner and a defined response time.
• It fixes retention and deletion rules, so the company does not keep information forever out of habit or out of fear of deleting it.
• It works as evidence in internal audits, customer reviews and supplier onboarding processes that ask for documented proof.
• It gives a common framework to new staff: the policy is handed over and explained, instead of improvised depending on who is on shift.

What the template includes

These are the real sections of the file, in the order they appear. The right-hand column summarises what goes in each one.

How to fill it in, step by step

1. Replace the company name in the header and footer, adjust the [PD-___] code to the numbering your company uses and delete the instruction notes left in the file.
2. Write the purpose in two or three lines: what is protected and why. If it does not fit in three lines, the purpose is badly stated.
3. Define the scope with real names: sites, areas, processes and information systems included. Whatever is not named stays out of the policy.
4. Go through the list of purposes and remove the ones that do not apply. If the company does not run marketing with customer data, that purpose should not be written down.
5. Adapt the principles with examples from your own operation: what necessity means when someone asks for one document too many, and what purpose means when someone wants to reuse a database for something else.
6. Define the contact channel and the owner: a visible email address or form, with the role of the person who answers, not the name of someone who may leave next month.
7. Write the retention and response times using values the company can actually meet; if in doubt, leave the field editable and check with your adviser.
8. Mark on the security list which measures already exist and which are pending with a date, and describe how access is granted and withdrawn.
9. Sign, version and communicate: register the approved version, publish it where staff can find it and keep a record of who received it.

The rights of the data subject, without jargon

The rights section is the one that generates the most questions. This table summarises what each right means in the daily life of a warehouse or an office:

Common mistakes before you approve it

• Copying another company's policy and leaving the other company's name in it: it happens more often than you would think and it undermines the whole document.
• Listing purposes the company does not actually carry out. Every purpose written down becomes a commitment you later have to explain.
• Promising security measures that do not exist, such as encrypted databases or daily backups nobody ever configured.
• Naming a contact channel that nobody really checks, or appointing an owner who rotates every few months.
• Leaving no trace of consent: the policy describes the right, but there is no evidence of how permission was actually given.
• Leaving the document unsigned, unversioned and undated, so nobody knows whether it is the current one or an old draft.

When it is worth moving to a system

The policy says what should happen with data; the system is what makes it happen without relying on memory. While the operation is small, with a handful of databases and few users, a Word policy and an orderly folder can be enough. Trouble starts as users, sites and transactions multiply: permissions get copied too widely, lists get exported without control and nobody can say with certainty who looked at what.

At that point you want permissions by role, a change history and records showing who made each movement and when. A tool such as Kardex Tauro helps precisely there: it leaves a trace of movements and users instead of relying on loose spreadsheets. It does not replace the policy, but it makes the policy verifiable, which is the difference between a document that gets filed and one that gets followed.

This model is general guidance, not legal advice

The template is a model for internal use, written to help put information in order and to leave rules in writing. It is not legal advice and does not replace review by a professional: the commitments the company takes on must match its real operation and what it can actually deliver.

Before approving and publishing it, review it with your adviser, adapt the editable fields to your case and check the timeframes, contact channels and security measures with the people who handle that information every day. A policy the company cannot keep is worse than having no policy at all.