1. Tenancy and data isolation
- The platform is multi-tenant. Every customer record carries an organization identifier, and every query is scoped to the requesting user’s organization in the data layer.
- Membership in an organization is explicit; access to a workspace requires an active membership record.
- Cross-tenant references (clients, projects, invoices, documents) are re-validated server-side on write, not trusted from the request.
2. Authentication and sessions
- Passwords are hashed with bcrypt. We never store or log plaintext passwords, and we cannot recover them.
- Sessions are signed JSON web tokens. Each user carries a session version that is incremented on credential changes and password resets, which immediately invalidates every previously issued session.
- Sign-in attempts are rate limited per account and per source address; the counters are stored centrally so limits hold across every server instance and survive deployments.
- Optional Google sign-in is supported for organizations that prefer federated identity.
3. Authorization
- Role-based access control (owner, admin, member) governs every privileged action, enforced on the server for each request rather than in the interface.
- Sensitive operations — recording payments, managing members, changing billing — require an elevated role.
- Invitations are single-use, expiring tokens bound to an email address.
4. Encryption
- In transit — HTTPS/TLS is required for the application, and database connections use TLS.
- At rest — data is stored on managed infrastructure with encryption at rest enabled, including database volumes and object storage.
- Document uploads use short-lived, signed URLs scoped to a single object and content type; upload intents are signed server-side so a client cannot redirect an upload to another tenant’s prefix.
5. Payments
We do not store, process, or transmit full payment card numbers. Card data is handled entirely by our PCI-DSS compliant payment providers; we retain only the provider’s identifiers needed to reconcile a payment. Inbound payment webhooks are signature-verified and recorded in an idempotency ledger, so a replayed or forged callback cannot alter an invoice.
6. Logging, monitoring, and auditability
- Privileged actions write to an append-only audit log recording the actor, action, entity, and timestamp.
- Application errors are captured by our error-monitoring provider; we scrub credentials and tokens from reports.
- Health checks and container-level monitoring detect failed deployments and unhealthy instances.
7. AI features
The AI assistant sends only the prompt and the workspace data required to answer it to our AI subprocessor, and only when a user invokes it. Prompts and workspace data are not used to train third-party models. Per-organization token quotas bound usage. See our Subprocessors page for the current provider.
8. Availability and backups
- The application runs as a stateless container image; state lives in a managed PostgreSQL database and object storage, which are backed up by the provider on an automated schedule.
- Deployments are immutable and roll forward; database migrations run automatically and are applied in order at start-up.
- Customers can export their workspace data at any time, so recovery never depends solely on us.
9. Vendor management
Every vendor that processes customer data on our behalf is listed on our Subprocessors page and is bound by written terms at least as protective as our Data Processing Addendum. We give advance notice of new subprocessors so customers can object.
10. Incident response
We maintain an incident response process covering detection, containment, eradication, recovery, and post-incident review. Where we act as a processor, we notify affected customers without undue delay after becoming aware of a personal data breach and provide the information they need to meet their own notification obligations, as set out in the DPA. Where we are the controller, we notify affected individuals and regulators as required by applicable U.S. state breach-notification laws.
11. Reporting a vulnerability
Email security@businessmanagementai.com with enough detail to reproduce the issue. We acknowledge reports within 3 business days and aim to provide a remediation plan within 10 business days.
Safe harbor. We will not pursue legal action against researchers who act in good faith and: test only against accounts they own or have permission to test; avoid privacy violations, data destruction, and service degradation; do not access, modify, or retain data belonging to others; and give us reasonable time to remediate before public disclosure. Denial-of-service testing, social engineering, and physical attacks are out of scope. We do not currently operate a paid bug bounty.
12. Compliance posture
We do not currently hold a SOC 2 or ISO 27001 certification, and we will not claim one we do not have. The controls described above are implemented in the product; customers requiring formal attestation should contact security@businessmanagementai.com to discuss our roadmap and to request a security questionnaire response.