Security
Last updated August 30, 2026
This page describes how CineScope protects venue and guest data.
Hosting and infrastructure
CineScope runs entirely on Cloudflare's edge network (Workers and Durable Objects). There are no servers of our own to patch or expose — the application runs in Cloudflare's sandboxed runtime, behind Cloudflare's DDoS protection and web application firewall.
Each customer circuit is its own isolated database. There is no shared, multi-tenant data store: one circuit's reports, accounts, and settings live in a database that no other circuit's requests can reach, and every request is routed to its own circuit before any data is read.
Encryption
In transit: all traffic is served over HTTPS with TLS. This includes the guest report form, the staff dashboard, and every API call.
At rest: all stored data is encrypted at rest on Cloudflare's infrastructure.
In the application: passwords are hashed with bcrypt and are never stored, logged, or emailed in plain text. Point-of-sale credentials a customer connects are sealed with AES-GCM encryption before storage and are never sent to any third party. Push notifications are end-to-end encrypted to each device using the Web Push standard (RFC 8291), so notification content is unreadable to the push relays that carry it.
Access control
Access is role-based and enforced on the server, not just hidden in the interface. Head-office admins, general managers, and maintenance staff each get their own scope: a general manager sees only their own venue, a maintenance account sees only the areas it has been granted, and every API route re-checks the caller's role and scope before answering. Additional permissions (such as letting a manager work the review queue) are narrow, individual grants rather than role upgrades.
Account admins can review who has access at any time on the Active users page, see each account's sign-in history, and download the full sign-in log. Support access to a customer's circuit is read-only — support sessions cannot take actions on cases.
Authentication
Passwords are strength-checked at creation and hashed with bcrypt. Accounts created by an admin start with a temporary password that must be replaced at first sign-in. Sign-in attempts are rate-limited.
Two-factor authentication is supported with authenticator apps (TOTP) and passkeys, including Face ID and Touch ID on supported devices. Sessions are server-side, expire after 7 days, and can be reviewed and revoked individually from Settings.
Data retention and deletion
Circuit data is retained for as long as the subscription is active. Account admins can export their circuit's complete data from Settings at any time — the export is a full copy, not a summary.
When a customer leaves, deletion of the circuit is scheduled with an explicit, name-confirmed request and completes within 30 days, removing reports, photographs, accounts, and settings. Data-subject requests (access, correction, erasure) are handled together with the customer, who remains the controller of their staff's and guests' data, within one month of the request.
Backups and disaster recovery
Stored data is durably replicated by Cloudflare as part of its Durable Objects storage. Independently of that, account admins can take complete backups of their circuit from Settings whenever they choose, and those backups can be restored into a circuit. The export and restore paths are exercised by our automated test suite on every release, so a restore is a tested operation rather than a hopeful one.
Monitoring and logging
The service watches itself from both sides:
- Outside in: independent uptime checks probe the application — including the guest QR scan path end to end — from multiple regions, and alert on failure.
- Inside out: the application sweeps every circuit's health every 5 minutes and sends a heartbeat to our monitoring provider; if the heartbeat goes silent, an alert fires within about 15 minutes even if everything else looks fine (a dead-man's switch, so a failure that can't report itself still gets reported).
Live and historical availability is published at status.cinescope-app.com, where anyone can subscribe to incident notifications.
Inside the application, every action on a report — validation, release, notes, resolution, AI decisions — is recorded in that case's history under the name of whoever (or whatever) did it, and sign-ins are logged per account.
Payments
Subscription payments are processed by Stripe. CineScope never sees or stores full card numbers.
Guest anonymity
Guest reports are anonymous by design — guests are not asked to create an account or provide their name or contact details.
Subprocessors
CineScope processes data on behalf of its customers, and engages the following subprocessors. Because each circuit is isolated, no subprocessor ever receives a cross-customer dataset — each email, text, or AI call carries only the single report or question that occasioned it.
| Subprocessor | Purpose | Data touched |
|---|---|---|
| Cloudflare | Hosting, storage, DNS, TLS, WAF | All service data, at rest and in transit, in per-circuit isolated databases |
| Stripe | Subscription billing | The customer business's billing details — never guest or operational data |
| Resend (delivering via Amazon SES) | Transactional email | Staff email addresses and notification content |
| Twilio | SMS alerts, only where a circuit enables texting | Staff phone numbers; messages contain no guest-written text |
| Anthropic | AI assistant, translation, and AI triage — only while a circuit's AI features are switched on | Report text submitted for translation or triage, and staff questions to the assistant; not used to train models |
| Cronitor | Uptime monitoring and the status page | No customer or guest data — request URLs, response codes, and sweep counts only |
Switching off a circuit's AI assistant keeps that circuit's data away from the AI provider entirely.
Compliance
CineScope maintains an internal security control register mapped to the SOC 2 Trust Services Criteria, with written policies covering incident response, breach notification, data-subject requests, and subprocessor management. We do not currently hold a third-party certification and won't claim one here until an independent auditor has issued it.
Under GDPR, CineScope acts as a processor for its customers. Our outbound email is authenticated with SPF, DKIM, and DMARC.
Incident response
Incidents are detected by the monitoring described above and by reports from customers and staff. Every incident has a named lead who owns it from triage through fix and communication; availability incidents are reported on the status page as they happen.
If a security incident involves personal data, we notify affected customers within 24 hours of becoming aware, with the facts then known, and follow up within 72 hours with the fuller picture — categories of data involved, likely consequences, and measures taken — so customers can meet their own notification obligations. Every incident ends with a written review.
Report a vulnerability
Email Security@cinescope.org with details of the issue. We aim to acknowledge reports promptly and will keep you updated while we investigate.
CineScope LLC · max@cinescope-app.com