Privacy Policy

1. What this policy covers

This policy covers every Rimon Labs service. We keep one policy rather than one per product so that you only have to read it once, and so that we cannot quietly hold a different standard on a different domain.

When we launch a new product it is covered by this policy from day one, and we update the table above. A product may publish additional, product-specific privacy information — for example a school-facing data sheet. Where it does, that information adds to this policy; it does not reduce the protections described here.

This policy does not cover services operated by anyone else, even where we link to them or you connect them to a Rimon Labs product. See section 17. Our Terms of Service and Refund Policy sit alongside this document.

2. Who we are and our role

Rimon Labs LLC is a Wyoming limited liability company (Entity ID 2026-001975416), registered at 5830 E 2nd St, Ste 7000 #35694, Casper, WY 82609, United States. We are a United States company, founded in 2026. We are the organisation responsible for the information described in this policy — in European and UK terms, the data controller.

When we act for someone else instead

Data protection law splits responsibility between two roles. A controller decides why and how personal data is used. A processoronly handles data on a controller’s instructions. Which role we are in depends on how you reached us — and it changes who you should contact first.

If you signed up yourself, with your own email address and your own payment method, Rimon Labs is the controller of your personal data and you can exercise every right in this policy directly with us.

If a school, district, university, employer or other organisation created your account, pays for it, or administers it, then that organisation is the controller and Rimon Labs acts as its processor. We process the data on that organisation’s documented instructions — to run the service they asked us to run — and not for our own purposes. In that arrangement:

• The organisation instructs us. We do not act on our own initiative with their data.
• We engage subprocessors only under the conditions in our data processing agreement, and we remain responsible for them.
• We help the organisation respond to requests from its people rather than responding on our own authority. If you write to us, we will acknowledge it, forward it, and tell you that we have.
• When the relationship ends, we delete or return the data on the organisation’s instruction.

One exception, stated plainly.Even in an institutional deployment we remain the controller for a narrow set of data we need for our own purposes: billing and account-administration records for the institution, security and abuse-prevention logs, and correspondence with the institution’s own staff.

For schools specifically, this includes acting as a “school official” under FERPA — see section 14.

Data processing agreement

A data processing agreement (DPA) is available to every institutional and business customer. It incorporates the European Commission’s Standard Contractual Clauses, the UK International Data Transfer Addendum and the Swiss adaptations described in section 15, and it contains our written commitment that customer content is never used to train AI models — a commitment we pass down to our own subprocessors. To request it, email privacy@rimonlabs.com with your organisation name and the product you use. We countersign electronically, and there is no fee.

Data protection officer and representatives

We have not appointed a Data Protection Officer. Article 37 of the GDPR requires one where an organisation is a public authority, where its core activities require large-scale regular and systematic monitoring of individuals, or where its core activities involve large-scale processing of special category data. We are none of those: we do not monitor or profile users, we do not seek special category data, and our handling of it is incidental rather than a core activity. That does not leave privacy unowned — privacy questions, rights requests and complaints go to the address in the final section and are handled by the person at Rimon Labs accountable for data protection. If we appoint a Data Protection Officer, voluntarily or because our processing changes, we will publish their details here.

We have not designated a representative in the European Union or the United Kingdom under Article 27. We are assessing whether one is required for our processing and, where it is, we will appoint representatives and publish their names and contact details in this section. Until then, please contact us directly at privacy@rimonlabs.com. We will not use the absence of a representative as a reason to delay or refuse a request, and every right in this policy remains fully available to you.

3. Information we collect

We collect three kinds of information: what you give us, what is recorded automatically when you use our services, and the small amount we receive from other companies that help us operate. This section lists all of it. Not every item applies to every product — a product only collects what it actually needs to work.

Information you give us

• Account information. Where a product offers accounts: your email address and a password. Passwords are stored only as salted cryptographic hashes — we never store, and cannot recover, your actual password. You may also add optional profile details such as a display name, an organisation or school name, a role, and a profile image.
• Sign in with Google. If you choose it, we receive a limited set of details from Google: your name, email address, profile picture, language preference and a stable account identifier. We do notreceive your Google password, and we gain no access to your Gmail, Drive, Calendar or Contacts. You can disconnect Rimon Labs from your Google account at any time in Google’s security settings; if you do, you may need another way to sign in.
• Billing information. Paid plans are handled by a third-party payment processor. Your full card number, security code and bank details go directly to that processor and never touch our servers — we cannot see them. What we receive and store is the billing name and email, billing country and postal code for tax, the card brand and last four digits, the expiry month and year, the processor’s customer and subscription identifiers, and your invoice and payment history.
• Content you upload. Our products let you upload files so they can be turned into something useful. In MCQForge this includes PDF, DOCX, PPTX, XLSX, image, text and CSV files in over 100 languages. Whatever the file contains, we receive.
• Content our products generate for you. Questions, answer keys, exams, exports and similar output created from your uploads or prompts. We store it so you can return to it, edit it, share it and export it.
• Assessment and exam data. Exam configuration (timing, question order, availability), the responses submitted by people who take an exam, the scores produced by grading, and the resulting analytics. Where an exam is administered by a school or organisation, that institution — not Rimon Labs — decides what is collected and who may see it.
• Support and other communications. Emails, in-product support messages, bug reports and any attachments you send us, plus our replies. Our contact form on rimonlabs.com collects your name, email address, company (optional) and message and routes them to our inbox so a person can reply.
• Anything else you choose to send us. Survey answers, feature requests and beta feedback.

Information we collect automatically

When you load a page or use a product, some data is created just by the request happening. We keep this deliberately narrow and use it for reliability, security and basic product measurement — never to build an advertising profile.

• Network and request data. Your IP address, the date and time of the request, the URL requested, the referring URL and your user agent string, which reveals your browser, browser version, operating system and device type. This is standard web-server and CDN logging.
• Approximate location. Derived from your IP address at country and sometimes region level. We do not collect GPS or precise device location, and our pages deny browser geolocation access outright.
• Product usage events. Which pages and screens you opened, which features you used, and when. In products with accounts, this is linked to your account so we can support you and understand which features earn their keep.
• Error and diagnostic logs. When something breaks we record the error, a stack trace, the request identifier and the state needed to reproduce it. These logs can incidentally contain fragments of the content you were working with at the moment of failure.
• Cookieless analytics. Privacy-friendly measurement that sets no cookies, does not follow you across other websites, and does not fingerprint your device. See section 8.
• Security and anti-abuse signals. Rate-limiting counters, failed sign-in attempts and signals from our bot protection. Our contact form uses Cloudflare Turnstile, which is designed to tell humans from bots without the tracking a traditional CAPTCHA relies on; when you submit the form we send Turnstile’s one-time token and your IP address to Cloudflare so the submission can be verified. The form also uses two invisible checks that collect nothing about you: a hidden field real people never see, and a measurement of how long the form was open before you submitted it.
• Device preferences you set. For example your dark or light theme choice, stored in your own browser.

Information we receive from others

• From your sign-in provider, if you use Sign in with Google — the profile fields described above.
• From our payment processor — payment outcomes, subscription status, refunds, chargebacks and fraud signals, enough to know whether your plan is active and whether a payment succeeded.
• From schools and organisations — where an institution gives you access to a Rimon Labs product it may supply your name, school email address, class or group assignment, role (teacher, student, administrator) and a student identifier. The organisation decides what to share with us and why.
• From service providers who help us operate — delivery and reliability information, such as whether an email we sent you was delivered or bounced.

