Trust & Security

Security & Data Handling

Company: Lumor Technologies Pvt. Ltd. · Last updated: 9 September 2026 · Applies to: lumor.tech & app.lumor.tech

This page describes, in practical detail, how Lumor secures the data you and your research participants entrust to us: the infrastructure we run on, the AI models we use and what they are permitted to do with your data, the sub-processors involved, how long we keep things, and the quality controls available to you. It is written to answer the questions that security, procurement, and privacy teams actually ask.

It sits alongside our Privacy Policy, Terms of Use, and Cookie Policy. Where this page describes a technical control and the Privacy Policy describes a legal commitment, both apply.

01 · Summary

The commitments below are the ones customers most often need in writing.

• We do not train AI models on your data. Lumor does not train, fine- tune, or otherwise build models from your survey content, respondent answers, recordings, or transcripts.
• Our AI providers do not train on your data either. We deliberately use enterprise AI platforms — Amazon Bedrock and Azure OpenAI — whose terms prohibit using customer inputs and outputs to train or improve their foundation models. See Section 05.
• Your research data is yours. You retain ownership of your surveys, responses, recordings, and generated reports, and can export them at any time.
• Data is encrypted in transit and at rest. TLS for everything in transit; AES-256 for object storage and managed databases.
• Primary storage is in India. Application data and media are stored in AWS Asia Pacific (Mumbai) — ap-south-1. Some AI inference happens outside India; we are explicit about exactly where in Section 03.
• We do not sell data, and we run no advertising. Your data is never shared with ad networks or data brokers.

02 · The Data We Process

Lumor processes three broad categories of data, and our legal role differs across them.

Special category data. Lumor does not intentionally collect sensitive personal data through the platform itself. If your survey asks for it, we will process it as your processor — you must ensure the appropriate consents and safeguards are in place first.

03 · Where Your Data Lives

We separate two questions that are often conflated: where data is stored, and where it is processed during an AI request. Both are set out below.

Where personal data is transferred outside India, we rely on Standard Contractual Clauses or equivalent safeguards as required under the Digital Personal Data Protection Act 2023 and other applicable law.

04 · The AI Models We Use

We use managed, enterprise AI platforms rather than consumer AI products, specifically because their contractual terms are stronger on training and retention. The table below lists every AI service in the production platform and exactly what reaches it.

AI features are triggered by an explicit action — generating a report, asking a question of your data, running a review, or recording an interview. Simply storing responses in Lumor does not send them to any model provider.

05 · AI Training: Our Commitment

This is the question we are asked most often, so we will answer it directly and in layers.

5.1 Lumor does not train models on your data. We do not build, train, fine-tune, or evaluate any machine learning model using your survey content, respondent answers, recordings, transcripts, or generated reports. We do not pool customer data into a shared training corpus, and we do not use one customer’s data to improve outputs for another.

5.2 Our AI providers do not train on your data. We chose Amazon Bedrock and Azure OpenAI as our primary AI platforms precisely because both contractually commit that customer inputs and outputs are not used to train their foundation models:

• Amazon Bedrock. Bedrock operates a zero data retention model: by default it does not store model inputs or outputs. It also operates zero operator access, meaning no operator of the service can read model input or output. Model providers are served from isolated deployment accounts they cannot access, so the provider of the model we use never sees your prompts or completions, and content processed through Bedrock is not used to train the underlying foundation models. Traffic is encrypted in transit and at rest. Note that a small number of models offered on Bedrock — not the one Lumor uses — carry a documented abuse-detection retention window; we deliberately run on Anthropic Claude Sonnet 4.5, which is on the default zero-retention path.
• Azure OpenAI Service. Microsoft states that your prompts, completions and embeddings are not available to other customers, are not available to OpenAI, are not used by model providers to improve their models or services, are not used to train any generative AI foundation model without your permission, and are not used to improve Microsoft or third-party products or services. The models are stateless — no prompts or completions are stored in the model. The service is covered by the Microsoft Products and Services Data Protection Addendum.

5.3 Abuse monitoring is not training. Both platforms run safety and abuse detection on requests. This is a safety control, it is operated by the provider under its own contractual limits, and in neither case is it a source of model training. On Azure OpenAI, content flagged by the classifiers may be sampled for review; that review is automated by default and reviewed content is not stored or used to train the reviewing models, with limited, just-in-time human review by authorised Microsoft personnel reserved for cases the automated systems cannot resolve. Microsoft offers an approved “modified abuse monitoring” configuration that removes the storage and human review step entirely. On Bedrock, abuse detection is automated and, for the model we use, operates without retaining your content.

If your programme requires a formally documented zero-retention configuration, contact us — we will pursue the relevant provider exemption for your tenant and confirm the resulting configuration in writing.

