The Operator's Guide to Restaurant Data Security and Multi-Tenant Intelligence

The Trust Question Every Operator Asks

Before any restaurant group adopts a cloud intelligence platform, someone in the room asks the question: "Is our data safe?"

It is the right question. Restaurant operational data is commercially sensitive. Your sales figures, labor costs, food cost percentages, supplier pricing, and competitive intelligence represent genuine trade secrets. If a competitor gained access to your location-level P&L data, they would know exactly where you are vulnerable and how to attack.

For multi-location operators, the stakes are even higher. You are not just protecting one restaurant's data - you are protecting an entire portfolio's operational intelligence. And if you are using a platform that also serves your competitors, the question becomes even sharper: "How do I know my data is completely isolated from every other operator on the platform?"

This article answers that question in detail - not with marketing language, but with architectural specifics that your technology team can evaluate.

Multi-Tenant Architecture: Your Data Lives Alone

Sundae operates on a multi-tenant architecture where every organization's data is completely isolated at the database level. Here is what that means in practice.

Organization-Level Data Isolation

Every data record in Sundae - every transaction, every labor entry, every benchmark, every intelligence query - is tagged with an organization identifier. This is not a soft filter that could be accidentally bypassed. It is enforced at the database level through Row-Level Security (RLS) policies.

Row-Level Security means the database itself - not the application code - enforces that queries can only return data belonging to the authenticated organization. Even if there were a bug in the application layer that failed to filter by organization, the database would refuse to return another organization's data. This is defense-in-depth: multiple independent layers of protection, each sufficient on its own.

What this means practically:

• When you log into Sundae, your session is bound to your organization
• Every database query automatically includes your organization scope
• There is no API endpoint, no dashboard, no query path that can access another organization's data
• Your data cannot appear in another organization's benchmarks, reports, or intelligence outputs (benchmarks use anonymized, aggregated market data - never raw organizational data)

How Benchmarks Work Without Exposing Data

A natural question: if Sundae provides competitive benchmarks, does that mean your data is being shared?

No. Benchmark data is generated through aggregation and anonymization. When Sundae Benchmarks shows that the "casual dining average food cost in Dubai" is 31.2%, that number is derived from aggregated data across many operators. No individual operator's data is identifiable. The aggregation thresholds ensure that benchmark categories always contain enough operators to prevent reverse-engineering individual performance.

Your raw data is never, under any circumstance, visible to another organization. Benchmarks are statistical aggregates - directionally useful, specifically anonymous.

Role-Based Access Control

Data isolation between organizations is the foundation. Role-based access control (RBAC) within your organization is the second layer.

How RBAC Works in Sundae

Not everyone in your organization should see everything. The CFO needs P&L data. The area manager needs location-level operations data. The marketing director needs guest and campaign data. The general manager needs their location's data but not other locations' financial details.

Sundae implements RBAC at the feature and data level:

• Organization Admin: Full access to all data, all features, all locations. Can manage users and permissions.
• Executive: Portfolio-wide visibility across all modules. Can view but not modify system configuration.
• Operations Manager: Multi-location operational data (sales, labor, inventory, guest feedback). May be scoped to a region or subset of locations.
• Location Manager: Single-location access to operational modules relevant to their restaurant.
• Finance: Access to financial modules (P&L, budgets, forecasting) across the portfolio.
• Analyst: Read-only access to specified modules for reporting and analysis.

Roles are configurable. If your organizational structure does not fit the standard roles, permissions can be customized to match how your team actually operates.

Read-Only Intelligence Queries

Sundae Intelligence - the conversational AI layer - operates with read-only database access. When an operator asks "Why did food cost spike at Location 7 last week?", the system executes analytical queries against the data. These queries are strictly SELECT operations - they can read data to generate insights but cannot modify, delete, or export raw data.

Additionally, Intelligence queries are subject to row limits and complexity constraints that prevent bulk data extraction. The system is designed to answer analytical questions, not to serve as a data export tool.

Data Encryption

In Transit

All data transmitted between your browser and Sundae's servers is encrypted using TLS 1.3 - the current industry standard for transport encryption. This applies to every interaction: login, data viewing, API calls, file uploads, and webhook data from integrations.

Data transmitted between Sundae's application servers and database servers is also encrypted in transit, protecting against internal network interception.

