Contents
Most personal data protection budgets are spent on attacks from outside. Yet most data leaves through the front door, with permission and good intentions: a business unit asks for a customer list, someone writes the query, the result is saved as a spreadsheet and mailed. There is no bad intent in this flow, but there is no control either.
Why This Is the Widest Leak Channel
There are three reasons. First, volume: these requests are part of daily life and arrive dozens of times a week. Second, invisibility: the request starts in a chat application or a corridor rather than a ticket system. Third, diffusion of responsibility: the requester downloads the data to their own machine, the file travels onwards and nobody tracks where it ends up.
The question an auditor actually asks
An auditor does not ask whether you have data security. They ask how many times data left production last quarter, who requested it, who approved it and which columns were masked. That answer is either in the record or it does not exist.
The Seven Step Process
1. The request record
The query, the justification and the recipient are captured in a single record. The justification must be mandatory, because it is the answer to the auditor's question about necessity. The query text belongs in the record too: the difference between the approved query and the executed one is the weakest point in any audit.
2. Automatic review
The query is parsed and the tables it touches are extracted. A query touching a table marked as critical takes a different approval path. This step must work on statement structure rather than text search, otherwise a subquery or a join slips past easily.
3. Policy based approval
Approval depth should follow the content of the request. An ordinary reporting query can pass with one approval, while a query touching a critical table or asking for unmasked output may need a second. A fixed single step approval makes two mistakes at once: it slows simple requests and underestimates risky ones.
4. Sensitive column detection
Detection should work in two ways. Catalog matching on column names is fast and catches even empty columns. Content scanning finds columns that never made it into the catalog. Relying on only one leaves a gap: content scanning cannot see an empty column, and the catalog misses a column whose name cannot be guessed.
5. Masking and recording the decision
What was not masked must be recorded as much as what was. A system that cannot answer why a given column was left unmasked cannot prove that it masked anything either. Store the decision and its reason per column.
6. Encrypted delivery
The result should be delivered encrypted and the recipient address verified. Delivery to an address used for the first time should require a separate approval, because a typo or a deliberate redirection is usually caught right there.
7. Download tracking
Who downloaded the file and when must be recorded. Without this step the process ends at delivery and you never learn who actually received the data.
How the Masking Decision Is Made
The biggest enemy of masking is the false positive. A system that mistakes an order number for a card number loses credibility quickly and the team turns the rule off. That is why pattern matching alone is not enough; a validation algorithm is needed.
| Data type | Is a pattern enough? | Validation method |
|---|---|---|
| National ID | No, not every 11 digit number is an ID | Check digit rule |
| Card number | No, order numbers can be similar in length | Luhn |
| IBAN | No, similar looking strings exist | Mod 97 check |
| Email and phone | Usually yes | Format check is sufficient |
Another critical point is column aliasing. If the query renames a column, a system that only inspects the returned column name can be fooled. The way to prevent it is to capture the source of the column when the request is saved and use that information at execution time.
Four Objections from the Team
"This process will slow us down." What slows work down is asking a person for every decision, not the process itself. When policy takes the decision, ordinary requests actually speed up because they wait for nobody.
"We cannot work with masked data." Some analyses genuinely need real values. That is why unmasked requests should not be forbidden but placed behind an extra approval. The difference is that the exception becomes visible and countable.
"There is no real data on test anyway." In most organizations that sentence is not true, and even when it is, it should be proven by defining the regime per environment: when a server is relaxed, a justification is written and exempt environments are listed.
"Nobody here has bad intentions." The process is not aimed at bad intent but at accidents and forgotten files. A single email to the wrong address happens in well meaning teams too.
Checklist
- Every data request has a justification and a record
- The approved query and the executed query are identical
- Critical tables are defined and change the approval path
- Sensitive columns are detected by both name and content
- The masking decision is recorded per column with its reason
- Unmasked output requires an extra approval
- Delivery is encrypted and the recipient address is verified
- Downloads are recorded
Frequently Asked Questions
Does managing data requests through a process instead of email slow things down?
It slows things down for the first week and speeds them up afterwards. Over email every request is negotiated from scratch: which columns, who approves, how it is delivered. In a process those decisions are made once and recurring requests flow on their own. The real gain is that it becomes visible who a request is waiting on.
Who should make the masking decision, the database team or the requester?
Neither on their own. Which column is sensitive is a classification decision and it belongs to the data owner; it should be made once and applied on every request. The requester only writes why they need unmasked data, and approving that exception is a separate authority.
Is sending the result file by email safe?
If the file goes in an encrypted archive and the password does not travel on the same channel, it is a reasonable solution. Sending the password in the same email as the file makes the encryption pointless. The strictest approach is to have the file downloaded from the portal and give the password on a separate channel; the choice between them depends on the organisation's risk appetite.
See this flow in action
We will demonstrate the Production Query Governance layer on your own table structure.
Book a Demo →