Skip to content
IVMS.next
Sign in

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 15 October 2026 · Last updated 15 October 2026

Operator
SmartCense Tec
Privacy requests
support.ivms@smartcensetec.com
Support
support.ivms@smartcensetec.com

On this page

  1. In short
  2. 1. Who we are and how to reach us
    1. 1.1 The operator
    2. 1.2 Our two roles: controller and processor
    3. 1.3 Privacy contact
    4. 1.4 Effective date and versions
  3. 2. Who this notice covers
    1. 2.1 Tenant administrators and staff (account holders)
    2. 2.2 Website visitors and people who contact support
    3. 2.3 People whose data a tenant stores (customers, suppliers, employees, quote recipients, storefront shoppers, reviewers, report recipients)
    4. 2.4 Developers and integrations (API tokens, webhooks, Zapier/Make)
    5. 2.5 Mobile app users
    6. 2.6 EEA and UK users
  4. 3. Data we collect as controller
    1. 3.1 Account and profile
    2. 3.2 Sign-in security and second factor
    3. 3.3 Billing and payments
    4. 3.4 Security, device and audit records
    5. 3.5 Support and correspondence
    6. 3.6 Usage and error reports
    7. 3.7 Mandatory data and consequences of not providing it
    8. 3.8 Where we get data when not from you
    9. 3.9 Support session and platform administration records
  5. 4. Data we process on behalf of tenants
    1. 4.1 What tenants store
    2. 4.2 We act on the tenant's instructions
    3. 4.3 If you are a customer, supplier or employee of a business using the platform
    4. 4.4 Data Processing Addendum and sub-processors
    5. 4.5 Where we are still controller
  6. 5. Why we use data and the legal basis
    1. 5.1 Purpose-to-basis table
    2. 5.2 Further processing
    3. 5.3 Direct marketing
    4. 5.4 Automated decision-making
  7. 6. AI assistant
    1. 6.1 What leaves the platform
    2. 6.2 Which providers and their published data terms
    3. 6.3 Providers your company can choose under bring-your-own-key
    4. 6.3 Bring your own key
    5. 6.4 Controls and switches
    6. 6.5 Storage and retention of AI data
    7. 6.6 Training
  8. 7. Payments
    1. 7.1 Safaricom M-Pesa
    2. 7.2 Paystack
    3. 7.3 Invoices
    4. 7.4 Storefront and tenant payments
  9. 8. Who we share data with
    1. 8.1 Sub-processors
    2. 8.2 Other recipients
    3. 8.3 Recipients you choose
    4. 8.4 Adding a sub-processor
    5. 8.5 What we do not do
  10. 9. Where data is stored and international transfers
    1. 9.1 Primary storage in the EU
    2. 9.2 Transfers from Kenya
    3. 9.3 Transfers out of the EEA/UK
    4. 9.4 Backups
    5. 9.5 Sensitive personal data
    6. 9.6 Kenyan localisation reservation
  11. 10. How long we keep data
    1. 10.1 Retention schedule
    2. 10.2 What happens when a subscription ends
    3. 10.3 Account deletion
    4. 10.4 Anonymisation
  12. 11. How we protect data
    1. 11.1 Technical and organisational measures
    2. 11.2 Data breaches
    3. 11.3 Your part
    4. 11.4 Support access to your company's records
  13. 12. Cookies, local storage and offline data
    1. 12.1 Why there is no cookie banner
    2. 12.2 Storage inventory
    3. 12.3 Clearing data and shared devices
  14. 13. Notifications and communications
    1. 13.1 Push notifications
    2. 13.2 Email we send
    3. 13.3 Emails we send on a tenant's behalf
  15. 14. Your rights and how to exercise them
    1. 14.1 Your rights under the Kenya Data Protection Act
    2. 14.2 How to make a request and how fast we answer
    3. 14.3 Self-service tools
    4. 14.4 If your data is held by a business using the platform
    5. 14.5 Complaints to us
    6. 14.6 Complaints to the Office of the Data Protection Commissioner
  16. 15. Children
  17. 16. EEA and UK users
    1. 16.1 Controller and representative
    2. 16.2 Lawful bases
    3. 16.3 Transfers
    4. 16.4 Your GDPR rights
    5. 16.5 Supervisory authority
  18. 17. Storefronts, public pages and custom domains
    1. 17.1 The store owner is the controller
    2. 17.2 What we receive
    3. 17.3 Anti-abuse processing
    4. 17.4 Custom domains
  19. 18. Changes to this document
    1. 18.1 How we tell you
  20. Version history

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 categoryExamplesWhy we need itRequired?
Account identityName, email, role, store assignmentsSign-in and permissionsYes
ProfileAvatar, timezone, language, preferencesPersonalisationNo
Sign-in securityPassword, 2FA secret, backup codesAccount protectionPassword yes; 2FA optional
BillingPlan, M-Pesa phone, Paystack email, saved-card tokenCharging and invoicingOnly to pay
Security and auditIP address, device string, sign-in records, device identifier, audit entries, server logsSecurity, fraud preventionAutomatic
Device registrationDevice ID, platform, app version, push tokenMobile push, device limitsMobile 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 dataWho it is aboutWho decides retention
Customer and loyalty records: contact details, vehicles, addresses, tags, preferences, credit profilesThe business's customersThe business
Supplier contacts and purchase ordersSupplier staffThe business
Orders and point-of-sale receiptsCustomers named on an orderThe business
Bank statement lines and M-Pesa payment confirmations (payer name, phone number, amount, reference)The business's customersThe business
Quotations and acceptance records (signer name, verified email, time, IP address, browser string; hidden from the public quote page)Quote recipientsThe business
Product reviews (display name, rating, comment)Storefront shoppersThe business
Online orders placed on a storefront (name, mobile number, email address, optional note, the items ordered)Storefront shoppersThe 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 accountantThe business
Huddle messages, attachments, reactions and read receiptsThe business's staffThe business (Settings > General > Huddle)
AI assistant attachmentsThe business's staffUs (no purge today; removal on request)
Account-export archivesEveryone in the company accountFixed 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.

