WhizzMS
Compliance & Security Policy
Last updated: September 22, 2026
Contents
1. Multi-Tenant Data Isolation
WhizzMS is multi-tenant: every Business's indexed catalog data lives in its own, separate vector search collection, keyed to that Business only. Application-layer queries are always scoped to the Business the authenticated user or API key belongs to; there is no cross-tenant query path in normal operation. Field mappings, prompts, chat widget configuration, and AI provider credentials are likewise stored per-Business and are not shared or pooled across tenants.
2. Encryption
- In transit: the dashboard, headless API, and chat widget endpoints are served over HTTPS in production deployments.
- At rest: AI provider API keys, AWS secret access keys, and other configured credentials are encrypted at rest using application-level authenticated encryption before being written to the database - they are never stored, logged, or displayed in plaintext once saved. Passwords are stored as salted one-way hashes, never encrypted or in plaintext.
3. Access Control
Access within a Business is governed by role-based permissions (e.g. Owner, Admin, and any custom roles a Business defines), scoped to actions like managing data migrations, configuring the AI provider, managing prompts, or managing the chat widget. Platform-level administrative functions (e.g. managing subscription plans across all tenants) are restricted to WhizzMS operator accounts, separate from Business user accounts.
4. Infrastructure & Sub-Processors
The Service is built on the following categories of infrastructure and sub-processors:
| Category | Purpose | Notes |
|---|---|---|
| AI provider (Business-selected) | Generates embeddings and chat completions | OpenAI, Google (Gemini), Microsoft Azure OpenAI, or AWS Bedrock - whichever a Business configures, using that Business's own credentials. Not selected by WhizzMS on the Business's behalf. |
| Vector database | Stores per-Business embeddings and search metadata for retrieval | Isolated per-Business collection (Section 1) |
| Relational database | Account, Business, billing, and configuration data | Encrypted-at-rest credential fields (Section 2) |
| Cache & queue infrastructure | Session storage, background job processing (e.g. catalog sync), short-lived facet/response caching | See Section 5 for cache expiry |
| Payment processor | Handles subscription billing; WhizzMS does not store full card numbers | [Named on the Billing page] |
| Hosting provider | Runs the application, database, and background workers | [To be confirmed based on production deployment] |
We will update this list if a new category of sub-processor is introduced. A Business's choice of AI provider is itself made by that Business, not by WhizzMS.
5. AI Response Caching
To reduce redundant calls to your configured AI provider and lower your usage cost, some AI calls are cached for a bounded period keyed to your Business and the specific input (for example, embedding lookups, translation of non-English queries, and filter-extraction calls). Cached entries expire automatically, typically within 24 hours, and are never shared across Businesses. Search facet vocabularies sampled from your own catalog are cached separately for a shorter window (around one hour) to keep search responsive without re-scanning your entire catalog on every query.
6. Rate Limiting & Abuse Prevention
The chat widget endpoints and the headless chat API are rate-limited per widget/API key to protect both your Business's AI provider spend and the shared platform from abusive or runaway traffic. Requests exceeding the configured limit are rejected rather than queued indefinitely.
7. Network & Application Security
- Session-based dashboard authentication with CSRF protection on all state-changing requests;
- Bearer-token authentication, separate from dashboard sessions, for the headless chat API;
- Widget endpoints are restricted to the origins a Business explicitly allow-lists in its chat widget configuration;
- Internal service-to-service calls (dashboard to the AI/search service) are authenticated with a shared internal secret, not exposed to the public internet as an open endpoint.
8. Incident Response
In the event of a security incident affecting your data, we will notify affected Businesses without undue delay and in line with applicable legal notification timelines, with a description of the incident's nature and scope and the steps taken to address it. [Specific notification SLA to be defined by the operating entity - e.g. "within 72 hours of confirmation."]
9. Certifications
WhizzMS does not currently hold formal third-party security certifications such as SOC 2 or ISO 27001. This page will be updated, with links to the relevant audit reports, if and when such certifications are obtained. Until then, the controls described above reflect our current technical and organizational measures, not a certified audit outcome.
10. Responsible Disclosure
If you believe you've found a security vulnerability in the Service, please report it to [security contact email] rather than exploiting it or disclosing it publicly. We will acknowledge good-faith reports and will not pursue legal action against researchers who report vulnerabilities responsibly and avoid accessing data beyond what's needed to demonstrate the issue.
11. Contact
Security or compliance questions: [security/compliance contact email].