Security claims should point to evidence.

#QUE Security Trust Surface

Hero: Operational control includes knowing where your data lives.

Effective date: pending legal and security approval. This draft describes the current product posture; it is not an operative security commitment until the required approval and deployment evidence are recorded.

QUE is the operations layer for booking-led teams. Its security posture is written the same way its product is built: as one connected system, where every boundary, ownership question, and control is visible to the people who actually run the operation. This page explains the security model, the tenant isolation design, the access controls, the self-hosting option, the monitoring and backup disciplines, the recovery posture, and the responsible disclosure process. It deliberately avoids certification-style promises. What follows is the operating reality, described honestly so a security-minded operator can make a decision, not a badge.

A security page is a trust surface in two directions. To operators it must explain what the platform protects and how. To evaluators it must withstand the question "how would I verify that?" This page is written so that both readers finish with the same picture: a system whose boundaries are defined, tested, and documented, and whose honesty about limits is itself a security property. No claim below is made because it sounds reassuring. Each claim exists because a documented mechanism or a testable behavior supports it. The sections are ordered the way a security review tends to proceed: model, data boundaries, identity and authority, deployment sovereignty, visibility, persistence, failure response, and the external reporting channel.

#The security model

QUE treats security as an operational layer, the same way it treats booking coordination. The model rests on five commitments that apply regardless of deployment model, and each commitment exists because an operator somewhere needed it to be true, not because a compliance framework asked for it.

The first commitment is defined ownership. Every piece of data in QUE belongs to a tenant, and every tenant boundary is enforced at the storage layer, not at the UI layer. A dashboard screen is a projection of data the platform has already decided that identity may see; the screen itself is never the control.

The second commitment is least-privilege by construction. Service roles, API tokens, and integration credentials are scoped to the minimum surface they need. A credential that can read every table in the platform is a configuration error, not a feature.

The third commitment is verifiable boundaries. Security controls are tested continuously: cross-tenant isolation suites, authorization tests on every data boundary, and input validation on every public endpoint. A control that cannot be shown to work in a test is not a control QUE will advertise.

The fourth commitment is operator sovereignty. QUE is designed to be self-hostable. Operators who deploy QUE on their own infrastructure own the physical and administrative boundary: their databases, their keys, their backups, their observability. The platform does not architect a dependency on any single external vendor where control is concerned.

The fifth commitment is honest reporting. QUE publishes what it can verify and refuses language it cannot support. No guarantees, no inflated claims, no certification theatre. If a claim on this page is worth making, it must be traceable to a documented mechanism.

#Tenant isolation

Booking-led businesses share a platform with other businesses. The entire security model depends on one property holding everywhere: a tenant can only ever see its own data.

QUE enforces tenant isolation at three layers simultaneously, so that a single missed check in one layer is caught by the others.

This is not a claim that isolation is "basically there." Isolation is the property that is tested most aggressively in the QUE verification suite, because every other control assumes it. Cross-tenant leak tests are run as part of the release gate: the platform attempts to read, update, export, and observe one tenant's data from another tenant's authenticated context, and the build does not release if any of those attempts succeed.

Isolation also applies to operational data. Logs, error reports, and analytics are tenant-scoped or tenant-stripped. A support operator reading a queue should see the operational question, not another tenant's customer records.

The isolation posture has one deliberate consequence for the platform itself: multi-tenant testing is expensive, so it is invested in once as infrastructure rather than performed per-release as heroics. Isolation suites run as part of the release gate with the same authority as functional tests, because from an operator's perspective an isolation failure and a functional failure are indistinguishable — both mean the product shipped broken.

#Access control

Access control in QUE distinguishes three things that are easy to conflate: who is this (authentication), what may they do (authorization), and what did they do (audit).

Authentication establishes identity through protected credentials managed by the deployment's identity layer. Que's public surfaces do not accept password-equivalent secrets in support tickets, forms, or error reports, and the platform actively rejects submissions that appear to contain them.

Authorization is role-based and tenant-scoped. Business owners, operations leads, staff members, and practitioners see different surfaces of the same operation, and no role's surface includes controls the role should not hold. Administrative actions — adding or removing members, changing integrations, exporting data — are reserved for roles explicitly granted that authority, and membership in those roles is checked at the point of the action, not only at the point of login.