PurposeData usedKenya DPA s.30 basisGDPR Art. 6 basisCan you object/withdraw?
Creating and running your accountAccount, profile, sign-in securityPerformance of a contractArt. 6(1)(b) contractNot while you hold an account
Invoicing and tax recordsBilling, invoicesLegal obligationArt. 6(1)(c) legal obligationNo
Security, rate limiting, App Check, audit trails, security alerts to your company's administratorsIP 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 logsLegitimate interestsArt. 6(1)(f) legitimate interestsYou 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 soName, mobile number, email address, note, items orderedPerformance of a contract (the shopper's order)Art. 6(1)(b) contractContact the business, which is the controller (Section 17.1)
Push notificationsPush subscription or device tokenConsentArt. 6(1)(a) consentYes, at any time
AI assistantPrompts, page context, business recordsContract and legitimate interestsArt. 6(1)(b) and (f)Yes; an administrator can disable it
Usage analytics (only if enabled)Page, referrer, viewport, device typeLegitimate interestsArt. 6(1)(f) legitimate interestsYes
Improving the Help HubThe words of a Help Hub search that found nothing (not who searched); your answers about guidesLegitimate interestsArt. 6(1)(f) legitimate interestsYes; answering is optional, and you may ask us to delete your answers
Support and correspondenceYour messagesPerformance of a contractArt. 6(1)(b) contractYou 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 whereThe 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 stringLegitimate interestsArt. 6(1)(f) legitimate interestsYou 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.