What we do not collect

To be explicit: we do not collect your full payment card number, we do not buy personal information from data brokers, we run no advertising or social media tracking pixels, we do not track you across other websites, and we do not collect precise geolocation, biometrics, or anything from your device beyond the files you deliberately upload.

4. How we use information

We use information for the purposes below and nothing else. If we ever want to use your information for a genuinely new purpose, we will update this policy and — where the law requires it — ask you first.

• To provide the service. Create and maintain your account, authenticate you, process your uploads, generate the output you asked for, run and grade exams, produce analytics, and deliver exports.
• To process payments. Start, renew, change and cancel subscriptions; issue invoices and receipts; calculate tax; handle refunds and disputes.
• To communicate with you. Reply to support requests and contact-form messages, and send service messages you cannot opt out of while you hold an account — billing notices, security alerts, and material changes to our terms or this policy.
• To send optional product updates. Only with your consent where consent is required, and with a one-click unsubscribe in every message. Unsubscribing never affects your service messages or your account.
• To keep the service secure. Detect and stop bots, spam, credential stuffing, fraud, abuse and denial-of-service traffic; enforce rate limits; investigate suspected violations of our terms.
• To keep the service working. Diagnose faults, fix bugs, monitor availability and performance, and restore data from backups after a failure.
• To improve our products. Understand which features are used and where people get stuck, using aggregated, cookieless measurement. We do not use your uploaded content or generated content to train AI models — see section 6, which is unconditional.
• To meet legal obligations. Keep tax and accounting records, respond to lawful requests, and establish or defend legal claims.
• To support schools and organisations.Deliver the service under an institution’s instructions, for the educational purposes it has authorised, and nothing else.

We do not sell your personal information, we do not share it for cross-context behavioural advertising, and we do not serve targeted advertising in our products. We never show behavioural advertising to children.

5. Legal bases for processing

If you are in the European Economic Area, the United Kingdom or Switzerland, the law requires us to have a specific legal basis for each thing we do with your information. We do not use one vague basis for everything. Here is the whole map.

Two notes on the table. Billing sits under contract, but keeping the resulting records afterwards is a separate legal obligation under tax and accounting law. And service messages — a failed payment, a password reset, a security alert — are operational rather than promotional: you should not have to consent to being told your password was reset.

What is not on this list: training AI models

There is no “legitimate interest in model improvement” row in the table above, and no opt-out you need to find and click, because there is nothing to opt out of. We never train AI models on your content. See section 6.

If you object to a legitimate-interests purpose

Where we rely on legitimate interests we have weighed our interest against your rights and concluded ours does not override them. You can object at any time by emailing privacy@rimonlabs.com. We will stop unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data to establish, exercise or defend legal claims. If the processing is for direct marketing, there is no balancing test — we stop, full stop. We carry out and document a legitimate interests assessment for each purpose above; institutional customers can request a summary.

6. AI, your content, and our no-training commitment

Our products use artificial intelligence to turn the material you provide into something useful — for example, extracting multiple-choice questions and answer keys from a document you upload. Because that means your content passes through AI systems, you deserve a precise account of what happens to it. This section is that account, and we intend every sentence of it to be enforceable against us.

This is not a setting you have to find and switch off, and it is not conditional on your plan, your price or your location. It applies to every Rimon Labs product, every plan including free ones, and every customer, all the time — and we do not intend to offer a version of our services where it is untrue. We are stating it plainly because the industry default is the opposite, and we think that default is wrong for a product people feed their work into.

How AI processing actually works

When you ask a product to do something that needs AI, this is the sequence:

• The relevant content — the text and images extracted from your file, plus the instructions the product constructs — is transmitted over an encrypted connection to an AI processing provider we have contracted with.
• The provider runs the model and returns the output.
• The output is stored in your account so you can edit, share and export it.
• The content sent for processing is handled transiently: it is used to produce your output and is not retained by the provider afterwards beyond what is strictly necessary to complete the request.

We use third-party AI providers rather than running our own models because they are better at this than we would be. That choice does not dilute the commitment above — it is exactly why the commitment has to be contractual.

We require this of our AI providers in writing

We contract with AI processing providers on terms that require them to:

• not use our customers’ content to train or improve any model, including their own;
• not retain that content beyond what is needed to process the request and return a result, other than any short-lived retention strictly required for the provider’s own abuse monitoring, subject to a defined and limited period;
• not disclose it to anyone else except as needed to deliver the service to us, or where they are legally compelled;
• process it only on our documented instructions, as our processor or subprocessor; and
• apply security measures appropriate to the sensitivity of the content.

If a provider will not commit to these terms, we do not use that provider for customer content. If a provider we already use changes its terms in a way that conflicts with this section, we will migrate away from it — and we will tell institutional customers before we make the change, not after.

A commitment you cannot check is worth little, so: the providers who process customer content are disclosed in section 7, and if you believe this commitment has been broken, tell us at privacy@rimonlabs.com and we will investigate and reply. Weakening this section would be a material change under section 19, published at least 30 days before it took effect.

Your content and your output belong to you

You keep ownership of everything you upload. You also own the output our products generate for you — the questions, answer keys, exams and exports. We claim no ownership over them. The only rights we take are the narrow, temporary permissions we need to run the service for you: to store your content, process it, display it back to you, and share it with the people you choose. Those permissions end when you delete the content or close your account.

Please note that AI-generated text is not automatically protected by copyright in every country, and the extent of any protection may depend on how much you edit or arrange it. That is a question of law rather than of our policy, and nothing here grants us any interest in your output.

How grading works

Automated grading in our products is deterministic, not generative. A submitted answer is compared against the answer key for that question and scored by fixed rules. There is no AI model deciding whether you deserve the mark and no hidden judgment about the person answering; the same submission scored twice produces the same result. Where a product supports it, the person who owns the exam can review every question and response, correct an answer key, adjust or override an individual score, regrade after a change, and add manual scores. If you believe a score is wrong, raise it with the teacher or organisation that set the exam — they, not Rimon Labs, hold authority over that assessment. See also section 16.

AI output is not always right

• AI can misread a document, extract a question inaccurately, produce a wrong or ambiguous answer key, invent plausible-sounding content, or mishandle formatting, tables, handwriting, low-quality scans or less widely supported languages.
• Generated questions and answer keys should be reviewed by a qualified person before being used to assess anyone. Our products are built to make that review fast — everything is editable — precisely because we expect you to do it.
• Do not treat our output as the sole authority for a grade, a certification, an academic decision, or any other consequential outcome affecting a person.

Confidentiality of your content and prompts

Your uploads, prompts and generated content are confidential to you and to the people you share them with. We do not publish them, display them to other customers, use them in marketing, or feature them as examples without your explicit written permission.

Human access is the narrow exception. A small number of authorised Rimon Labs personnel can access customer content, and only when: you ask us to, for example to reproduce a bug you reported; we are investigating a security incident, abuse, or a credible violation of our terms; we are legally required to, in which case we will notify the affected customer first where we are permitted to; or a serious technical failure cannot be diagnosed any other way. When it happens, access is limited to the minimum data needed, restricted to staff whose role requires it, and recorded in an access log. We do not browse customer content out of curiosity, and doing so is a terminable offence for our personnel.

Content you share, and what that means