At Rest

All data stored in Sundae's database is encrypted at rest using AES-256 encryption. This means that even if someone gained physical access to the storage hardware, the data would be unreadable without the encryption keys.

Encryption keys are managed through a dedicated key management service, separate from the application infrastructure. Key rotation follows industry best practices.

Backup Encryption

Database backups - which are essential for disaster recovery - are also encrypted at rest. Backup access is restricted to infrastructure team members with explicit authorization, and all backup access is logged and auditable.

Authentication and Session Security

JWT-Based Authentication

Sundae uses JSON Web Token (JWT) authentication. When you log in, a cryptographically signed token is issued that encodes your identity and organization. This token is stored in a secure, HTTP-only cookie that cannot be accessed by client-side JavaScript - preventing common cross-site scripting (XSS) attacks from stealing session credentials.

Tokens have a defined expiration period. After expiration, re-authentication is required. There is no "remember me forever" option that could leave a session vulnerable indefinitely.

Session Isolation

Each user session is bound to a single organization. If an operator manages multiple organizations (e.g., a management company overseeing several restaurant groups), they must explicitly switch context. There is no way for a session to simultaneously access data from multiple organizations, eliminating the risk of accidental cross-organization data exposure.

Multi-Factor Authentication (MFA)

Passwords alone are not sufficient for protecting access to sensitive financial and operational data. Sundae now supports full multi-factor authentication using Time-Based One-Time Passwords (TOTP) - the same standard used by banking and enterprise SaaS platforms.

How It Works

When MFA is enabled, users authenticate with their password plus a 6-digit code from an authenticator app (Google Authenticator, Authy, Microsoft Authenticator, or any TOTP-compatible app). The code rotates every 30 seconds and is cryptographically tied to the user's account. Even if a password is compromised, the attacker cannot access the account without the physical device running the authenticator app.

Backup Codes

During MFA setup, Sundae generates a set of single-use backup codes. These are recovery codes that allow access if the authenticator device is lost, damaged, or replaced. Each backup code can only be used once. We recommend storing these codes in a secure location - a password manager or a physical safe - separate from the device running the authenticator app.

Organization-Level MFA Enforcement

For enterprise operators who need to mandate MFA across their entire team, Sundae supports organization-level MFA enforcement. When an organization admin enables mandatory MFA, every user in the organization must set up MFA before they can access the platform. There is no opt-out for individual users. This is critical for organizations with regulatory requirements or internal security policies that mandate two-factor authentication for all personnel accessing financial data.

The enforcement setting is controlled from the organization security settings page. Once enabled, users who have not yet configured MFA are redirected to the setup flow on their next login. There is no grace period - enforcement is immediate, ensuring no gap in coverage.

Password Policies

Weak passwords are the most common attack vector against SaaS platforms. Sundae implements configurable password policies that go beyond basic complexity requirements:

Complexity Requirements: Minimum length, required character types (uppercase, lowercase, numbers, special characters), and prevention of common passwords. These requirements are enforced at registration, password change, and password reset.

Account Lockout: After a configurable number of failed login attempts, the account is temporarily locked. This prevents brute-force attacks where an attacker tries thousands of password combinations. The lockout duration and attempt threshold are configurable by organization admins, balancing security against user convenience.

Password History: Users cannot reuse recent passwords, preventing the common pattern of rotating between two or three familiar passwords.

Security Status Banner: When security-relevant events occur - failed login attempts, password policy changes, MFA enrollment reminders - Sundae displays contextual security banners to the relevant users. These are not generic marketing messages. They are actionable security notifications that help users and admins maintain their security posture.

PII Masking

For organizations with strict data privacy requirements, Sundae supports automatic PII (Personally Identifiable Information) masking in the admin interface. When enabled, sensitive fields - guest names, email addresses, phone numbers, and other personal identifiers - are partially or fully masked in admin views and audit logs.

This is particularly important for organizations subject to GDPR, CCPA, or regional data protection regulations where access to raw PII must be limited to authorized personnel. PII masking ensures that support staff, analysts, and other team members can perform their functions without unnecessary exposure to personal data.

Cookie Consent and Privacy Controls

Sundae implements a cookie consent framework that complies with GDPR and ePrivacy Directive requirements:

