Mapping Personal Data in a Small Business: Where Is Your Data Actually Stored

A personal data map is a list of the places where information about people actually sits, with a source, an owner and the outbound channels for each. It is an engineering discovery exercise: you start from what the business does on an ordinary day, not from the list of systems somebody remembers buying.

This is a technical description of a working method, not legal advice. What is required of a particular business is a question for a lawyer or for the Privacy Protection Authority.

What the map is, and what it is not

A map is not a policy and not an opinion. It is an inventory: where, what, whose, and where it leaks to. Its value is that a question can be answered from it in minutes instead of opening an investigation, and that holds whether the question comes from a customer, a vendor, an accountant or a lawyer.

• It does not decide what is permitted and what is not.
• It does not replace advice, and it is not a conclusion about whether some duty applies.
• It does record facts that can be checked.
• It does produce a list of focused questions for the right professional.

Israel's privacy protection regulations dealing with information security refer to documentation components such as a database definitions document, an up-to-date inventory of the database's systems, and a diagram of the network it runs in. Those are documentation components; whether they apply to a given business is a separate question.

Where personal data actually accumulates

The surprising answer is that the central system is usually the tidiest place, not the place with the most data. Real accumulation happens at the edges.

• The inbox, holding years of enquiries with names, phone numbers and attachments.
• Messaging threads with customers, including files sent inside them.
• The website contact form, and every destination it sends to.
• Local spreadsheets created for a one-off analysis and never removed.
• Third-party tools for newsletters, support, invoicing or appointment booking.
• Old backups of a system that has since been replaced.
• Personal devices with an app signed into a business account.
• External vendors who touched the data during a project and never deleted it.

The important point: each of those places was created by a legitimate business process. Nobody decided to scatter data. Scattering is a by-product of working, which is exactly why a list of systems does not reveal it.

How do you find copies nobody remembers making?

You start from the process, not from the system. Pick a real event - a new customer, a website enquiry, a quote, a payment - and follow it in practice, step by step, until there is no next stop.

"Nothing" in the last row is the most common finding, and it is not a technical fault but an absent decision. Running this exercise over three core processes usually surfaces more than a week of system review would.

What one row in the map holds

A good row is verifiable. A bad row is a heading. The difference is the fields that let somebody else check what was written.

• The system or place, named precisely enough that it can be found.
• The data categories actually present there, not the ones that ought to be.
• The source of the data: where it came from and through which process.
• Who has access, at a defined permission level.
• Outbound channels: export, interface, manual sending.
• A named human owner, not a department.
• The date the row was last verified.

That last field is what separates a live map from a document. Without it there is no way to tell whether a row reflects today or the day somebody sat down to write it.

What to do with what the map reveals

The exercise produces two kinds of finding, and they are worth separating while you are still writing them down. One kind is operational tidying you can act on immediately with no external decision. The other is a question that needs a professional.

• Tidying: an old file on a shared drive nobody has opened in two years, with no process depending on it.
• Tidying: a permission left open for somebody who no longer holds the role.
• Tidying: an external service you stopped using, whose account is still active.
• Question: whether a given data category may be passed to a given vendor.
• Question: how long a particular kind of enquiry should be kept.
• Question: what has to be documented and what has to be notified.

The first three close inside a week and genuinely shrink the surface area. The last three stay open until somebody qualified answers them, and guessing serves nobody. The real gain from the map is that it separates the two lists instead of leaving one pile of worries.

Why does the map go stale so quickly?

Because it describes behaviour rather than infrastructure. A new tool somebody signed up for free, an integration switched on between two existing services, an employee who started keeping their own working spreadsheet - each moves the map without anybody initiating a technology change.

• A new tool that entered use with no formal decision.
• An integration enabled between two services that were already there.
• A vendor that was replaced, while the copy at the old one stayed.
• An employee who left, whose spreadsheets remain on a shared drive.
• A change to a website form that added a new field.

So the map needs refresh points wired to those events rather than to a date in a calendar. Folding the map update into joining and leaving processes covers a large share of the cases, as described in a cross-team employee onboarding workflow. The distinction between an organised place and a shared pile of files is set out in a digital client folder with access rules and retention.

Sources

• Israeli Privacy Protection Authority
• Full guide to implementing the Privacy Protection (Information Security) Regulations