This page separates controls implemented in the application from controls that depend on a live Cloudflare account, configured provider, deployment procedure, or operator drill. Source-backed capabilities are described as capabilities; external operating evidence is called out instead of being inferred from code. This is not a certification or service-level agreement.
- Application controls
- Mechanisms that can be verified from the repository and its supported workflows.
- External evidence
- Live provider settings, certificates, objects, logs, and drills an operator must verify.
- Assurance boundary
- No certification, uptime promise, recovery guarantee, or provider activation is inferred.
Audit trails for protected changes
Protected business and administrative changes — including sales, expenses, costing, role management, and workspace settings — write audit records with actor, action, time, and scoped change evidence appropriate to the operation. Normal application mutation paths append these records rather than editing an earlier audit event.
When a Mezbano super administrator uses the product’s impersonation workflow, the session is marked as impersonated and mutation audits preserve the administrator attribution instead of presenting the action as the workspace user.
The scheduled retention workflow can copy aged audit rows to an R2 archive before removing only the archived rows from the hot D1 working set. Source code establishes that ordering; archive objects, job health, retention, and retrieval in a live deployment require operator evidence.
Financial month locks
When you finalize a month, that month’s sales, expenses, labour, and purchases are locked against edits so your closed books stay closed. The lock is enforced at the database, not just in the interface.
Owners and admins can finalize a month; reopening a finalized month is restricted to the workspace owner, because it reverses a financial-control decision.
Optimistic concurrency on edits
On editors where saving replaces a whole record and its children — recipes, checklists, daily sales — Mezbano checks that no one else changed the record since you opened it. If they did, your save is rejected with a clear conflict message instead of silently overwriting their work.
Two-factor authentication and workspace security policy
Any user can turn on time-based two-factor authentication (an authenticator app) for their account. A workspace can go further and require two-factor authentication for its owners and admins, so privileged access always carries a second factor.
Each workspace controls its own sign-in policy, so a stricter operator is never held back by a more relaxed one.
Brand-scoped tenant isolation
Recipes, ingredients, costs, SOPs, and checklists are brand-scoped. Authenticated route guards resolve current server-side membership, role, feature, and workspace state rather than trusting tenant identifiers or permissions from the browser.
The one deliberate exception is the standard chart of expense and revenue categories, which is shared so that reporting stays consistent and comparable across the platform. That standard chart is a feature, not a leak of your operating data.
Application and platform encryption controls
The application adds HTTP Strict Transport Security to HTTPS responses and marks authentication cookies Secure in HTTPS environments. Cloudflare documents encryption at rest for R2 and transport encryption for its services. The deployment operator must separately verify active certificates, HTTPS redirects, DNS proxying, Cloudflare plan settings, and the live response path; source code alone cannot establish those controls.
Automated backups and disaster recovery
The scheduled Worker contains a nightly D1-to-R2 backup job that publishes a completed generation only after its artifacts are written and verified. Cloudflare offers plan-dependent D1 point-in-time recovery; the exact retention available to a deployment must be checked against its live database and plan.
An optional off-provider replication path can copy completed database generations, archived audits, and claimed attachments only after a complete provider configuration is present. Cross-provider recovery and recovery-time objectives are not guarantees: they require provider-side object verification and a successful restore drill. The first recorded staging drill remains an operator acceptance item.
Safe, reviewed database changes
The repository’s supported production migration command first replays migrations against a production clone and compares the resulting schema contract before it can apply. Project policy requires additive production changes and prohibits direct remote write or DDL commands; an operator must use that gated path for the control to hold.
Deploys gated by an automated test floor
The supported release command runs a dedicated security and authorization test floor and stops when it fails. CI and the release workflow pin additional validation, build, migration, and browser checks. This is a repository control, not proof that an operator used the supported command for a particular deployment.
Reporting a security concern
Found something that looks wrong, or have a question about how your data is handled? Email support@mezbano.com and we will route it to the right person. See our subprocessors for the third parties that help us run the service, and the privacy policy for how we handle personal data.