Some products let you share what you create — MCQForge lets you share an exam by link or by a six-character code. That is deliberate: a class can start an exam in seconds, with nothing to install and no account to create. It also has a direct consequence you should understand.

• Anyone who has the link or the code can open that exam. There is no additional identity check unless you have enabled one. A link forwarded, screenshotted, posted in a group chat or read off a projected screen works for whoever receives it.
• The code space is small. A six-character code is short by design so it can be read aloud and typed quickly. Short codes are, by definition, easier to guess than a long random link. We apply rate limiting and abuse monitoring to make systematic guessing impractical, but we will not pretend a six-character code is a security control.
• Treat any exam you share by link or code as semi-public. Do not put confidential information in it — personal information about students, staff details, health or disciplinary information, internal or commercially sensitive material, or credentials.
• High-stakes exams need more than a link. Use the strongest controls the product offers — availability windows, required sign-in, single-attempt limits, restricting distribution to a known group — and supervise delivery.

You stay in control of an exam you own. From the product you can unpublish or close it so the link and code stop admitting anyone new, rotate the code or regenerate the link to invalidate the old one, set an availability window so access expires automatically, or delete the exam entirely. Revoking access takes effect straight away. It cannot retrieve anything already viewed or copied while the link was live — so the moment you suspect an exam has leaked, rotate or close it.

When someone completes an exam you shared, their responses and score are visible to you as the exam owner. If you are a teacher or an organisation, you are responsible for handling those responses under your own privacy obligations and for telling participants what you will do with them. We process that data on your behalf and under your instructions.

7. How we share information

We do not sell your personal information, and we do not share it for cross-context behavioural advertising. We have never done either. We do not run ads, and we do not disclose personal information to data brokers or advertising networks.

We do rely on a small number of service providers to run our services. Each receives only what it needs, is bound by a written agreement to protect it and use it only for us, and may not use it for its own purposes. Paying a company to provide a service to us is not a sale.

Rows marked Category describe a type of provider rather than a named company, because we have not finalised that provider for the feature in question. We would rather tell you the category honestly than name a company we do not yet work with. Each will be named in this table before the feature it supports becomes generally available, and before any provider in that category handles K-12 student data.

Our commitments about this list

• We keep this list current and update it when a provider is added, removed or replaced.
• Institutional customers — schools, districts and organisations — can ask to be notified in advance of subprocessor changes affecting their data. Email privacy@rimonlabs.com to be added to that list. Where a written agreement requires advance notice and a right to object, that agreement governs.
• We require every provider to process data only on our instructions, to protect it with appropriate security, to assist us in responding to your privacy requests, and to delete or return data when our relationship ends.
• Where a provider touches customer content for AI processing, it is contractually barred from training on it — see section 6.

Other times we may disclose information

• When you ask us to — for example when you share an exam by link or code, or connect a third-party account.
• To your organisation, where your account belongs to a school, employer or team account.
• When the law requires it. We disclose only what a valid legal request actually compels, we challenge overbroad demands where there are reasonable grounds, and where we are permitted to tell you about it, we will.
• To protect people. To investigate fraud, abuse or security incidents, or to prevent serious harm.
• To our professional advisers — lawyers, accountants and auditors, under a duty of confidence.
• In a business transfer — see section 18.

8. Cookies and similar technologies

We use the minimum browser storage needed to make our services work, and nothing for advertising or cross-site tracking. Here is the complete list.

What we store

• Session and authentication. In products with accounts, a cookie or token that keeps you signed in and remembers which account you are using. Without it you would be signed out on every page load.
• Security. Short-lived values that protect forms against cross-site request forgery, plus the token used by Cloudflare Turnstile to verify that a form submission came from a person rather than a bot. Our infrastructure provider may also set a cookie to keep your requests going to the same server and to filter attack traffic.
• Preferences.Your dark or light theme choice, stored in your browser’s local storage — on your device, not sent to us. Products may store similar interface preferences the same way.

Analytics without cookies

Where we measure product usage, we use cookieless analytics:

• no analytics cookies are set;
• no cross-site tracking — we cannot see what you do on any other website, and no other company can use our analytics to see what you do on ours;
• no device fingerprinting;
• no advertising pixels, no social media trackers, no data brokers, no ad networks;
• no persistent identifier for you personally — we count events and pages, not people across time.

Why there is no cookie banner

Under EU and UK law, consent is required for storage that is not strictly necessary for a service you asked for. Everything we store is either strictly necessary — sign-in, security, load balancing — or a preference you set yourself, and our analytics set no cookies and perform no tracking. So there is no non-essential storage to consent to, and that is why you will not see a cookie banner on rimonlabs.com or in our products. We would rather remove the tracking than add a banner apologising for it. If we ever introduce storage that does require consent, we will ask for it properly and clearly before setting it.

Controlling storage in your browser

Every major browser lets you view, block and delete cookies and local storage, usually under Settings then Privacy. You can also use private browsing, or clear site data for our domains specifically. One honest caveat: if you block or clear essential storage, sign-in will break — you will not be able to stay logged in, and secured forms may reject your submissions. Blocking the theme preference simply means we will not remember your dark or light choice.

Do Not Track and Global Privacy Control

There is still no common industry standard for Do Not Track, so we do not respond to DNT signals specifically — instead we operate as though every visitor had sent one, since we do not track you across sites regardless. We do honour the Global Privacy Control and other recognised universal opt-out preference signals as a valid opt-out of any sale or sharing of personal information; unlike DNT, those have a defined legal effect. If you send a GPC signal we treat it as a valid opt-out without asking you to prove anything or confirm it twice — though as stated throughout, we do not sell or share personal information in the first place, so there is nothing for it to switch off. See section 13.

9. How long we keep information

Storage limitation is a principle, not a filing habit. We keep personal information only as long as we have a reason to, and when the reason ends we delete it or irreversibly strip it of anything that identifies you.

The criteria we use

• How long the purpose lasts — an active account needs its data; a closed one does not.
• Whether a law requires us to keep it — tax, accounting and company-law records have statutory minimums we do not get to shorten.
• Whether we need it to establish, exercise or defend a legal claim, and the relevant limitation period.
• Sensitivity and risk — the more sensitive the data, the shorter we keep it.
• Whether the purpose can be met with anonymised or aggregated data instead — if it can, we anonymise and delete the identifiable version.
• What our institutional customers have instructed, where we act as a processor. Where a customer contract or a school’s instruction sets a shorter period, the shorter period wins.

Our retention schedule

Two things sit outside that table. Aggregated, anonymised statistics that can no longer identify anyone are kept indefinitely — they are no longer personal information, so deletion does not apply to them. And we keep a minimal suppression record, a hashed note that an email address asked to be removed, so that we do not accidentally add you back.

About deletion and backups — the honest version. When you delete something it goes from our live systems promptly. It can persist in encrypted backup snapshots until those snapshots expire on the cycle above. We do not surgically edit backups, because doing so undermines their integrity. What we do guarantee is that data deleted from live systems is never restored from a backup into an active service, and that it disappears permanently when the snapshot expires.

We keep data longer than the periods above only where we must — to comply with a legal obligation, to comply with a legal hold, or to establish, exercise or defend a legal claim. If that applies to your request, we will tell you which reason applies and how long it lasts.

10. How we protect information

