Security overview

This page answers the questions a security questionnaire asks, in the order they usually come. It is written from the code, not from a template, and it includes the answers that are no. If your review needs a form filled in, send it to support@flowstateqsr.com; the person who answers it is the person who wrote the software.

The short version

Organization

Who builds and operates FlowState QSR? One person, Connor Grindstaff, an operator running seven stores who uses the product in them daily. There is no outsourced development and no offshore support desk. See About.

Who has access to production? The founder. There is a single named administrative account in the product, and every time it enters a store the event is written to that store's own security log, where the store's owner can see it.

Is there a security policy? This page, the data retention schedule below, the privacy policy and the terms are the written policy. They are short because the company is small, and they describe what the code does rather than what a larger company would aspire to.

Do you carry certifications? No. No SOC 2, no ISO 27001, no PCI assessment of our own (card data never reaches us; see Payments below). If your process requires a report, we are not a fit yet, and it is better to know that now.

Hosting and infrastructure

Where is the data hosted? On Render, in the United States. The application runs as a single web service with a persistent data volume. A managed Postgres database, also on Render in the United States, holds a mirror of every store's records as the durability copy.

Is data ever hosted outside the United States? No. Subprocessors that receive data are listed below with their locations.

How is the network protected? The service is only reachable over HTTPS through the hosting provider's edge. The application sends Strict-Transport-Security for one year with subdomains, a content security policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict referrer policy and a permissions policy that disables location, camera, microphone, payment and USB access in the browser. The database accepts connections only from the application: its public allow list is empty.

How are deploys done? From version control, automatically, on every commit to the main branch. A deploy is only routed traffic after the health check passes. The main branch is gated by continuous integration: the full server test suite, the app test suite, lint, type checking, and a dependency audit that fails the build on any high-severity advisory.

Data protection

Is data encrypted at rest? Yes. Each store's records are encrypted as a whole with AES-256-GCM before being written to disk. The key lives only in the hosting environment's configuration, never in the code or the repository. The service refuses to start if the key it is given cannot open the existing data, so a mistaken key change fails loudly instead of silently corrupting records.

What about the database copy? The Postgres mirror stores records as queryable JSON so operational questions can still be answered, and the two genuinely sensitive fields, hourly wage and date of birth, are field-encrypted with AES-256-GCM inside it. Time records that age out of the working set are moved to a line-encrypted archive rather than deleted.

Is data encrypted in transit? Yes. HTTPS for every browser and app request. The application's connection to the database is TLS with the server certificate verified against a pinned identity; a certificate the application does not recognise stops the mirror rather than proceeding unverified.

Is customer data separated by customer? Yes. Each store is a separate tenant with its own records. Requests are scoped to one tenant for their whole lifetime, including across asynchronous work, and the test suite includes a check that fires interleaved writes from different stores through the real HTTP stack and asserts that nothing crosses.

Who can see wages? Owners, and only on their own device. Wages are masked on shared devices by default, are never sent to the AI features, and every change to a wage is written to the security log.

Identity and access

How do users authenticate? With their store number, their username and a password. New accounts receive a temporary password and must choose their own on first sign-in. Passwords are at least eight characters and are hashed with bcrypt at cost 10. On iPhone, a person can enable Face ID for their own device; the device list is visible to them and any device can be revoked, which blocks its sign-in immediately.

Is there single sign-on? No. There is no SAML or OIDC integration. Sign in with Apple can be linked to a personal account, but there is no directory integration for a group. If your group requires SSO, tell us the size and the provider; it is the first thing we would build for a group that needs it.

Is there multi-factor authentication? No. Face ID device binding is available on iPhone, but there is no TOTP or SMS second factor.

How are sessions handled? Session cookies are HttpOnly, SameSite=Lax and Secure in production. Session tokens are stored hashed on the server, the same way passwords are, so a copy of the data store does not yield usable sessions. Sessions expire after 21 days without use and after 45 days regardless. Signing out revokes the session everywhere.

What stops password guessing? Failed sign-ins are counted per account and per network address in a fifteen-minute sliding window: after eight failures on one account, or thirty from one address, further attempts are locked out for the rest of the window. A sign-in for a username that does not exist takes the same time as one for a real username, so the failure does not reveal which names exist.

What roles exist? Team member, shift leader, kitchen director, marketing director and owner, plus our own administrative account. A team member sees their own shifts, their place in the lineup, checklists, chat and recognition. Leaders see the boards and logs for the shift. Owners see everything, including team management, payroll export, the audit binder, the security log and billing. Only an owner can create or promote another owner. Groups add two more roles, group manager and group viewer, that reach every location in the group.

How is access removed? An owner archives or deletes a person from the Team screen. Deletion disables sign-in, revokes sessions, push tokens and devices, and is recorded in the security log with the actor's name.

Application security

How is the software tested? Every commit runs more than 1,400 server tests and 800 app tests, lint and type checking, and a dependency audit. The suite includes tests that reproduce a vulnerability class first and then prove the fix, for example the cross-tenant race and session-token storage described above.

Are there rate limits? Yes. Writes are limited per network address, sign-in failures are limited as described above, AI features carry per-minute and per-day budgets per store that fail closed when exhausted, and the website assistant is limited per visitor.

Are writes idempotent? Yes. Every write from the apps carries an idempotency key scoped to the signed-in credential, so a retry after a dropped connection is applied once rather than twice.

How are errors handled? Error messages returned to a client are sanitised so they never carry stack traces, file paths or another person's data.

Has there been a penetration test? Not by a third party. An internal whole-application security review was completed on 2026-09-04 using a find-then-disprove method across the server, both clients, the repository history and both dependency trees; it found no high-severity issue, and every medium and low finding it raised has since been fixed and pinned by a test. We will commission an external test when a customer's process requires one.

