Personal data in spreadsheets: a risk checklist

There is a genre of advice that treats spreadsheets as inherently unsafe for personal data and recommends a database instead. It is mostly wrong, and it is unhelpful because the alternative rarely gets built.

A modern cloud spreadsheet has per-user access control, an audit trail, encryption at rest and in transit, versioning, and a permission model most small businesses never fully use. The gap between that and a purpose-built system is narrower than people assume.

What genuinely differs is the culture around the tool. Spreadsheets get duplicated, emailed, downloaded and shared by link, because that is what they are good at. The risk lives in those habits rather than in the file format.

This is a working explanation for people who run websites, not legal advice. If your processing is unusual or high-risk, take proper advice.

Start here, because it is the failure that actually happens. Somebody needed to show a sheet to a contractor in 2024, switched it to anyone with the link, and nobody switched it back.

A link-shared sheet of enquiries is readable by anyone who ever receives that URL, including in a forwarded email, a support ticket, a screenshot with the address bar visible, or a browser history on a shared machine. It is not indexed, which people take as safety, and it is one paste away from being public.

The check takes a minute per sheet: open sharing, confirm it is restricted to named people, and remove anyone who has left. The habit worth adopting is to make link sharing a decision with an expiry rather than a default.

Where a sheet genuinely must be shared widely, share a filtered view or a copy with the personal columns removed rather than the source of truth.

The second check is the list of people, and it is always longer than expected. Former staff, an agency from a project that ended, a personal account somebody used before they had a work one, and the person who set it up originally.

Access accumulates because adding someone is a small helpful act and removing them is nobody's job. A quarterly review fixes it permanently, and the review takes about as long as reading this paragraph.

Pay particular attention to editor rights. Most people who need to see enquiries do not need to change them, and read-only access removes an entire category of accident, including the one where somebody sorts a single column and detaches every row from its neighbours.

Every export creates a copy that has no access control, no retention rule and no owner. A CSV downloaded for a meeting lives on a laptop, then in a cloud backup of that laptop, then in a folder called old, forever.

This is the single largest divergence between what a business believes it holds and what it actually holds. It also breaks any retention policy you have written, because the policy applies to the sheet and the copies are not the sheet.

The fix is cultural rather than technical: share a view instead of a file, and treat an export as something you delete after the meeting. Where a copy is genuinely needed, note where it went.

A spreadsheet makes it trivially easy to add one more column, which is exactly why they proliferate. Each one is data you now hold about a person.

Look at the columns you have and ask which ones anyone has used in the last year. Free-text notes fields are worth particular attention, because they attract judgements about people that nobody would write into a structured field and that a subject access request would eventually surface.

The rule of thumb is that a spreadsheet of leads should contain what you need to answer and qualify an enquiry. Opinions about the person belong somewhere with a shorter life or nowhere at all.

A spreadsheet interprets certain leading characters as the start of a formula, which means text arriving from a form can become executable content in a cell. A submission beginning with an equals sign is the classic case.

The practical risks are a broken sheet, a misleading value, and in some configurations a cell that fetches an external URL when opened. This is what formula injection means in an ordinary lead-capture context.

The defence belongs at the point of writing rather than at the point of reading, because by the time a human opens the sheet the cell already exists. Any pipeline writing untrusted text into a spreadsheet should neutralise leading formula characters as it writes, which is what our delivery path does before a row lands.

Cloud spreadsheets keep version history and, on business tiers, an activity log. Most owners have never opened either.

They are worth knowing about for two reasons. After an accident, version history is how you get the rows back, which makes it your recovery plan whether or not you thought of it that way. And after a suspected exposure, the activity view is the only place that can tell you who opened the file and when.

Neither is a substitute for restricting access. Both are the difference between an incident you can describe and one you can only guess at.

It is worth picturing the realistic version rather than the dramatic one. Nobody is going to attack your spreadsheet. What happens is that a link gets forwarded, or a departing employee keeps access, or an export sits in a shared folder that later becomes public.

All three are quiet, all three are discovered late, and all three are prevented by the checks above. That is the argument for doing them: not that the tool is dangerous, but that the realistic failure modes are unglamorous and entirely preventable.

If personal data does get exposed, notification obligations may follow, and the first question will be what exactly was in the file. A sheet that has been minimised and pruned makes that answer much shorter.

1. Sharing is restricted to named people, with no live anyone-with-the-link setting.
2. The access list has been reviewed in the last quarter and contains only current people.
3. Most people have view access rather than edit.
4. Columns are limited to what is used, with no stale free-text opinions.
5. Untrusted text is neutralised on write so formulas cannot be introduced by a submission.
6. Exports are rare, deliberate and deleted afterwards.
7. A retention rule exists and someone runs it.

Seven items. Most sites can complete the first three in ten minutes and are meaningfully safer afterwards.

Run it on a schedule rather than once. Sharing settings and access lists both drift, and the value of the list is that it catches the drift while it is still boring rather than after somebody forwards the wrong link.

The recommendation to move personal data out of spreadsheets and into a proper system usually results in the data staying exactly where it is, because the migration never becomes anyone's priority.

A checklist that can be completed this afternoon reduces real risk today. Whether the eventual home is a database is a separate question, and one you will answer for operational reasons long before privacy forces it.

In the meantime, a well-governed sheet is a perfectly respectable place to keep leads.

Is a spreadsheet an acceptable place to keep personal data?

What is the most dangerous setting?

Should I password protect the file?

How do I stop formula injection from form submissions?

How often should I review who has access?

Are exports ever acceptable?

What about notes columns?

Does version history undermine deletion?