Chain – Security and Access Control

Security in chain operations is not built on "hiding buttons in the UI" but on real rules directly in the database. Every time someone tries to read or modify data, the system runs a check – even if someone tries to bypass the app and talk directly to our API, they cannot see or modify data they don't have rights to.

Base principles

1. Secure from the start: new features start locked down and only open up for the roles that should have access
2. Rights inherited via chain membership: a chain admin automatically gets access to their member restaurants without extra configuration
3. Chain data is separate from restaurant data: a chain owner sees chain-wide info in addition to the restaurants
4. Multiple layers: the app, the API, and the database all verify permissions independently

Roles and what they see

Capability inheritance – inherited rights

When Alice is chain admin for "Burger Buffet Holding" (5 restaurants) and opens one of the units in admin:

1. System checks: is Alice a direct member of the restaurant? No.
2. Is she chain admin for the chain the restaurant belongs to? Yes.
3. → Access granted automatically.

She never needs to be manually added to each unit. Saves time and reduces mistakes.

Chain gift cards – cross-unit access

A chain gift card is redeemable at all member restaurants. In practice:

• A restaurant member sees local cards and all cards redeemed at their place
• A chain member sees all chain-scoped cards in their chain
• Nobody outside the chain sees anything

Same principle applies to menu templates, brand settings, and intercompany transactions.

What a chain admin actually sees at a sister restaurant

Inherited permissions now reach all the way down into the data, not just to the page. Previously a chain admin could open a restaurant they were not a personal member of and be met by empty lists — the guest register, loyalty members, stamp cards, parts of booking and the SMS log all showed zero rows. It looked like data was missing rather than access, which is the worst kind of error.

That is fixed. A chain admin now sees:

Four things that deliberately stay closed

• The fiscal journal. The cash register journal is locked to the restaurant itself. It is protected under Swedish cash register law and is not opened by chain membership.
• Logs can be read but never edited. An editable audit log is not an audit log.
• Private AI conversations. Each person's Boss chat is personal — even a regular restaurant admin only sees their own. A chain admin does not get to read other people's.
• A paused restaurant. If the restaurant is paused, the chain route closes just like the membership route. The pause cannot be bypassed via the chain.

Data isolation between chains

Different chains can never see each other's data. Chain A's guest gift cards are invisible to Chain B's admin. The system automatically filters by chain membership in every relevant check.

We test this continuously with negative tests: "Try to read data from chain B when you're admin in A" → 0 rows returned.

When sharing flags are OFF

If you turn off central menu control in chain settings, the menu template page disappears from navigation for all chain admins. Existing published menus remain in each restaurant – frozen in place.

Same principle for brand lock, shared loyalty, and shared gift cards.

Traceability – audit log

All critical changes are logged for traceability:

The question "who turned off loyalty on June 15?" must always be answerable. Chain admins see their own chain's log; Vendion support sees the entire log.

Regional data residency

• Customer data stored within EU (eu-west-1 / eu-north-1)
• Data never leaves EU
• Vendion doesn't use US-based services for core data
• Compliant with GDPR and Swedish data protection requirements

Penetration testing and monitoring

Vendion runs:

• Internal pen-test before production
• Continuous monitoring via error reporting
• Annual external audit as customer volume grows

Security incident – flow

If an incident occurs:

1. Detection (via monitoring, logs, or customer report)
2. Immediately: isolate affected data
3. Analysis: what happened?
4. Patch: fix root cause
5. Communication: inform affected chain owners within 72 hours (GDPR requirement)
6. Report: document the incident

Summary

• Database level: permissions enforced per row, not just in the UI
• Inherited rights: chain admin automatically gets access to member restaurants
• Data isolation: chains can never see each other's data
• Audit log: all critical changes are traceable
• EU residency: data never leaves EU
• Multiple layers: app, API, and database all verify independently

This multi-layer model provides strong protection against both external attacks and internal mistakes.

Next step: For deeper bookkeeping aspects, read Chain Bookkeeping – Multiple Legal Entities (or equivalent in the Bookkeeping module).