Trust
Information Security Policy
This policy describes how Bella protects the data salons entrust to us: the program objectives, the controls that operationalize them, who owns each control, and where the program is going.
1. Program objectives
- Confidentiality — salon financial data, guest contact data, and authentication credentials are accessible only to people and systems that need them.
- Integrity — mutations to financial and operational records are authenticated, authorized, and auditable. Audit history is append-only.
- Availability — the platform is engineered to recover quickly from failures and to isolate one tenant's incident from another.
- Accountability — every action that touches customer data leaves a trace tied to a specific user, system, or scheduled job.
2. Data classification
Bella applies a four-tier classification scheme to every data category. Controls scale with the classification.
- Restricted — OAuth tokens (Intuit, Plaid), payment processor secrets. Encrypted at rest using column-level encryption (current production uses a single platform-wide key; tenant-scoped key derivation is on the SOC 2 readiness roadmap), never logged, never returned over the wire.
- Confidential — salon financial transactions, payroll detail, guest contact information (name + phone + email), TCPA consent records, message content.
- Internal — tenant profile, user list, integration status, audit log metadata.
- Public — marketing pages, policy documents, public-facing platform status.
3. Controls
- Network — Cloudflare WAF + TLS 1.2+ on every public endpoint. Application servers are not directly internet-reachable.
- Authentication — JWT-based session auth with short-lived access tokens and separate refresh tokens. TOTP-based multi-factor authentication is available for every user. Mandatory MFA enrollment for owner-role accounts before sensitive operations (financial integrations, kill-switch toggles) is being rolled out incrementally under the SOC 2 readiness program.
- Authorization — role-based access control with five distinct roles (Owner, Regional, Manager, Front Desk, Stylist). Every API request resolves to a tenant scope before any database read or write.
- Data isolation — tenant-owned tables carry a tenant key and every authenticated request resolves to a tenant scope through request-scope middleware. On financial-write paths (audit log and staging queue), a database-layer invariant trigger additionally verifies tenant + realm + connection identity match before any row is inserted. Continued route-by-route scope-enforcement audit is on the SOC 2 readiness roadmap.
- Encryption — covered separately in our Encryption & Key Management Policy.
- Audit and accountability — append-only audit logs capture authentication events, financial mutations, kill-switch toggles, and offboarding actions. Audit rows cannot be updated or deleted by application code.
- Change management — pre-commit secret scanning, lint and syntax checks, migration safety verification, and adversarial code review before every merge. Detail in our Change Management Policy.
- Workforce — covered separately in our Access Control Policy (onboarding, offboarding, periodic access review).
- Subprocessors — full list and due-diligence process in our Subprocessor Policy.
- Incident response — covered separately in our Incident Response Policy.
- Business continuity — covered separately in our Business Continuity Policy.
4. Roles and responsibilities
- Policy owner — Bella platform engineering lead.
- Day-to-day enforcement — automated controls (pre-commit hooks, CI checks, database triggers, scheduled retention jobs) carry the operational load. Manual quarterly reviews verify the automation is healthy.
- Annual review — this policy is reviewed at least once per calendar year and on any material change to applicable data privacy law. Updates are committed to version control alongside the corresponding code changes.
- Escalation — any deviation from this policy, security incident, or material control gap triggers an incident review under the Incident Response Policy.
5. SOC 2 readiness
Bella has not yet completed a SOC 2 examination. Bella is operating a SOC 2 readiness program, aligning security controls, evidence collection, vendor review, access management, incident response, change management, and backup/restore procedures to the SOC 2 Trust Services Criteria. Bella's target is to be ready to begin an independent SOC 2 Type I examination within 12 months, followed by a Type II observation period after readiness gaps are remediated. Until an independent report is available, Bella provides security questionnaires, policy documentation, and control evidence under NDA where appropriate.
Specific readiness items targeted within the next 90 days: published subprocessor inventory, completed data classification, formal access review log, documented incident runbook, backup-restore test record. All of these are in progress.
6. Mobile device management
A formal mobile device management (MDM) program is not yet deployed. Employee devices are subject to the controls described in the Acceptable Use Policy (full-disk encryption, automatic OS updates, password / biometric lock, no production credential storage). A formal MDM is planned as part of the SOC 2 readiness program.
7. Third-party penetration testing
An independent third-party penetration test has not yet been commissioned. This is on the SOC 2 readiness roadmap. In the interim, Bella relies on automated dependency scanning, pre-commit secret detection, adversarial code review on every significant change, and Cloudflare's managed WAF and rate-limiting.
8. Contact
Questions about this policy or specific controls can be sent to [email protected]. Security incidents or vulnerability reports should be sent to the same address with the prefix [SECURITY] in the subject line.