How Kvutza protects your group and your data

1. Your own installation

You get your own copy of the application and your own database. It is not a shared system with a customer column; your records never sit in the same database as any other group's. It runs on your own web address, sends email from your own domain through your own email account, and shows your name and branding. Your shipping, payout and messaging accounts are yours, in your name; we never pool them.

2. Encryption, and a key you hold

Everything travels over HTTPS, our hosted installations connect to their database over TLS, and the database and its backups sit on encrypted storage. On top of that, the portal encrypts the values it must never show in full: two-factor secrets, buyers' payout destinations, and shipping and other provider credentials.

That key can be wrapped by a key in your own AWS account. Disable it and, within five minutes, nobody, us included, can read those fields; every use of it appears in your own CloudTrail. What it doesn't cover: fields the portal must search or sort, such as buyer names, emails, addresses, orders and tracking, are protected by access control, TLS and encrypted storage, not by that key.

3. Support only when you let us in

No account for us exists in your portal until your owner creates a grant under Settings → Support access, confirmed with a code from their authenticator app. The owner records who asked and why, and chooses which areas, read-only or may make changes, and for how long: 1, 4, 24 or 72 hours. Payments can never be granted, and your finance, exports, team, settings, messaging and dealer pages are out of reach whatever is ticked.

We get a one-time link. While it is in use, every page shows a banner with the end time, and Revoke now ends it at once. Every page support opens and everything it does is written to your audit log.

4. An audit log that can't be quietly edited

Staff changes, security events, exports and support activity are recorded. The database refuses edits and deletions of past entries, and each entry is sealed to the one before it, so a change behind the application's back shows up when the chain is checked.

The limit: whoever holds the database's owner login could switch that protection off and rebuild the seals. What catches that is a seal noted outside the database. You can note the latest one yourself, and the health report sends it to us, so it raises an alert if it ever goes backwards or changes.

5. What the portal tells the platform

A hosted installation sends us a short health report every few hours: your installation's name, the time, the software and database versions, whether the database is reachable and its size, counts of queued messages only (waiting, sending or failed, never who or what), which live switches are on, the license status, the audit log's latest seal, and one number, how many orders were entered last month, used only to match your plan. Never who, what, or any amount.

Apart from those queue counts and that one number, it never holds a buyer, member, staff member, deal, order, amount or message, nor any other count of them, and our side refuses a report with any other field. Settings → What we share shows you the exact last report sent, including that number.

6. You always get your data back

You always get your data back. If hosting ends, we keep an encrypted archive for 12 months, then delete it. The owner can download spreadsheets of your records at any time.

If you run Kvutza on your own server, self-hosted or as a one-time purchase, your data never leaves it, and we delete nothing. When you leave on purpose, you get a full copy of your database, and we delete your installation and its backups on your written instruction.

7. Accounts

Two-factor sign-in is required for the owner and every staff account, with one-time recovery codes. Repeated wrong passwords lock an account for 15 minutes, and sign-in is rate limited. Removing a staff member or changing their permissions takes effect on their next click. Assistants see only what they are granted.

8. Running it yourself

You can run the same released images in your own cloud, with your own database, backups and keys. We then hold none of your data and have no access unless you grant it. A one-time purchase never expires and needs no connection to us. With the health report off, nothing is sent, not even the monthly order count: the portal checks it against your plan itself and shows it to your owner.

9. In the contract

Our customer agreements are in legal review. The final versions will put these commitments in writing: you own your data; we process it only to run the service; we don't contact or trade with your buyers or dealers using anything learned through it; breach notification; deletion on exit, only on your written instruction; your right to audit.

10. If you choose Kvutza-managed hosting

You can run Kvutza on infrastructure you control, or choose Kvutza-managed hosting. With managed hosting, the infrastructure operator is technically able to reach the server, so access is limited, controlled and recorded through the safeguards below.

This section applies only to Kvutza-managed hosting. If you run Kvutza on infrastructure you control (section 8), none of it applies: we have no access unless you grant it.

• Our staff hold no account in your portal and no day-to-day credentials to your database.
• Upgrades run from a pipeline that holds no database credential at all.
• Support gets in only when you grant it (section 3).
• Emergency access during an outage needs two of our staff, a written reason, access that ends on its own, and a note to your owner within one business day.
• Separate installations keep other customers away from your data, and the key you hold (section 2) keeps the most sensitive fields unreadable once you switch it off.

These are policies and controls rather than physical impossibility, and the final customer agreements will state them in writing.

Want the full technical version? Ask for the security overview when you book a demo; it covers the same ground in more detail.