We are a small team, which shapes how we think about security: fewer moving parts, strong defaults, and no dependence on anyone remembering to do the right thing. Below is what is actually in place — not an aspiration list.

In transit

• HTTPS everywhere. Every connection to our sites and products is encrypted with TLS, and plain HTTP requests are redirected to HTTPS.
• HSTS with preload. We send Strict-Transport-Security with a two-year duration, covering subdomains, with preload — so browsers refuse to connect to us over an unencrypted connection at all, including on the very first visit.

Hardened browser defences

We set these HTTP security headers on every response:

• Strict-Transport-Security — enforces HTTPS for two years, across subdomains, with preload.
• X-Content-Type-Options: nosniff— stops browsers guessing a file’s type, a common route to script injection.
• X-Frame-Options: SAMEORIGIN — prevents other sites embedding our pages to trick you into clicking something.
• Referrer-Policy: strict-origin-when-cross-origin — stops the full URL you came from leaking to other sites.
• Permissions-Policy — our pages cannot access your camera, microphone or location, and are excluded from interest-based advertising APIs, even if a script tried.
• Cross-Origin-Opener-Policy: same-origin — isolates our pages from other windows in your browser.

We also explicitly disable the legacy browser XSS auditor. It is deprecated, it could itself be abused, and current security guidance is to turn it off and rely on the controls above together with our framework’s built-in output escaping.

Infrastructure and abuse protection

• Cloudflare provides our hosting, content delivery, DDoS mitigation and web application firewall. Attack traffic is filtered before it reaches our application.
• Cloudflare Turnstile protects our contact form against automated abuse, alongside rate limiting, an invisible honeypot field, a submission-timing check, and strict origin validation that rejects submissions not made from our own site.

Data at rest and access control

• Encryption at rest. Stored data, including uploaded files and backups, is encrypted at rest by our infrastructure providers.
• Password hashing. Where we manage passwords we store them only as salted hashes produced by a modern, deliberately slow password-hashing algorithm. We never store plaintext passwords and cannot tell you what your password is.
• Least privilege.Access to production systems and customer data is limited to personnel whose role requires it, protected by multi-factor authentication, reviewed periodically, and revoked immediately when someone’s role changes or ends.
• Secrets management. API keys and credentials are stored as encrypted secrets in our deployment platform, never in source code.
• Logging. Administrative access to customer data is logged.

What we do not claim

We hold no security or privacy certifications — no SOC 2, no ISO 27001, no HIPAA attestation, and no EU–US Data Privacy Framework certification. We would rather tell you that than imply otherwise. If we obtain a certification we will say so here, with the date, and be able to prove it.

The honest caveat

No system is perfectly secure. We work hard to protect your information, but no company can guarantee that data transmitted over the internet or stored on any service is absolutely safe. You can help: use a strong, unique password, enable multi-factor authentication where a product offers it, sign out on shared computers, and do not upload highly sensitive information to services designed for teaching and assessment content. Please also do not send us passwords, payment card numbers, government identifiers or health records through a contact form or a support email — we do not need them, and we will ask you to remove them.

Reporting a vulnerability, and what happens after an incident

If you discover a security vulnerability in a Rimon Labs product, report it to privacy@rimonlabs.com. We will acknowledge your report, investigate, and will not pursue legal action against good-faith researchers who follow responsible disclosure and avoid accessing or destroying other people’s data. Please include enough detail to reproduce the issue, and please do not access or exfiltrate anyone else’s data while investigating.

No one can promise a breach will never happen. What we can promise is how we will behave if one does: we triage every credible report immediately and contain first, we notify affected people and regulators on the timelines set out in section 12 and section 13, we keep a record of every incident and its remedial action whether or not it was notifiable, and we do not quietly bury incidents. If we get something wrong, we will say what happened.

11. Your privacy rights

These rights are available to you wherever you live. Some are required by law in the EEA, the UK, Switzerland and a growing number of US states; we do not run a two-tier privacy operation, so we extend them to everyone. If you are not in a covered jurisdiction and you want your data deleted, ask us anyway. We will do it.

• Access. Get confirmation of whether we process data about you, a copy of it, and an explanation of what we do with it — including the categories of data, the sources, our purposes and the recipients.
• Correction. Have inaccurate data corrected and incomplete data completed. Most account details you can fix yourself in your product settings, immediately — that is faster than asking us.
• Deletion. Have your data deleted, subject to the narrow exceptions the law allows. If an exception applies — for example a billing record we must keep for tax — we will tell you which one.
• Portability. Receive your data in a structured, commonly used, machine-readable format, and have it sent directly to another provider where that is technically feasible.
• Restriction. Have us pause processing while a dispute over accuracy or legitimate interests is worked out.
• Objection. Object to processing based on legitimate interests. For direct marketing your objection is absolute — see section 5.
• Withdraw consent. Where we rely on consent, withdraw it at any time. Withdrawal does not affect the lawfulness of what we did before you withdrew it.
• Opt out of sale, sharing, targeted advertising and significant-decision profiling. We do none of these, so there is nothing to switch off — the right is listed because you have it.
• Non-discrimination. We will never deny you service, charge you a different price, give you a lower quality of service, or suggest we might, because you exercised a privacy right. We offer no financial incentives in exchange for personal information.
• Appeal. If we decline a request, you can ask us to think again. See below.
• Complain to a regulator. See section 20.

How to exercise them

Email privacy@rimonlabs.comwith the subject line “Privacy Request”. Tell us which right you want to use, the email address associated with your account, and which product it concerns. A specific request gets a faster, better answer than a general one.

Identity verification.Before we hand over or delete personal data we need to be confident you are who you say you are — releasing someone’s exam history or uploads to an impostor would be a breach in itself. Usually, replying from the email address on the account is enough. If we cannot establish identity that way and we have genuine doubts, we may ask for additional information, strictly limited to what is necessary, and we delete it afterwards. We will never ask you to send us a passport, a government ID or a payment card to verify a privacy request. If someone claiming to be Rimon Labs asks you for those, it is not us. We will also never ask you to create an account just to make a request.

Timing. We acknowledge requests within 10 business days. Under the GDPR and UK GDPR we respond within one month, extendable by up to two further months for complex or repeated requests — we will tell you within the first month, and tell you why. Under US state privacy laws we respond within 45 days, extendable once by a further 45 days where the law permits. In every other case we aim to reply within 30 days, and sooner where the law requires it.

Cost. Free. We only charge, or refuse, where a request is manifestly unfounded or excessive — in particular, repetitive. If we take that position we will explain it in writing and tell you how to challenge it.

Authorised agents. You may use an authorised agent. The agent must write from a working address and provide either a copy of written permission signed by you, or proof of a valid power of attorney. Unless a power of attorney is in place, we may contact you directly to confirm you gave permission and ask you to verify your own identity. Several US states also let you exercise rights through a browser signal, and we accept that too — see section 8. If we cannot verify a request, we will tell you rather than silently doing nothing.

Appeals. If we decline your request, our response will explain why and tell you how to appeal. To appeal, reply to our decision or email privacy@rimonlabs.comwith the subject line “Privacy Appeal”. A different person from the one who made the original decision will review it. We respond in writing within 45 days with our reasons, and if we still decline we will give you contact details for your state Attorney General or supervisory authority. Most US state laws require an appeal process; we offer it to everyone, everywhere, because one decision-maker being wrong is not a good enough answer.

Exporting your data

