Security and privacy

How we protect the data entrusted to us

QueuePower processes personal data on behalf of its customers. Under the UK GDPR and the EU GDPR, your organisation is the controller and we are the processor. The data we hold on your behalf comprises the content of support conversations, the names and email addresses of the customers who raise them, any account context you choose to attach, and the analysis the AI produces from that material. We do not request payment card details, identity documents or other special-category data. Should a customer include such information in a ticket, it is subject to the same safeguards described below.

Data location. The database and application servers are located in the United Kingdom (AWS London and Vercel London). Two subprocessors process a limited category of data outside the United Kingdom; both are identified on the subprocessor list together with the data each receives.

Two principles

The design rests on two safeguards that apply regardless of configuration.

Each organisation's data is isolated at the database

All customers are served from a single deployment, but the database enforces the separation. PostgreSQL row-level security policies apply to every read, write, update and delete on every table that holds customer data, and the application connects under a role that cannot bypass those policies. A query that omits the tenant condition returns no rows. This protection does not depend on the application code being correct.

Personal identifiers are withheld from the AI provider

Before any ticket content is submitted for AI processing, customer names and email addresses are replaced with placeholders. The original values remain in our database and are reinstated in the draft only after the response has been received. This safeguard is applied to every request and cannot be disabled for an individual organisation.

Technical and organisational measures

Encryption

Customer email addresses and all stored third-party credentials (CRM tokens, mailbox refresh tokens and IMAP passwords) are encrypted with AES-256-GCM at the application layer before being written to the database, in addition to the storage provider's encryption of data at rest. Lookups by email address use a one-way hash, so no plaintext address is held in an indexed column. All traffic is encrypted in transit.

Authentication and access control

Sign-in runs on a dedicated identity provider (named on our subprocessor list), with organisation-level membership, short-lived session tokens, email verification when a new device signs in, lockout after repeated failed attempts, bot protection on sign-up, and cookies restricted to HTTPS. Roles (administrator, manager and agent) and individual permissions are held in our database and enforced on the server for every action, independently of the user interface.

Audit trail

Every configuration change and every action taken by a person or by the AI is written to an append-only audit log, with the state before and after the change. Administrators may export the log in CSV format at any time. Audit records are retained when the underlying record is deleted, so the history remains complete.

Public endpoints

The hosted support form, customer-satisfaction links, the intake API and all webhook receivers verify signatures using constant-time comparison, reject replayed requests, limit request size and apply per-organisation rate limits. Security headers, including HTTP Strict Transport Security, frame denial, content-type protection and referrer and permissions policies, are sent with every response.

Data-subject rights

As processor, we assist your organisation in responding to requests from the individuals whose data it holds. Requests received directly from those individuals are referred to you as controller.

Measures in place

Tenant isolation by row-level security under a non-bypass database role, verified by an automated cross-tenant test suite
Application-layer encryption of customer email addresses and stored credentials
Placeholder substitution for personal identifiers before every AI request
Complete audit log with CSV export
Deletion from all application read paths on request, with a 30-day recovery period before permanent removal
Signature verification, replay protection and rate limiting on every public endpoint

Handling of requests

Access and portability (Articles 15 and 20): a structured export of your organisation's data, provided on request within one month.
Erasure (Article 17): records are removed from every application read path on request and permanently deleted after a 30-day recovery period. Each request is recorded in the audit log.
Rectification and restriction (Articles 16 and 18): carried out within your workspace, or on request.
Personal data breach: you will be notified without undue delay, and in any event within 48 hours of our becoming aware.
Requests should be sent to the privacy address on our contact page.

Standards and frameworks

Our controls are designed and assessed against the following.

UK GDPR and EU GDPR
OWASP Application Security Verification Standard 4.0.3
SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Privacy)
NIST Privacy Framework
CIS Controls v8

Subprocessors

We engage 6 subprocessors to provide the service, each under written data-processing terms, together with any mailbox provider your organisation elects to connect. The full list, with the purpose and location of each, is published and maintained.

View the subprocessor list

Security concerns or suspected vulnerabilities may be reported to security@queuepower.com. Reports are acknowledged within two working days, and we will not take action against researchers who act in good faith.

Due-diligence questionnaires, requests for a countersigned data processing agreement, and all privacy correspondence should be addressed to privacy@queuepower.com. The Data processing agreement and Privacy policy are published in full.