Consent Banner: First-time visitors see a clear, actionable consent banner that explains what cookies are used and why. Users can accept all cookies, reject non-essential cookies, or customize their preferences.

Granular Controls: Cookie categories are presented individually - essential (always active), analytics, marketing, and functional. Users choose which categories to enable, and their preferences are respected across sessions.

Consent Records: All consent decisions are logged with timestamps and IP addresses, providing the audit trail that GDPR requires for demonstrating valid consent.

Infrastructure Security

Cloud Infrastructure

Sundae runs on enterprise-grade cloud infrastructure with:

• Network isolation: Application and database servers operate in private networks not directly accessible from the internet
• Firewall rules: Only necessary ports and protocols are open. All other traffic is blocked by default.
• DDoS protection: Distributed denial-of-service mitigation at the network edge
• Automated patching: Operating system and runtime security patches applied automatically
• Geographic data residency: Data is stored in regions compliant with local data protection regulations

Monitoring and Alerting

All infrastructure is continuously monitored for:

• Unauthorized access attempts
• Unusual query patterns that might indicate data exfiltration attempts
• Performance anomalies that could indicate security incidents
• Configuration changes that might weaken security posture

Security alerts are routed to the engineering team 24/7 with defined response SLAs.

Compliance and Audit Readiness

SOC 2 Compliance Path

Sundae is on a defined path toward SOC 2 Type II certification, the industry standard for SaaS security and availability. This involves:

• Formal security policies and procedures
• Regular security assessments and penetration testing
• Incident response procedures
• Vendor security management
• Employee security training

For enterprise prospects who require SOC 2 certification as a procurement prerequisite, we are happy to share our current compliance status, security questionnaire responses, and certification timeline.

GDPR and Data Protection

For operators with European guests or employees, Sundae's architecture supports GDPR compliance:

• Data minimization: We collect only what is needed for intelligence functionality
• Right to deletion: Organization data can be purged on request
• Data portability: Organizations can export their data in standard formats
• Processing records: We maintain records of data processing activities as required by GDPR

Audit Logging

Every significant action in Sundae is logged:

• User logins and logouts
• Data access patterns
• Configuration changes
• Permission modifications
• Intelligence queries
• Data exports

These audit logs are immutable (they cannot be modified or deleted) and available to organization admins for compliance and internal audit purposes.

What We Do Not Do

Transparency about what we do not do is as important as describing what we do:

• We do not sell your data. Your operational data is yours. Period. We do not monetize it, share it with third parties, or use it for any purpose other than providing you with intelligence services.
• We do not train AI models on your data. Your organization's data is not used to train machine learning models that serve other customers. Intelligence models are trained on anonymized, aggregated industry data - never on identifiable organizational data.
• We do not provide backdoor access. There is no "admin mode" that allows Sundae employees to browse your data casually. Internal access to customer data requires explicit authorization, is logged, and is limited to support and engineering functions with a documented business need.
• We do not retain data after termination. If you leave Sundae, your data is exported to you and purged from our systems within a defined retention window. We do not keep your historical data as a leveraging tool for retention.

The Enterprise Security Conversation

For enterprise hospitality groups evaluating Sundae, we understand that security is not a checkbox - it is an ongoing relationship. We support:

• Security questionnaire responses: Detailed answers to your procurement team's security assessment
• Architecture reviews: Technical deep-dives with your IT security team
• Penetration test results: Sharing of third-party security assessment findings
• Custom security requirements: For organizations with specific compliance needs (PCI-DSS for payment data, regional data protection regulations, internal security policies)
• Dedicated security contact: A named individual who handles your organization's security questions and concerns

Building Trust Through Transparency

Data security in restaurant intelligence is not a feature to be marketed. It is a foundational commitment that enables everything else. If operators do not trust the platform with their data, the most sophisticated intelligence capabilities in the world are worthless.

Sundae's approach is to earn trust through architectural decisions (multi-tenant isolation, RLS, encryption), operational practices (monitoring, patching, incident response), and transparency (this article, security documentation, direct conversations with your technical team).

Your restaurant data is your competitive advantage. Protecting it is not negotiable - it is the baseline requirement for everything Sundae delivers.

Book a demo to discuss your organization's specific security requirements and see how Sundae's architecture protects your data while delivering portfolio-wide intelligence.