GDPR: Is it possible to decrypt sensitive fields only at visualization layer in Qlik Sense?
We are working on implementing GDPR-compliant data handling in a Qlik Sense application and need clarification on a specific requirement.
Our current architecture is:
Data is encrypted at source (e.g., MySQL/MariaDB using AES encryption)
Encrypted data is stored in QVDs and loaded into the data model
Sensitive fields include name, email, username, etc.
The requirement we are trying to meet is:
Decrypted values should not be exposed in the Qlik script or data model at any stage, and should only be visible at the visualization (sheet) level for authorized users.
We have explored:
SQL-based decryption using AES_DECRYPT → but this exposes decrypted data in the load script
Mapping / join approaches → same limitation
Section Access → controls access but does not prevent exposure in the data model
Our questions:
Is there any native capability in Qlik Sense to decrypt or transform data only at visualization/render time, without exposing it in the script or data model?
Can this be achieved using:
REST Connector (on-demand API calls from charts?)
Dynamic expressions or extensions?
What would be the recommended architecture in Qlik for this requirement?
Given our environment includes many dynamic databases (1000+), solutions requiring database-level objects (like views/functions per DB) are not ideal.
We are trying to understand whether this requirement is achievable within Qlik itself, or if it necessarily requires an external API/service layer for controlled decryption.
Any guidance or real-world implementation examples would be very helpful.
@adityasshd , is it possible to reframe your core requirement? What you currently list as a requirement is framed more like a solution. Is the main requirement that the application/dashboard developers cannot have access to the sensitive data? There are other ways to solution for that than trying to decrypt during presentation. If your requirement is to limit access to sensitive fields for only specific end users, that also has other solutions. If you're looking to reduce the risk of exposing sensitive data outside your organization, there are specific solutions for that as well.
@mshann01, thanks for the reply. To give you some context on why I'm looking for this specific solution:
Our requirement is actually driven by a strict "Zero-Knowledge" policy. In our setup, the Qlik Data Model (the RAM and the QVDs) is treated as a storage layer. My compliance team doesn't allow decrypted PII to sit in the data model at all, even if it's hidden by Section Access. We need the data to stay as ciphertext until the very second it hits the user's screen.
Because I have to manage over 1000 dynamic databases, I can't really go with database-level views or complex Mapping Loads in the script. Instead, I’ve been working on a "side-car" approach:
Ciphertext in Model: I keep the fields (email, name, etc.) encrypted in the Qlik app.
External API: I have a secure API that handles the decryption.
Custom Extension: I’ve built an extension that identifies which IDs are currently visible in the user's table viewport, fetches the cleartext from the API, and then uses a "dynamic patch" to overlay that data onto the native Qlik object.
It’s working well in my initial tests, but I’m curious if anyone here has run into issues with this kind of approach—specifically regarding engine performance or limits on how large those dynamic "Pick(Match())" expressions can get before they start causing timeouts for users.
I’d love to hear if there’s a more "native" way to intercept the data at the render level, but so far, this API-to-Extension path seems like the only way to keep the cleartext out of the engine entirely.
I have implemented almost everything, with only thing remaining is Realtime tracking of scrolling and table update to get the visible record range.
I don't understand how Section Access would not handle this. What do you mean that the data would be exposed in the data model? Are there field names with sensitive information (e.g. a field like [John Doe])?
On the issue of not exposing data in the script, perhaps you could use an include statement to protect sensitive information in the script:
Are you using Qlik Cloud? Or QSEoW? I work in a strict healthcare environment utilizing the BYOK/CMK for Qlik Cloud and in the US, it's got the basics covered to be compliant with our PHI/PII regulations.
Qlik Clouduses the following encryption standards:
In transit—TLS 1.2 encryption
At rest—AES-256-GCM encryption
Within the platform (after authentication with a designated IdP)—Signed JSON Web Tokens (JWTs) to ensure integrity, authenticity, and non-repudiation