• From the product. Where a product supports exports you can download your content yourself at any time, without asking us for anything. MCQForge exports questions, answer keys and exams to DOCX, PDF and JSON; JSON is the machine-readable format if you want to move your content into another system.
• By request. Email privacy@rimonlabs.com and we will provide a copy of the personal information we hold about you in a structured, commonly used, machine-readable format, once we have verified your identity.
• Export before you delete. Deletion is permanent and we cannot rebuild your content afterwards.

Deleting content and closing your account

You can delete uploaded files, generated questions and exams from within the product at any time. Where a product provides a trash or recycle bin, deleted items are recoverable there for the period that product states and are then permanently removed.

To close your account, use the account deletion option in your account settings where a product offers one, or write to privacy@rimonlabs.com from your account email address. We will confirm your identity and your intent before we proceed, because it cannot be undone. When you delete your account:

• your account, profile, uploaded files, generated content, exams and product settings are deleted from our live systems;
• any active subscription is cancelled — refunds are governed by our Refund Policy, and deleting an account does not by itself trigger a refund;
• sharing links and access codes for your exams stop working immediately;
• deleted data may persist in encrypted backups until they expire on the cycle in section 9. Backups exist only for disaster recovery; if we ever have to restore from one, we re-apply outstanding deletions.

What we keep afterwards, and why. We cannot delete everything, and we would rather tell you what stays than quietly keep it: billing and tax records we are legally required to hold; a minimal suppression record so we do not accidentally re-add you; enough information to enforce a suspension imposed for abuse and to defend a legal claim; server and security logs until they rotate; support correspondence for the period shown in section 9; aggregated statistics that identify no one; and anything a legal hold requires us to preserve while a matter is live.

If we ever introduce automatic deletion of long-dormant accounts, we will email you well in advance so you have time to sign in or export your work.

If a school or organisation manages your account

Send your request to them first.They are the controller; they hold the relationship, the records and the decision, and they can usually act faster than we can. Under our DPA we are required to assist them, and we will — promptly and at no charge. If you send the request to us instead, we will not ignore you: we will acknowledge it, forward it to the organisation, and tell you that we have. We just will not act on it unilaterally, because acting on a controller’s data without its instruction is exactly what a processor must not do. See section 14 for the additional rights that apply to students, parents and guardians.

12. Additional information for the EEA, UK and Switzerland

This section applies if you are in the European Economic Area, the United Kingdom or Switzerland. It sits alongside the rest of this policy — it does not replace it. Where this section gives you a stronger right than the general terms above, this section wins.

Throughout, “GDPR” means Regulation (EU) 2016/679, “UK GDPR” means the UK version of that Regulation as retained in UK law alongside the Data Protection Act 2018, and “FADP” means the Swiss Federal Act on Data Protection. We apply the same standard to all three. Our controller and processor roles are set out in section 2, our lawful bases in section 5, and the rights themselves — with the one-month response clock — in section 11.

Sensitive data in the documents you upload (Article 9)

We do not ask for special category data, and we do not want it. We do not seek out data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric data, health data, or data about sex life or sexual orientation. We build no feature that detects it, infers it, profiles on it, or segments users by it. It is not part of any product decision we make about you.

But a document is a container, and we cannot see inside it before you send it. A biology worksheet may describe a medical condition. A theology exam may quote scripture. A scanned page may carry a photograph of a face. If it is in the file, it passes through our systems.

Your side of it.Please do not upload material containing special category data, and do not upload documents containing other people’s personal data unless you have a lawful basis to do so. For teachers and institutions that means: do not upload student medical records, safeguarding notes, disciplinary files or anything from a pupil’s confidential file into a question-generation tool. It is not what the tool is for.

Our side of it. Where special category data does end up in an upload, we treat it as ordinary customer content under your control — we do not index it, tag it, categorise it or extract it as sensitive attributes; we do not use it to infer anything about anyone named in the document, and we make no automated decision about any person on the basis of it; it is protected by the same encryption in transit and at rest, and the same access controls, as everything else; it is subject to the same retention limits and deletion controls; and we never use it to train AI models. Where we process it at all, we do so on your instruction as the person who chose to upload it. For institutional accounts the school remains the controller and is responsible for the lawful basis and the Article 9 condition for whatever it uploads.

If you have uploaded something you should not have, delete it in the product and then email privacy@rimonlabs.com. We will confirm removal from our live systems and tell you when it will age out of backups.

If there is a data breach

• Regulator notification within 72 hours.Where we are the controller and a personal data breach is likely to result in a risk to people’s rights and freedoms, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, as Article 33 requires. If we cannot give the full picture in 72 hours we notify anyway and follow up in phases rather than waiting.
• Telling you. Where a breach is likely to result in a high risk to your rights and freedoms we will tell you without undue delay, in clear, plain language — what happened, what data was involved, what we assess the likely consequences to be, what we are doing about it, and what you should do to protect yourself. That is Article 34, and we will not water it down.
• When we are a processor, we notify the affected controller — the school, institution or business customer — without undue delay, and we give them the information and assistance they need to meet their own Article 33 and 34 duties.
• We keep a record of every personal data breach, its effects and the remedial action taken, whether or not it was notifiable, as Article 33(5) requires.

Data minimisation, accuracy and purpose limitation

We collect as little as we can get away with. We do not ask for a date of birth, a phone number, a postal address or a photograph in order to generate questions from a document. MCQForge lets you try the core function — your first upload — before creating an account at all. Optional fields are labelled optional and are genuinely optional. If we cannot articulate the purpose a field serves, we remove the field.

We keep it accurate. You can view and correct your account details yourself at any time. Where you tell us something we hold is wrong we correct it, and where the inaccurate data was shared with a service provider we pass the correction on. If you dispute the accuracy of something we cannot immediately verify, you can ask us to restrict processing of it while we check.

We keep it purpose-limited. Data collected to run the service is used to run the service. We do not quietly repurpose it, your content is never used to train AI models, we do not sell personal data, we share nothing with advertising networks, we run no advertising pixels and no cross-site tracking, and our analytics are cookieless.

Complaining to a regulator

If you think we have handled your data unlawfully, you can complain to a data protection supervisory authority — normally in the country where you live, where you work, or where the problem happened. In the UK that is the Information Commissioner’s Office ↗ (opens in a new tab). In Switzerland it is the Federal Data Protection and Information Commissioner ↗ (opens in a new tab). In the EEA the list of national authorities is published by the European Data Protection Board ↗ (opens in a new tab). We would rather you told us first at privacy@rimonlabs.com so we get the chance to put it right — but that is a preference, not a condition, and you are never required to come to us before going to a regulator.

13. Additional information for US state residents

This section is our notice at collection under the California Consumer Privacy Act as amended by the California Privacy Rights Act (together, the “CCPA”), and it sets out the equivalent rights under other US state privacy laws. It applies to every Rimon Labs product. Terms such as “personal information”, “sell”, “share” and “sensitive personal information” have the meanings given to them in those laws.

Categories of personal information

California law asks us to set this out by statutory category. This table covers the preceding twelve months across all Rimon Labs services — the corporate website collects far less than a product account does.

We do not collect precise geolocation — location accurate to within 1,850 feet — and we do not collect government identification numbers, financial account numbers, health information, or information about racial or ethnic origin, religious beliefs, union membership, sexual orientation or sex life. Your full payment card number never reaches our servers.

Sensitive personal information

