Security

This page describes how CineScope protects venue and guest data.

Hosting and infrastructure

CineScope runs entirely on Cloudflare's edge network (Workers, Durable Objects and R2 storage). 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. 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. Photographs and documents are kept in Cloudflare R2 object storage: one storage bucket holds every circuit's files, each under that circuit's own prefix, and every read, write, and delete is checked against the prefix of the circuit making the request.

We do not currently tie a circuit's data to a particular country or region. Cloudflare decides where each circuit's database is stored, and the AI, email, and text-message providers listed under Subprocessors process what is sent to them in their own facilities.

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-256-GCM encryption under a key held separately from the database, are decrypted only at the moment the app calls that cinema's POS provider, and are never included in a backup. Addresses on a cinema's community-ratings email list are sealed the same way. Links and codes that grant access — scan identifiers, guest tracking links, password-reset links, sign-in codes, recovery codes, and crew links — are stored only as hashes. Authenticator-app secrets cannot be hashed, because the app has to compute codes from them; they are stored in the circuit's own database and are part of its backups (see below). 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, and they carry only where, how urgent, and which case — never a guest's words or contact details.

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.

Crew scheduled in Staffing do not have accounts. Each crew member reaches only their own shifts, through a personal link that stops working 14 days after it is sent or 24 hours after it is first opened, and then a session on their own phone. A shared back-office tablet identifies only its cinema, shows only who is on, and asks for each person's 4-digit PIN, which is stored hashed and locks after repeated wrong tries.

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.

CineScope's support account is not one of your users; its address is shown on the Support access card in Settings. Without your permission it reads your circuit blinded: it sees the shape of your work — case references, issue types, severities, statuses, and dates — but none of its content. It sees no guest's words or seat, no contact details, no photographs, no staff or crew names, not which cinema a report came from, and none of your figures. It cannot open Staffing or download anything, and it cannot change your cases, cinemas, inspection records, showtime schedules, invoices, announcements, guides, or branding. It can still administer accounts and settings — for example, set a temporary password or clear a lost second factor when one of your users is locked out, or change a setting — and it reads the bug reports and assistant feedback your staff send to us. When you need us to look closer, an administrator can turn on temporary support access for 1, 4, 8, or 24 hours; it ends by itself and can be ended early. While it is on, support can read your circuit's content, download a backup, and make changes at your direction. Every support sign-in, every grant, and any early end to a grant is emailed to your administrators, and your pages show a notice while support is present.

Authentication

Passwords must be at least 12 characters and pass a strength check that refuses common passwords, repeated or sequential characters, and the person's own name or email address; they are then hashed with bcrypt. The rule is the same for every circuit — there is no separate password policy to configure. 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-step verification is available with an authenticator app (TOTP), with a six-digit code sent by email, or by signing in with a passkey, including Face ID and Touch ID on supported devices. An account admin can require two-step verification for every admin and developer account: such an account uses its passkey or authenticator app where it has one, and otherwise receives a six-digit code by email. General manager and maintenance accounts are not covered by the requirement, because back-office computers are often shared. Sessions are server-side, end after 7 days or after 12 hours without use, 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, except where the app deletes it sooner — for example, a guest's email address is deleted as the one email is sent, or after 90 days, and the sign-in log keeps 180 days. Our Privacy Policy lists every retention period. Account admins can download a backup of their circuit from Settings while the subscription is active (see Backups below for what it contains), and export detailed reports as PDF and spreadsheets.

When a customer leaves, deletion of the circuit is scheduled with an explicit request that names the circuit — on the customer's written request, or by us at any time after 60 days following termination. Nothing changes for 30 days, during which the deletion can be called off; then the circuit's database — reports, photographs held in it, accounts, and settings — is deleted, along with the photographs and documents the circuit stored in file storage, and its web addresses stop resolving. Cloudflare keeps 30 days of point-in-time history of each database, so deleted data can remain recoverable there for up to 30 days after deletion. 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, which also keeps 30 days of point-in-time history of each circuit's database. Independently of that, account admins can download a backup file of their circuit from Settings whenever they choose while the subscription is active.

A backup is not a copy of everything. It contains every report, account, and setting, the crew, the schedule, and — so that a restore never locks anyone out — every account's password hash, authenticator-app secret, recovery codes, and passkey public keys, so a backup file should be stored as carefully as a password. It leaves out point-of-sale passwords, the sign-in log, open sessions, guests' email addresses, the community-ratings email list, bug reports, push subscriptions, and other short-lived or operational records. Photographs held in the circuit's database are included unless the admin chooses a backup without them; photographs and documents held in R2 storage are carried as references to the stored files, and invoice documents, inspection certificates, guide PDFs, and placard artwork are never included as files. Every download is recorded in the sign-in log, and we are notified by email.

Restores are carried out by CineScope, not from a customer's own account: a restore replaces everything in a circuit, so an administrator at the circuit must turn on temporary support access before we can run one. 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. The sign-in and security log keeps 180 days of entries.

Payments

Subscription payments are processed by Stripe. CineScope never sees or stores full card numbers.

Guest anonymity

Guest reports are anonymous by default — guests are not asked to create an account or to give their name or phone number, and the form refuses a description that appears to contain personal details such as an email address or phone number. The one exception is the guest's own choice: an optional box (on by default; each circuit can switch it off) to be emailed once when their report is resolved. That address is kept apart from the report, is never shown to your staff or sent to any AI provider, is left out of exports and backups, and is deleted as the email is sent, or after 90 days. A cinema can also offer an opt-in community-ratings email list (off by default), whose addresses are sealed and never linked to a rating. Each report records the language its form was shown in. Guest photographs are checked by an AI model before staff see them, and camera metadata such as location is removed before they are stored.

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, push notification, or AI request is made for one circuit and carries only that circuit's data, though one AI request can cover several of its reports — for example, a batch of the Needs review queue.

Switching off a circuit's AI assistant stops everything that goes to Anthropic, and with it translation, the guest-photo field, AI verification, and Two-step triage. AI triage has its own setting: its first step (One-step, the default) sends each new guest report to the triage model on Cloudflare Workers AI whether or not the assistant is on, and only setting AI triage to Off stops it.

Two other kinds of service receive data at a circuit's direction, and are not our subprocessors. When a cinema connects its point-of-sale system, the app fetches schedules and ticket sales from that POS provider with the cinema's own credentials. And if a circuit switches on "Let staff connect their own AI assistant" (off by default), the answers a staff member asks for are delivered to the AI provider they connected, under their own account. The app also reads public data that involves no personal information: the weather at each cinema from Open-Meteo (it sends the cinema's town or postcode — or its name, if neither is set — and its map location).

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 max@cinescope-app.com with details of the issue. We aim to acknowledge reports promptly and will keep you updated while we investigate.