Audit provides the record. Meaningful administrative actions are recorded with an actor, a timestamp, and a correlation identifier. The purpose is not surveillance of the team; it is the ability to answer the question "what happened, who did it, and when" without reconstructing it from logs written for debugging.

Credential hygiene is part of the same discipline. Secrets are injected through the deployment's secret management, never committed to source, never placed in client bundles, and rotated after suspected exposure. The rotation policy favors action over certainty: suspected exposure triggers rotation regardless of whether misuse has been observed, because the cost of rotating is small and the cost of waiting is not. Production and non-production environments use separate credentials, and unused deploy keys are revoked. The same discipline extends to public surfaces: support forms, contact forms, and marketing lead endpoints strip and reject submissions that appear to contain secrets or credential material, and the platform publishes that expectation so a well-meaning reporter does not accidentally become a leak vector.

The credential picture has a second half that is operator-owned, especially under self-hosting. Database passwords, provider API keys, webhook signing secrets, and session secrets all belong to the deployment environment, and the deployment runbooks document where each lives and how each is rotated. Operators inherit the same expectation the platform holds internally: a deployment whose secrets live in a chat message or a notebook is a deployment whose security story ends there.

#Self-hosting

QUE's self-hosting option is the foundation of its data-sovereignty promise. Operators who self-host choose where the data lives, which providers touch it, and who holds the keys. The architecture is deliberately portable: a React/TanStack application, a relational data layer (Supabase-compatible Postgres), a Redis-compatible coordination and rate-limiting layer, and self-hosted observability options including Grafana, Prometheus, Loki, Promtail, Sentry, and Alertmanager. None of these components requires a proprietary cloud lock-in to function.

Self-hosting is presented honestly, not as a silver bullet. It gives operators real control — over data residency, over backup ownership, over network policy — and it transfers real responsibility: patching, key management, backups, observability, and incident response all belong to the operator in a self-hosted deployment. QUE supports that operator with documented deployment runbooks, secret rotation procedures, and migration paths, but the boundary of responsibility is not hidden in fine print. The division of labor between the platform and the operator looks like this:

The platform's code is the same in both models. A self-hosted deployment is not a different product with different guarantees; it is the same operational system running inside the operator's control boundary.

#Monitoring

Security monitoring in QUE is treated as operational monitoring with a security lens: failures should be visible, abnormal patterns should be surfaced, and the visibility should not itself leak sensitive data. The discipline behind that sentence is worth stating, because monitoring systems are where many platforms quietly fail: dashboards are built that look impressive and alert nothing, log pipelines are created that store secrets, and alerts are written that nobody owns.

The platform's observable surface is designed so that dashboards and alerts expose system health without exposing customer content or secrets. Log pipelines are structured and redacted at the source rather than hoping downstream filters catch everything. Rate limiting is enforced both client-side and server-side on every public form, including this site's contact and lead surfaces, so abuse patterns degrade the experience of the abuser before they degrade the inbox of the team.

Self-hosted deployments can wire the same observability stack the platform itself uses. Prometheus metrics, Grafana dashboards, Loki log aggregation, Sentry error tracking, and Alertmanager alert routing are documented as part of the deployment model, including their own authentication, retention, and upgrade discipline. An observability stack that is itself unprotected is a monitoring failure; the runbooks treat it as such.

Security-relevant events follow the same pipeline discipline as everything else: structured, redacted at the source, and routed to an owner. Rate limiting deserves a sentence beyond its mention above because it is quietly one of the most effective protective surfaces a public platform has. Every form on the public site — contact, lead capture, and disclosure — is rate limited, so an operator's inbox is protected whether the traffic comes from a competitor's scraper, an attacker's enumeration, or an honest visitor who refreshed too often. Protection that works the same for abuse and for impatience is protection designed by people who have read their own logs.

Alerts are written to be actionable. A meaningful alert names a symptom, suggests a first check, and routes to the right owner. Dashboards are built to show where attention is needed, not to generate alert fatigue. The same principle applies everywhere in QUE: coordination that produces noise instead of signal is coordination that has failed.