ProviderUsed forData sentProvider's published retention/training defaultWhere we checked
Google (Gemini API)Chat, tool calls, Help Hub embeddingsEverything in Section 6.1Paid tier: no product improvement; abuse logs kept briefly; may be cached in any Google facilityGemini API terms (opens in a new tab), as published on 3 September 2026
OpenAI (API)Chat, tool calls, Help Hub embeddingsEverything in Section 6.1Not used to train OpenAI models by default; abuse-monitoring logs kept up to 30 days; flagged content may be reviewed by peopleOpenAI API data usage guide (opens in a new tab), as published on 3 September 2026
Anthropic (API)Chat, tool callsEverything in Section 6.1Not used to train models under its commercial terms; deleted within 30 days; content flagged by safety systems may be kept up to 2 yearsAnthropic 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-processorPurposeDataLocationSafeguard (DPA / SCC / DPF)
Google Cloud and FirebaseHosting, database, file storage, authentication, App Check with reCAPTCHA v3, push messaging, the queue for webhook deliveriesAll platform data; sign-in credentials; push tokensFirestore eur3, Functions and the webhook queue (Cloud Tasks) europe-west1, App Hosting europe-west4; Authentication, App Check and Cloud Messaging are globalGoogle Cloud data-processing terms
Upstash (Redis)Rate limiting, CSRF tokens, cacheIP-keyed counters, session-bound tokensAs configured by us; confirmed on requestUpstash data processing agreement
Google (Gemini API)AI assistant, when usedSee Section 6Any country where Google has facilitiesGemini API terms and Google's data-processing addendum
OpenAIAI assistant, when usedSee Section 6Primarily United StatesOpenAI data processing addendum
AnthropicAI assistant, when usedSee Section 6Primarily United StatesAnthropic commercial terms and data processing addendum
Safaricom (M-Pesa)Subscription paymentsPhone number, amount, reference, receiptKenyaSafaricom's own terms (independent controller)
PaystackSubscription card paymentsEmail, amount, masked card data, authorisation tokenKenya; hosting per Paystack's noticePaystack's own terms (independent controller)
Google (Gmail SMTP)Sending all platform emailRecipient address, message content, attachmentsGlobal Google infrastructureGoogle's terms of service and privacy policy
Browser push services (Google, Mozilla, Apple) and Firebase Cloud MessagingDelivering notificationsTitle, short message, category, linkGlobalEach vendor's own terms
Open Food Facts family and UPC Item DBBarcode reference lookupThe scanned barcode only; no personal dataGlobalNot 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.

DataLocationTransfer routeSafeguard
Database records, files, invoices, chat, AI conversationsGoogle Cloud, EUKenya to EUGoogle Cloud data-processing terms; Section 9.2
AI prompts and fetched recordsGoogle, OpenAI or AnthropicEU to the provider, including the United StatesProvider addenda; EU SCCs where applicable
Rate-limit counters, CSRF tokensUpstash, region as configuredEU to UpstashUpstash 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.