How are vulnerabilities in dependencies handled? The dependency audit gate fails the build on high-severity advisories, and known-vulnerable transitive packages are pinned to fixed versions. Reports from outside can be sent to support@flowstateqsr.com and reach the engineer directly.

Logging and monitoring

What is logged? Each store has an append-only security log, line-encrypted on disk and never rewritten or capped, holding: successful and failed sign-ins, password changes and resets, role changes, account archives and deletions, every data export (personal data, payroll, temperature logs, the audit binder), every playback of an applicant's interview video, time record creation, edits and closures, wage changes, temperature log and write-up deletions, group membership and store changes, partner token mints and revocations, and every switch into the store by our administrative account. Viewing the log is itself logged.

Can the customer see it? Yes. An owner can view and export the store's security log as JSON or CSV at any time.

Are records tamper-evident? Temperature logs keep every prior value when edited and leave a tombstone naming the actor when deleted; the inspector export shows both. Discipline write-ups are soft-deleted with actor and timestamp. Time records are archived, never destroyed.

Is there error monitoring? Error reporting to Sentry is built in and off by default. When it is enabled it is configured to exclude personal data and wages.

Business continuity

How are backups taken? A snapshot of every store's data is taken every six hours and kept on the persistent volume for about a week. Separately, every write is mirrored to the managed Postgres database, and a daily job verifies the mirror against the primary and repairs any difference it finds. Snapshots copy the encrypted files, so a backup is no more readable than the live data.

Are backups offsite? Not today. Shipping snapshots to an S3-compatible bucket is built and can be switched on for a group that requires it; ask. Interview videos, when a store keeps them in a bucket, live in that bucket rather than on the volume, with the bucket's own durability.

Has a restore been tested? Rebuilding a store from the database mirror is exercised in the automated test suite, and the mirror is compared against the primary every day.

What is the uptime commitment? There is no contractual SLA. The terms provide the service as-is and as-available. The service is health-checked continuously by the hosting provider and restarted if it stops answering. We will publish measured uptime once we have 90 days of measurement behind it, and only then discuss an SLA.

What happens if the company stops operating? Every store can export everything it holds, at any time, in ordinary formats: schedules, temperature and food-safety logs, payroll CSVs, the audit binder and the security log. That is the continuity plan, and it does not depend on us.

Privacy and data handling {#data-retention}

What personal data is processed? For team members: name, username, role, phone and email where a leader entered them, date of birth where entered (used for under-18 labor rules), hourly wage where an owner entered it, time records, schedules and availability, messages, recognition, and app notification tokens. Location is recorded with a time punch only when the store has turned on a geofence. The privacy policy has the full list. A store that takes job applications through its own link also holds what an applicant entered and the video they recorded, visible to that store's directors only.

How long is data kept?

Can a person get their data or delete their account? Yes, self-serve, from their own account. Deletion scrubs profile details, disables sign-in and revokes sessions everywhere. Three categories the store is legally required to keep stay with the store with identity intact: time records, food-safety logs and disciplinary records. An owner can also delete an account, and that is logged.

Do you market to team members? No, and it is a term of the contract (section 4 of the terms), not a policy line. No sales, no rental, no advertising audiences. The only email a team member receives is a password reset they asked for.

Is there tracking inside the product? No. Google's advertising tag runs only on the public marketing pages, never on the sign-in page, never in the apps, and never on any screen after sign-in.

Employees under 18? Date of birth is set once and cannot be cleared by the employee afterwards, so the under-18 break and curfew checks cannot be self-disabled.

Which laws do you work to? The retention rules above are built for the Fair Labor Standards Act's record-keeping requirements and for food-safety record-keeping. Access, export and deletion rights are provided to every person regardless of where they live, which covers what the California Consumer Privacy Act asks of a service provider handling employee data.

AI features

Which AI features exist and who controls them? An in-app assistant that answers questions from the store's own data, checklist extraction from a photo or document, schedule reading from an uploaded file, and a website assistant on the marketing pages. An owner can turn the AI features off for their store.

Which provider, and what does it receive? Anthropic, in the United States. It receives the text needed to answer the request. It never receives wages, and data sent through the API is not used to train models. Each store has a per-minute and per-day budget that fails closed.

Payments

How are payments handled? Web purchases go through Stripe Checkout; we never receive or store card numbers. Purchases in the iPhone app go through Apple, and on Android through Google Play, in both cases through RevenueCat, which receives purchase identifiers and no employee data. Groups on annual invoicing pay by invoice.

Integrations

Is there an API? Yes, a partner API for reading a store's members, contacts, availability, shifts, time records, labor summaries and payroll, and for writing shifts. Tokens are minted by an owner, scoped to one store and to named read scopes, stored hashed, revocable at any time, and every mint and revocation is logged. The reference is at flowstateqsr.com/developers.

Are there webhooks? Not yet.

Point-of-sale integrations? Not yet. This is the next area of build; if your group runs Toast, Square, Clover or Lightspeed, tell us.

Subprocessors

Changes to this list are made on this page and in the privacy policy before they take effect, and existing stores are told.

Contracts

What governs a self-serve store? The terms and the privacy policy, accepted at signup.

What about a group? Groups on annual invoicing can be covered by a master services agreement and a data processing addendum in place of the click-through terms. Ask, and tell us whether you have paper of your own; we would rather read yours than make you read ours.

Can you sign a customer's security addendum? Send it. We will answer every line honestly, including the lines where the honest answer is that we do not do that yet.

Reporting a security concern

Write to support@flowstateqsr.com. It reaches the engineer, not a queue. Say what you found and how to reproduce it; we will acknowledge it, fix it, and tell you what changed.

The rollout for a group is written down in the 30-day plan, and the plain-language account of what happens to your data is on the trust page.