#The boundary is tested, not asserted

The tenant boundary is the single most important property in a multi-tenant booking platform, so it is worth describing how QUE verifies it rather than simply claiming it. The platform's verification works at three levels: the storage level, where isolation queries are tested against synthetic multi-tenant data before release; the authorization level, where role and permission suites verify that each identity sees only the projection its role is allowed; and the integration level, where external-facing surfaces such as public booking pages, forms, and messaging are tested for cross-tenant leakage under normal, changed, unavailable, failed, and permission-limited states.

An operator should never have to take the boundary on trust alone. Self-hosted operators can run the same isolation and authorization suites against their own deployment as part of acceptance testing and periodic review. That is deliberate: a boundary that an operator can test is a boundary an operator can rely on, and a boundary that only the vendor can see is not a boundary for procurement purposes, however well-intentioned. Documentation, test outlines, and the claim ledger describe which isolation properties are currently verified by suite, which are enforced by architecture, and which are roadmap rather than current fact. The claim ledger exists so that a reader can tell the difference, because the difference is where trust is usually broken.

#Backup and data retention

Backup discipline is the difference between an incident and a catastrophe. A scheduling business cannot lose its operational picture — the appointments, the customers, the configurations, the records of what happened and who owned it — because that picture is the business. QUE's backup posture covers three properties: coverage, recovery evidence, and retention honesty.

Coverage means the backup set includes everything an operator would need to restore the operational picture — database contents, configuration, and any operator-managed object storage. Incremental and full backups are scheduled with documented retention windows.

Recovery evidence is the part most organizations skip. A backup that has never been restored is a theory. QUE's posture requires periodic restore verification: a restoration is performed into an isolated environment, the restored system is checked against expected state, and the result is recorded. Operators who self-host inherit the same expectation and the runbook to meet it.

Retention honesty means the platform does not keep data past its stated purpose. Records are retained according to documented retention periods, and deletion requests are honored within those boundaries. Backup media that hold retired data follow the same lifecycle. Keeping everything forever is not a security feature; it is a liability with a retention date. The retention policy is written to serve the operator's obligations as well as the platform's: booking records, customer data, intake answers, payment context, and audit logs each have a purpose, and data that has lost its purpose is data the operator should no longer carry.

A practical recovery test is worth performing periodically, whether hosted or self-hosted: pick a real question about the operation — a booking from three months ago, a customer's intake answer from a past appointment — and recover it from backup into an isolated environment. If the answer arrives quickly, the backup posture is real. If the answer requires a weekend and three different tools, the posture is a theory, and it is better to know that before the incident does than to discover it during one.

#Incident response and recovery

Every team that has run an incident has learned the same lesson: the response that worked was the one that had a decision already attached to it. QUE's incident posture exists to attach decisions before the incident arrives, and to keep the evidence that shows what happened and what was done.

When something goes wrong, the response should be faster than the investigation. QUE's incident posture defines five stages, each with an owner and an exit condition.

Detection. Symptoms are observed through monitoring, self-reporting, or responsible disclosure. Every report receives a correlation identifier regardless of how it arrives.

Containment. The first action is to limit blast radius, not to preserve appearances. Credentials that may be exposed are rotated; affected paths are isolated; outbound surfaces that may be misused are paused.

Assessment. The scope of the incident is determined factually: which tenants, which data classes, which time window. Scope assessment drives everything that follows, and it is not compressed to shorten a communication.

Remediation. The root cause is addressed, not the symptom. Fixes are verified against the same isolation and authorization suites that gate releases, so the remediation itself is tested, not merely asserted.

Communication. Affected parties are notified through the applicable channel with what is known, what is not known, and what happens next. Communication is written to be useful to the reader, not to protect the writer.

Recovery follows the same evidence discipline as backup: restoration is verified, verification is recorded, and the record survives the incident. The incident record — timeline, decisions, affected scope, remediation, and communication — is retained as part of the operational history, because post-incident learning depends on a record that was written while the event was still legible. An incident without a record is an incident that can happen again without anyone being able to see why.

#Audit trail integrity

