Our docs make two specific security statements about Que. Data is encrypted at rest using the AES-256-GCM specification, and Que offers field level masking for scrambling sensitive fields. That is the whole documented list, and this page explains what each statement means for a real pipeline, what it does not mean, and which questions you should send us before you put personal data in.
We make Que, so read this as the maker’s explanation. We will stay inside what our own help pages say. Where our pages are silent, we will say so plainly, because a security answer that fills gaps with comfortable guesses is worse than no answer.
What our docs actually say
Que is a web-based application and a datastore with an API. It holds the data your videos are built from, and it holds the list of render jobs. That is why the security question comes up at all. A spreadsheet on a shared drive holds your data, but Que is a service you send data to, so you are entitled to ask what happens to it there.
Our help site makes the main statement in the section written for developers. It says Que offers field level masking for scrambling sensitive demographic data, and that all data is encrypted at rest using the AES-256-GCM specification. Our product page for Que says the same thing in marketing language. It describes end-to-end encryption and field-level masking, where appropriate, and says decryption occurs only when an authorized client requests the data.
Those are our own words about our own product, so weigh them accordingly. They are statements from the vendor. They are not a report from an outside auditor, and this page does not claim any outside certification, audit or compliance standard for Que. If your buyer or your legal team needs one, ask us in writing and use the answer, not this article.
The plan table in the help pages lists data encryption as included in both the Solo and the Team plan. So encryption is not an add-on you have to remember to buy. For current plan details and what each plan includes, see the Que page at dataclay.com/que, because plan terms are the sort of thing that changes and this page will not.
Encryption at rest and field masking are two different tools
It helps to pull these two apart. Encryption at rest protects stored data. Field level masking protects chosen fields inside a job. Both can matter in one pipeline, but they answer different questions.
Encryption at rest answers the question of what is sitting in storage. The data that Que stores is encrypted using the AES-256-GCM specification. Our docs do not describe where the keys are kept, who holds them or how they are rotated, so we will not guess.
Field level masking answers a narrower question. Of all the properties on a job, which ones should be scrambled so that they are not stored as plain readable values? Our campaign help page says you configure this in the Que Dash, per campaign, by choosing specific properties of its jobs to mask or otherwise encrypt. It is a choice you make. Nothing in our docs says every field is masked automatically, and the product page itself says “where appropriate,” so treat masking as something you set up deliberately, field by field.
Here is a detail to plan for. Masked data still has to become a video. The help page says that when Templater retrieves job data with masked properties, it decrypts them immediately before the data displays in a layer or renders into output. The text must be readable when it is drawn into the frame, so the unmasking happens at that point.
Where the data goes between your app and the finished video
A datastore is one stop on a route. To judge your own risk you have to follow the whole route, because a protected stop does not fix an exposed one. Here is the route our docs describe, in order, with the exposure at each step.
First, the data leaves your app or your spreadsheet and goes into Que. You can send it through the Que API, through the Zapier integration, or by inserting jobs from the Que Dash. The sending side is yours to manage. Whatever you export from your own system before it reaches Que is outside anything Que can protect.
Second, the data sits in Que inside a campaign, as jobs. Here the encryption at rest applies, and here you decide which properties to mask. This is the step our documentation covers best.
Third, a machine of yours asks for the jobs. In Que, a render machine that has been added to your account is called a satellite. Templater runs on that machine, profiles it, and sends the profile to Que. The satellite then has read and write access to your Que data. The help page for satellite properties shows an authorization area with the satellite’s ID, its name and the expiration date of its authorization. So a satellite is a trusted participant in your account, and treating it that way is the sensible reading.
Fourth, the machine renders. Per the campaign help page, masked properties are decrypted immediately before they display in a layer or render into output. The finished video file carries whatever text or imagery you put in the frame.
Fifth, the output is saved where you told the satellite to save it. The satellite properties list an output root, which is the directory where the satellite saves output. Who can read that folder is something to check on your side, since our docs do not describe it.
Data route
Where your data travels, step by step
-
Data leaves your appYou send it through the Que API, through the Zapier integration, or by inserting jobs from the Que Dash.
-
Data sits in QueThe data sits in Que inside a campaign, as jobs.
-
A satellite fetches the jobsA render machine added to your account is called a satellite.
-
The machine rendersMasked properties are decrypted immediately before they display in a layer or render into output.
-
Output is savedThe satellite saves output to the output root, the directory where the satellite saves output.
The two exposures that masking cannot touch
Masking cannot hide something that you deliberately print into the video. If a personalized video says a member’s name and a milestone, the video contains that name and that milestone. Anyone who receives the file can read it. This is the point of the video, and it is worth stating because it is easy to overlook when attention is on the datastore.
Masking also cannot protect a file path that you handle carelessly. We have a separate article on passing asset URLs into render jobs, and its core point is that the link itself is the secret: whoever can read the row can fetch the file. If a job holds a link to a private asset, then the question is who can read that job, and masking that property is one option to ask us about. Read that article, how to pass dynamic asset URLs into a render job without exposing credentials, before you design a pipeline around private files.
Controls you hold: roles, satellites and tokens
Encryption is something we operate. Access is something you operate, and our docs give you several levers for it.
The first lever is roles in the Que Dash. The help page lists four. An account owner and an administrator have read and write access to satellites, campaigns and templates. A collaborator has read access to satellites, campaigns and templates, and no plan control. A billing admin has no access to satellites, campaigns or templates. Only the account owner can remove users from the organization. The practical use is simple. Give each person the lowest role that lets them do their job, and keep the account owner role to as few hands as your organization allows.
Que Dash roles
What each role can access in Que
| Role | Access to satellites, campaigns, templates | Unique permission |
|---|---|---|
| Account owner | Read and write | Only role that can remove users from the organization |
| Administrator | Read and write | No unique permission stated |
| Collaborator | Read only | No plan control |
| Billing admin | No access | No access to satellites, campaigns or templates |
The second lever is the satellite itself. Our API documentation says a satellite token is long lived, so you should keep it secure and private on the machine that requested the authorization, and never share it. If you believe a token has been compromised, revoke the satellite’s authorization and then authorize again to get a new token. When you no longer want a machine to reach your data, you can remove the satellite. The help page recommends removing it with Templater, because that clears the security tokens from both Que and the host machine. If you remove it from the Que Dash instead, you can clear the host machine’s profile in Templater later. Any jobs assigned to a deleted satellite become unassigned.
The third lever is the shape of the data. This one is general practice, not a documented feature. The cleanest way to protect a personal field is to not send it. If a video does not need a customer’s birthdate, leave the birthdate out of the job. A field that never entered the datastore cannot leak from it. Masking is for fields the video genuinely needs but that you do not want sitting readable in storage.
Before you go live
Steps to take before loading real customer records
- Leave out any field the video does not need, a field that never entered the datastore cannot leak from it
- Configure masking in the Que Dash, per campaign, for fields the render needs but storage should not show
- Give each person the lowest role that lets them do their job
- Keep the satellite token secure and private on the machine that requested the authorization, and never share it
- Remove a satellite with Templater when you no longer want a machine to reach your data, so security tokens are cleared from both Que and the host machine
- Put unanswered questions, key management, data hosting region, DPA, audit reports, to us in writing before a real customer record goes in
A hypothetical example
This example is invented, to make the choices concrete. Picture a gym that sends each member a progress video. The job for each member has five properties: first name, number of visits this month, a goal the member chose, a membership tier and an email address used by the marketing system.
The video draws on four of them. First name, visits, goal and tier appear in the frame. The email address is there only so the marketing system can match the finished file to the member. Walk through the decisions.
The email address does not belong in the video at all, so ask whether it needs to be in the job. If your marketing system can match on some other identifier, drop the email from the job and the question disappears. If it truly must travel with the job, it is a good candidate for masking, because nothing in the render needs it readable.
The goal is the sensitive one. A member who chose a goal about weight or a health condition may not want it spoken or shown in a file that gets forwarded. Masking will not help here, because the goal is printed in the frame by design. The decision belongs to your team and to the member’s consent, not to a setting. Masking protects the stored job. It does not make a visible caption private.
First name, visits and tier are the plain fields. Mask them or not, depending on your own policy.
The example shows the real use of the feature. Masking applies to the stored job. It does nothing about what the finished video says, and it cannot replace the decision to leave a field out.
What our docs do not say, and what to ask us
A fair security page includes its own gaps. These are the questions our saved help pages do not answer. We list them so you can ask them, not so you can assume the answers.
Where is the data hosted, and in which region? The docs call Que cloud-based, and that is the extent of it. Who at Dataclay can read stored data, and under what process? The docs say decryption occurs only when an authorized client requests the data, which describes the design but not the internal access policy. How are the encryption keys managed? What happens to your data when a plan is canceled? Does the free Que account get the same encryption as the paid plans, given that the plan table covers Solo and Team only? Is there a security questionnaire, a data processing agreement or an audit report available to your buyer?
These are the questions a security reviewer will ask, so send them to us before the review, not during it. You can reach the team at the sales address listed on the Que plan page, and you can read the broader framing in our article on security and compliance requirements that force video production on-premise. That article is explicit that we cannot tell you which requirement applies to you. That is a question for your own security or compliance team, and nothing here is legal advice.
If your requirements say the data may not leave your own network, then a cloud datastore is the wrong tool and no masking setting changes that. Our article on choosing between cloud and on-premise video automation lays out that decision, and it is honest about when the answer is to keep everything in-house. Templater can read from a spreadsheet or another data source without Que at all, and for some teams that is the better fit.
Bottom line
Que encrypts stored data with AES-256-GCM and lets you mask chosen job fields, and both statements come from our own docs. Neither is a certification, and neither protects a name you print on screen. Use masking for fields the render needs but storage should not show, leave out everything the video does not need, hold roles and satellite tokens tightly, and put the unanswered questions to us in writing before a real customer record goes in. To understand how Que fits with Templater first, start with what Que is in Templater.
That covers what the docs say. If you are still weighing whether to send personal data to Que, these are the questions to settle first.
Frequently Asked Questions
Does Que encrypt the data I store in it?
Our help pages say all data in Que is encrypted at rest using the AES-256-GCM specification, and the plan table lists data encryption as included in both the Solo and Team plans. The pages do not describe where keys are held or how they are managed. If your security review needs that detail, ask us in writing before you load real customer records, and treat our answer, not this page, as the record.
What is field level masking in Que?
It is a way to scramble sensitive properties of the jobs in a campaign. In the Que Dash you configure a campaign to mask, or otherwise encrypt, specific properties. Templater decrypts a masked property immediately before it displays in a layer or renders into output. You choose the fields, so it is a setting you configure and not something that happens to every field on its own.
If I mask a field, is it hidden in the finished video?
No. Masking applies to the stored job. When Templater renders, it decrypts the masked property right before it is drawn, so any text you place in the frame is readable in the video. If a field should not appear on screen, leave it out of the template. If it must appear, masking will not make the printed result private.
Is Que certified for any compliance standard?
This page makes no such claim, and the help pages we have do not state one. We will not imply one here. If your buyer requires a specific certification, audit report or data processing agreement, ask us directly and rely on what we send you. Your own security or compliance team decides whether that is enough for your situation.
Who inside my team can see the data in Que?
That depends on roles in the Que Dash. Account owners and administrators have read and write access to satellites, campaigns and templates. Collaborators have read access to them. A billing admin has no access to those areas. Only the account owner can remove users. Give each person the lowest role that fits the job.
What should I do if a render machine is lost or compromised?
Remove the satellite, and revoke its authorization if you believe the token is compromised. Our docs recommend removing a satellite with Templater, because that clears security tokens from both Que and the host machine. Jobs assigned to a deleted satellite become unassigned. Authorize again from a trusted machine to get a fresh token.