The only sensitive personal information we collect on purpose is your account log-in credentials, used for exactly one thing: to verify that you are you and keep your account secure. We store passwords using a one-way cryptographic hash — we cannot read your password, and neither can anyone who obtains our database.

You may incidentally include sensitive information inside a file you upload. We do not seek it, do not use it to infer any characteristic about you or anyone else, and do not disclose it beyond the providers needed to produce your output. We do not use or disclose sensitive personal information for any purpose beyond those permitted by California Civil Code § 1798.121 — performing the service you requested, securing the service and preventing fraud, ensuring physical safety, and verifying and maintaining service quality. Because of that, California’s “Limit the Use of My Sensitive Personal Information” right does not apply to our processing, and we do not display that link.

Other US states

If you live in a US state with a comprehensive consumer privacy law, you have rights similar to California’s. We do not maintain a different privacy standard per state — we apply the strongest treatment across the portfolio. These rights are available to residents of Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Delaware, Iowa, Nebraska, New Hampshire, New Jersey, Maryland, Minnesota, Tennessee, Indiana, Kentucky and Rhode Island, and of any other state whose comprehensive privacy law takes effect after the date at the top of this page. As new state laws come into force we extend the same rights automatically rather than waiting to be asked. Exactly which rights apply, and any thresholds or exemptions, are set by your own state’s law; some rights we offer are broader than a particular state requires.

The full list of rights, how to exercise them, how we verify you, our response clocks and the appeal process are in section 11. Where a state requires a data protection assessment before certain high-risk processing, we complete one before that processing begins. In states requiring consent for sensitive data, we will not process sensitive data without it.

No targeted advertising, no sale, no significant-decision profiling

• We do not engage in targeted advertising. We serve no ads in any Rimon Labs product and run no advertising pixels or ad-network tags on any of our sites. We build no cross-site or cross-application profiles for advertising.
• We do not sell personal data for monetary or other valuable consideration.
• We do not use personal data for profiling in furtherance of decisions that produce legal or similarly significant effects about you. No Rimon Labs product makes an automated decision about your credit, employment, housing, insurance, education admission or access to an essential service. Auto-grading an exam against the answer key its author supplied is the product doing the job it was asked to do, not us profiling you — see section 16.

Data breach notification

If we discover a security incident that compromises your personal information, we will notify you and the relevant authorities as required by the breach-notification law of your state and by any other law that applies to you. We will notify affected users without unreasonable delayonce we have confirmed an incident and determined who is affected, and in any event within the deadline your state’s law sets. Where a school’s student data is involved we notify the school directly and within any shorter deadline that applies — see section 14. Our notice will describe, so far as we know it, what happened, what information was involved, what we have done, and what you can do. We will not delay notification to protect our reputation. If law enforcement asks us to delay in order to protect an investigation, we will comply with that request and notify you as soon as we are permitted to.

California “Shine the Light”

California residents may ask us once a year for a list of the third parties to whom we disclosed their personal information for those third parties’ own direct marketing purposes, and the categories of information disclosed. We do not disclose personal information to third parties for their direct marketing purposes. There is nothing on that list and there never has been. If you would like that confirmed in writing, email privacy@rimonlabs.comwith the subject line “Shine the Light Request”.

Nevada residents

Nevada law lets consumers direct a website operator not to sell certain covered information. We do not sell covered information, and we have no plans to. If you would like to submit a verified request anyway, email privacy@rimonlabs.comwith the subject line “Nevada Opt-Out” and include the email address associated with your account. We will confirm your request in writing.

HIPAA, GLBA, and data you should not upload

Rimon Labs is not a HIPAA covered entity or business associate, and is not a financial institution under the Gramm-Leach-Bliley Act. We do not offer our products as a compliant environment for regulated data, we will not sign a Business Associate Agreement, and we make no representation that our products meet HIPAA, GLBA, PCI DSS or any similar standard. We hold no security or privacy certifications; we describe our actual practices in section 10 rather than pointing at a certification we do not have. If you need a certified environment for regulated data, we are not the right choice for that workload — and we would rather tell you now than after you have uploaded it.

Please do not upload to any Rimon Labs product:

• protected health information, medical records or patient data;
• payment card numbers, bank account or routing numbers, or other financial account credentials;
• Social Security numbers, passport or driving licence numbers, or other government identifiers;
• classified, export-controlled or otherwise legally restricted material;
• anyone else’s personal information that you do not have the right to share with us.

If you upload this kind of data anyway, you do so at your own risk and you are responsible for any legal obligation that attaches to it. Tell us at privacy@rimonlabs.com and we will help you remove it.

This section describes our practices under United States law. It is written to be accurate and specific rather than exhaustive, and it is not legal advice to you. If you are a school, a district or a business evaluating us for a regulated use, read it alongside whatever written agreement we sign with you — that agreement, not this page, governs our obligations to you where the two differ.

14. Children, schools and student privacy

We have written this at length, because a policy that says “we do not knowingly collect data from children” and stops there is not much of a commitment.

Our general rule: 13 and over

Rimon Labs products are for people aged 13 and over. If you are under 13 you may not create your own Rimon Labs account. We do not knowingly collect personal information directly from a child under 13 who signs up on their own, and if we learn that a child under 13 created an account without the school authorisation described below, we will delete the account and the associated personal information promptly. There is exactly one exception, and it exists because teachers asked for it: a school can authorise under-13 use.

The school-consent pathway under COPPA

The Children’s Online Privacy Protection Act (“COPPA”) allows a school to provide consent on behalf of parents when an online service is used solely for a school-authorised educational purpose and for no commercial purpose. We rely on that pathway, and only that pathway, for children under 13.

A school, district, teacher or other educational institution (the “School”) may authorise students under 13 to use a Rimon Labs product as part of classroom or school activity. In doing so the School acts as the parent’s agent for the limited purpose of consenting to our collection of the child’s information for that educational use. By enabling under-13 student use, the School represents and warrants that it:

• has the authority to consent on behalf of parents under COPPA’s school-consent provision, and is doing so;
• is using the product solely for an educational purpose and for no commercial purpose;
• has given parents notice of the School’s use of the product, of the categories of information collected, of how it is used, and of our identity and contact information — or has authorised us to provide that notice, which we will do on request;
• will make our direct notice below available to parents on request;
• will not enable under-13 use for any purpose we have not been told about;
• will obtain direct parental consent itself where COPPA requires it, in particular where use is not limited to the school-authorised educational context; and
• has determined that our practices, as described here, are acceptable for its students.

We will not accept a School’s consent as a substitute for parental consent for any commercial purpose. If a School’s use ever stops being purely educational, the school-consent pathway stops applying and we will require direct verifiable parental consent, or disable under-13 access.

Direct notice to Schools and parents

This is our COPPA direct notice. A School may share it with parents as-is, and we will supply it in writing on request to privacy@rimonlabs.com.