Every meaningful security event in QUE is recorded in a tamper-evident chain. The security_events table stores operational security events — authentication failures, rate-limit denials, abuse reports, payment disputes, MFA enrollment changes, disaster-recovery drill results, erasure requests — and each row carries a chain_hash computed as SHA-256 of the previous row's chain hash concatenated with a fingerprint of the current event. The chain is per-tenant, so each tenant's audit trail is independently verifiable.

Tampering with a historical record breaks the chain and is detected by the verification function, which surfaces an alert through the existing Alertmanager pipeline (the QueAuditChainBroken rule). Retention periods are set by severity: informational events are retained for 30 days, warnings for 90 days, and high-severity or critical events for 365 days to five years depending on the record class. The retention schedule is a documented constant, not an operator preference, so an auditor can verify that the platform has not silently shortened its own retention.

#Data erasure and GDPR alignment

QUE supports GDPR Article 17 (right to erasure) through a confirmed, audited pipeline. An erasure request is created with a confirmation token; the request must be confirmed with that token before execution proceeds. Tier 1 tables — bookings, customers, staff members, and event types — are directly affected: customer records are deleted and related booking records have their PII fields masked with SHA-256 pseudonymization. Tier 2 audit tables — security events and webhook delivery attempts — are preserved but stripped of identifiable content, because audit integrity and privacy obligations are both real and neither may silently defeat the other.

Retention policy is applied automatically: booking records older than 365 days are pruned by the retention job, and customers with no activity for 180 days are flagged as eligible for erasure. Every erasure is logged to the tamper-evident audit trail with the request identifier, the tables touched, and the row count affected. The erasure pipeline is documented in the compliance evidence pack, and the admin dashboard exposes erasure request status, pending counts, and completion records for operator review.

#Signed webhooks and API integrity

Webhooks delivered to customer endpoints are signed with HMAC-SHA256 over the payload body, using a per-endpoint secret that the customer configures. The signature header is verified before any delivery side effect is applied; a failed verification is a delivery failure, not a best-effort attempt. The public API uses scoped keys (que_live_ / que_test_ prefixes) with explicit scope enforcement, and key anomalies — unusual usage patterns, geographic spikes, or scope violations — are reviewed through the developer abuse pipeline, which can suspend or ban a key without affecting other keys on the same account.

#Dispute handling and payment integrity

Payment disputes received from Stripe are recorded with a timestamp, the dispute reason, and the associated booking. The platform tracks dispute rate as a first-class metric and surfaces it on the admin security dashboard; a dispute rate above 10% triggers an alert through the existing pipeline. Card decline velocity is monitored per payment method fingerprint, and repeated rapid declines from a single source trigger a CAPTCHA gate before further payment attempts are accepted. The dispute rate, velocity configuration, and carding thresholds are all documented in the compliance evidence pack.

#Responsible disclosure

QUE maintains a responsible disclosure process for security researchers and operators who find problems first. The process is designed around one principle: the fastest safe path from discovery to fix must be obvious to the person who found the issue, because an unclear reporting path is how many severe vulnerabilities become public incidents.

Reports are accepted through the contact page, using the security route. A useful report contains an impact description, reproduction steps that do not harm another tenant, relevant timestamps, and a safe reply address. It must not contain live secrets, customer data, or anything that would create harm in order to demonstrate harm.

QUE records a correlation identifier for every report, limits access to the report contents, triages severity, and communicates next steps appropriate to the evidence. High-severity reports are escalated to the responsible owner and tracked through the same incident stages as any other incident.

The team does not require NDAs as a condition of acknowledgement, does not threaten reporters acting in good faith, and does not demand that a vulnerability remain unpatched for marketing purposes.

Coordination with reporters follows the evidence, not a schedule. Where a fix is ready, it is verified and shipped through the same gating suites as any release. Where a fix requires architectural change, the team communicates that honestly with a working window rather than a promise. Reporters are informed of the resolution appropriate to their report; the goal is that a person who took time to report responsibly receives a response worthy of that effort.

The same channel serves operators who have operational security questions: deployment boundaries, credential rotation, network policy, or how to prove a property to an auditor. The security route is answered by a person who can actually route the question, within one business day on monitored routes.