RecordRetentionSet byReference
Account and profile recordsLife of the company account, then archived under our archival policyUsSection 10.3
Audit logs90 days active, then archived; deleted after 730 days under our archival policy, or later where tax or other law requiresUsSection 3.4
Server request and application logs (Google Cloud Logging)30 days (Google's default retention)UsSection 3.4
Orders, point-of-sale transactions and payment recordsLife of the company account; after closure, for as long as tax law requiresThe business and the lawTerms of Service, Section 18.5
Storefront analytics (product views, searches)Per tenant setting; 720 days by default; purged dailyThe businessSettings > 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 honouredThe businessSection 13.3
Huddle messages and attachmentsUntil the business sets a retention period; then purged dailyThe businessSettings > General > Huddle
Account-export archives7 days, then deletedUsSettings > Export/Import
AI conversations20 most recent per user; older deleted automaticallyUsSection 6.5
AI attachmentsIndefinitely today; removal on requestUsSection 6.5
AI usage records (email, tokens, cost)Life of the company account, then archived under our archival policyUsSection 6.5
InvoicesAt least the statutory tax period; no deletion todayLawSection 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 automaticallyUsSection 3.4
Devices your account is known onUp to 25; a device not seen for 180 days is dropped the next time you sign inUsSection 3.4
Countries your account has been used fromUp to 10; a country not seen for 180 days is dropped the next time you sign inUsSection 3.4
Counts of failed sign-in attempts (per account per hour, with the latest IP address)30 days, then deleted automaticallyUsSection 3.2
Records of a change to your sign-in email address180 days after the change was requested or, once it completes, 180 days after that; then deleted automaticallyUsSection 14.3
Deletion requests made in Account > Your dataWhile open, and for 730 days after it is answered; then deleted automaticallyUsSection 10.3
Session cookie; CSRF token7 days; 1 hourUsSection 12
Device identifier cookie (ivms_device)400 days, renewed while you use the app signed inUsSection 12
Browser description cookie (ivms_agent)400 days, renewed while you use the app signed inUsSection 12
Password reset link; email verification link1 hour; 3 daysUsFirebase defaults
Two-factor enrolment in progress10 minutesUsSection 3.2
Firebase Authentication records after deletionRemoved by Google within 180 daysGoogleFirebase privacy notice
Mobile device registrationsUntil you sign out or the device is removedYouSection 3.4
Webhook dead letters90 daysUsTerms of Service, Section 11.2
Answers from devices asked to send waiting work90 days, then deleted automaticallyUsSection 3.4
Help Hub searches that found nothing (the words, page, company and time; not who searched)1 year after the search, then deleted automaticallyUsSection 3.6
Answers to "Was this guide helpful?" (with your account)1 year after you last answered, then deleted automaticallyUsSection 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 policyUsSection 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 deletedUsSection 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.

ItemTypePurposeLifetimeStrictly necessary?
session-idCookieBinds CSRF tokens to your browser7 daysYes
ivms_deviceCookie (API requests only)Recognises this browser in your sign-in records and for new-device sign-in notices400 days, renewed while signed inYes
ivms_agentCookie (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 sends400 days, renewed while signed inYes
ivms.device-idlocalStorageThe same browser identifier, so the cookie can be renewedPersistentYes
Firebase Auth persistenceIndexedDBKeeps you signed inUntil sign-outYes
Firestore offline cacheIndexedDBRecently read records for offline useUntil sign-out or evictionYes
ivms_{companyId} (Dexie)IndexedDBEncrypted offline copy of products, transactions, orders, customers, credit invoices, users, reference data, pending operationsUntil sign-out or clearedYes
Serwist precache and runtime cachesCacheApp shell and pages for offline useUntil the app updates or is uninstalledYes
Session bookkeeping (sessionStartTime, currentSessionId, session_last_activity, session_timeout_config, pendingLoginSessionId, pendingLoginTimestamp)localStorageInactivity timeout; sign-in audit de-duplicationUntil sign-out or timeoutYes
ivms_user_snapshotlocalStorageCached profile and company for offline reload30 daysYes
product-storelocalStorageCached product list for the Products page (not encrypted)PersistentYes
order-storelocalStorageCached order list (not encrypted)PersistentYes
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)localStorageLayout, parked POS sales, locale, accessibility and theme choicesPersistentYes
Drafts and history (ivms-chat-draft:*, ivms-search-history, ivms-saved-searches)localStorageUnsent chat drafts (ignored after 7 days), recent and saved searchesPersistentYes
error_report_*localStorageUp to 10 local error reports for the offline sync engine; not sent to usPersistentYes
Per-tab flags (2fa_verified, mfa_enrollment_checked, email_verification_ok, ivms-initializing, ivms-app-initialized, pwa-prompt-dismissed, ivms.tour.*)sessionStorageSign-in gates, start-up state, install prompt, snoozed toursUntil the tab closesYes
Guided setup (ivms.setup.draft., ivms.setup.summary., ivms.setup.return-to, ivms.setup.resume-after-sign-in)sessionStorageWhat 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 wayUntil the tab closes or sign-outYes
Storefront wishlist and compare listslocalStorageSaved product IDs on a storefront; not sent to usPersistentYes
Storefront cart (sf:cart:*)localStorageProduct IDs and quantities a shopper has added on a storefront; not sent to us until the shopper places the orderPersistent, until the order is placed or it is clearedYes

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.

RightWhat it meansKenya response timeHow to use it
To be informed (s.26(a))Knowing how your data is usedNot applicableThis notice
Access (s.26(b))A copy of your data7 days (reg. 9)Account > Your data, or email us
Object (s.26(c))Stopping legitimate-interest processing; absolute for direct marketing14 days (reg. 8)Email us
Correction (s.26(d), s.40)Fixing inaccurate, outdated, incomplete or misleading data14 days (reg. 10)Profile page or email us
Deletion (s.26(e), s.40)Erasing false, misleading or unneeded data14 days (reg. 12)Account > Your data, email us, or your administrator
Restriction (reg. 7; s.40(3))Pausing processing during a dispute14 days (reg. 7)Email us
Portability (s.38)Your data in a machine-readable format30 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 daysEmail us; Section 5.4
Withdraw consent (s.32)Ending consent-based processing, such as pushImmediateNotification 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

VersionDateChange
2.515 October 2026Sections 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.410 October 2026New 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.330 September 2026Sections 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.129 September 2026Sections 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.229 September 2026Sections 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.229 September 2026The 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.129 September 2026Section 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.129 September 2026Sections 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.029 September 2026Section 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.24 September 2026Section 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.14 September 2026Section 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.03 September 2026First published.
IVMS.next© 2026 All rights reserved
Privacy PolicyTerms of ServiceSupport