• Who we are. Rimon Labs LLC, a Wyoming limited liability company (Entity ID 2026-001975416), 5830 E 2nd St, Ste 7000 #35694, Casper, WY 82609, United States. Privacy contact: privacy@rimonlabs.com.
• What we collect from a child user.The minimum needed to deliver the product: an account identifier, which may be a school-issued email address or a pseudonymous class identifier chosen by the teacher; the child’s name or class display name if the School supplies it; the child’s responses to the assessment the teacher created; the resulting scores; and technical log data such as IP address and device or browser type collected for security and to make the service work.
• What we do not collect.We do not ask a child for a home address, phone number, date of birth, photograph, government identifier, or any information about the child’s family. We do not require a child to disclose more than is reasonably necessary to participate, and we do not collect persistent identifiers for any purpose other than supporting internal operations.
• How we use it.Solely to deliver the educational service the School asked for — delivering the exam, grading it against the teacher’s answer key, and returning results to the School.
• Who we disclose it to. Only to the service providers that help us run the product, listed in section 7, each under contract, each permitted to use the data only to perform that function, and each prohibited from training AI models on it. We disclose a child’s information to no one else.
• Consent.Because we rely on the school-consent pathway, we obtain the School’s consent and the School acts as the parent’s agent. A parent may review the child’s information, ask for it to be deleted, and refuse to permit further collection or use.
• A parent’s refusal does not end the child’s education. If a parent refuses, the child simply will not use our product; the School decides what to do instead.

Rights of parents and Schools

A parent or guardian, and the School acting on their behalf, may at any time review the personal information we hold about their child, ask us to delete it, and refuse further collection or useof it, which means discontinuing the child’s use of the product.

Because a School controls the account and holds the roster, the fastest route is almost always through the child’s teacher, school or district — they can usually delete a student’s data directly without involving us. If you would rather come to us, email privacy@rimonlabs.comwith the subject line “COPPA Request”. When a request comes to us directly we verify it and then route it to the School that authorised the child’s use, and support the School in honouring it — because the School, not Rimon Labs, is the controller of the student’s educational record, and because we cannot reliably verify a parent-child relationship the School has already established. We will not stall behind that: we contact the School promptly, tell the parent we have done so, and act on the School’s instruction. We honour a School’s own deletion instruction at any time, for any student or for all of them, without asking why.

We keep a child’s personal information only as long as is reasonably necessary to fulfil the educational purpose it was collected for, and then we delete it. A School may set a shorter period, or ask us to delete at the end of a term, course or school year — we follow that instruction. When a School’s relationship with us ends, we delete or return student data at its direction.

FERPA and student records

Where a School uses a Rimon Labs product with its students, student information may constitute an “education record” under the Family Educational Rights and Privacy Act (“FERPA”). For that data Rimon Labs acts as a school official with a legitimate educational interest under FERPA’s school-official exception. Concretely:

• We perform a service the School would otherwise perform using its own employees.
• We are under the direct control of the School with respect to the use and maintenance of education records. The School tells us what to do with them; we do not decide independently.
• We use education records only for the purpose the School authorised— delivering the product’s assessment functionality — and for nothing else. Not for marketing. Not for product research on identifiable student data. Not for AI training, ever.
• We do not re-disclose education records to anyone other than the subprocessors listed in section 7, each contractually bound to the same restrictions and permitted to use the data only to perform its function for us. We will not re-disclose to any other party without the School’s written authorisation or a legal obligation — and if we are legally compelled, we will notify the School unless the law forbids it.
• The School remains responsible for its own FERPA obligations, including its annual notification and its determination that we qualify as a school official.

Student data belongs to the School and its students — not to Rimon Labs. Student records processed in a Rimon Labs product remain the property of, and under the control of, the School. We acquire no ownership of and no licence to exploit student data. We hold it as a processor and hand it back or delete it whenever the School says so. We claim no right to use student data to develop or improve any product beyond what is necessary to deliver the service to that School, and no right to train AI models on it under any circumstances.

FERPA gives parents — and students once they turn 18 or enrol in a postsecondary institution (“eligible students”) — the right to inspect and review education records, to request amendment of records they believe are inaccurate or misleading, and a right to a hearing if the School declines to amend. Those rights are exercised through the School, which holds the relationship, the identity verification and the authority to amend a record. If a parent or eligible student contacts us directly we will not refuse to help — we forward the request to the School and support it in responding, including by providing the underlying data or making a correction the School directs.

US state student-privacy laws

Several states impose obligations on education technology providers that go beyond FERPA and COPPA. We comply with them across the portfolio, not only in the states that require it — running one standard is safer than running fifteen. For all student data processed on a School’s behalf, Rimon Labs:

• does not sell, rent, trade or otherwise transfer student data, in any form and to any party, other than to the subprocessors that operate the service under contract — and, in a merger or acquisition, only to a successor that agrees in writing to these same commitments;
• does not use student data for targeted advertising, on our service or anywhere else;
• does not create a profile of a student except in furtherance of the School-authorised educational purpose;
• does not use student data to train AI models, ours or any vendor’s, and requires AI processing providers by contract not to do so;
• uses student data only for the educational purpose the School authorised, and for maintaining, supporting and securing the service;
• maintains reasonable administrative, technical and physical safeguards, including encryption of student data in transit over HTTPS-only connections and encryption at rest, access controls limiting internal access to personnel who need it, and hardened security headers on all our web properties;
• deletes student data at the School’s request and on termination, at the School’s direction, giving the School a reasonable opportunity to retrieve its data first;
• notifies the School without unreasonable delay of an unauthorised disclosure of student data and cooperates with the School’s own notification obligations, meeting any specific statutory deadline that applies;
• supports the School in honouring parent and student access, review, correction and deletion requests; and
• flows these obligations down by contract to every subprocessor that touches student data.

California — SOPIPA and AB 1584. We comply with the Student Online Personal Information Protection Act and with AB 1584. We do not engage in targeted advertising to students using covered information acquired through our service; we do not amass a profile about a K-12 student except in furtherance of K-12 school purposes; we do not sell or disclose covered information except as SOPIPA permits; pupil records remain the property of and under the control of the local educational agency; students may retain possession and control of their own school-generated content, and a School may specify how a student transfers it to a personal account; we use pupil records only for the purposes our agreement with the School requires or permits; parents, guardians and eligible pupils may review and correct information through the School; and we certify that pupil records will not be retained or available to us once the School’s agreement ends, other than as needed for the purposes of that agreement.

New York — Education Law § 2-d.For New York educational agencies we comply with § 2-d and 8 NYCRR Part 121. That includes maintaining a data security and privacy plan aligned to the NIST Cybersecurity Framework and to the agency’s own policy; signing the agency’s contract and supplying the supplemental information that accompanies its Parents’ Bill of Rights for Data Privacy and Security; using student, teacher and principal data only for the exclusive purposes stated in the contract; never selling it and never using it for marketing or commercial purposes; encrypting personally identifiable information in motion and at rest; requiring subcontractors to meet the same obligations by written agreement; notifying the agency of a breach or unauthorised release in the most expedient way possible and no later than seven calendar days after discovery; and deleting or returning data at the end of the contract at the agency’s direction.

Illinois — SOPPA. For Illinois schools we comply with the Student Online Personal Protection Act: entering into a written agreement with the school or district before receiving covered information; publishing and keeping current the list of subprocessors that may receive covered information, which is the table in section 7; not selling, renting or trading covered information; not using it for targeted advertising; deleting it at the school’s request; notifying the school within the statutory deadline of a breach and cooperating with parent notification; and supporting the school in providing parents access to and correction of their child’s covered information.

Other states. Many other states — including Connecticut, Colorado, Maryland, Texas, Virginia and Washington — have student-privacy statutes with substantially similar requirements. The commitments above are written to satisfy them, and we extend them to every School regardless of state.

