Choose a language:

Security, privacy & availability at Queue-it: Frequently asked questions

Published:
Stairs with lock on top of them

Virtual waiting rooms are a powerful tool to control your online traffic. But if you’re going to implement one, you need to make sure it meets your standards for security, privacy, and availability. In this article, you’ll get answers to the most common security and compliance questions our customers ask us before choosing Queue-it as their virtual waiting room provider.

We’re in the business of high-demand events. Some of the world’s biggest companies trust Queue-it to protect their sites on their busiest days.

It’s a big responsibility, and one we take very seriously. That’s why we set extreme standards for security, availability, and privacy—and spend a lot of time and money ensuring we live up to those standards.

We’re proactive about security and reliability because the high-volume, high-visibility events we work with attract a lot of attention—both from genuine customers and bad actors. These events can be magnets for malicious activity, with huge profit incentives for abuse.

And we're strict on privacy because we work with companies and organizations across industries that handle sensitive data, such as the public sector, banking, insurance, telecommunications, and air travel.

In this article, you'll get answers to the most common security questions our customers ask, including how we ensure the availability and security of our platform, how Queue-it processes and handles customer data, and how we protect ourselves and our customers from outages and attacks.

Table of contents

 

How does Queue-it ensure the security of the platform?

1. Penetration testing

To detect and mitigate any potential security vulnerabilities within Queue-it, we run bi-annual penetration tests with independent cybersecurity company Intigriti. These tests involve experienced ethical hackers doing their best to find and exploit vulnerabilities in Queue-it’s systems.

The findings of these pen tests are acted on immediately, if necessary. They’re also documented in detailed reports that are available to customers on request.

On top of pen testing, we run a private bug bounty program, which offers a bonus to any ethical hacker if they find any vulnerabilities within our systems.

These two ongoing practices ensure we detect and mitigate any potential security vulnerabilities before malicious actors do.

2. 24/7 monitoring & incident response team

To ensure we can act fast to control any potential malicious activity, we’ve set up comprehensive monitoring that notifies us immediately of any anomalous activity or behavior within our systems, such as an unexpected login or someone getting access to our production environment.

We have a dedicated and experienced incident response team who work 24/7 across our global offices to ensure any potential incidents are acted on and resolved swiftly.

3. Managing open-source vulnerabilities

Open-source software is an increasing source of security risk for companies. At Queue-it, we take several steps to avoid open-source code introducing risk. These include:

  • Open-source policy: a strict policy with instructions on what types of licenses we accept on open-source libraries.
  • Open-source code scanners: we use several tools to detect all use of third-party libraries, any security issues in these libraries, and that scan daily for vulnerabilities in our code base.

 

4. Cybersecurity training & best practices

Software isn’t the only potential attack route for cyber criminals—they’re also increasingly targeting employees. That’s why all Queue-it employees have gone through mandatory cyber security training, comprising of e-learning and classroom training.

To apply this knowledge, we run in-house phishing simulations to build awareness and ensure employees remain vigilant.

To further reduce risk, Queue-it bases the ability to access and change data on the principle of least privilege (PoLP). For example, in recent years we’ve severely decreased access to our AWS production environment. By minimizing the number of people who have access to data and who can view and edit production code, we minimize the risk of both human error and abuse from bad actors.

Additionally, Queue-it employees are required to use a secure password manager with strict rules for passwords and multi-factor authentication (MFA). All internal and third-party services used by employees are accessed via single sign-on (SSO) where possible.

5. Multi-factor authentication & SSO

Brute force attacks and credential stuffing aren’t just a risk for our employees—they’re also a risk to our customers.

That’s why customers using the GO Queue-it Platform can set up MFA through an authenticator app or through a phone text message. To avoid brute force attacks, user accounts get temporarily locked after five failed login attempts.

We’ll soon launch an SSO option for the GO Queue-it Platform, to further comply with our customers’ requirements and boost security.

Additionally, when setting up a Queue-it account you can choose from varying levels of privileges to adhere to the principle of least privilege. These include:

  • Read-only: Can only see data, but not make any changes to settings
  • User: Can alter data, but cannot change users and security settings
  • Admin: Can modify data, users, and security settings
  • Owner: Privileged admin account that can create and delete sub-accounts

The GO Queue-it Platform is also equipped with detailed change logs and notification features, so you can monitor activity within your Queue-it account.

How does Queue-it protect sensitive data & ensure compliance?

1. Limiting access & storage

Queue-it’s approach to sensitive data, first and foremost, is to limit our own access to it. By default, Queue-it processes a very limited amount of personal data, and no sensitive personal data, such as name, identification, or login details.

Queue-it runs 100% isolated from our customers’ infrastructure, meaning there’s no data transport between our customers’ web pages and Queue-it. Our interaction with your system is as though your site visitor enters the Queue-it URL in their browser, waits, and then enters the URL for your website.

This means Queue-it only accesses the information transported by the browser, such as device type, IP address, and browser version. This browser data is collected to provide our customers with traffic analytics, but follows strict encryption, access, and deletion policies.

2. Data encryption & automatic deletion

In some cases, our customers need us to collect more sensitive personal data, such as email addresses. This is the case, for example, when customers use our email notification feature, which notifies visitors when they reach the front of the queue. Emails are also collected with our invite-only waiting room, which allows site access only to verified visitors.

