Data Handling Policy
Effective 1 October 2026
The rule we build by: collect only what a feature genuinely needs, keep it only as long as it is useful, protect it while we have it, and delete it properly when it is no longer needed. This policy applies to everyone who works on Krivollo and is reviewed at least once a year. Our Privacy Policy describes what we collect; this policy describes how we handle it.
1. Data minimisation
What we commit to:
- Purpose first. Every new field, log or integration must have a stated purpose before it is built. If we cannot say why we need a piece of personal information, we do not collect it.
- Least data. We request the narrowest access available — for example Google Sheets uses the
drive.filescope, which reaches only the sheet you pick, not your Drive. - No passwords. Sign-in is passwordless or through your identity provider, so we hold no password to lose.
- No card numbers. Payment details go straight to Stripe and never touch our servers.
- No tracking. No analytics or advertising trackers on our website or app. Product usage records stay in our own database and are used only to run and improve Krivollo.
- Hashed where possible. API keys are stored only as one-way hashes; IP addresses on public brochure enquiries are stored only as salted hashes.
- Redaction. Card-number and tax-file-number patterns are removed from extracted documents and transcripts before they are stored or sent for AI processing in the features where those documents are handled.
What we ask of customers:
- Only create custom fields and capture information you actually use.
- Do not store government identifiers (tax file numbers, passport, driver’s licence or Medicare numbers), full card or bank account numbers, passwords, or health information in Krivollo unless it is lawful, necessary and consented to — and if you must, mark the field masked so only the roles you choose can see it.
- Turn off integrations and AI features you do not use.
- Set a retention period for recordings, and delete leads and records you no longer need.
2. Retention schedule
| Information | How long it is kept |
|---|---|
| Account information | While the account is active; removed within 90 days of the workspace closing or on a verified deletion request, unless needed for an open dispute or legal obligation |
| Customer Data (leads, content, documents) | Under the customer's control while the workspace is active. Deleted items go to a recycle bin and are permanently removed after 30 days |
| Call and meeting recordings | For the retention period the workspace sets; if none is set, until the customer deletes them. We recommend customers set a period (for example 12 months) unless they have a legal reason to keep longer |
| Transcripts and AI summaries | Until the customer deletes the call or the workspace closes |
| Supplier delivery records (the original data a lead supplier sent) | Until the related lead is deleted or the workspace closes; kept so customers can resolve supplier disputes |
| Audit logs | For the life of the workspace, so actions can always be traced to the person who took them |
| Error and diagnostic logs | Up to 12 months |
| Billing and tax records | 7 years, as Australian tax law requires |
| Website assistant conversations | Not stored by us; processed only to produce a reply |
| Backups | Overwritten on the provider's rolling cycle (generally no more than 30 days) |
| After a workspace closes | Customers can export for 30 days; Customer Data is then deleted or de-identified within 90 days of closure |
Where the law requires us to keep information longer (for example because of a legal claim or a regulator’s request), we keep only what is required, restrict access to it, and delete it when the obligation ends.
3. Security measures
| Area | Measure |
|---|---|
| Encryption | TLS for all traffic; encryption at rest by our hosting and database providers; AES-256-GCM application-level encryption for integration tokens, API secrets and AI keys |
| Isolation | Every workspace's data is tagged with its workspace and accessed through a wrapper that will not compile an unscoped query — isolation is enforced in code, not by convention |
| Access | Passwordless sign-in, Google and enterprise SSO (SAML/SCIM), automatic sign-out after inactivity, role-based permissions checked on the server for every action, and field masking |
| Accountability | Audit logs of significant actions; when an administrator acts as another user, every action records both identities |
| Credentials | API keys stored as hashes and shown once; integration credentials scoped to one workspace and never shared between workspaces |
| Our people | Production access limited to the people who need it, using individual accounts and multi-factor authentication; destructive operations on a customer workspace require a guarded tool that exports first and refuses when a workspace shows signs of real use |
| Engineering | Automated checks on every change for tenant scoping, permission decisions, audit attribution and AI-billing correctness; dependencies kept up to date |
| Suppliers | Sub-processors chosen for their security practices and bound by written data protection terms |
We continue to strengthen these controls. Please report a suspected vulnerability to privacy@krivollo.com — we will acknowledge it promptly, will not take action against good-faith research that respects people’s privacy, and will tell you when it is fixed.
4. Data breach response
If we suspect a data breach, we follow these steps:
- Contain — stop the breach and limit the damage straight away (revoke credentials, disable access, preserve evidence).
- Assess — work out what information was involved, whose, and whether serious harm is likely. We complete this assessment as quickly as possible and within 30 days, as the Notifiable Data Breaches scheme requires.
- Notify — tell affected customers without undue delay (within 72 hours of confirming a breach of their Customer Data). Where an eligible data breach has occurred, notify the OAIC and affected individuals (or support our customers to do so), and notify any other regulator the law requires.
- Review — find the cause, fix it, and record what we changed.
5. Access, correction and deletion requests
- Users can view and update their profile in Krivollo. To have your account deleted, ask your workspace administrator to remove you and email privacy@krivollo.com; we will delete your account information within 30 days, except records we must keep (for example audit logs showing actions you took in a workspace, which belong to that workspace).
- End contacts should contact the business that holds their information. That business can correct or permanently delete a lead in Krivollo, and we will help it find and remove related records such as recordings and transcripts, or export them if access is requested.
- We respond to requests within 30 days and verify identity before releasing or deleting anything.
6. AI and data
- Customer Data is sent to an AI provider only to perform a feature the workspace has turned on, and only the data that feature needs.
- We do not use Customer Data to train models. We use AI providers whose business terms do not permit them to train on it, and switch off any model-improvement option a provider offers.
- Workspaces can use an Australian data-residency option or their own AI provider key where available.
7. Review
We review this policy, our retention schedule and our sub-processor list at least once a year and whenever we add a feature that handles a new kind of personal information.
Krivollo is operated by [Krivollo legal entity name] (ABN [ABN to be confirmed]), [Registered business address, Victoria, Australia]. Questions about this document: privacy@krivollo.com.