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.

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).