All visitor data—both sensitive and otherwise—that gets processed and stored by Queue-it is encrypted, both in transit and at rest. At rest, we use AES256. In transit, we use TLS 1.2 or TLS 1.3 with strong cipher suites. In the unlikely event that someone with malicious intent gets access to Queue-it’s database, the data is indecipherable and unusable.

As stated, internal access to data is also given based on the principle of least privilege—meaning very few internal staff have access.

Additionally, all sensitive data, such as email addresses, that Queue-it processes gets automatically deleted after 90 days. Customers can also choose to delete this data at any time.

3. Transferring data regionally to ensure compliance

We operate in four different AWS regions to comply as much with possible with local legislation, and any Queue-it customer can freely choose where to place their data.

You can choose whether your data is transferred through data centers residing in the European Union, the United States, Brazil, or Japan, based on your requirements and regional requirements.

Queue-it is fully compliant with major global data protection regulations, including GDPR, CCPA, HIPAA, and PCI DSS legal frameworks.

How does Queue-it safeguard against outages or attacks on ourselves & our customers?

1. Protecting our systems

Queue-it is bound to strict availability SLAs. It’s in both our own and our customers’ interests to protect against attacks, surges in activity, and outages. That’s why reliability and availability are our top priorities in system design and development approach.

Like many businesses, we use DDoS protection, web application firewalls (WAFs), uptime monitoring, and a highly available and scalable domain name system (DNS) service.

But we’ve also made and continue to make many not-so-common decisions that prioritize the availability of our systems over things like cost and speed-to-market. We work with the “design for failure” approach, which means our software is built with the assumption that it will fail, and as such is designed to limit the blast radius of any issues and to be self-healing.

Some of unique practices and processes we take to ensure extreme availability include:

  • Multiple availability zone architecture: In each region Queue-it has data centers in, it is deployed across at least three availability zones. This allows Queue-it to remain available in the unlikely event of two availability zones failing at the same time.

  • Cell-based architecture: Each Queue-it customer has at least one dedicated subdomain and load balancer entry point which handles traffic and distributes load. This ensures potential attacks on one customer cannot impact other customers, and enables us to incrementally deploy new releases.

 

Graphic showing Queue-it's fault tolerant, cell-based architecture

Queue-it's availability zones (on the left),
and cell-based architecture (on the right).

  • Aggressive autoscaling: Our autoscaling is configured to be highly aggressive, which can increase costs, but allows us to scale extremely fast when traffic starts to rise.

  • Regular load testing: We regularly load test our systems with huge volumes of traffic (up to one million virtual users per minute) to ensure it can handle extreme surges in activity.

  • Redundancies: In every spot where there’s potential for failure or insufficient resources, we have redundancies in place.

  • Microservices architecture: Queue-it’s solution is made up of multiple microservices designed to limit the blast radius of failure within one component. For instance, our admin platform is completely detached from our end-user-facing queue service.

  • Simplified architecture: We prioritize simplicity in our architectural approach, because the simpler our architecture is, the simpler it is to scale. All systems are purpose-built to minimize dependencies and single points of failure, which may make us slower moving than some companies, but lets us maintain extremely high availability.

  • Minimal third-party usage: Aside from AWS, our service relies on very few downstream services to operate—to minimize the risk of third-party outages.

  • Fire drill days: The Queue-it DevOps team conducts fire drill days to simulate various system faults and ensure the backup and restore processes are efficient and accurate.

 

2. Protecting our customers' infrastructure

All the work we put in to safeguarding our own systems against attacks and outages enables us to do the same for our customers. We’re responsible for controlling the flow of traffic to our customers’ sites, and we can only do that if our systems remain available and operational.

Queue-it isn’t a DDoS protection or cybersecurity tool. But by controlling our customers’ site traffic and absorbing large spikes in visitors, we ensure their sites aren’t brought down by surges in activity—both genuine and malicious. So if your site is hit with extreme load or a DDoS attack while Queue-it is activated, that load is absorbed by Queue-it’s highly scalable and resilient infrastructure.

45% of online businesses say bot attacks result in more website and IT crashes. That’s why, alongside traffic control, we protect our customers (and their customers) from the threat of bots and abuse with our multi-layered suite of bot mitigation tools.

The virtual waiting room acts as a security checkpoint, allowing you to run checks on visitors before they access your site. These checks include data center blocking, Proof-of-Work challenges, CAPTCHA tests, anomaly detection, traffic access rules, queue tokens, and the invite-only waiting room.

RELATED: Bots & Abuse Protection: Serve Real Customers, Not Bad Bots

Customers with these features enabled see dramatic reductions in malicious bot activity during high-profile online events. For example:

By blocking bots and bad actors, Queue-it not only helps keep our customers’ websites online and secure in the face of unprecedented demand, it also creates a fairer experience, reduces infrastructure costs, reduces support and operational costs, and protects their reputation.

Additional security & availability resources

If you couldn’t find the answers to your security, privacy, or availability questions in this article, you can check out our technical white papers, which include in-depth information on:

And if you’ve got a more specific question or just want to learn more about the Queue-it, you can contact us here.

(N.B. The information in this article is accurate as of October 2024.)

Still got questions about Queue-it?