Security Policy

1 Our Security Commitment

Beezifi commits to the following principles across all aspects of the IOM platform:

• Defence in depth — multiple independent security controls at every layer, so that no single failure exposes your data
• Least privilege — users and system components are granted only the minimum access required for their role or function
• Transparency — we document our security controls honestly and notify affected customers in the event of a security incident
• Continuous improvement — security controls are reviewed and updated as threats and best practices evolve

2 Authentication & Access

🔐 Password Security

All user passwords are hashed using bcrypt with a work factor of 10 before storage. Plaintext passwords are never written to disk, logs, or any persistent store. Even if a database backup were obtained, recovering passwords would be computationally infeasible.

🔑 Session Tokens

After successful login, IOM issues a JSON Web Token (JWT) signed with a server-side secret. Tokens are short-lived and carry only the minimum claims needed (user ID, org ID, role). No session state is stored server-side. Tokens are validated cryptographically on every API request.

• Tokens are stored in browser localStorage and sent via the Authorization: Bearer header
• Signing secrets are rotated on a regular schedule
• Expired or tampered tokens are rejected immediately

📱 Two-Factor Authentication (TOTP)

Every IOM user account supports optional TOTP-based two-factor authentication. When enabled, login requires a valid time-based one-time code from an authenticator app in addition to the password. We strongly recommend enabling 2FA for all accounts, especially those with Admin or Manager roles.

• Compatible with Google Authenticator, Authy, 1Password, Bitwarden, and any RFC 6238 TOTP app
• TOTP secrets are stored encrypted and are never exposed after initial setup
• Recovery codes are generated at setup — store them securely

⚡ Brute-Force Protection

Login, password reset, and 2FA verification endpoints are rate-limited. After a configurable number of failed attempts from a given IP address, further attempts are temporarily blocked. This prevents automated password-guessing attacks.

3 Data Isolation

IOM is a multi-tenant platform. Every organisation's data is stored in a dedicated, isolated database schema identified by a unique prefix (e.g., iom_acmecorp_). This is an architectural boundary — not just a filtering convention — meaning:

• There is no shared table between tenants that could be queried across organisations
• A bug or misconfiguration in one tenant's session cannot expose another tenant's data
• Database queries are always scoped to the authenticated organisation's schema
• Backups are taken and stored at the schema level, maintaining isolation in backup archives

Beezifi engineering staff may access a workspace schema for support purposes only with explicit authorisation from the account administrator. All such access is logged.

4 Encryption

🔒 Encryption in Transit

All communication between your browser (or API client) and the IOM platform is encrypted using HTTPS/TLS. There is no plaintext HTTP endpoint on any production service. HTTP requests are automatically redirected to HTTPS. TLS certificates are maintained with automatic renewal.

🗄️ Encryption at Rest

Production databases and backup archives are stored on encrypted volumes. Encryption is applied at the storage layer using AES-256 or equivalent, provided and managed by our infrastructure provider. Beezifi-managed secrets (API signing keys, integration tokens) are stored in encrypted secret management systems, not in code or plain configuration files.

5 Application Security

🧱 Security Headers

Every HTTP response from IOM includes a set of security headers applied via Helmet.js. These headers instruct browsers to enforce security policies regardless of user configuration:

• Content-Security-Policy (CSP) — restricts which scripts, styles, and resources the browser will execute
• HTTP Strict Transport Security (HSTS) — instructs browsers to always use HTTPS for this domain
• X-Frame-Options — prevents the platform from being embedded in iframes (clickjacking protection)
• X-Content-Type-Options — prevents MIME-type sniffing attacks
• Referrer-Policy — controls referrer information sent with outbound requests

📦 Input Validation

All API inputs are validated against strict schemas on the server side before being processed. Unrecognised fields are rejected. Numeric fields enforce type and range constraints. String fields are sanitised to prevent injection attacks. We do not rely solely on client-side validation.

⚡ Rate Limiting

Rate limiting is applied across the API — not just authentication endpoints. This protects against denial-of-service attempts and ensures fair resource allocation across all tenants. Limits are configurable per-endpoint based on expected usage patterns.

