GDPR and database access
The GDPR sets out what controllers and processors must do with personal data. It does not require a particular tool and no tool can satisfy it for you. What a tool can do is produce evidence that a technical measure ran: who accessed personal data in a database, who approved it, and what they were shown. QueryProxy helps with that evidence for database access.
This page is not legal or audit advice. Your data protection officer or counsel decides what the GDPR requires of you.
Which GDPR provisions relate to database access?
Three provisions in Regulation (EU) 2016/679 (text read on 2026-10-13 via the article-by-article mirror at gdpr-info.eu):
- Article 32, security of processing. The controller and the processor must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including, where appropriate, pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, and a process for regularly testing and evaluating the effectiveness of the measures.
- Article 25, data protection by design and by default. By default, only personal data necessary for each specific purpose of the processing should be processed.
- Article 5, principles. Personal data must be adequate, relevant and limited to what is necessary (5(1)(c)), and processed with appropriate security (5(1)(f)). Under 5(2) the controller must be able to demonstrate compliance with the principles.
Whether a given measure is appropriate depends on your risk and your context. That judgement is yours.
What evidence can QueryProxy produce?
QueryProxy helps with evidence for these provisions. It does not satisfy any of them alone.
| Provision | What QueryProxy produces | What it does not cover |
|---|---|---|
| Art. 32, security of processing | Developers never hold the production credential, which is stored encrypted (AES-256; see the approval workflow reference). Statements pass a guard and a second person’s approval before they run. An administrator can override the rule against approving your own request, and the override is flagged in the audit log. TOTP two-factor authentication can be required for administrators, DBAs or all users (configuration). | A security assessment of your whole processing, testing of measures, and resilience of your systems. |
| Art. 25 and 5(1)(c), minimisation | Masking rules (full, partial, hash; see the masking reference) are applied to every result value, and to error messages, before storage. A default LIMIT of 1000 and a hard cap of 10000 bound how many rows a read returns (SQL guards). |
Deciding which data is necessary for a purpose. Masking acts on what rules match. |
| Art. 5(2), accountability | An audit log that cannot be edited or deleted through the application: requester, approver, channel, execution, duration, affected rows, result downloads, logins and grants. An Auditor role reads it without seeing result rows. | Your records of processing, policies and the rest of your evidence. |
The dynamic data masking page explains how masking works, and the approval workflow page shows how a request reaches a database.
What stays with your organization?
- Lawful basis, purpose limitation, transparency and consent.
- Data subject requests: access, rectification, erasure and the rest.
- Breach detection and notification. The audit log can help you establish who accessed data (see what an audit trail should record), but you run the process.
- Retention and deletion of personal data. The documentation names no retention period for the audit log, and result files follow a configured period. Note that audit entries record SQL, requesters and client IPs, which can themselves be personal data.
- International transfers, processor contracts and records of processing.
- Data protection impact assessments.
- Securing the host and QueryProxy’s own database.
What are the limits?
- Masking is rule-based. A value no rule matches comes back as stored, and a database user with broad grants can still read broadly. Review rules against your real columns.
- The audit log covers requests made through QueryProxy, not other routes to the database.
- “Cannot be edited” describes the application, not someone with direct access to its database.
- Pseudonymisation as Article 32 mentions it is a wider practice than masking
query output. The
hashstrategy returns a deterministic SHA-256 prefix (see the masking reference), and whether that counts as pseudonymisation for you is a legal question.
When do you not need this?
If the GDPR does not apply to your processing (Article 3 sets the territorial scope: it turns on where the controller or processor is established, and on whether you offer goods or services to, or monitor, people in the EU), this page has little to say to you. If the databases people query hold no personal data, it has little to say either. If one person administers the database and nobody else reaches it, there is no second person to approve. Where analysts only use pre-aggregated, anonymised extracts, access to raw data may not be an issue at all. If you only need to restrict who connects, database roles may be enough; see what database access control is.
Related reading: SOC 2, PCI DSS and ISO 27001.
Frequently asked
- Does QueryProxy make us meet the GDPR?
- No. The GDPR sets obligations on controllers and processors about lawful basis, transparency, data subject rights, security and more. QueryProxy helps with evidence for part of the security of processing, for database access. It covers none of the rest.
- Which GDPR articles does QueryProxy relate to?
- Article 32 on security of processing, Article 25 on data protection by design and by default, and Article 5, specifically data minimisation, integrity and confidentiality, and the accountability principle in 5(2). Whether your processing meets them is for you and your advisers to judge.
- How does masking relate to data minimisation?
- Article 5(1)(c) asks for personal data that is adequate, relevant and limited to what is necessary. Masking limits what a person sees and what is stored in a result, which supports minimisation when the work does not need raw values. It masks only what your rules match.
- Does QueryProxy handle data subject requests?
- No. It does not search, export or erase personal data for access or erasure requests. It records who ran which statement against a database, which can help you show who touched data, but the request process is yours.
- Is QueryProxy a processor of our personal data?
- QueryProxy is self-hosted, so you run it in your own infrastructure. Whether a given arrangement involves a processor depends on your setup and contracts, and this page cannot say. Take that question to your data protection officer or counsel.