5.4 We do not enable prompt logging. Lumor has not enabled Amazon Bedrock model invocation logging, so prompts and completions are not written to logs in our AWS account. Application logs record operational metadata — job identifiers, timings, and errors — rather than research content.

5.5 Speech, voice and other providers. The providers behind transcription, translation, speech synthesis, conversational voice, slide generation and meeting capture do not all operate the same defaults, and we would rather set that out than imply a uniform position we cannot yet evidence. Recall.ai states that it does not use customer data to train or fine-tune models. Gamma’s terms permit training on content from individual-plan workspaces unless the account-level AI training control is switched on; we have switched it on, and we are seeking written confirmation from Gamma that it also covers content submitted through their API, which is the route Lumor uses. For the remaining providers we are working through the contractual and configuration steps needed to guarantee a no-training position for our account, and we will confirm the current, dated status for any provider on request. Until we can evidence it, we will say so rather than assume it.

Several of these power features that are off unless you turn them on — Indian-language transcription, conversational AI voice, slide generation and meeting capture. If you would prefer your workspace never touch them, we can disable them at the tenant level.

06 · Sub-Processors

The following third parties may process personal data on our behalf. We maintain written data processing terms with each of them, and we do not sell personal data to anyone.

Optional integrations you choose to configure — such as Slack or Discord notifications, Zoom or Google Meet scheduling, and calendar connections — will transmit the data you configure to those services. Those flows are under your control and are off by default.

We will give at least 30 days’ notice before adding a sub-processor that materially changes how research data is handled. To be notified, email contact@lumor.tech.

07 · Encryption

• In transit. TLS 1.2 or higher for all traffic between browsers, our APIs, our database, and every third-party service listed above.
• At rest. AES-256 server-side encryption on S3, enforced by a bucket policy that rejects any unencrypted upload. Managed database storage is encrypted at rest by the provider.
• Credentials and secrets. API keys, database credentials, and signing secrets are held in AWS Secrets Manager and SSM Parameter Store, encrypted with AWS KMS, and are never committed to source control.
• Passwords. Stored as bcrypt hashes with a work factor of 12. Plaintext passwords are never stored or logged. One-time passcodes are hashed the same way.
• Media access. Recordings and uploads are never publicly readable. Access is granted through short-lived, pre-signed URLs issued only to authorised users.

08 · Access Control and Authentication

For your users. Lumor supports email and password sign-in with bcrypt hashing and email verification, Google sign-in via OAuth 2.0, short-lived access tokens with refresh token rotation, and CAPTCHA verification on sign-up and sign-in to deter automated account abuse.

For Lumor staff. Access to production infrastructure is managed through AWS IAM Identity Center with group-based, least-privilege permission sets. Engineers do not have standing access to customer research content; access is limited to what is required to operate and support the service, and administrative access to cloud infrastructure requires multi-factor authentication.

09 · Tenant Isolation and Permissions

• Organisation scoping. Every resource — workspace, project, folder, survey, response, report — belongs to an organisation, and queries are constrained to the organisations the requesting user belongs to. Cross-organisation reads are rejected at the resolver layer rather than filtered in the client.
• Role-based access control. Sharing is expressed as explicit access levels — admin, edit, and view — evaluated per resource and inherited down the workspace hierarchy.
• Server-side enforcement. Permission checks, response validation, quota evaluation, and disqualification logic are all re-evaluated on the server at submission time. Client-side checks exist for user experience, not as the security boundary.
• Audit logging. Create, update, delete, publish, and sharing events on key resources — including surveys, responses, quotas, and collectors — are recorded to an audit log with a six-month retention window, and can be retrieved for your organisation on request.
• Abuse controls. Rate limits apply to AI chat, connector emails, and invitation reminders. Uploads are restricted by MIME type and size.

10 · Recordings and Transcription

Audio and video are only captured when you enable a feature that requires them — a recorded interview, a spoken-answer question, or a conversational AI session — and when the participant proceeds through the consent your study presents.

The pipeline is: the browser or meeting bot uploads media to S3 in ap-south-1 with AES-256 encryption; a transcription provider reads it through a short-lived pre-signed URL and returns text with per-segment confidence scores; transcripts may be translated into English; and the resulting text is then analysed by an LLM to produce summaries and insights. Raw media is not sent to the language models — only the transcript text is.

Media retention. Interview media under the interviews/ prefix is automatically deleted 30 days after upload. All other objects in the media bucket are automatically deleted after 365 days. These are enforced by S3 lifecycle rules, not manual process.

11 · Quality Control for Research Data

Data quality is a security-adjacent concern: a clean dataset is one you can defend. The controls below are available in the platform today. We have deliberately listed only what exists, and noted what does not.

