Trust.
For a vendor risk or IT reviewer: how a client’s data is separated, how people sign in, how it is backed up, who else touches it, and what we have not done yet. Each line describes something built and running today. Where something is not built, this page says so.
Last updated 5 November 2026 · Great Breads Studio
At a glance
In place today
- Row level security on every table that holds client data
- Money records readable by the studio's owner seats only
- Passwordless sign-in, with an authenticator a company can require
- Nightly off-site backup of the database and client files, restore tested
- A full export of a company's records, from Settings, at any time
- A signed incident response policy with notice within 72 hours
Not in place yet
- A SOC 2 report or an independent penetration test
- Single sign-on (Microsoft Entra ID, Google Workspace, SAML)
- Two-step sign-in enforced for every company and staff account
- Signed data processing agreements from our providers
- Deletion from inside the product
- Backup of call and meeting recordings
How a client's data is separated
Each company runs as its own tenant in one database. Every table that holds client data has row level security switched on, so the database itself refuses a signed-in person the rows of a company they do not belong to. The rules identify a person by the memberships recorded in the database, read on every request, never by a claim carried in the sign-in token. Views run with the permissions of the person asking.
Inside the studio, money records (invoices, payments, proposals, contracts) are readable by owner seats only, never by staff or sales reps. Server functions check who is calling, against those same memberships, before they read anything.
A client's subcontractors, architects and owners never get an account. Each opens one page through one link that does one thing, such as signing a purchase order. The link's token is kept as a hash on the record it opens, and is removed from the address bar the moment the page loads.
The workspace owner can download every record the company holds from Settings, at any time: each table as a spreadsheet file, a script that loads it all into any Postgres database, and links to every stored file that work for one hour. Each export is logged before any record is read, and the studio is alerted.
Row level security confirmed on every table in the review of 15 October 2026. Owner-only money access live since 11 October 2026. Export live since 15 October 2026.
Sign-in and two-step
The AsBuilt sign-in has no password. A person signs in with a one-time code sent to their email or phone, or on the web with a passkey (Face ID, Touch ID or a security key). In the iPhone app, Face ID or the phone's passcode unlocks the app on the device.
The studio can require an authenticator app for a company's staff, from that company's setup. When it does, the server functions that check it refuse a session that has not passed the authenticator. Not every server function checks it yet; that work is in progress. The check reads the live session, so a session that signs out stops working at once.
What is enforced today: the authenticator is required only where the studio has switched it on for a company, and it is off by default. It is not yet required for every studio staff account. Single sign-on (Microsoft Entra ID, Google Workspace or SAML) is not available, and there is no maximum session length yet.
Authenticator enforcement in server functions since 27 September 2026.
Backups and recovery
The database host keeps a daily backup for seven days. Point-in-time recovery is off, so a failure could lose up to 24 hours of changes. The database runs in one region, in the United States (AWS us-east-1).
Every night a separate job copies the whole database and the storage buckets that hold client documents to a private Cloudflare R2 bucket, outside the database host's account, using a key that can reach that one bucket only. A watchdog raises an alert if 30 hours pass without a backup report.
A restore was tested on 4 October 2026 into a fresh project: every key table matched the backup exactly. On 22 October 2026 every file in the eight buckets then covered was counted against it: 661 of 661.
Not covered yet: call and meeting recordings (their transcripts are in the database and are backed up). Photos taken with the phone capture tool and screen recordings sent with Show a problem are part of the nightly copy. Copies already in the backup are not removed when a record is deleted.
Off-site backup running since 4 October 2026.
Who else touches the data
Every provider the live system sends a client’s record, a person’s details or a visitor’s network address to, and what each one does. Each name links to that provider’s own security or privacy page. Each provider is used under its own standard customer terms. We have not yet collected a signed data processing agreement or a security report from each of them. We do not sell data.
Runs the service
Used when a feature is used
Accounts a client connects
For its own business the studio also uses its bank (Mercury, read only), its advertising accounts (Google Ads and Meta, spend figures only), a newsletter service (Kit) and a social posting service (Blotato). None of them receives a client’s record. Built from the hosts the code calls, 5 November 2026.
Incidents and changes
If we confirm that someone reached a client's data without authorization, we tell that client directly, in plain language, within 72 hours of confirming it. That is our incident response policy, signed 17 September 2026.
The app ships only by pushing the main branch, and server functions are deployed through a script that refuses code not on it (an emergency override exists, and its use is logged for the CEO). Every change pushed to the main branch runs the repository's checks, including one that fails the build if the database's privileged key appears in code a browser can load. Nothing the system does commits money, signs anything, or sends a new document outside the company until a person releases it. What does run on its own is follow-up on something a person already sent, for example a reminder to sign a purchase order, and short text conversations written by the AI inside Mark's approved rules, with someone who texted the studio's card number first or whom Mark met in person; it books a Read only when they pick a time it offered, and each stops when they reply STOP. The log of what it may do on its own is public at runorrery.com/record.
What we have not done yet
- We have no SOC 2 report and no auditor engaged.
- We have not had an independent penetration test.
- Single sign-on is not available.
- Two-step sign-in is not enforced for every company or every studio staff account, and sessions have no maximum length.
- We have not collected a signed data processing agreement or a security report from each provider listed above.
- Deletion is done by hand on a verified written request, within 30 days, not from inside the product.
- Point-in-time recovery is off, the database runs in one region, and call and meeting recordings are not backed up.
- Automated dependency scanning and branch protection on the code repository are not switched on.
- We do not yet offer a standalone data processing agreement, a service level agreement or a public status page. One person, Mark Riley, answers support.
How to reach a person
Mark Riley, Founder and CEO, at studio@greatbreadsny.com. Mark Riley answers every client message by the end of the next business day, Monday to Friday, New York time.
Send a security questionnaire, a vulnerability report or a question this page does not answer to the same address. Questionnaires are answered from the same facts as this page.
Great Breads Clothing, LLC, doing business as Great Breads Studio, New York.