Trust
Access Control Policy
Access to customer data and to Bella's production systems is granted on a least-privilege basis, authenticated with multi-factor authentication where it matters, scoped to a specific tenant context, and reviewed on a periodic cadence.
1. Customer-facing access (tenant users)
- Roles — every customer-facing user is assigned exactly one of: Owner, Regional, Manager, Front Desk, Stylist. Roles are hierarchical; each role inherits a subset of the permissions of the next role up.
- Scope — users are scoped to their tenant (the salon company they belong to) and, where applicable, to one or more salon locations within that tenant. Cross-tenant data access is prevented through a combination of request-scope middleware on every authenticated route and database-trigger invariants on financial-write paths. We continue to audit additional routes for explicit scope enforcement as part of the SOC 2 readiness program.
- Authentication — JWT-based session authentication. Access tokens are short-lived; refresh tokens are issued separately with a longer lifetime. Refresh-token rotation and unconditional session invalidation on password change are on the SOC 2 readiness roadmap.
- Multi-factor authentication — TOTP-based MFA (RFC 6238) is available for every user. Mandatory MFA enrollment for owner-role accounts prior to sensitive actions (approving financial entries, connecting bank or accounting integrations, toggling kill switches) is targeted as part of the SOC 2 readiness program; the underlying gate is being rolled out incrementally.
- Page-level overrides — an owner may grant or revoke specific page access for individual users, on top of the role-based default, for narrow exceptions.
- Session management — sessions can be revoked centrally by an owner from the user management page; revocation is immediate.
2. Internal access (Bella staff)
- Least privilege — staff have only the access required for their role. Production database read access is granted on a named-individual basis; production write access is reserved for engineers actively responsible for a deploy or incident.
- Production access controls — production hosts are not directly internet-reachable. Engineer access goes through IP-restricted and identity-verified channels (no shared accounts, no password authentication).
- Multi-factor authentication — required on every internal account that can access customer data (email, code repositories, cloud provider consoles).
- Audit — every internal action that reads or writes customer data is logged in the append-only audit log with the actor identity and the affected tenant.
3. Workforce access lifecycle
- Onboarding — new hires are granted the minimum access required to do their job. Access requests are documented and approved.
- Role change — on internal role change, access is reviewed and adjusted within five business days. Permissions previously held that are no longer needed are revoked, not retained.
- Offboarding — on separation, all access is revoked the same business day. Shared credentials they had visibility into are rotated within seven calendar days. Hardware is collected; backups of personal-device work product are confirmed deleted.
- Periodic access review — at least quarterly, the policy owner reviews every active internal user, the systems they can reach, and the customer data those systems touch. Any access not justified by the user's current role is removed.
4. Service accounts and automation
- Inventory — every service account, cron job, and scheduled task is documented with its purpose, the secrets it holds, and the data it can read or write.
- Secrets — application secrets and third-party credentials are stored encrypted at rest. They are never committed to source code, never logged, and never returned over the wire.
- Rotation — third-party API keys, OAuth refresh tokens, and signing keys are rotated on a scheduled cadence or immediately on suspected compromise.
- Tenant isolation — service accounts that operate on tenant data carry a tenant context through every operation; the database trigger layer rejects writes whose tenant context does not match the row's tenant identity.
5. Authentication strength
- Passwords are hashed with bcrypt at a cost factor consistent with current OWASP guidance.
- TOTP MFA secrets are stored in the database, protected by the database disk-encryption layer, and validated server-side. Column-level encryption of TOTP secrets is on the SOC 2 readiness roadmap. Recovery is supported via an owner-initiated reset that re-enrolls MFA from scratch.
- Repeated failed authentication attempts trigger automated lockout and rate limiting at the network layer.
- Authentication events are logged with the actor, the source identity, the outcome, and a coarse-grained network attribution.
6. Roles and responsibilities
- Policy owner — Bella platform engineering lead.
- Operational enforcement — automated controls (RBAC middleware, database tenant-realm triggers on financial-write paths, session expiry) carry the day-to-day load; mandatory MFA-gating for sensitive owner actions is being rolled out incrementally as part of the SOC 2 readiness program. Manual quarterly access reviews verify the automation matches the documented intent.
- Escalation — any access-related policy deviation triggers an incident review under the Incident Response Policy.