Security controls and gaps

What we control today, and what we don’t.

QueueRoom’s signing, edge and audit controls, mapped to ISO/IEC 27001 and PCI DSS for scope planning. This is a mapping, not an audit result or certification.

Controls

Four controls in place today.

  1. Card data stays out of QueueRoom

    QueueRoom never asks for card details. Waiting-room responses from the Worker send Permissions-Policy: payment=(). A queue ticket keeps the protected page address, including its query string, so do not put card or personal data in protected URLs.1

  2. Signed configuration

    Each hostname has its own signing key. The Worker checks HMAC-SHA-256 signatures and rejects configuration signed for another hostname, and the room's admission authority refuses to accept an older revision than the one it holds.

  3. Missing or expired settings

    Own Cloudflare zone: with no valid signed settings the Worker returns a temporary error (503) to every request. Once settings are past their expiry plus about a minute, protected pages return 503 and other pages load normally. Hosted tag: pages load normally, without a queue, until a room is published, and again once settings are past their expiry plus about a minute, until you publish again. Settings expire when the sale window ends (at most 30 days).

  4. Audit log

    Changes to a launch or waiting room are written to the dashboard audit log with the signed-in operator's Clerk identity, in a hash chain you can check from the dashboard up to the history limit.2

ISMS standard

ISO/IEC 27001:2022 mapping

How current controls relate to ISO/IEC 27001 Annex A. This is a mapping, not an audit result or certification.

ControlObjectiveWhat QueueRoom does today
A.5.15 Access control Dashboard sign-in through Clerk, role checks on dashboard actions, and access scoped to the organizations that own each hostname.
A.8.12 Data leakage prevention A CI scan for cardholder-data field names (card number, PAN, CVV, track data) in runtime and configuration source, and Permissions-Policy: payment=() on waiting-room responses.
A.8.15 Logging Changes to a launch or waiting room go to a hash-chained audit log with the operator's identity. The dashboard shows, checks and reports an event's audit log only while it holds at most 1,000 entries and 4 MiB. Above that, new entries are still recorded but the log cannot be viewed, checked or reported until an archive exists.
A.8.20 Network security Cloudflare edge routing, HTTPS (HTTP requests are redirected to HTTPS), and per-IP rate limiting when the rate-limit binding is configured.3
A.8.24 Use of cryptography Configuration, queue tickets, and admissions are signed with HMAC-SHA-256.

Payment card standard

PCI DSS v4.0.1 requirement mapping

How QueueRoom affects your PCI DSS scope. This is a mapping, not an assessment or certification. Your assessor decides scope.

RequirementTopicWhat QueueRoom does today
Req 3 Protect stored account data

QueueRoom does not collect card numbers or security codes. The Worker keeps:

  • Queue-ticket records: ticket id, timing, lease and delivery records, a hash of the protected page address, and a keyed hash of the client network.
  • The signed room settings.
  • Sampled per-request decision records: hostname, path without query string, decision and time.

The protected page address with its query string is held only in the visitor's signed ticket cookie. Free-text fields (contact form, audit notes) are not scanned for pasted card numbers; do not enter card data.
Req 4 Protect data in transit Worker responses send Strict-Transport-Security,1 and queue and admission cookies are marked Secure, so browsers send them only over HTTPS.
Req 6 Secure software CI runs the security test suites and a cardholder-data field-name scan.
Req 8 Identify and authenticate access Dashboard sign-in through Clerk.
Req 10 Log and monitor access Changes to a launch or waiting room go to the dashboard audit log (see Logging above). Platform-admin actions go to a separate log the dashboard cannot yet show or check. The Worker keeps a sampled share of queue decisions (5% by default, less under load) in R2 through a Cloudflare Queue; this is capacity analytics, not an access log, and nothing reviews it automatically.

Stated up front

Known gaps.

What QueueRoom does not have today. Plan your review around these.

  • No external penetration test yet.
  • No ISO/IEC 27001 or PCI DSS certification. The tables above are a mapping only.
  • Changes to production code are not yet gated by enforced review.
  • The dashboard shows, checks and reports an event's audit log only while it holds at most 1,000 entries and 4 MiB. Above that, new entries are still recorded but the log cannot be viewed, checked or reported until an archive exists.
  • Audit log checks are run by hand from the event page; there is no scheduled review or alert on a broken chain.
  • The audit check shows removal of the newest entries only until the next audit write, and misses it if the signed head record is also deleted or rolled back.
  • Sampled decision records in R2 have no automatic deletion yet.
  • Zone rate-limit rules for the hosted queue host are defined but not yet confirmed active. WAF managed rules and bot controls on your own zone are yours to enable.
  • Turnstile is not a waiting-room check today; proof-of-work is.
  • Production rollback is a manual Cloudflare version rollback.
  • A validly signed older revision of a hostname's settings written directly to the Worker's KV or cache is accepted until the next refresh from the room's admission authority.
  • The hosted script queues browsers that run it; bots, scripts and direct links can skip it.
  • No published throughput or latency figures yet.

Your audit steps

Before a formal audit.

Steps your team owns when QueueRoom is in scope for an ISO/IEC 27001 or PCI DSS review.

  1. Step 01Governance

    Record controls in your ISMS

    Record the controls on this page in your governance tool (for example Vanta or Drata), alongside your own policies for access reviews, onboarding, and device management.

    • Draft an information security policy
    • Complete an annual risk assessment
  2. Step 02PCI scope

    Confirm routing scope

    If you run QueueRoom on your own Cloudflare zone, every request to that hostname passes through the Worker before it reaches your origin, so agree routing with your network team. In both setups, keep payment submission endpoints (for example /api/pay or /checkout/submit) outside queued pages. If the hosted tag runs on a page where card data is entered, the PCI DSS 6.4.3 script inventory and 11.6.1 tamper checks for that page are yours, and the tag is one of the scripts to list.

    • Confirm your SAQ type with your assessor
    • Do not proxy payment scripts through protected routes
  3. Step 03External review

    Scans and assessor review

    Schedule quarterly scans with an Approved Scanning Vendor (ASV) where they apply, and have your assessor (QSA) review the signing and routing setup.

    • Schedule quarterly ASV scans
    • Keep evidence ready for your assessor

Questions from your security team?

Tell us what your reviewer needs. The setup guide shows how the Worker is installed and what it checks.

Plan a launch Read the setup guide