11.1 Screening and disqualification. You can build screening questions and condition-based logic that disqualifies a respondent mid-survey or ends the survey early. Disqualification is re-evaluated server-side at submission, so a respondent cannot bypass it by manipulating the client.

11.2 Quotas. Simple, study-level, and combination quotas let you cap how many completions each cell accepts. Counters are incremented atomically at submission to prevent overfilling under concurrent load, and you choose what happens on overflow: end the survey, show a custom message, redirect to a URL, or close the window.

11.3 Duplicate prevention. Enabling one response per participant enforces a single submission per respondent email address, and per authenticated user where respondents are signed in. This is checked on the server against both completed and disqualified responses.

11.4 Response validation. Per-question rules — mandatory answers, minimum and maximum selection counts, text length bounds, email, URL and numeric formats, and fixed-sum or numeric constraints across multi-textbox questions — are enforced server-side when configured, in addition to client-side prompts.

11.5 Completeness segmentation. Partial responses are autosaved and stored with an explicit status. Analytics default to completed responses only, and incomplete, disqualified, and over-quota responses are viewable and exportable separately, so a partial never silently contaminates a headline number.

11.6 Cleaning and export. Individual responses can be reviewed and removed, and analytics and exports can be filtered by collector, date range, answer values, and response status. Exports are available in CSV and XLSX.

11.7 Survey design review. An AI-assisted review checks a draft survey for typos, unclear or gibberish labels, leading or biased wording, wrong question types, missing options, broken logic references, and circular rules — catching quality problems before fieldwork rather than after. This is currently a staged feature; ask us to enable it for your workspace.

11.8 Transcription confidence. Transcripts carry per-segment confidence scores from the speech provider, so low-confidence passages can be identified during review.

12 · Retention and Deletion

Account deletion is available in-product from profile settings and removes the account along with its owned resources. You can also request deletion by writing to contact@lumor.tech; we action requests within 30 days, subject to any statutory retention obligations.

13 · Data Subject Rights

Individuals have the right to access, correct, delete, restrict, port, and object to the processing of their personal data, and to withdraw consent where processing relies on it. Indian residents additionally hold the rights granted by the Digital Personal Data Protection Act 2023, including the right to nominate someone to exercise those rights on their behalf.

If you are a survey respondent and want your responses removed, contact the organisation that sent you the survey — they are the controller and can delete your response directly. If you are unsure who that is, write to us and we will route your request. If you are a Lumor customer receiving a rights request from your own respondents, you can locate and delete individual responses in-product, and we will support you with anything the interface does not cover.

Full detail on rights and how to exercise them, including our Grievance Officer for India, is in the Privacy Policy.

14 · Compliance and Certifications

Lumor is built to support compliance with the Digital Personal Data Protection Act 2023 in India and, for customers with European respondents, the GDPR. We offer a Data Processing Agreement, act as processor for respondent data, rely on Standard Contractual Clauses for transfers outside India, and support data subject rights as described above.

Being straightforward about certifications. Our infrastructure runs on providers that independently hold SOC 2 Type II, ISO 27001, and equivalent certifications — Amazon Web Services, Microsoft Azure, and MongoDB Atlas — and we inherit the physical, environmental, and platform controls those certifications cover. Lumor Technologies Pvt. Ltd. does not itself currently hold a SOC 2 Type II or ISO 27001 certification. If your procurement process requires one, contact us and we will discuss our roadmap and what alternative assurance we can provide in the meantime, including a completed security questionnaire.

15 · Security Incident Response

We monitor application and infrastructure logs for errors and anomalous activity, and maintain an internal process for triaging, containing, and remediating security events.

If a personal data breach occurs that is likely to result in a risk to individuals’ rights and freedoms, we will notify affected customers without undue delay, and report to the Data Protection Board of India as required under the DPDP Act 2023 and to other supervisory authorities where applicable. Notifications will describe what happened, what data was involved, what we have done, and what we recommend you do.

16 · Responsible Disclosure

If you believe you have found a security vulnerability in Lumor, please report it to contact@lumor.tech with enough detail for us to reproduce it. We ask that you give us a reasonable opportunity to investigate and remediate before any public disclosure, and that you avoid accessing, modifying, or deleting data belonging to other users while testing. We will acknowledge your report within two business days and keep you updated on our progress. We will not pursue legal action against researchers who act in good faith and follow this guidance.

17 · Contact and Documentation

For a Data Processing Agreement, our current sub-processor list, a completed security questionnaire, model and region details for your tenant, or anything else your review requires, contact us and tell us what you need.

Lumor Technologies Pvt. Ltd.
38, 1st Floor, Aswini Layout, 2nd Main Rd, Viveknagar, Ejipura, Bengaluru, Karnataka – 560047
Email: contact@lumor.tech · Phone: +91 98898 81155

© 2026 Lumor Technologies Pvt. Ltd. All rights reserved.