🔗 Dependency Management

Platform dependencies are pinned to specific versions and reviewed for known vulnerabilities. We monitor security advisories for all production dependencies and apply patches on a priority basis based on severity and exploitability.

6 Audit Trail

Every significant action within an IOM workspace generates an immutable audit log entry. The audit trail is a core feature of the platform — not a security add-on — because operational accountability is as important as data security for inventory and order management businesses.

The audit log captures:

• Inventory movements — every stock adjustment, transfer, and write-off, with the acting user and timestamp
• Order lifecycle events — creation, modification, fulfilment, and cancellation
• Warehouse actions — pick, pack, ship, and receive operations attributed to individual users
• Point-of-sale transactions — till open/close, sales, refunds, and voids
• Accounting events — journal entry creation, sync trigger, and reconciliation actions
• Authentication events — logins (success and failure), password changes, 2FA enable/disable
• Administrative changes — user creation, role changes, permission updates, integration configuration
• API access — endpoint, method, timestamp, IP address, and response status for all API key requests

Audit records are retained for 12 months within the platform and are read-only — they cannot be edited or deleted by any workspace user, including administrators.

7 Role-Based Access Control

IOM enforces granular role-based access control (RBAC) at the API layer. Every endpoint checks the authenticated user's role and permissions before processing the request. UI-level hiding is supplementary — security is enforced server-side.

Built-in roles and their capabilities:

• Admin — full access including user management, billing, workspace settings, and all operational features
• Manager — full operational access (inventory, orders, warehouse, POS, suppliers, reports) without user/billing management
• Warehouse — warehouse execution, inventory viewing, and stock movement recording; no order creation or financial access
• Accounting — read access to orders, inventory valuation, and accounting sync features; no warehouse or POS operations
• Read-Only — view-only access to dashboards and reports; no ability to create, modify, or delete any record

Roles are assigned per user by administrators and enforced consistently across the platform, API, and webhook payloads.

8 Integration Security

IOM connects to third-party services (Xero, QuickBooks, Shopify, Amazon, and others) using OAuth tokens or API keys that you provide. These credentials are:

• Stored encrypted in our secrets management system — never in application code or plain config
• Transmitted only over HTTPS to the respective integration endpoint
• Scoped to the minimum permissions required for the integration to function
• Logged when used — each sync operation generates an audit entry with timestamp and outcome
• Revocable at any time from within the integrations settings page

IOM does not share your integration credentials with any party other than the target integration service. Beezifi staff cannot view stored integration tokens — only their existence and metadata (last sync time, status) are accessible.

9 Incident Response

In the event of a confirmed security incident affecting customer data, Beezifi will:

• Contain the incident as quickly as possible — isolating affected systems or accounts
• Investigate to determine scope, root cause, and affected data
• Notify affected customers via the registered account email address within 72 hours of confirmation
• Remediate the root cause and implement controls to prevent recurrence
• Report post-incident findings including a timeline, impact summary, and remediation steps

Notifications will be sent to the primary account contact email. We recommend ensuring this address is actively monitored. Notification timing may be affected by legal or law enforcement holds in rare circumstances.

10 Responsible Disclosure

If you discover a potential security vulnerability in IOM, we ask that you disclose it to us responsibly before making it public. We are committed to working with security researchers in good faith.

Please include in your report:

• A description of the vulnerability and its potential impact
• Steps to reproduce or a proof-of-concept (where applicable)
• Your contact information for follow-up

Our commitments to researchers:

• We will acknowledge receipt of your report within 2 business days
• We will investigate and provide a status update within 10 business days
• We will not pursue legal action against researchers who follow responsible disclosure principles
• We will credit researchers (with permission) in our security changelog upon resolution

We ask that you do not access, modify, or delete data belonging to other users during your research, and that you do not disclose the vulnerability publicly until we have had a reasonable opportunity to remediate it.

For general security questions, contact security@beezifi.com.
For general support, contact support@beezifi.com.