The Life of a File That Leaves Production: Where Is That Customer List Now?

On Tuesday morning an email arrives from marketing: "For Friday's campaign we need the list of customers who bought in the last three months. Name, email, phone, last order value." An analyst writes a query, runs it, saves the result into a spreadsheet and sends it by email. Five minutes. The campaign goes well. Now the question: where is that file at this moment?

The Moment of Exit Is Managed, What Follows Is Not

Most organisations try to answer "who asked for the data": a ticket, an approval, sometimes a reason. That is good. But once the file has left the story ends, because no system follows its life. The file is saved on the analyst's desktop, emailed to the marketing specialist, uploaded to a shared drive and copied to a folder shared with the agency. The campaign ends. Nobody deletes it.

This picture is not imaginary. In a breach at a large financial cooperative in Canada, an employee with limited access to the data warehouse reached the data because other employees had regularly copied the same data to a shared drive as part of their work. The privacy commissioner recorded this as a lack of access control and data separation. About 9.7 million people were affected.

The Picture From Turkey in September

In September 2026 the Turkish data protection authority announced 44 data breach notifications. In all 28 notifications of the first wave, the breach occurred not in the data controller's own systems but at a data processor it used. Most were in e-commerce infrastructure. The picture shows one thing: even if data is kept within the organisation's boundaries, every place it goes to starts another chain of responsibility, and at every link of that chain the questions of where the data came from and who took it can go unanswered.

Five Questions for the Life of a File

1. Who asked and why? Is the reason written down, or is it a chat?
2. Which columns went? Did the marketing list need the full ID number, or were email and name enough?
3. Who was the file delivered to, and how? An email attachment or a link?
4. How long will it stay? Does the file disappear by itself when the campaign ends?
5. Who downloaded it, and when? Is the file something that can be passed around like a key, or is every download recorded?

How Can a Single Route Answer These Five Questions?

Let exit happen through a single channel and let that channel manage the file's life too:

• Request and reason. The person asking for data opens the request and writes the reason. Which columns will be returned is visible before the query runs.
• Sensitive columns are masked. ID number, card, IBAN, phone; if the campaign list does not need them they never leave.
• Delivery is an encrypted package. In the default mode the package goes as an email attachment, but the password does not travel by email: it is shown only in the portal against a written reason. The organisation can choose "portal only", in which case the file does not enter email either. There is also a looser mode where the password and file travel in the same email, but it demands a written reason on every request.
• A new recipient address needs a separate approval. For an address used for the first time, the default policy adds an approval step. The organisation can switch this policy off; while it is on, the risk of going to a wrong address is reduced.
• The file has a retention period. When it expires the file is deleted and the deletion is recorded too.
• Every download is recorded. Who downloaded it, from which address, for what reason. The same report shows that the file was deleted when it expired.

So part of the question "where is this file now" is answered: while it is in our hands we know where it is and when it was deleted.

The Query Size Needs a Limit Too

There is one more question: "How much data fits in the query?" In the rule catalogue a finding is raised for result queries with no row limit by TOP or FETCH NEXT. This makes it visible when a whole customer table goes into a file in one go. The rule is not a leak prevention measure, but it makes the difference between "the whole table" and "a sample" visible on the approval screen.

The Honest Limits

• Copies made after download are outside the product. If someone downloads the file and uploads it to a shared drive, the product does not see that. So a short retention period, encrypted delivery and masking should be considered together: what leaves should already be reduced.
• Knowing who the file was sent to is not knowing what the recipient will do. An approval step for a new address reduces the risk of going to a wrong address; it does not remove the recipient's own responsibility.
• The data is not tracked end to end. The product follows the data for as long as it holds it. Its life outside is a separate layer: data loss prevention and endpoint protection.

Frequently Asked Questions

Does the encrypted file go by email?

In the default mode the encrypted package goes as an email attachment, but the password does not travel by email; it is shown only in the portal against a written reason. If the organisation chooses "portal only", the file does not enter email either.

How long is the file kept, and can you see who downloaded it?

The file has a retention period; when it expires the file is deleted and the deletion is recorded. Every download is recorded with who, from which address and for what reason, and appears in the "Data Access and Export Log" report.

Does the product see it if the downloaded file is copied somewhere?

No. Copies made after download are outside the product. That is why masking, encrypted delivery and a short retention period should be considered together. Its life outside is a matter for data loss prevention and endpoint protection tools.