What Schools should do before deploying

Schools with additional contractual requirements — a data privacy agreement, a state-specific rider, a required parents’ bill of rights, or a standard framework agreement — should contact legal@rimonlabs.com before deployment. We expect to sign a written agreement with Schools using our products for K-12 student data, and we would rather do that first than retrofit it.

15. International data transfers

Rimon Labs LLC is a United States company. If you use our products from Europe, the United Kingdom or Switzerland, your personal data will be transferred to and processed in the United States, and may be processed in other countries where our service providers operate. We are telling you this directly because it is the single most consequential fact about international transfers in this policy, and it should not be buried.

The transfer mechanisms we rely on

• EEA to the US and other third countries: the Standard Contractual Clauses adopted by the European Commission in Decision 2021/914 — Module Two (controller to processor) or Module Three (processor to processor), as applicable to the relationship.
• UK to the US: the SCCs as amended by the UK International Data Transfer Addendum issued by the Information Commissioner under s.119A of the Data Protection Act 2018, or the UK International Data Transfer Agreement where a customer prefers it.
• Switzerland to the US: the SCCs with the Swiss adaptations recognised by the Federal Data Protection and Information Commissioner — references to the GDPR read as references to the FADP, the FDPIC treated as the competent authority, and the clauses extended to protect the data of legal entities where Swiss law requires it.

These clauses are built into the DPA available to institutional customers, and we impose equivalent terms back-to-back on our subprocessors. We do not claim certification under the EU–US Data Privacy Framework, the UK Extension, or the Swiss–US Data Privacy Framework. We are not certified under any of them and we do not rely on them. If that changes, we will say so here with the certification date.

Transfer impact assessment

Before relying on the SCCs, and periodically afterwards, we assess whether the law and practice of the destination country would undermine the protection the clauses promise. That assessment looks at the categories of data actually transferred, how sensitive they are, how long they are kept, whether they are encrypted and who holds the keys, the nature of the recipient, whether the recipient has ever received a government access request, and the available legal remedies. If we conclude the clauses cannot be honoured for a given transfer, we suspend the transfer or change the provider. Institutional customers can request our current assessment summary.

Supplementary measures

Contract terms alone are not protection. Alongside the clauses, all data is encrypted in transit with TLS on HTTPS-only services with HSTS preload; data at rest is encrypted in the storage systems our products use; access is limited to the small number of people who need it, over authenticated connections, and is logged; and we minimise what crosses the border in the first place, because short retention limits mean there is less data in existence to be exposed to any request. The full technical detail is in section 10, and the providers and their processing locations are in section 7.

16. Automated decision-making

We do not make decisions about you that produce legal effects or similarly significant effects using automated processing alone.

Our products use AI to generate content — questions, answers, summaries — and to grade assessments automatically where an educator has set one up. Auto-grading is a comparison, not a judgment: the educator who builds the exam supplies the correct answer for each question, and when a candidate submits, the system compares the selected option to that stored answer, marks it, and totals the score using the weighting the educator configured. It does not evaluate the candidate’s writing, tone, effort, character or likely ability, it looks at no other data about the candidate, and it uses no predictive or profiling model. Where AI is involved earlier in the workflow — extracting candidate questions from an uploaded document — that output is presented to the educator for review and editing before any exam goes live.

Article 22 of the GDPR restricts decisions based solely on automated processing that produce legal or similarly significant effects. Our position is that auto-grading, as we deliver it, falls outside that restriction for two reasons. First, a human is meaningfully involved: the educator wrote or approved every question and answer key, set the pass mark and weighting, can see every individual response, and can override, re-mark, void or re-run any result. The determination that carries consequence — a grade, a pass, a place, a certificate — is made by the educator or the institution, not by us and not by the software. Second, we are not the one deciding:in an institutional deployment we act as a processor, and any decision made about a student on the basis of a score is the school’s decision, taken under its own assessment rules.

We are not claiming this is a grey area with nothing behind it. A machine-produced exam result can matter a great deal to a person. So we do not rely on the analysis above alone — we build the safeguards in regardless:

• Human review is always available. Every result is visible to the educator alongside the individual answers, and every result can be changed by the educator.
• You can contest a result. Raise it with the educator or institution that set the exam — they hold the override. If you cannot reach them, or the exam was set by an individual account holder, email privacy@rimonlabs.com and we will route it and support the review.
• You can ask for human intervention and express your point of view through the same route, in line with Article 22(3).
• The logic is disclosed above in plain terms, and we will explain the scoring configuration applied to a specific result on request.
• No special category data is used in scoring, and no automated decision is made on the basis of it.
• Children get more protection, not less. We do not make automated decisions with legal or similarly significant effects about children without human involvement, and we do not profile children for advertising — ever.

If an institution configures the product to release results with no human review at all, that configuration decision belongs to the institution, and the institution is responsible for meeting Article 22 — including telling its students. Our DPA says so explicitly, and the safeguards above remain available.

We also use automated checks to detect spam, fraud and abuse. If an automated check restricts your account, you can ask a person to review it by writing to privacy@rimonlabs.com.

17. Third-party sites and integrations

Our services link to and can connect with services other people run — your sign-in provider, your payment processor’s checkout, and any link a user places in content they create. Once you are on someone else’s service, their privacy policy applies, not ours. We do not control what they collect and we are not responsible for it. Read their policy before you hand over information.

If you connect a third-party account to a Rimon Labs product, you can disconnect it at any time in your account settings, and you can also revoke our access from that provider directly.

18. Business transfers

If Rimon Labs is involved in a merger, acquisition, financing or sale of assets — including the sale of a single product — personal information may transfer as part of that transaction. If it does, we will require the receiving party to honour this policy for the information it receives, and we will tell you before your information becomes subject to a materially different policy, so that you can delete your account first if you prefer.

Student data carries an additional condition: a successor must agree in writing to the student-privacy commitments in section 14 before any student data transfers to it.

19. Changes to this policy

We update this policy when what we do changes. For minor changes — clarifications, reformatting, or a new provider inside a category already listed here — we update the “last updated” date at the top.

For material changes — a new category of information, a new purpose, a new type of recipient, longer retention, or anything that narrows your rights — we publish the new version at least 30 days before it takes effect, record it below, and email registered users. That gap is deliberate: a change you find out about after it takes effect is not a change you had any say in.

We never prune this history. The value of a public version history is that it is complete — it lets you verify that a policy did not quietly get worse.

Version history

20. How to contact us

A real person reads these addresses. For anything about your information or your rights, write to privacy@rimonlabs.com. We aim to reply within 30 days, and sooner where the law requires it. Schools and organisations needing a data processing agreement or a state-specific rider should write to legal@rimonlabs.com.

If you are not satisfied

Please come to us first — most things are a misunderstanding we can fix quickly. If we cannot resolve it, you can complain to your data protection supervisory authority in the EEA, to the Information Commissioner’s Office in the UK, to the Federal Data Protection and Information Commissioner in Switzerland, or to your state Attorney General in the United States. You do not have to come to us first, but we would like the chance. The regulators’ own contact points are listed in section 12.

This is version 2.0 of the Rimon Labs Privacy Policy, last updated July 18, 2026 and effective July 18, 2026. Its permanent address is https://rimonlabs.com/privacy ↗ (opens in a new tab) — cite that URL in procurement forms and data processing agreements rather than a product domain, because this is the one policy that governs them all.