Privacy Basics for Ops Teams: Handling Personal Data in Internal Tools
A practical starting point for ops teams handling personal data in internal tools: collect less, restrict access, and handle access and deletion requests.

Your intake form asks for date of birth. When you ask why, the honest answer is that the old spreadsheet had a date of birth column, so the new form does too. Nobody has used it in years. It is still being collected from every new customer, every day.
Most privacy problems in ops teams look like this. Not dramatic breaches, just personal data gathered out of habit, visible to more people than need it, and kept long after its purpose ended. The good news is that the fixes are mostly design decisions you already make.
A quick note before we start: this is general guidance for building sensible tools, not legal advice. Privacy rules differ by country and sector, so confirm your specific obligations with your legal or privacy adviser.
What counts as personal data
Personal data is anything that identifies a person, or could identify them when combined with other information. Names, email addresses and phone numbers are obvious. Less obvious are employee ID numbers, home addresses on delivery records, free-text notes (“called back, she mentioned her surgery”), photos, and the “created by” field on every record.
Some categories are more sensitive: health details, financial information, identity documents, and anything about children. These deserve tighter handling everywhere.
A useful exercise is to walk through your main tool and highlight every field that would count. Most teams are surprised. The notes field is usually the worst offender, because people type whatever they know into it.
Collect less
The cheapest personal data to protect is the data you never collected.
For every personal field on a form or table, ask three questions:
- What do we use this for? A specific process, not “it might be useful”.
- Do we need it at this stage? A delivery address is needed once an order ships, not when someone requests a quote.
- Would something less precise do? An age band instead of a date of birth. A city instead of a full address. “Has a valid licence: yes/no” instead of a scan of the licence.
Say your facilities team runs a visitor log. The old sheet captured full name, company, phone, email, car registration and the host’s name. When you check, the only things anyone uses are name, company, host and time in. Car registration is needed only for visitors who park on site. Drop the rest, and make registration a conditional question that appears only when “parking needed” is ticked.
Free-text fields need guidance too. Add a short hint under each one saying what belongs there and what doesn’t. “Notes about the request. Don’t record health or personal circumstances here.” It won’t be perfect, but it changes habits.
Restrict who sees it
Spreadsheets tend to be all-or-nothing: if you can open the file, you can see every column. Proper tools let you do better, and personal data is the main reason to bother. Permissions That Make Sense: Who Should See and Edit What covers role design in general; for personal data, a few specific moves help most.
- Hide fields, not just records. The finance team may need to see every expense claim but not the claimant’s bank details. Field-level permissions or separate views let you show the record without the sensitive parts.
- Separate the sensitive table. If only HR needs emergency contact details, put them in their own table linked to the employee record, with access limited to HR.
- Watch the side doors. Exports, shared links, automations that post record details into your chat tool, and email notifications that include the full record. Each one copies personal data somewhere your permissions don’t reach.
- Review access regularly. People change roles. A quarterly check of who has access to sensitive views takes ten minutes and catches the leaver who still has an account.
Your tool’s audit log, if it has one, is worth turning on. Being able to see who viewed or exported a sensitive record is valuable if something goes wrong.
Be ready for access and deletion requests
In many places, people have the right to ask what data you hold about them, to have it corrected, or to have it deleted. Whether and how these rights apply to you is a question for your adviser, but being technically able to respond is just good tool design.
Picture the request arriving: “Please send me everything you hold about me.” Could you answer it? In a spreadsheet world, that means searching a dozen files, three inboxes and someone’s personal copy of the client list. In a well-designed tool, it should be a search plus a known list of places to check.
Prepare for that by:
- Knowing where personal data lives. Keep a short list of every table and system that holds it. This often overlaps with the inventory from Who Owns This Sheet? Mapping the Shadow Processes in Your Company.
- Linking records to a person. If a customer appears in orders, tickets and feedback, those records should link to one customer record, not repeat their name as text. Then “find everything about this person” is one step.
- Deciding what deletion means. Sometimes you can delete outright. Sometimes you must keep a transaction record but can remove or anonymise the personal fields. Agree the approach per table in advance, ideally alongside your retention schedule from Data Retention: How Long to Keep Records and When to Let Go.
- Logging requests. A simple request register: who asked, what they asked for, when, who handled it, and when it was closed. This is a process like any other, and it deserves to live in a tool rather than an inbox.
Watch the migration itself
Migrations are a privacy risk all of their own. Exports sit in download folders. Test copies of the live system get shared with a contractor. A cleanup file with every customer’s details is emailed “just for a second look”.
Treat migration files as sensitive. Keep them in one restricted location, delete working copies when you’re done, and use fake or anonymised records in test environments wherever you can.
Where to start this week
- Highlight personal fields in your main internal tool, including free-text notes and attachments.
- Pick one form and remove at least one field you can’t justify, or make it conditional.
- Check one side door: find every automation or notification that copies personal data into email or chat, and trim it to a link instead.
- Write down where personal data lives and share the list with your legal or privacy adviser so they can tell you what obligations apply.