Security and data

This page explains, in plain language, how Wimzi protects company data today, what we've tested, and what we haven't done yet. We'd rather be specific than reassuring. Wimzi has no security certifications (such as SOC 2 or ISO 27001) and has not yet had an independent penetration test.

For security questions or to report a vulnerability, use the contact form. [to confirm: dedicated security contact]

How company data is kept separate

• Every quiz, brand kit, report and challenge belongs to one workspace. The server checks the workspace on every request, not just in the browser. Asking for another company's item returns "not found", so nothing about it is revealed.
• Roles (Owner, Admin, Trainer, Viewer) are enforced on the server for every action, including live-session controls. If a member is removed or their role changes, it takes effect on their next action.
• Automated tests try to read, edit, delete, export and host across two separate companies, and check every attempt is refused. These tests run with every change.

Accounts and sign-in

• Passwords are hashed with scrypt and a unique salt. Passwords must be at least 10 characters.
• Sign-in uses a random token in an HttpOnly, SameSite cookie, so page scripts can't read it. Only a hash of the token is stored. Resetting your password signs you out on every device.
• Sign-in, sign-up, password reset, joining with codes and demo requests are rate-limited to slow down guessing.
• Single sign-on (SSO) and two-factor authentication are not available yet.

Web protections

• A strict Content Security Policy, anti-framing, no-sniff and referrer headers. HSTS when served over HTTPS.
• Requests that change data must come from Wimzi's own pages (origin checks) and be sent as JSON.
• Uploaded images are size-limited. SVGs containing scripts or external links are refused, and logos are resized in the browser before upload.
• CSV exports neutralise spreadsheet formulas so a malicious answer can't run in Excel.

Participants and anonymity

• Participants join with a code and need no account. Hosts choose whether a session records names.
• In anonymous sessions, names aren't collected at all, and reports show totals only.
• Product analytics stay on Wimzi's own server and never include answers, names, report content or credentials.

Your control over data

• Report retention can be set per workspace (30 days to 2 years, or keep forever).
• Owners can export the whole workspace and delete it. Deletion removes it from the live database straight away.
• An audit log records role changes, deletions and exports.

Operations

• Data is stored in a single SQLite database. A backup command creates a consistent copy, and restore checks the copy's integrity first. Backup and restore have been tested as a round trip.
• Hosting provider, location, backup schedule and off-site backup copies are [to confirm] for each deployment. We make no data-residency claims.
• Logs are structured and strip passwords, tokens and cookies.

Live-session capacity: what we tested

We ran an automated load test on one server process: simulated participants joined a single live session, answered 5 timed questions, and 5% of them disconnected and reconnected mid-session. All simulated players ran on the same machine as the server (a 22-core Windows PC) over a local connection.

What this does and doesn't show. It shows the session engine handles 2,000 participants in one session on a single process without dropped answers. It doesn't include real internet latency, mobile networks, company firewalls, or slower cloud servers. The Company pilot plan allows 500 participants per session by default, a cautious figure while we gather real-world results. Wimzi currently runs as a single server process, so very large events or many simultaneous large sessions haven't been tested.

Not done yet

• Independent penetration test or security audit
• Certifications (SOC 2, ISO 27001) and formal compliance programmes
• SSO, two-factor authentication and SCIM provisioning
• Encryption at rest beyond what the hosting provider supplies [to confirm per deployment]
• Multi-server high availability