A participant registers for a programme.
Their name and email arrive through an online form. The information moves into a spreadsheet or project platform. Someone downloads an attendance list. An email system sends confirmation messages. Analytics record activity. A supplier hosts the platform. Backups are created somewhere in the background.
Months later, somebody exports the participant list for another task. A colleague uses an AI assistant to summarise feedback. The original record is eventually deleted.
So where is the data now?
That question is much harder to answer than it looks.
Most organisations can tell you why they collect personal information. Many have privacy policies, retention periods, supplier agreements and internal procedures. Yet when we move away from the documentation and follow one piece of information through the infrastructure itself, the picture often becomes considerably less tidy.
The problem is not necessarily poor intentions or careless staff. Modern digital work simply creates more pathways than most people see from the interface.
Personal data rarely stays where it entered
We still tend to imagine data collection as a fairly linear process.
Information enters a system, somebody uses it for an agreed purpose, it remains there for a defined period, and eventually it is deleted.
Actual digital systems rarely behave so neatly.
Data can move through integrations, authentication systems, analytics services, email platforms, suppliers, subprocessors and automated backups. A colleague may export it. Another platform may receive a copy. Logs may contain identifiers. An existing supplier may quietly introduce an AI feature into a tool that was originally purchased for something completely different.
None of those events necessarily represents a privacy violation.
But together they create a governance problem: the organisation may know what it intended to do with the data without having a complete view of what its infrastructure is actually doing with it.
That difference matters.
A privacy policy can tell us that personal information will be deleted after a particular period. It cannot, by itself, tell us whether a backup still contains a copy, whether an old export remains on somebody’s device, whether an integration retained its own version, or whether the organisation could recover all of those copies if somebody exercised a deletion right.
The written rule and the operational reality are related, but they are not the same thing.
The hidden layer is increasingly the important one
This is a pattern we keep encountering when looking at digital systems.
The visible application is usually only the first layer.
Behind it may sit cloud infrastructure, identity services, analytics, APIs, external suppliers, security tools, telemetry and other dependencies that the ordinary user never sees.
That matters for privacy because every additional layer can introduce another question.
What information reaches it?
Why?
Who controls it?
How long is it retained?
Where is it processed?
Can the organisation retrieve it?
Can it delete it?
What happens when the relationship with that supplier ends?
These are not exotic technical questions reserved for large companies with enormous compliance departments. A small association using a registration form, an email platform, a cloud drive, a project-management tool and an AI assistant can already have a surprisingly complicated data infrastructure.
The number of systems involved matters less than whether anyone understands how they connect.
AI has made the map even harder to ignore
Artificial intelligence adds another reason to look at data flows more carefully.
For many organisations, AI did not arrive through a formal decision to build an AI system. It arrived through everyday tools.
A staff member began using an assistant to draft emails. A meeting platform introduced automatic summaries. A software supplier added an AI feature. Somebody uploaded a document to obtain a faster analysis.
The workflow changed before the organisation necessarily considered the data implications.
This creates a very practical question for responsible AI governance:
What information is reaching AI systems, and through which route?
That cannot always be answered by maintaining a list of approved AI tools. An AI capability may exist inside a platform already in use. Information may move through an API rather than a visible chatbot. Suppliers may rely on other providers further down the chain.
Understanding AI use therefore increasingly requires understanding the wider data infrastructure around it.
Privacy, supplier governance and responsible AI are becoming much harder to separate.
Deletion is often where the real architecture becomes visible
One of the most useful tests of whether an organisation understands its data is not asking how the information enters.
Ask how it leaves.
Suppose a participant asks for their information to be deleted.
The record disappears from the main platform.
Is the job finished?
Perhaps.
But perhaps the information also exists in a downloaded attendance sheet, an email tool, an analytics service, a backup, a connected application or an archived project folder.
The point is not that every copy must necessarily disappear immediately. Different systems can have legitimate retention requirements, and backups often operate according to separate technical schedules.
The important thing is whether the organisation knows those copies exist and understands what happens to them.
The same applies when leaving a supplier.
Can the organisation export its information in a usable form? What remains after the contract ends? Are backups eventually removed? Does another integration still depend on the old platform? Is there evidence that deletion has taken place?
We tend to think of exit as a procurement issue.
It is also a privacy issue.
Privacy is partly an infrastructure problem
This is why we increasingly think privacy work needs to move beyond the question, “Do we have the correct documentation?”
Documentation matters enormously. GDPR accountability depends on it.
But good documentation cannot substitute for visibility.
An organisation needs to understand where personal data is collected, where it travels, which systems touch it, which suppliers are involved, where additional copies are created and what happens at the end of the lifecycle.
That is essentially what data mapping is meant to provide.
A useful data map is not simply an inventory of databases. It shows the relationships between people, systems, suppliers and processing activities. It makes dependencies visible and gives teams somewhere to record the questions they cannot yet answer.
Sometimes those unanswered questions are the most useful part.
“We do not know whether the supplier retains this after deletion” is far more valuable operationally than quietly assuming it does not.
“We need IT to confirm what is contained in the backup” creates an action.
“We discovered this export is still being created manually” gives someone something concrete to review.
Visibility turns uncertainty into work that can be owned.
Following the data instead of the policy
That is the idea behind the Data & Privacy Infrastructure Map we have now added to REDefine’s resource collection.
The workbook starts from a simple premise: choose a real data flow and follow it.
Where is the information collected? Where does it go? Who can see it? Which suppliers and integrations are involved? Does telemetry capture any of it? Does it reach an AI system? What happens in backups? How is it exported? What does deletion actually mean? And what happens when the organisation eventually leaves the system altogether?
The purpose is not to produce another immaculate compliance document.
It is to discover the places where the infrastructure is less well understood than the policy suggests.
The 21-page interactive workbook includes structured review fields, status controls, worked examples, action planning and a final review summary so unresolved questions can become decisions with owners rather than observations that disappear after the meeting.
For us, that distinction is important.
A policy describes what should happen.
A map gives you a chance to find out what does.
The Data & Privacy Infrastructure Map is available through the REDefine Member Library for paid subscribers. If you do not want a membership, the workbook can also be purchased individually on Gumroad.
Explore the Data & Privacy Infrastructure Map →
or
And perhaps before opening it, try the simplest version of the exercise yourself.
Pick one piece of personal information your organisation collected this week.
Then follow it.
You may be surprised by how quickly one line becomes a network.
