Legal
Privacy Policy
How IVMS.next collects, uses, stores and shares personal data, which AI and payment providers are involved, and how to exercise your rights under Kenyan law and the GDPR.
Version 2.5 · Effective · Last updated
- Operator
- SmartCense Tec
- Privacy requests
- support.ivms@smartcensetec.com
In short
- IVMS.next is operated by SmartCense Tec. We are the controller for your account and billing data, and the processor for the business records your company loads.
- We collect what is needed to run your account (name, email, role, sign-in records), your company's billing details, and the business data your company chooses to store.
- Your data is stored on Google Cloud in the European Union and is transferred there from Kenya under the safeguards described in Section 9.
- We use no advertising or third-party analytics tags, and show no cookie consent banner because everything we store in your browser is strictly necessary.
- The AI assistant sends your prompts, and the business records it looks up, to an AI provider without redaction. On our own key that is Google, OpenAI or Anthropic; under bring-your-own-key your company chooses the provider. An administrator can switch it off.
- Our support staff look at the business records your company stores (sales, stock, customers and settings) only while a support session is open. One of your administrators must allow it, it is read-only, it lasts at most 24 hours, everyone in your company sees a notice while it is open, and it is recorded in your audit trail. The administration of your account, billing and security records is separate, and we record each change we make to your company's records at your request in your audit trail (Section 11.4). A company can switch support sessions off.
- To exercise your rights, email support.ivms@smartcensetec.com. You may also complain, free of charge, to the Office of the Data Protection Commissioner (Section 14).
1. Who we are and how to reach us
This section names the operator, explains our two roles and gives our privacy contact.
1.1 The operator
IVMS.next is an inventory and point-of-sale platform operated by SmartCense Tec ("we", "us").
This notice is written to meet the Data Protection Act 2019, s.29 and the Data Protection (General) Regulations 2021, reg. 23. Section 16 adds what the GDPR and UK GDPR require for readers in the European Economic Area (EEA) or the United Kingdom.
1.2 Our two roles: controller and processor
For your account, billing, support and use of our website we are the data controller. For the business records you and your staff load into IVMS.next we are your data processor. Sections 3 and 4 explain which data falls into which role, because that changes who you should contact.
1.3 Privacy contact
Send privacy requests to support.ivms@smartcensetec.com. General product support is at support.ivms@smartcensetec.com.
1.4 Effective date and versions
This is version 2.5 of our Privacy Policy. It takes effect on 15 October 2026 and was last updated on 15 October 2026. Section 18 explains how we tell you about changes.
2. Who this notice covers
This section says which parts of the notice apply to each kind of reader.
2.1 Tenant administrators and staff (account holders)
You hold an account because a company using IVMS.next (a "tenant", or "the business") provisioned it. There is no public self-serve sign-up: we create a company account for the business, and one of its administrators invites staff by email. Most account holders therefore first appear in our systems because an administrator gave us their name, email and role (Section 3.8).
2.2 Website visitors and people who contact support
If you browse our marketing pages or Help Hub, or write to our support desk, we process the server request logs described in Section 3.4 and the content of your message. Those pages carry no analytics or advertising tags.
2.3 People whose data a tenant stores (customers, suppliers, employees, quote recipients, storefront shoppers, reviewers, report recipients)
A business using IVMS.next may record its customers, loyalty members, suppliers, staff, quotation recipients, and storefront visitors and shoppers, including the name, mobile number and email address a shopper gives when ordering from its storefront, and the email addresses outside its company to which it sends its scheduled reports. It decides why the data is collected and how long it is kept; we process it only on its instructions. If you are one of these people, contact the business first and we will assist it (Section 4.3).
2.4 Developers and integrations (API tokens, webhooks, Zapier/Make)
If a business gives you an API token or configures a webhook, connected app or Zapier/Make integration, we record who created the credential, its scopes, and when and from which IP address it was last used. The business is responsible for the recipients it chooses (Section 8.3).
2.5 Mobile app users
If you sign in through the IVMS.next mobile app, the app registers your device with us for push notifications and per-user device limits. Section 3.4 lists what a registration contains.
2.6 EEA and UK users
If you are in the EEA or the UK, Section 16 sets out the lawful bases, transfer safeguards, rights and supervisory authorities that apply under the GDPR and UK GDPR.
3. Data we collect as controller
This section covers the data we decide how to use: account, sign-in, billing, security records, correspondence and error reports.
3.1 Account and profile
Your user record, stored under your company account, holds your name, email address, phone number, role, status and store assignments, plus the profile details you choose to add: avatar, timezone, language, bio, social links and preferences such as theme, currency and date format.
Profile photos are stored as publicly readable files: anyone who has the link can view your photo, even without signing in. If you would rather not have a public photo, do not upload one, or remove it from your profile at any time.
3.2 Sign-in security and second factor
Sign-in uses Firebase Authentication with an email address and a password. A password you set in IVMS.next must be at least 15 characters long, or at least 8 characters when signing in to your account also needs a second factor; there is no rule about which kinds of characters to use. A password that is common, easily guessed or built from your own name or email address is refused, and so is one that has appeared in a known data breach. For that check your browser works out a SHA-1 hash of the new password and sends only its first five characters, through our server, to the Pwned Passwords service run by Have I Been Pwned, which answers with every hash that starts with them; your browser does the comparison, so neither we nor that service receive the password or its full hash from that check, and the service does not receive your IP address. When you set a new password from a reset link, our server, which receives the new password in order to set it, also makes the check itself in the same way: it sends the service only the first five characters of the hash and does the comparison. If the check cannot run, the password is judged on the other rules alone. If you enable two-factor authentication we store an encrypted authenticator secret and hashed backup codes, or hashed one-time email codes, with your two-factor status. A two-factor enrolment you do not finish is discarded after 10 minutes. Firebase Authentication may temporarily lock an account after repeated failed sign-in attempts. Our server also counts the failed attempts it sees: a wrong two-factor code entered after the right password, and a wrong recovery code for an authenticator app. It does not see a wrong password, which Firebase checks without telling our server, so wrong passwords are not counted. For each account and each hour it keeps the number of each, the time of the latest and the IP address it came from, and deletes the count automatically after 30 days. Your company's administrators can ask to be told when an account reaches a number of failed attempts they choose (Section 3.4).
3.3 Billing and payments
For the paying company we record the plan, subscription status, period dates and the last payment provider used. For M-Pesa we record the phone number you gave us in Kenyan international format, the amount and the receipt number Safaricom returns. For card payments through Paystack we record your email, the amount and the transaction reference. If you choose to save a card, we store only Paystack's authorisation token, the card brand, the last four digits, the expiry date, the email address you paid with and, where Paystack supplies it, the issuing bank; full card numbers and security codes do not reach us. Invoices are generated as PDF documents and stored under your company (Section 7).
If you cancel a plan we keep the reason you select and any comment you add. If you choose to save your M-Pesa number for future payments, we store it as a saved payment method that only you can see.
3.4 Security, device and audit records
Our server records each sign-in to your account the first time it receives a request from it: when you signed in, when that sign-in was first and last used, the IP address it was first used from and the latest one, your browser's user-agent string (from the ivms_agent cookie described in Section 12 when our hosting provider has replaced the one your browser sent) with a short description of the browser and system (such as "Chrome on Windows"), a one-way hash of the device identifier described in Section 12 (or of the browser and system description when your browser sends none), and when and how the sign-in ended. Account > Security shows you these records and lets you sign out any of them. We also keep a list of up to 25 devices your account has been used on, with each device's description and when it was first and last seen, so that we can email you when a new sign-in comes from a device your account has not been used on before. From the IP address of each sign-in, our server works out the country it appears to come from, using a country database kept on our own servers: the address is not sent to anyone for this. The country is kept with the sign-in record, and your account keeps a list of up to 10 countries it has been used from, with when each was first and last seen; a country not seen for 180 days is dropped. A country worked out this way can be wrong: a VPN, satellite or roaming connection can make a sign-in appear to come from another country. Your company's administrators can ask, in Alert Settings, to be told when a member signs in from a device or a country the account has not been used from before, or when an account reaches the number of failed sign-in attempts they choose (Section 3.2); the alert names the member and the device, country or number of attempts. Your user record keeps a count of your sign-ins and the times of your last sign-in and activity. Your company's audit log records, for each significant action, your user ID, name, email, the action, the record affected, the time and, where available, the IP address and browser string. API tokens are stored as SHA-256 hashes with a last-used time and IP address. Mobile registrations hold a device ID, installation ID, platform, app version, device name and push token.
When a platform administrator asks your company's devices to send the work waiting on them, each device that is online answers, and we record with the answer a short description of its browser and system, a one-way hash of its device identifier, the name of the person signed in on it and what happened (sent, nothing waiting, or failed). We keep each answer for 90 days, to see which devices can be reached.
Our servers on Google Cloud keep request and application logs for every page and API call: the time, the address requested, your IP address, browser string, the response status and, for signed-in requests, your user and company identifiers and occasionally your email address. We use them for security and troubleshooting and keep them for Google Cloud Logging's default period of 30 days.
3.5 Support and correspondence
Emails to our support desk and any service-level credit claims are kept as correspondence. Messages you post in Huddle, our team chat, are business records that your company controls (Section 4).
3.6 Usage and error reports
When the app hits an error, your browser may send a report containing the error message, stack trace, page address and browser string to our error endpoint, which rate-limits, sanitises and discards it; nothing is retained. We do not collect browser performance metrics.
We have built a first-party usage-analytics endpoint, but it is not connected to any page, so no usage events are collected today. We may collect usage events such as page, referrer, viewport and device type if we enable in-product analytics; we will update this notice first.
Help Hub. When a search in the Help Hub finds nothing, we record the words you searched, the Help Hub page you searched from, your company and when. We do not record who searched. We use these to find which guides are missing, and delete each one a year after the search. When you answer "Was this guide helpful?" at the end of a guide, we keep your answer, any reason you type and which guide it was, with your account, so that each person counts once per guide and can change their answer. We delete an answer a year after you last gave it. Answering is optional. Our platform team sees the searches and the answers per company, and sees a reason you typed, but not who searched or answered.
3.7 Mandatory data and consequences of not providing it
Name, email address and role are required to create an account; without them we cannot provision one. A phone number is optional, except for M-Pesa payment prompts.
No law requires you to give us this data; we collect it under our contract with your company to provide the service. Once a payment is made, Kenyan tax law requires us to keep the billing records described in Section 7.
| Data category | Examples | Why we need it | Required? |
|---|---|---|---|
| Account identity | Name, email, role, store assignments | Sign-in and permissions | Yes |
| Profile | Avatar, timezone, language, preferences | Personalisation | No |
| Sign-in security | Password, 2FA secret, backup codes | Account protection | Password yes; 2FA optional |
| Billing | Plan, M-Pesa phone, Paystack email, saved-card token | Charging and invoicing | Only to pay |
| Security and audit | IP address, device string, sign-in records, device identifier, audit entries, server logs | Security, fraud prevention | Automatic |
| Device registration | Device ID, platform, app version, push token | Mobile push, device limits | Mobile app only |
3.8 Where we get data when not from you
We receive personal data about you from two other sources. First, the administrator who invites you gives us your name, email and role. This notice is linked from the sign-in page, so you can read it before you first use your account, and where reg. 6(3) requires it we will tell you about this notice within 14 days of receiving your details. Second, Safaricom and Paystack send us payment confirmations with your phone number, email and transaction references.
3.9 Support session and platform administration records
When one of your company's administrators allows a support session, and when a member of our staff starts and ends one (Section 11.4), we keep a record of it. It holds who allowed it, when, for how long, the scope (read-only), the reason the administrator gave and the support request it was linked to, if any; the staff member who started it, when it started, when and how it ended; and the areas of the product the staff member looked at. Your company's audit trail shows you that record, with the staff member's first name and "(Support)" in place of the staff member's full identity, and without the staff member's IP address. We also keep our own, fuller record of every request made in the session: the staff member, the time, the area, the company, the staff member's IP address and browser string. We keep the same kind of record of the platform administration described in Section 11.4 (for example reopening a closed accounting period, or adding a user), and your company's audit trail shows each change that alters your company's records as a line in the name "Our platform team", without the staff member's name or address. These records are for security and for proving what happened, and your company cannot change them. Section 10.1 gives how long each is kept.
4. Data we process on behalf of tenants
This section covers the business records a company stores in IVMS.next, where the company is the controller and we act on its instructions.
4.1 What tenants store
A business may store the following categories of data about other people.
| Category of tenant data | Who it is about | Who decides retention |
|---|---|---|
| Customer and loyalty records: contact details, vehicles, addresses, tags, preferences, credit profiles | The business's customers | The business |
| Supplier contacts and purchase orders | Supplier staff | The business |
| Orders and point-of-sale receipts | Customers named on an order | The business |
| Bank statement lines and M-Pesa payment confirmations (payer name, phone number, amount, reference) | The business's customers | The business |
| Quotations and acceptance records (signer name, verified email, time, IP address, browser string; hidden from the public quote page) | Quote recipients | The business |
| Product reviews (display name, rating, comment) | Storefront shoppers | The business |
| Online orders placed on a storefront (name, mobile number, email address, optional note, the items ordered) | Storefront shoppers | The business |
| Email addresses outside the company that receive its scheduled reports (the address, whether it confirmed or asked to stop, when, and who in the business added it) | People outside the business, such as its accountant | The business |
| Huddle messages, attachments, reactions and read receipts | The business's staff | The business (Settings > General > Huddle) |
| AI assistant attachments | The business's staff | Us (no purge today; removal on request) |
| Account-export archives | Everyone in the company account | Fixed at 7 days by us |
4.2 We act on the tenant's instructions
The business decides the purpose of this data, how long it is kept and who receives it. Storefront analytics keep data for the number of days the business chooses (720 by default), and Huddle keeps messages until the business sets a retention period. Recipients are chosen through the integrations in Section 8.3. We do not use tenant data for our own purposes, except for security, abuse prevention and aggregate metrics such as record counts for plan limits. When one of your administrators allows a support session (Section 11.4), that is your instruction to let a named member of our staff look at your company's records for the time and scope chosen, to help with the problem you gave as the reason. Our staff are bound to use what they see only for that problem, and the viewer they use has no export, download or print function.
4.3 If you are a customer, supplier or employee of a business using the platform
Contact the business. It is the controller of your data and the only party that can instruct us to correct or erase it. If you write to us instead, we will forward your request to the business and assist it in answering within the statutory time limits.
4.4 Data Processing Addendum and sub-processors
The Data Protection Act 2019, s.42(2) and reg. 24 require a written contract between a controller and its processor, as does GDPR Article 28 for EEA and UK data. A Data Processing Addendum is available on request from support.ivms@smartcensetec.com. For EEA and UK data it will incorporate the EU Standard Contractual Clauses. The sub-processor list in Section 8 forms part of it. Whether or not a Data Processing Addendum is signed, we notify the business of a personal data breach without undue delay and, where practicable, within 48 hours of confirming it.
4.5 Where we are still controller
Even inside a tenant's company account we remain controller for security logs, rate-limiting counters, fraud and abuse prevention, the aggregate usage counters used to apply plan limits, and our own record of support sessions and of platform administration (Section 3.9).
5. Why we use data and the legal basis
Every purpose we process data for rests on a basis in the Data Protection Act 2019, s.30 and, for EEA and UK users, GDPR Article 6.
5.1 Purpose-to-basis table
The table maps each purpose to its basis and says whether you can object or withdraw.
| Purpose | Data used | Kenya DPA s.30 basis | GDPR Art. 6 basis | Can you object/withdraw? |
|---|---|---|---|---|
| Creating and running your account | Account, profile, sign-in security | Performance of a contract | Art. 6(1)(b) contract | Not while you hold an account |
| Invoicing and tax records | Billing, invoices | Legal obligation | Art. 6(1)(c) legal obligation | No |
| Security, rate limiting, App Check, audit trails, security alerts to your company's administrators | IP address, the country worked out from it, device string, sign-in records, device identifier, counts of failed sign-in attempts, session ID, audit entries, server logs | Legitimate interests | Art. 6(1)(f) legitimate interests | You may object; we may still act to protect the service |
| Taking and handling an online order from a storefront, and keeping the shopper's contact details to do so | Name, mobile number, email address, note, items ordered | Performance of a contract (the shopper's order) | Art. 6(1)(b) contract | Contact the business, which is the controller (Section 17.1) |
| Push notifications | Push subscription or device token | Consent | Art. 6(1)(a) consent | Yes, at any time |
| AI assistant | Prompts, page context, business records | Contract and legitimate interests | Art. 6(1)(b) and (f) | Yes; an administrator can disable it |
| Usage analytics (only if enabled) | Page, referrer, viewport, device type | Legitimate interests | Art. 6(1)(f) legitimate interests | Yes |
| Improving the Help Hub | The words of a Help Hub search that found nothing (not who searched); your answers about guides | Legitimate interests | Art. 6(1)(f) legitimate interests | Yes; answering is optional, and you may ask us to delete your answers |
| Support and correspondence | Your messages | Performance of a contract | Art. 6(1)(b) contract | You may ask us to delete closed threads |
| Recording support sessions and platform administration: who allowed a session, which staff member looked at your company's records or changed them, when and where | The administrator's name and reason, the staff member's name, the times, the areas looked at or the change made, the staff member's IP address and browser string | Legitimate interests | Art. 6(1)(f) legitimate interests | You may object; we may still keep the record, because it shows you and us what was looked at. Staff members' rights are exercised through their employer |
5.2 Further processing
We do not process personal data for a purpose incompatible with the one it was collected for, as s.30(2) requires; a new purpose means an update to this notice first.
5.3 Direct marketing
We send no marketing email today. If we ever do, it will be only with your express consent under s.37 and regs 15 and 16, with a free one-click opt-out and a visible sender identity. In-app renewal reminders, invoice emails, plan-change notices and security alerts are service messages needed to run your account; they cannot be opted out of.
5.4 Automated decision-making
We make no decision about you with legal or similarly significant effects solely by automated means. AI assistant outputs are suggestions, and every action it proposes that would change your data must be confirmed by a person first. Demand forecasts and anomaly flags are calculated on stock and sales figures, not on individuals.
6. AI assistant
The assistant answers questions by sending your messages and relevant business records to an external AI provider; this section explains what leaves the platform and what controls exist.
6.1 What leaves the platform
When you message the assistant, we send the AI provider selected for your company account the last 24 messages of the conversation, up to 4,000 characters of context from the page you are on, any file you attach (CSV, text, image or PDF up to 5 MB), and the business records the assistant fetches to answer you. Those records may include products, orders with the customer's name, email and phone number, supplier contacts, stores, stock movements, and staff names, emails and roles. No redaction or anonymisation step runs before this data is sent.
6.2 Which providers and their published data terms
On a key we supply, we route requests to Google (Gemini API, the default), OpenAI or Anthropic. These three are the only providers we operate as a sub-processor, and the table below states each one's published defaults. We have not agreed special retention or residency terms with any of them, so those defaults, as published on 3 September 2026, apply and may change.
| Provider | Used for | Data sent | Provider's published retention/training default | Where we checked |
|---|---|---|---|---|
| Google (Gemini API) | Chat, tool calls, Help Hub embeddings | Everything in Section 6.1 | Paid tier: no product improvement; abuse logs kept briefly; may be cached in any Google facility | Gemini API terms (opens in a new tab), as published on 3 September 2026 |
| OpenAI (API) | Chat, tool calls, Help Hub embeddings | Everything in Section 6.1 | Not used to train OpenAI models by default; abuse-monitoring logs kept up to 30 days; flagged content may be reviewed by people | OpenAI API data usage guide (opens in a new tab), as published on 3 September 2026 |
| Anthropic (API) | Chat, tool calls | Everything in Section 6.1 | Not used to train models under its commercial terms; deleted within 30 days; content flagged by safety systems may be kept up to 2 years | Anthropic API data retention page (opens in a new tab), as published on 3 September 2026 |
Our policy is to keep our platform Gemini key on a Google Cloud project with billing enabled, so that Google's paid-service terms apply to requests made with it. We cannot promise that any provider deletes data immediately or keeps it in one country.
6.3 Providers your company can choose under bring-your-own-key
The software can also reach xAI (Grok), DeepSeek, Qwen (Alibaba Cloud) and MiniMax. We do not operate a key for any of them. They are switched off on our side and are reachable only when your company supplies its own API key, in which case your company — not us — is the provider's customer and contracts with it directly, on that provider's own terms. We do not review, negotiate or warrant those terms, we take no fee or margin on what you spend with them, and some of these providers process data outside the EEA, including in jurisdictions without an adequacy decision. Your company should satisfy itself about a provider's retention, training and residency policy before storing a key for it, and should record that provider in its own processing records.
If we ever enable one of these providers on a key we supply, it becomes our sub-processor and we will give tenant administrators the advance notice described in Section 8.4 first.
6.3 Bring your own key
Companies on the Growth plan and above may store their own API key for any provider we support (Section 6.2 lists the ones we also operate; Section 6.3 lists the ones available only this way). Requests made with your key go to the provider under your own account and contract, so you are the provider's customer for that traffic. We store the key encrypted with AES-256-GCM and use it only for your company account; a platform administrator may require a company to use its own key. If your Gemini key belongs to a Google project without billing enabled, Google's unpaid-service terms apply: Google may use your prompts to improve its products and allow people to review them.
What it costs. Nothing to us. When you use your own key, the provider bills your account with them directly, at their prices, and SmartCense Tec adds no charge, margin or per-request fee of any kind on top. We do not receive a share of that spend and we do not resell provider capacity. Your subscription price is unchanged whether you use your own key or ours. The token and cost figures we show you for your own key are our own estimate from the model's published rates, shown so you can keep an eye on usage inside IVMS.next — they are not a bill, they are not authoritative, and only your provider's invoice is. Setting a spending limit, and paying it, is between you and your provider.
6.4 Controls and switches
A company administrator can disable the assistant for the whole company account at any time. With our managed keys it is available on the Professional plan and above, with 100 queries per month on Professional, and we apply per-account rate limits and spending budgets to the cost we carry. Those spending budgets do not apply to requests made with your own key, because that spend is not ours: only the rate limits still apply there, to protect the service. Any action the assistant proposes that would change your data requires a person to confirm it, and a platform-wide switch can disable all such actions.
6.5 Storage and retention of AI data
Conversations are stored in Firestore in the EU under your company. We keep the 20 most recent per user; older ones are deleted automatically, and you can delete any conversation yourself. Attachments are stored in Firebase Storage, cannot be read directly by browsers, and are served only through links that expire after 1 hour. Attachments are currently kept indefinitely: deleting a conversation does not delete its attachments, and no purge job exists yet. We will add one and update this notice; until then, email support.ivms@smartcensetec.com to have an attachment removed. For each request we also record your email, the tokens used and an estimated cost, for budgets and usage reporting.
6.6 Training
Our policy is that SmartCense Tec does not train or fine-tune any model on tenant data or on AI conversations.
7. Payments
Subscription payments go through Safaricom and Paystack; this section says what each receives.
7.1 Safaricom M-Pesa
When you choose M-Pesa we send your phone number, the amount and a payment reference to Safaricom, which sends the payment prompt to your phone. Safaricom returns a receipt number, which we store with the payment. Safaricom's own terms govern its handling of your data.
7.2 Paystack
When you choose card payment, Paystack receives your email address and the amount and collects your card details on its own pages. If you tick the option to save a card we store only Paystack's authorisation token, the card brand, the last four digits, the expiry date, the email address you paid with and, where Paystack supplies it, the issuing bank. We do not see or store full card numbers or security codes. Paystack's own notice governs its handling of your data.
7.3 Invoices
When a payment is confirmed we generate a PDF invoice, store it under your company and email it to your billing contact once. We keep invoices for at least the period Kenyan tax law requires; today nothing deletes them, and the download link in Billing stays valid for 10 years.
7.4 Storefront and tenant payments
A storefront can take an order from a shopper without an account, but it takes no payment: the shopper pays the business directly, on collection or delivery, and we are not a party to that payment. Where a business records a sale or connects its own M-Pesa pay bill for bank reconciliation, we process on its behalf the payment reference and, for M-Pesa confirmations, the payer's name, phone number and amount that Safaricom sends. That data is tenant data under Section 4.
8. Who we share data with
We share personal data with the providers listed here, with recipients your company chooses, and with authorities where the law requires.
8.1 Sub-processors
Each provider processes data only to deliver its service to us.
| Sub-processor | Purpose | Data | Location | Safeguard (DPA / SCC / DPF) |
|---|---|---|---|---|
| Google Cloud and Firebase | Hosting, database, file storage, authentication, App Check with reCAPTCHA v3, push messaging, the queue for webhook deliveries | All platform data; sign-in credentials; push tokens | Firestore eur3, Functions and the webhook queue (Cloud Tasks) europe-west1, App Hosting europe-west4; Authentication, App Check and Cloud Messaging are global | Google Cloud data-processing terms |
| Upstash (Redis) | Rate limiting, CSRF tokens, cache | IP-keyed counters, session-bound tokens | As configured by us; confirmed on request | Upstash data processing agreement |
| Google (Gemini API) | AI assistant, when used | See Section 6 | Any country where Google has facilities | Gemini API terms and Google's data-processing addendum |
| OpenAI | AI assistant, when used | See Section 6 | Primarily United States | OpenAI data processing addendum |
| Anthropic | AI assistant, when used | See Section 6 | Primarily United States | Anthropic commercial terms and data processing addendum |
| Safaricom (M-Pesa) | Subscription payments | Phone number, amount, reference, receipt | Kenya | Safaricom's own terms (independent controller) |
| Paystack | Subscription card payments | Email, amount, masked card data, authorisation token | Kenya; hosting per Paystack's notice | Paystack's own terms (independent controller) |
| Google (Gmail SMTP) | Sending all platform email | Recipient address, message content, attachments | Global Google infrastructure | Google's terms of service and privacy policy |
| Browser push services (Google, Mozilla, Apple) and Firebase Cloud Messaging | Delivering notifications | Title, short message, category, link | Global | Each vendor's own terms |
| Open Food Facts family and UPC Item DB | Barcode reference lookup | The scanned barcode only; no personal data | Global | Not applicable |
8.2 Other recipients
We may share personal data with our professional advisers and auditors; with regulators, including the Office of the Data Protection Commissioner and the Kenya Revenue Authority, on a lawful request; with courts and law enforcement where the law requires; and with a successor operator if we merge with or sell the business, with email notice to you before the transfer.
8.3 Recipients you choose
Integrations your company configures send data where it directs: API tokens, webhooks, Zapier and Make connections, CSV and Excel exports, Zoho Books when we enable it, and custom storefront domains. Your company is responsible for those recipients.
8.4 Adding a sub-processor
Before we add a sub-processor that will process tenant data, we will email tenant administrators at least 10 business days in advance. An administrator may object within that period; if we cannot resolve the objection, the business may cancel its plan as our Terms of Service, Section 6.3 describes.
8.5 What we do not do
Our policy is that we do not sell personal data. We use no advertising, retargeting or third-party analytics tags. We do not use third-party error monitoring, session-replay or live-chat widgets.
9. Where data is stored and international transfers
Your data lives in the EU, is transferred there from Kenya, and some providers process it elsewhere; this section gives the locations and safeguards.
9.1 Primary storage in the EU
Our database (Firestore) runs in the EU multi-region eur3, our server functions and the queue for webhook deliveries in europe-west1, and our web application in europe-west4. Files are stored in a Firebase Storage bucket on Google Cloud, which our residency policy places in the EU. Firebase Authentication, App Check and Cloud Messaging are global Google services not pinned to a region.
| Data | Location | Transfer route | Safeguard |
|---|---|---|---|
| Database records, files, invoices, chat, AI conversations | Google Cloud, EU | Kenya to EU | Google Cloud data-processing terms; Section 9.2 |
| AI prompts and fetched records | Google, OpenAI or Anthropic | EU to the provider, including the United States | Provider addenda; EU SCCs where applicable |
| Rate-limit counters, CSRF tokens | Upstash, region as configured | EU to Upstash | Upstash data processing agreement |
9.2 Transfers from Kenya
No Google Cloud region exists in Kenya, so data collected in Kenya is stored and processed in the EU. Under the Data Protection Act 2019, ss.48 and 49 and regs 40 to 46, we rely on appropriate safeguards, namely Google Cloud's data-processing terms and the security measures in Section 11, together with the necessity of the transfer to perform our contract with you. Copies are available from support.ivms@smartcensetec.com. Each sub-processor may transfer personal data onward only under safeguards equivalent to those in its agreement with us.
9.3 Transfers out of the EEA/UK
Google, OpenAI and Anthropic may process AI requests in the United States and other countries; Upstash may process data outside the EEA depending on the region we configure; Paystack processes payment data in Kenya and the locations named in its notice. If you are in the EEA or the UK, Section 16.3 gives the safeguards for these onward transfers.
9.4 Backups
We export the full database every day at 03:30 UTC to a Google Cloud Storage bucket. Backups exist for disaster recovery only. We have not yet set a fixed retention period for backups, so deleted data may remain in a backup until that backup is removed; we will state the retention period here once it is in place.
9.5 Sensitive personal data
Kenya's definition of sensitive personal data includes property and family details, which ordinary customer-relationship fields may contain. Where your company stores such data about its customers, it is the controller and must obtain the consent that s.49 requires before that data is processed outside Kenya. We process it only on the business's instructions, on the terms described in Section 4.4.
9.6 Kenyan localisation reservation
Under s.50 the Cabinet Secretary may require certain processing to take place on servers in Kenya. Reg. 26 already requires some categories, such as health and revenue-administration data, to be processed on servers in Kenya. We do not host those categories unless we agree it in writing, as our Terms of Service, Section 6.4 explains. If a wider requirement reaches IVMS.next, we will change our hosting and update this notice.
10. How long we keep data
We keep personal data while the purpose it was collected for continues, then for any period the law requires; this section gives the concrete periods.
10.1 Retention schedule
Where a period is described as our archival policy, it is applied by a job we run manually rather than by an automatic control.
| Record | Retention | Set by | Reference |
|---|---|---|---|
| Account and profile records | Life of the company account, then archived under our archival policy | Us | Section 10.3 |
| Audit logs | 90 days active, then archived; deleted after 730 days under our archival policy, or later where tax or other law requires | Us | Section 3.4 |
| Server request and application logs (Google Cloud Logging) | 30 days (Google's default retention) | Us | Section 3.4 |
| Orders, point-of-sale transactions and payment records | Life of the company account; after closure, for as long as tax law requires | The business and the law | Terms of Service, Section 18.5 |
| Storefront analytics (product views, searches) | Per tenant setting; 720 days by default; purged daily | The business | Settings > Analytics & Reports > Analytics Settings |
| Report recipients outside the company (address, confirmed or stopped, when, added by) | Life of the company account; a request to stop is kept so that it goes on being honoured | The business | Section 13.3 |
| Huddle messages and attachments | Until the business sets a retention period; then purged daily | The business | Settings > General > Huddle |
| Account-export archives | 7 days, then deleted | Us | Settings > Export/Import |
| AI conversations | 20 most recent per user; older deleted automatically | Us | Section 6.5 |
| AI attachments | Indefinitely today; removal on request | Us | Section 6.5 |
| AI usage records (email, tokens, cost) | Life of the company account, then archived under our archival policy | Us | Section 6.5 |
| Invoices | At least the statutory tax period; no deletion today | Law | Section 7.3 |
| Sign-in records (time, IP address, country, device) | 180 days after the sign-in was last used, or 30 days after it ends, whichever comes first; then deleted automatically | Us | Section 3.4 |
| Devices your account is known on | Up to 25; a device not seen for 180 days is dropped the next time you sign in | Us | Section 3.4 |
| Countries your account has been used from | Up to 10; a country not seen for 180 days is dropped the next time you sign in | Us | Section 3.4 |
| Counts of failed sign-in attempts (per account per hour, with the latest IP address) | 30 days, then deleted automatically | Us | Section 3.2 |
| Records of a change to your sign-in email address | 180 days after the change was requested or, once it completes, 180 days after that; then deleted automatically | Us | Section 14.3 |
| Deletion requests made in Account > Your data | While open, and for 730 days after it is answered; then deleted automatically | Us | Section 10.3 |
| Session cookie; CSRF token | 7 days; 1 hour | Us | Section 12 |
| Device identifier cookie (ivms_device) | 400 days, renewed while you use the app signed in | Us | Section 12 |
| Browser description cookie (ivms_agent) | 400 days, renewed while you use the app signed in | Us | Section 12 |
| Password reset link; email verification link | 1 hour; 3 days | Us | Firebase defaults |
| Two-factor enrolment in progress | 10 minutes | Us | Section 3.2 |
| Firebase Authentication records after deletion | Removed by Google within 180 days | Firebase privacy notice | |
| Mobile device registrations | Until you sign out or the device is removed | You | Section 3.4 |
| Webhook dead letters | 90 days | Us | Terms of Service, Section 11.2 |
| Answers from devices asked to send waiting work | 90 days, then deleted automatically | Us | Section 3.4 |
| Help Hub searches that found nothing (the words, page, company and time; not who searched) | 1 year after the search, then deleted automatically | Us | Section 3.6 |
| Answers to "Was this guide helpful?" (with your account) | 1 year after you last answered, then deleted automatically | Us | Section 3.6 |
| Support session entries in your company's audit trail (grant, start, areas looked at, end) | As audit logs: 90 days active, then archived; deleted after 730 days under our archival policy | Us | Section 3.9 |
| Our own record of support sessions and of platform administration (staff member, times, areas or change made, company, IP address, browser string) | 2 years after each entry, then deleted | Us | Section 3.9 |
10.2 What happens when a subscription ends
Nothing is deleted when a paid plan ends or is cancelled. The company account moves to the Free plan and its data is preserved: you cannot create new records above the Free limits, and existing records stay readable, exportable and deletable. If the company account holds more products than the Free plan allows, editing product details is paused 30 days after the move — for every product, not only those above the limit — until the count is back within the limit or a larger plan is bought; reading, exporting, archiving, deleting, recording stock and selling are not affected. The Terms of Service, Section 3.1, sets this out in full. Deletion of a company account by us is a reversible soft delete followed by permanent removal under our archival policy, within a period we will confirm on request.
10.3 Account deletion
No button deletes your account at once. In Account > Your data you can ask your company's administrators to delete your account and the personal data held about you, after confirming it is you. The request is recorded with an answer due seven days later, the administrators are notified and see it in a list of open requests, and when one of them answers, saying what was deleted or why something must be kept, you are told in the app. You can also email support.ivms@smartcensetec.com or ask your administrator, who can remove your ability to sign in immediately. Your user record is then archived, with your name, email and phone number retained for audit and recovery, and is permanently removed under our archival policy. We respond to deletion requests within 14 days, as the Data Protection (General) Regulations 2021 require, and will explain anything we must keep for tax or audit reasons and for how long.
10.4 Anonymisation
Records kept beyond this schedule, such as aggregate metrics, are anonymised or pseudonymised where feasible, as s.39(2) expects.
11. How we protect data
The Data Protection Act 2019, s.29(f) asks us to describe our security measures; this section lists only what exists today.
11.1 Technical and organisational measures
We apply the following measures:
- TLS in transit and Google-managed encryption at rest for the database and file storage.
- Firebase Authentication with an optional second factor (authenticator app or email code) and mandatory multi-factor authentication for our own platform administrators.
- Database and storage security rules that isolate each company's data and enforce role-based permissions, including expiry of temporary roles.
- Re-authentication before sensitive actions, and automatic sign-out, by default after 30 minutes of inactivity or 8 hours in total.
- A server-side record of each sign-in, from which you can see where your account is signed in and sign any device out, and email notice of a sign-in from a new device, a password change and other changes to how your account is protected. Where your company's administrators ask for them, alerts about sign-ins from a new device or country and about repeated failed sign-in attempts.
- CSRF tokens on browser requests and IP-based rate limiting on our APIs.
- Firebase App Check with reCAPTCHA v3, which may be used to attest requests to public endpoints.
- AES-256-GCM encryption of stored provider keys, authenticator secrets and single-sign-on secrets; API tokens stored as hashes; HMAC-signed webhooks.
- Staff access to your company's business records through the product only in a support session that your administrators allow, time-limited, read-only and recorded; the platform administration we do without a session is limited to the account, billing and security records, platform-wide statistics that do not show your business records, and a few named changes, which are recorded too (Section 11.4).
- Audit trails, daily database backups, server secrets held in Google Secret Manager, and encryption of the offline cache on your device.
We hold no security certification.
11.2 Data breaches
If a personal data breach poses a real risk of harm to you, we will notify the Office of the Data Protection Commissioner within 72 hours of becoming aware of it and notify you in writing within a reasonably practical period, as s.43 requires. Where we act as processor, we notify the business without undue delay and, where practicable, within 48 hours of confirming it. For EEA and UK data we notify the competent supervisory authority within 72 hours where the GDPR requires.
11.3 Your part
Keep your password private, enable two-factor authentication, sign out on shared devices and, as an administrator, remove staff who leave promptly.
11.4 Support access to your company's records
This section keeps two kinds of access apart: a support session, which is how our staff look at your business records, and platform administration, which is how we run your account.
Support sessions. In this section, your administrators are the members of your company who can manage it, whatever their role is called. Our support staff can look at the business records your company stores (sales, stock, customers and settings), through the product, only while a support session is open. A session starts only when one of your administrators allows it. It lasts at most 24 hours, and the administrator chooses one hour, four hours or 24 hours, with one hour offered first. It is read-only: the staff member can look but cannot change, add or delete anything, and cannot sign in as one of your users. No feature of the product lets any member of our staff sign in as one of your users, in a session or out of one. While the session is open, the app shows everyone in your company a notice, whenever it can read the record of the session. Your administrators can end it at any moment. It also ends by itself when its time is up, when your company is disabled, made inactive or deleted, and when we remove the staff member's permission to start sessions. Every session, and every area the staff member looks at in it, is recorded in your company's audit trail, which your administrators can read, and everyone in your company who can manage it is emailed, and notified in the app, when a session starts and when it ends. The staff member who looks at your records is one of a small number of our platform administrators who may start a session; each must have signed in with a second factor and confirmed their sign-in again just before starting it. A platform administrator's account gives no access to your company's records in the database: the way to them through the product is a session.
Platform administration. To run the service, our platform administrators work, without a session, with the account, billing and security records we hold about your company (Section 3): its profile, plan, payments and status, the messages you send our support desk, and the list of your company's users with their name, email address, role, status and sign-in times and counts. That list does not include phone numbers, security settings, store assignments, or the address and device of a sign-in. They also see platform-wide statistics across all companies (for example, how many companies, users, products and orders the service holds, and how many changes are waiting to sync), which do not show your business records. We also make a few changes to your company's records, only to help with a request you have made to us: reopening a closed accounting or reconciliation period, importing the default categories and materials, re-numbering customer cards, updating category classifications, changing a user's details or role, making or removing an administrator, adding, removing or restoring a user, sending a user a password reset link so that they can recover their account, deciding a role change request, changing your company's account details (such as its profile, plan or status), opening guided setup, changing your AI settings, updating a payment record (confirming or cancelling a payment, or issuing an invoice), changing single sign-on, and removing a notification. These are not read-only and are not a session. We record each of them in your company's audit trail, in the name "Our platform team", and our own record of it (Section 3.9) names the staff member. If a line cannot be saved we try once more, and if it still cannot be saved we note that in our own record so that it can be put right. We read your company's audit trail, with the address, device and values that changed, only in a support session.
Support sessions are your company's choice. An administrator can choose "Never allow support sessions" on the Support access page in the company's system settings, and no session can then be started. The choice does not stop platform administration, because a company that has chosen it still needs its account, billing and users administered. When a session is not open, our staff have no way through the product to look at the business records your company stores.
This section covers the business records your company stores. It does not limit what the law requires us to disclose (Section 8.2). It also does not describe the access that the people who run the underlying cloud project need to host, migrate, back up and repair the service: that is not a support session, and Section 9 and Section 11.1 describe how the data is stored and protected. Our staff are bound by confidentiality, as the Terms of Service, Section 6.3, says.
Support sessions are off until we switch the feature on. Until then no support session takes place; the platform administration described above is how we run your account today.
12. Cookies, local storage and offline data
IVMS.next works offline, so it keeps more in your browser than a typical website; this section lists every item and explains why no consent banner is shown.
12.1 Why there is no cookie banner
We set three cookies ourselves. session-id is HttpOnly and SameSite=Strict, lasts 7 days and is used only to bind the anti-forgery (CSRF) tokens that protect your requests. ivms_device holds a random identifier for your browser: it is set only while you are signed in, is SameSite=Strict and sent only with requests to our API, and lasts 400 days, renewed while you use the app. Our server keeps only a one-way hash of it, to tell your devices apart in your sign-in records and to notice a sign-in from a device your account has not been used on before (Section 3.4). ivms_agent holds your browser's own description of itself, its user agent (such as "Mozilla/5.0 (Windows NT 10.0; Win64; x64) … Chrome/128.0.0.0 …"), and is set, sent and kept in the same way as ivms_device. Your browser already sends that description with every request, but our hosting provider replaces it with "Google" before the request reaches our servers, so the cookie is how your sign-in records, the security emails in Section 13.2 and audit entries can still say which browser was used. Everything else is storage the app needs to sign you in, work offline and remember your settings. Because every item is strictly necessary for a service you have asked for, we do not show a cookie consent banner. Google reCAPTCHA, loaded through Firebase App Check, may set its own cookies where it loads. If we ever add storage that is not strictly necessary, we will ask for your consent first.
12.2 Storage inventory
The items we store on your device are listed here, grouped by purpose.
| Item | Type | Purpose | Lifetime | Strictly necessary? |
|---|---|---|---|---|
| session-id | Cookie | Binds CSRF tokens to your browser | 7 days | Yes |
| ivms_device | Cookie (API requests only) | Recognises this browser in your sign-in records and for new-device sign-in notices | 400 days, renewed while signed in | Yes |
| ivms_agent | Cookie (API requests only) | Your browser's own user agent, so your sign-in records, security emails and audit entries can name the browser where our hosting provider replaces the one it sends | 400 days, renewed while signed in | Yes |
| ivms.device-id | localStorage | The same browser identifier, so the cookie can be renewed | Persistent | Yes |
| Firebase Auth persistence | IndexedDB | Keeps you signed in | Until sign-out | Yes |
| Firestore offline cache | IndexedDB | Recently read records for offline use | Until sign-out or eviction | Yes |
| ivms_{companyId} (Dexie) | IndexedDB | Encrypted offline copy of products, transactions, orders, customers, credit invoices, users, reference data, pending operations | Until sign-out or cleared | Yes |
| Serwist precache and runtime caches | Cache | App shell and pages for offline use | Until the app updates or is uninstalled | Yes |
| Session bookkeeping (sessionStartTime, currentSessionId, session_last_activity, session_timeout_config, pendingLoginSessionId, pendingLoginTimestamp) | localStorage | Inactivity timeout; sign-in audit de-duplication | Until sign-out or timeout | Yes |
| ivms_user_snapshot | localStorage | Cached profile and company for offline reload | 30 days | Yes |
| product-store | localStorage | Cached product list for the Products page (not encrypted) | Persistent | Yes |
| order-store | localStorage | Cached order list (not encrypted) | Persistent | Yes |
| UI preferences (ivms-app-store, pos-store, ivms.dashboard.view, ivms.sidebar.rail.collapsed, ivms-notifications-group-similar, ivms_dismissed_upgrade_banners, ivms-locale, ivms-accessibility-config, prefersReducedMotion, highContrast, theme) | localStorage | Layout, parked POS sales, locale, accessibility and theme choices | Persistent | Yes |
| Drafts and history (ivms-chat-draft:*, ivms-search-history, ivms-saved-searches) | localStorage | Unsent chat drafts (ignored after 7 days), recent and saved searches | Persistent | Yes |
| error_report_* | localStorage | Up to 10 local error reports for the offline sync engine; not sent to us | Persistent | Yes |
| Per-tab flags (2fa_verified, mfa_enrollment_checked, email_verification_ok, ivms-initializing, ivms-app-initialized, pwa-prompt-dismissed, ivms.tour.*) | sessionStorage | Sign-in gates, start-up state, install prompt, snoozed tours | Until the tab closes | Yes |
| Guided setup (ivms.setup.draft., ivms.setup.summary., ivms.setup.return-to, ivms.setup.resume-after-sign-in) | sessionStorage | What an administrator has typed into a guided setup step and not saved yet, supplier names carried from one step to another, the reference of an import still running, how far the company's setup is, so a reload opens the dashboard or the setup choice straight away, the page the guide was opened from, for its Back button, and, just after a sign-in, a note to go back to the guide while setup is under way | Until the tab closes or sign-out | Yes |
| Storefront wishlist and compare lists | localStorage | Saved product IDs on a storefront; not sent to us | Persistent | Yes |
| Storefront cart (sf:cart:*) | localStorage | Product IDs and quantities a shopper has added on a storefront; not sent to us until the shopper places the order | Persistent, until the order is placed or it is cleared | Yes |
12.3 Clearing data and shared devices
Signing out clears the session keys, the encrypted offline database and the Firestore cache; the cached product and order lists remain until you clear site data. Your browser's site-data settings clear the rest, and uninstalling the installed app removes the service-worker cache. Offline data stays on the device until it syncs, so sign out on shared tills when you finish.
13. Notifications and communications
This section covers push notifications and the email we send, for ourselves and on a business's behalf.
13.1 Push notifications
Browser and mobile push are enabled only after you grant permission in your browser or device. We store the push subscription or device token under your user record, where only you and our servers can read it. Notification content passes through Google, Mozilla or Apple push services. You can revoke push in Notification preferences or your device settings. Security notifications cannot be muted.
13.2 Email we send
We send transactional platform email: invitations, password resets, email verification, two-factor codes, invoices, plan changes, product limit notices, export-ready notices and account security notices. A security notice goes to your own address when your password changes, when two-factor authentication or an authenticator app is turned on or removed, when a backup code is used to sign in instead of an authenticator app, when every device is signed out of your account, and when a new sign-in comes from a device your account has not been used on before; a change to your sign-in email address is announced to the old address before it takes effect. A product limit notice goes to the administrators and managers of a company account, and to the contact address held on the account, at most three times during the 30 days after a plan change leaves the account holding more products than its plan allows. It carries no unsubscribe link, because it tells you the date on which part of the Service stops working; it stops as soon as the account is back within the limit. Security alerts that your company's administrators choose in Alert Settings, such as a member signing in from a new device or country or an account reaching a number of failed sign-in attempts, go to those administrators in the app and, where they choose email, to the addresses they set; each names the member concerned. We also send product notifications and digests according to your Notification preferences, each with a link to change them. Renewal reminders are currently shown in the app only.
13.3 Emails we send on a tenant's behalf
Quotations, acceptance codes and purchase orders go to a business's customers and suppliers through our email transport.
A business may also send its scheduled reports to email addresses outside its company, such as its accountant. When someone in the business with permission to do so adds an address, we send that address one email asking it to confirm, at most once a day and five times in all; we send it nothing else unless the person presses Confirm on the page the email opens, within 14 days. A report sent to such an address never includes profit or cost, and every one carries a link to stop them, which we honour at once and which also works as your mail program's unsubscribe button. To be removed, use that link or ask the business. These messages are sent from our address and say they are sent on behalf of the business; replies go to the business's own support address where it has set one, and that address appears in the footer.
14. Your rights and how to exercise them
You have rights over your personal data under Kenyan law, most of which you can exercise by email or in the app.
14.1 Your rights under the Kenya Data Protection Act
Your rights under the Data Protection Act 2019, and the response times set by the Data Protection (General) Regulations 2021 that we meet, are as follows.
| Right | What it means | Kenya response time | How to use it |
|---|---|---|---|
| To be informed (s.26(a)) | Knowing how your data is used | Not applicable | This notice |
| Access (s.26(b)) | A copy of your data | 7 days (reg. 9) | Account > Your data, or email us |
| Object (s.26(c)) | Stopping legitimate-interest processing; absolute for direct marketing | 14 days (reg. 8) | Email us |
| Correction (s.26(d), s.40) | Fixing inaccurate, outdated, incomplete or misleading data | 14 days (reg. 10) | Profile page or email us |
| Deletion (s.26(e), s.40) | Erasing false, misleading or unneeded data | 14 days (reg. 12) | Account > Your data, email us, or your administrator |
| Restriction (reg. 7; s.40(3)) | Pausing processing during a dispute | 14 days (reg. 7) | Email us |
| Portability (s.38) | Your data in a machine-readable format | 30 days (reg. 11) | Account > Your data (a JSON file), or email us |
| Automated decisions (s.35) | Reconsideration of any solely automated decision (we make none today) | A reasonable period (s.35(4)); we aim for 14 days | Email us; Section 5.4 |
| Withdraw consent (s.32) | Ending consent-based processing, such as push | Immediate | Notification preferences |
Users with the export permission can also download the company account's data with Account archive (Section 14.3), although it leaves out each person's preferences, devices, sessions and saved payment methods.
Under s.27, a parent or guardian may exercise these rights for a child, and a person with a lawful mandate for someone who lacks capacity.
14.2 How to make a request and how fast we answer
Email support.ivms@smartcensetec.com from your account email address. We may ask you to verify your identity first. We answer access requests within 7 days; correction, erasure, restriction and objection requests within 14 days; and portability requests within 30 days. Requests are free unless clearly excessive.
14.3 Self-service tools
You can edit your name, phone number and photo on your profile; change the email address you sign in with, which sends a link to the new address and a notice to the old one; change your password and two-factor settings; see where your account is signed in and sign any device out; manage your Notification preferences; and delete individual AI conversations. In Account > Your data, after confirming it is you, you can see what is held about you and download it as a JSON file: your profile and settings, your sign-in records with their IP addresses, countries and devices, the devices and countries your account is known in, the counts of failed sign-in attempts, any change of sign-in email address or deletion request, and a record of the actions you took, without your company's business records or anything about other people. You can also ask for deletion there (Section 10.3). Users with the export permission can run a full Account archive from Settings > Export/Import on every plan (links expire after 7 days) and export customers, orders, suppliers, products and other records as CSV or Excel.
14.4 If your data is held by a business using the platform
Contact the business; we will help it answer within the same time limits and act on its instructions.
14.5 Complaints to us
If you are unhappy with how we handle your personal data or a request, email support.ivms@smartcensetec.com with "Complaint" in the subject line. We will acknowledge your complaint, investigate it, and give you a written response as soon as we can and in any case within 30 days. Complaining to us does not limit your right to complain to the Office of the Data Protection Commissioner at any time.
14.6 Complaints to the Office of the Data Protection Commissioner
You may lodge a complaint with the Office of the Data Protection Commissioner free of charge, using Form DPC 1, orally or electronically. The Office is at Britam Tower, 12th and 13th floor, Hospital Road, Upper Hill, Nairobi; P.O. Box 30920-00100; email info@odpc.go.ke; or its online complaints page (opens in a new tab). You do not have to contact us before complaining.
15. Children
IVMS.next is a business tool. Accounts are for adults acting for a business, and we do not knowingly collect personal data from anyone under 18. Because company accounts are provisioned for businesses and accounts are created by their administrators for adult staff, the proportion of data likely to relate to a child is negligible, so we apply no technical age-verification step; this is the criterion s.33(3) allows us to apply. We will review it if we add features aimed at individuals. If we learn that a child's personal data was collected without a parent's or guardian's consent, we will delete it or obtain that consent, as s.33 requires. We do not profile children for direct marketing, as reg. 13(2) prohibits. A business that operates a storefront is responsible for age-appropriate practices with its shoppers.
16. EEA and UK users
If you are in the EEA or the UK, the GDPR or UK GDPR applies alongside Kenyan law; this section gives the additional information those laws require.
16.1 Controller and representative
SmartCense Tec is the controller of your account, billing, support and website data. For business records your company loads into IVMS.next, your company is the controller and we are its processor under Article 28. Where we receive your data from someone else, such as an administrator who invites you, we give you this notice within one month and no later than our first message to you (Article 14).
16.2 Lawful bases
We rely on Article 6(1)(b) (contract) to run your account and provide support; Article 6(1)(c) (legal obligation) for invoicing and tax records; Article 6(1)(f) (legitimate interests) for security, fraud and abuse prevention, service improvement and, if enabled, usage analytics; and Article 6(1)(a) (consent) for push notifications. Our legitimate interests are keeping the service secure and reliable and understanding how it is used. Withdrawing consent does not affect earlier processing.
16.3 Transfers
Your data is processed in the EU. Onward transfers to the United States and other countries occur when the AI assistant is used (OpenAI, Anthropic and Google) and, where applicable, through Upstash and Paystack, under the EU Standard Contractual Clauses, the UK International Data Transfer Addendum or the provider's data processing addendum. Kenya has no adequacy decision; our own access from Kenya to EU-hosted data is protected by the measures in Section 11.
16.4 Your GDPR rights
You have the rights of access, rectification, erasure, restriction, objection and data portability, and the right not to be subject to solely automated decisions, under Articles 15 to 22. We respond within one month, extendable by two further months for complex requests, and will tell you if so.
16.5 Supervisory authority
You may complain to the data protection supervisory authority of your habitual residence or place of work in the EEA, or to the Information Commissioner's Office in the UK.
17. Storefronts, public pages and custom domains
If you shop on a storefront powered by IVMS.next, the store owner is responsible for your data; this section explains the little we receive.
17.1 The store owner is the controller
If you shop on a storefront at a /store/ address or on a store's own domain, the business that runs the store is the controller of your data and its privacy notice applies; we process the data below on its behalf.
17.2 What we receive
We receive product reviews you submit (display name, rating and comment; no email, IP address or account is stored). If the store takes online orders and you place one, we receive the items, your name, mobile number and email address, and any note you add, and record them as a pending order for the business, which contacts you about it; no account is created and no payment is taken. The order is priced from the store's catalogue, not from your browser, and the order request is protected as in Section 17.3. Wishlist and compare lists stay in your browser and are not sent to us. If the store has enabled them, we receive anonymous product-view and search-query events with no IP address, browser string or cookie. If you accept a quotation, we record your name, verified email, the time, your IP address and browser string for the business. Our servers also keep the request logs described in Section 3.4.
17.3 Anti-abuse processing
To keep storefronts free of spam we use hidden honeypot fields, Firebase App Check with reCAPTCHA v3 where configured, and rate limiting (for online orders, six per network address in ten minutes), relying on legitimate interests. A key created in your browser for each order stops a repeated tap or a retry from placing it twice.
17.4 Custom domains
When a business uses its own domain, requests to it are rewritten to our storefront. Links to this notice from a storefront point to this page on our own site, https://ivms-production--ivms-eu.europe-west4.hosted.app/privacy, so the address may differ from the store's domain.
18. Changes to this document
We update this notice when the platform or the law changes; this section explains how you will hear about it.
18.1 How we tell you
For material changes we will email tenant administrators and show an in-app notice at least 30 days before the new version takes effect. Minor changes, such as clarifications or an updated provider link, are posted with a changelog entry. The effective date and version appear at the top of this page, and a version history generated from our changelog appears at the end of it; earlier versions are available from support.ivms@smartcensetec.com on request.
Version history
| Version | Date | Change |
|---|---|---|
| 2.5 | Sections 2.3, 4.1, 10.1 and 13.3 now cover scheduled reports a business sends to email addresses outside its company, such as its accountant. Someone with the right permission in the business may add an address; we then send that address one email asking it to confirm, and send it nothing else unless the person presses Confirm on the page the email opens. Each report sent to it carries a link to stop them, which we honour at once. A copy sent outside the company never includes profit or cost. For each address the business added we keep the address, whether it confirmed or asked to stop, when, and who added it, with the business's records; the business is the controller and we process it on its behalf. No change to what we collect for ourselves. | |
| 2.4 | New Section 11.4 and new Section 3.9 describe support sessions and platform administration. Our support staff look at the business records your company stores (sales, stock, customers and settings) only while a support session is open. A session starts only when one of your company's administrators allows it, lasts at most 24 hours, is read-only, shows a notice in the app to everyone in your company for as long as it is open, can be ended by your administrators at any moment, ends when your company is closed or the staff member loses the permission to start sessions, and is recorded in your company's audit trail. Everyone in your company who can manage it is emailed and notified in the app when a session starts and when it ends. A company can choose never to allow support sessions. Section 11.4 also names the platform administration we do without a session: your account, billing and security records, the list of your users (without phone numbers, security details or the address and device of a sign-in), platform-wide statistics across all companies that do not show your business records, and the few changes to your records we make at your request, which we record in your audit trail in the name Our platform team. We keep our own record of sessions and of platform administration, with the staff member, the times, the areas looked at, the IP address and the browser string, for two years and then delete it. Sections 1 (In short), 4.2, 4.5, 5.1, 10.1 and 11.1 follow. Support sessions are off until we switch the feature on; until then nothing in this version happens. | |
| 2.3 | Sections 2.3, 4.1, 5.1, 7.4, 12.2 and 17 now cover online orders. A business can let shoppers order from its storefront without an account. The shopper gives a name, a mobile number and an email address, and an optional note, which go to the business, which is the controller; we process them on its behalf, and a shopper's cart stays in the browser until the order is placed. Nothing is paid through the storefront. Section 7.4 no longer says we operate no storefront checkout. The order form is protected by a hidden field, Firebase App Check where configured, and a limit on orders per address. No change to what we collect for ourselves, or to how long we keep it. | |
| 2.2.1 | Sections 3.4, 10.1 and 12 now describe the ivms_agent cookie, which carries your browser's own description of itself (its user agent) to our API. Your browser sends that description with every request, but our hosting provider replaces it before the request reaches our servers, so without the cookie your sign-in records, security emails and audit entries could not say which browser was used. No change to what we collect, why, or how long we keep it. | |
| 2.2 | Sections 3.2, 3.4, 5.1, 10.1, 11.1, 13.2 and 14.3 describe what our server now does with sign-ins. It works out the country each sign-in appears to come from, on our own servers with a country database, so the address is sent to nobody for it; it keeps up to 10 countries your account has been used from, each dropped 180 days after it was last seen; it counts failed sign-in attempts it sees (wrong two-factor and recovery codes, not wrong passwords) per account per hour, with the latest address, and keeps the counts for 30 days; and your company's administrators can choose to be told about sign-ins from a new device or a new country and about failed attempts. Section 3.2 no longer says we keep no counter of our own. The country, the countries and the counts are in Account > Your data. Sections 2.2 and 6.2 call the in-app help the Help Hub, its new name. Section 3.4 also says what a device records when the platform asks it to send waiting work, and that each answer is kept 90 days. Sections 3.6, 5.1 and 10.1 describe what the Help Hub keeps: a search that found nothing (the words, the page, your company and when, not who searched), kept a year; and your answers to "Was this guide helpful?", kept with your account a year after your last answer. | |
| 2.1.2 | The retention table now says storefront analytics retention is set in Settings > Analytics & Reports > Analytics Settings, where it moved from Product settings. No change to what we collect, why, or how long we keep it. | |
| 2.1.1 | Section 12.2 now lists what the guided setup keeps in your browser tab: what you have typed into a setup step and not saved yet, the supplier names carried from one step to another, the reference of an import still running, how far your company's setup is (so the dashboard opens on the right page), the page the guide was opened from (for its Back button), and, just after you sign in, a note to take you back to the guide if setup is under way. It goes when the tab closes or you sign out. The quick start's layout flag (ivms.quickstart.*) is gone from the list: the quick start was replaced by the guided setup, and signing out clears any flag an older version left. No change to what we collect, why, or how long we keep it. | |
| 2.1 | Sections 8 and 9 now say that webhook deliveries are queued on Google Cloud in the EU (europe-west1), not by Upstash, which handles only rate limiting, CSRF tokens and cache. No new processor and no new transfer: less data goes to Upstash than before. | |
| 2.0 | Section 3.2 gives the current password rule (15 characters, or 8 with a second factor) and the breached-password check. Sections 3.4, 10.1 and 12 describe the record our server keeps of each sign-in, the list of devices an account is known on and the ivms_device cookie, and how long each is kept. Sections 10.3, 14.1 and 14.3 describe Account > Your data, where you can see and download what is held about you and ask for it to be deleted. Section 13.2 lists the account security emails. | |
| 1.0.2 | Section 13.2 now lists the product limit notice among the transactional email we send, says who receives it, how often, and why it carries no unsubscribe link. No change to what we collect, why, or how long we keep it. | |
| 1.0.1 | Section 10.2 now describes the 30-day window after which product details become read-only, for every product, while a company account holds more products than its plan allows, and confirms that reading, exporting, archiving and deleting stay available. No change to what we collect, why, or how long we keep it. | |
| 1.0 | First published. |