#Security FAQ

#Does this page mean QUE is certified?

No. The page describes a review posture and public operating boundaries. A certification or contractual control statement requires the applicable evidence and agreement. What is stated here is what can be verified in the product and its documented operations.

#Where should I report a vulnerability?

Use /contact, choose security, and avoid including secrets or live customer data. For a high-risk issue, state the impact and a safe reproduction path so the report can be triaged. The responsible disclosure section above describes what happens next.

#Is self-hosting automatically more secure?

No. It can provide control over infrastructure and providers, but it also transfers patching, network security, backups, observability, and incident response responsibilities to the operator. Self-hosting is an option for operators who want sovereignty and accept the corresponding discipline.

#What happens after a report?

The team records the report, limits access, validates the issue, assesses scope, coordinates remediation, and communicates what can be responsibly confirmed. Response timing depends on severity, evidence, and the applicable agreement.

#Is there a security changelog or advisory channel?

Security-relevant changes travel through the same documentation discipline as the rest of the platform: meaningful changes are recorded in the documentation and claim ledger rather than buried in release notes, and operators who self-host receive runbook-level guidance for changes that affect their boundary. There is no separate advisory feed today; the contact page's security route serves that purpose, and affected-party notice follows the incident communication standard described above.

#Can QUE see my customers' data?

In the hosted model, the platform stores the data the operator places in it and protects it under the isolation model described above. In the self-hosted model, the operator's infrastructure never sends customer data anywhere the operator has not configured. Both models share the same code, the same isolation tests, and the same refusal to use operational data as training material without explicit operator consent.

#How do I verify the isolation claims?

The cross-tenant and authorization suites that gate releases are part of the platform's verification process. Operators who self-host can run the same isolation test suites against their deployment as part of their own acceptance and periodic review. Verification that an operator can reproduce is worth more than a statement an operator cannot.

#What should a prospective operator ask before trusting a security page?

Three questions compress most of the evaluation. First, where is the tenant boundary enforced, and can it be demonstrated with an isolation test rather than described? Second, what happens when something fails — is there a recovery path, and has anyone restored from it recently? Third, what is the honest boundary between the platform and the operator, written down rather than implied? A security page that answers all three without resorting to badges is worth reading twice.

#Does this page cover supply-chain risk?

The platform's dependency posture treats third-party code the way it treats any external boundary: dependencies are pinned, updated deliberately, and monitored for advisories. The observability stack is documented with the same care as the application, including authentication, retention, and upgrade discipline for each component. An operator evaluating supply-chain exposure should ask what changes when a dependency ships a vulnerability, and whether the answer is a monitored process or a hope.

#Does the platform support a security incident notice channel?

Yes. When an incident assessment concludes that affected parties should be notified, communication goes out through the applicable notice channel with what is known, what is not known, and what happens next. Contact the security route for how your deployment's notice obligations are handled.

#Closing

Operational control includes knowing where your data lives, who may act on it, what has been done with it, and what happens when something goes wrong. QUE's security posture is built to answer those four questions for the people who run booking-led businesses, and to give them the evidence to believe the answers.

A security posture is ultimately a promise about behavior under pressure. Many platforms write reassuring prose about normal operation; far fewer describe what happens when normal operation fails, because that description costs more and reads worse. This page has spent most of its length on the failure path deliberately: the boundaries that hold under normal conditions are not the boundaries that matter, and the teams that depend on this platform deserve to know both. If any part of the picture here needs verification, the mechanisms are documented, the test suites are reproducible, and the disclosure channel is open. For deployment questions, security reviews, or responsible disclosure, the contact page's security route is monitored and answered by a person.

#What does QUE deliberately not promise?

Honesty requires naming limits. QUE does not promise that no vulnerability will ever exist; it promises a process that finds, reports, and fixes vulnerabilities faster than they cause damage. QUE does not promise that infrastructure is invulnerable to its provider's failures; it promises recovery paths, retention evidence, and clear responsibility boundaries. QUE does not promise that security is a feature you enable; it promises that security is the shape of the system itself — defined ownership, least privilege, tested boundaries, visible failure, and a disclosure path that stays open to anyone who needs it.