Privacy policy — SchoolApp.One

Lumiowl Private Limited · SchoolApp.One

This policy explains how Lumiowl Private Limited (“Lumiowl”, “we”, “us” or “our”) handles personal information through SchoolApp.One and lumiowl.com (the “Services”). SchoolApp.One supports schools, colleges and institution groups (“Institutions”), their staff, applicants, students, parents and lawful guardians. The Services are currently intended for use in India.

Reading this policy or continuing to use SchoolApp.One does not, by itself, give consent to every use of your information. Where consent is required, it must relate to a stated purpose and be obtained separately from agreement to contractual terms. Contact grievance@lumiowl.com for privacy questions or requests.

1. Scope and responsibility

Institutions generally decide why student, parent and staff records are collected, which records are needed, who receives access and how long educational or employment records must be retained. For those activities, the Institution ordinarily acts as the data fiduciary and Lumiowl processes data on its instructions under its service agreement. Lumiowl is responsible for processing it determines for its own purposes, such as handling enquiries, managing its business relationship with Institutions, security and legal obligations. The actual purpose and applicable law determine these roles.

Institutions must provide appropriate notices, establish a lawful basis, collect any required verified permissions and keep access assignments accurate. A service contract or an administrator’s assertion alone does not replace a person’s or guardian’s consent where the law requires it. We remain responsible for our own obligations.

This policy covers information even if you do not have a login, including pending or rejected applicants, younger students and contacts entered by an Institution. A school’s separate privacy notice may also apply. Other websites and payment providers have their own notices.

2. Information we handle and where it comes from

Information comes from you, your Institution, authorised staff, parents or guardians, payment providers and devices using the Services. Institutions can create staff accounts and create or link student and parent profiles during admission approval. An existing profile may be reused when its email address matches. Registration may also be available on a particular deployment; availability of a registration page does not establish authority to submit another person’s data.

Welcome emails can provide password-reset instructions, and email OTPs support verification and recovery. We store password and OTP hashes for authentication; do not send us your password or OTP in a support request.

Information depends on your role and enabled features
Category	Examples and purpose
Identity and account	Name, email, mobile number, date of birth, gender, profile identifier, verification flags, password hashes, session identifiers, preferences and privacy acceptance information; used to identify you, manage access and personalise the service.
Profile and identity documents	Photo, current and permanent addresses, ID type, ID number and document attachment where required by an Institution. Provide only necessary documents; ask whether a masked copy or alternative is acceptable. This policy does not make government ID mandatory for every user.
Family and guardian information	Up to two parents’ or guardians’ names, relationship, contact details, date of birth, gender, photo, identification details, occupation, annual income and office address where entered. An Institution should request income or identity information only for a specific, necessary purpose.
Admissions and education	Applications, enquiry/admission numbers, approval or rejection status and dates, previous education, course preferences, institution, batch, department, class, roll number, enrollment, promotion history, timetables, attendance, exam schedules, marks, calculated results and progress summaries.
Employment and permissions	Employee identifier, joining date, job profile, designations, departments, assigned subjects/classes, attendance, role privileges and account activation or archive status.
Tasks, events and uploads	Task and task-group descriptions, assignments, status and associated dates; calendar titles, descriptions and audiences; profile, staff and student photos, logos, covers, and supported attachments. Free text and files may contain information about others: include only information you are authorised to share.
Billing and payments	Institution subscriptions, billable student/staff counts, invoices, fee configuration, amounts, currency, payment status, order/payment references and payer or payment-method details returned by Razorpay. The backend currently implements platform subscription payments; fee configuration does not establish a complete school-tuition collection service.
Transport	Vehicle and route details, milestones, zones and responsible staff names. Precise live location is a separate, conditional feature described in section 6.
Device, technical and audit data	Registered device identifier, platform, app version, push token, registration and last-seen times; IP address for anti-abuse verification; request, error and audit information, actor identifiers, and creation/update timestamps. Hosting or client diagnostics may add browser, operating-system and device details.
Enquiries and support	Contact/demo form fields, Institution name, role, messages, correspondence and identity-verification information needed to handle a request. Avoid including unnecessary student records or payment credentials.

We do not sell or rent personal information or use student data for advertising. The Services do not require access to contacts, SMS, call logs or microphone for the functions described here. Photos or files should be limited to those you choose to provide. Do not upload full payment-card numbers, card security codes, UPI PINs, bank passwords, unrelated health records or biometric data. Payment credentials entered in a provider’s checkout are handled by that provider.

Missing information can prevent account verification, admission processing, payment or another requested function. The Institution should distinguish mandatory information from optional fields and explain any educational or legal requirement.

3. Purposes and legal grounds

Deliver educational and administrative functions: manage admissions, enrollment, staff, attendance, classes, tasks, calendars, exams and progress records; provide role-appropriate views and institutional reporting.
Authenticate and protect accounts: send welcome/reset emails and OTPs, maintain sessions, check permissions, verify CAPTCHA and investigate misuse.
Communicate: deliver account, security and enabled institutional notifications and respond to support or privacy requests. Optional marketing requires a separate appropriate basis and choice.
Administer billing: calculate subscriptions from applicable institutional usage, generate invoices, reconcile provider responses and maintain financial records.
Maintain the Services: diagnose errors, operate infrastructure and, where enabled and lawfully permitted, use limited analytics and configuration tools. Pseudonymous identifiers can still be personal data.
Meet legal obligations: maintain required records, respond to valid legal demands and protect rights and safety.

We and the Institution must identify a lawful ground for each activity. Depending on the activity and the law in force, this may be specific consent, a permitted use expressly recognised by law, or a legal obligation. A contract explains service responsibilities; it is not a blanket substitute for required consent. “Improvement” or “legitimate use” is not unrestricted permission to reuse student records.

Scores, attendance totals and progress summaries can be calculated automatically from institutional inputs. This does not mean the service independently makes admission, promotion, employment or disciplinary decisions. Ask the Institution to review disputed inputs, calculations or decisions.

4. Children, guardians and vulnerable users

For the Indian DPDP framework, a child is a person under 18. The existing product policy permits a student’s own login from age 16; younger students access information through a parent or lawful guardian. A login at 16 does not make the student an adult or remove any required parental consent. Login-age enforcement and guardian verification must be confirmed before deployment.

Before processing a child’s data where consent is required, the responsible Institution and Lumiowl must arrange verifiable consent from a parent or lawful guardian and an appropriate record of authority. Neither admission approval, a welcome email, a shared surname, an email match nor a student’s checkbox alone proves that authority. Any statutory educational or safety exemption must be checked for the specific activity and its conditions; it is not presumed for the entire platform.

We do not use children’s information for targeted advertising. Optional analytics involving children must remain disabled unless reviewed for applicable restrictions on tracking and behavioural monitoring and a lawful basis is established. Necessary educational attendance records and transport safety functions must be assessed separately rather than treated as permission for general tracking.

Institutions must promptly report disputed guardianship, custody restrictions, incorrect parent links or a compromised guardian account. Access should follow verified legal authority, not merely who supplied an email address. Where an adult is represented by a lawful guardian, authority must similarly be verified where required; disability alone does not establish a need for substituted consent.

When a student turns 18, review parental access and any continuing consent or authority. For suspected unauthorised collection or disclosure, contact the Institution and our grievance team. We will coordinate appropriate access restriction, correction or erasure, subject to lawful preservation requirements.

An account may have separate records indicating privacy-policy acknowledgement and acceptance of terms, together with an acceptance date/time. These serve different purposes. Acknowledging this notice does not authorise optional analytics, location sharing, marketing or every future use of information.

Accounts created by an Institution, older accounts, or accounts with missing or incomplete acceptance information must not be assumed to have consented. A recorded acceptance does not by itself establish the accepted policy version, the purposes agreed to, who acted for a child, or their authority. Where consent is relied on, those facts need an appropriate supporting record.

You may withdraw consent for a specific purpose through the relevant control where available or by contacting us. Withdrawal does not invalidate earlier lawful processing and may prevent the related feature from working. We will explain any processing that must continue under another applicable legal ground. Turning off a device permission does not erase information already held or withdraw every other consent.

This HTML document is a notice; viewing it does not submit an acceptance or change your account. Materially new purposes require a fresh notice and consent where required. Consent must not be inferred merely from continued use after a policy change.

6. App permissions and conditional location features

Depending on the installed app and enabled feature, permission may be requested for a camera or selected photos/files to upload an image, and for notifications to receive alerts. You can deny or revoke optional permissions in device settings; this may disable the associated function. Network access is needed to connect to the service.

Live bus tracking is not established as an operational feature by the current backend specification. Transport route and vehicle records do not themselves collect your phone’s live location. If a deployed app enables live tracking, it must first explain who shares location, whether precise or background access is involved, who can view it, how to stop sharing and how long location history is kept.

Tracking should be limited to assigned transport users and the authorised transport purpose, with the device permission and visible foreground indication appropriate to the implementation. This policy does not authorise continuous background tracking, tracking every passenger’s phone, or off-duty employee tracking. No specific location-history retention period is asserted here because it has not been established. Foreground-service or wake-lock use, if present, must be limited to the active feature.

7. Cookies, analytics and notifications

Sign-in cookies

The web service uses an Authorization access cookie with a configured lifetime of 15 minutes and a Refresh-Token cookie with a configured lifetime of 30 days. They are configured as Secure and HttpOnly; domain and SameSite behaviour depend on deployment. Cookies can contain identifiers tied to your account. Blocking these cookies can prevent sign-in. Logging out expires the browser cookies; it is not account erasure or a guarantee that every previously issued token is immediately revoked.

Analytics, diagnostics and configuration

The existing policy describes Firebase Analytics, Crashlytics, Remote Config and Google Analytics on the website. These client-side integrations are not verified by the backend specification and apply only where actually enabled. Depending on configuration they may process app-instance or pseudonymous user identifiers, roles, screens/events, device/app information, crash traces, IP addresses, browser data and website cookies. Do not include names, email addresses, phone numbers, identity documents, marks or free-text student records in analytics events.

Where optional analytics requires consent, it must not start before that choice. Rejecting analytics should not block essential educational functions. Use an available consent control or contact us for withdrawal; browser/device settings can also limit cookies or permissions. A cookie banner or in-app analytics opt-out is not asserted to exist on every deployment. Disabling cookies alone may not disable native-app telemetry. This policy page itself loads no analytics, scripts, remote fonts or cookies.

Push alerts and shared devices

Push delivery uses registered device tokens and may pass notification titles, bodies and data to Firebase Cloud Messaging. Notification previews can be seen on a lock screen or by other people using a device. Hide previews where needed, and avoid sharing accounts. Turning off notifications or uninstalling the app does not delete institutional records or necessarily remove a stored server token. Device unregistration is separate from logout; ask support if an old or shared device still receives alerts.

Essential account, security or legally required communications may continue even if optional push or promotional messages are disabled. General messaging and every notification channel are not necessarily available in every release.

Within Institutions and groups: authorised staff, administrators and owners access information according to assigned scope and privileges. Group-level roles may extend across subgroups and Institutions. Class-only roles are narrower. Actual permissions matter; a menu label or job title does not establish the access boundary.
Students and parents: linked roles can provide access to relevant admissions, classes and records. Some authorised views include class-level information. Do not assume every response is restricted to a single student solely because the account is a parent or student account. Report unexpected visibility promptly.
Across memberships: one personal profile may be linked to several Institutions and roles. Reuse of a profile is not permission to copy all academic or family records between unrelated Institutions. Institution records, profile updates and role changes can have separate effects.
Service and support providers: limited to the functions in section 9, with appropriate contractual and security controls. Authorised Lumiowl personnel may access information for support, operations, incident handling or compliance.
Legal and safety disclosures: where required or permitted by applicable law, following assessment of the request and relevant restrictions.
Business transfers: a merger, acquisition or asset transfer may require disclosure under confidentiality safeguards. Affected users and Institutions should receive appropriate notice, and the recipient must respect applicable obligations. A transfer does not itself authorise unrelated reuse.
Other disclosures: only under an appropriate lawful ground, including specific consent where required. An Institution cannot authorise an unrelated disclosure merely because it holds the data.

Recipients can retain screenshots, exported documents or delivered emails outside SchoolApp.One. We cannot retract those copies through account deletion; contact the recipient or Institution about their obligations. Publicly shared logos or content and third-party links may have a different audience from private student records.

9. Service providers, storage and transfers

Providers identified in the specification or existing policy
Provider	Function and information involved
Amazon Web Services	Hosting and infrastructure; S3 stores uploaded files and SES sends email containing recipient addresses and message content. Database hosting arrangements must be confirmed separately. AWS privacy notice.
Razorpay	Payment orders, checkout, verification and payment events; payer/contact details where supplied, amounts, references, status and payment-method metadata. Payment credentials go to the payment provider, not into SchoolApp.One profile fields. Refund or failed-payment status may need reconciliation with support. Razorpay privacy policy.
Google Firebase	Cloud Messaging uses device push tokens and message payloads. Analytics, Crashlytics and Remote Config are conditional client integrations described in section 7. Firebase privacy information.
Cloudflare Turnstile	Anti-bot verification for selected requests, including verification token and request IP address; browser-side processing depends on the integration. Cloudflare privacy policy.
Google Analytics and Google Play services	Website analytics, device location services or update prompts only where enabled by the website/app. These are described in the existing policy but not confirmed by backend source. Google privacy policy.

The existing policy identifies AWS Mumbai, India, as the intended location for app data. The current specification does not verify live database, object storage, backup or support-access locations. Confirmed locations and any material additional providers must be reflected in the published policy. We do not claim all information stays in India: Google and other provider services may involve processing outside India.

Cross-border processing must follow applicable Indian restrictions, contractual commitments and other laws that apply. Provider privacy notices explain their practices but do not replace Lumiowl’s obligations. We do not authorise providers to use institutional records for unrelated marketing. Provider changes require appropriate review and notice where required.

10. Retention, account closure and deletion

We retain information for its stated purpose and any applicable recordkeeping obligation, rather than treating an active subscription as permission to retain everything indefinitely. Academic records, employment records, invoices, identity documents, security logs and backups can have different schedules.

Proposed operating targets from the existing policy — implementation must be confirmed
Information or event	Target and qualifications
Active account and institutional records	Keep only as needed for the service, institutional instructions and applicable obligations. Rejected applications, old identity copies and inactive records need separate review; active service alone is not a reason to keep unnecessary data.
Institution subscription ends	Target return, deletion or irreversible anonymisation of service data within 90 days, subject to lawful retention and agreed transition arrangements. A return request should specify scope and a secure recipient; it should not extend storage indefinitely.
Verified account-deletion request	Target removal of eligible personal information from active systems within 60 days, with retained categories and reasons explained. There is no verified self-service account-erasure workflow in the current specification.
Backups	Proposed maximum rotation period: 60 days. If rotation starts after active-system deletion, residual copies may remain for a further 60 days; this is not a promise of complete backup erasure within 60 days of the original request. Confirm the actual schedule before publication. Restored data must have applicable deletion restrictions reapplied.
Financial records	Retain for the period required by the applicable tax, accounting or dispute rules. The previous policy’s “typically 8 years” is not a universal rule for every financial record; the relevant record and retention starting point must be established.
Demo and contact enquiries	Target closure-based deletion and no longer than two years unless a continuing relationship, request or legal obligation justifies retention.
Optional analytics and crash reports	Previously proposed ceilings are 14 months for analytics and 90 days for crash reports. Actual SDK settings, provider limitations and deletion procedures need confirmation; these are not verified current settings.
OTP and device records	Stored OTP records have a configured 30-minute expiry cleanup, which is asynchronous; the email’s advertised ten-minute validity is a separate matter. Push tokens require unregistration or another deletion process; logout alone is not verified to remove them.
Logs and acceptance evidence	Keep only as needed for security, accountability, requests and legal claims under a documented schedule. No universal automatic expiry for these records is established.

Deactivation, archiving, logout, uninstalling, rejected admission and removal of one role do not equal erasure. Promotion can leave linked historical enrollment records. Closing one institutional membership may leave other memberships and the personal profile active. Tell us whether you seek removal from one Institution or closure of the whole profile.

Deletion review must address linked profiles and roles, admissions, student and staff records, photos and document objects, device tokens, provider records, audit information and backups where applicable. Removing a database record does not automatically remove its uploaded file. Previously failed uploads or file deletions may require reconciliation. We will not describe a partial removal as complete erasure.

Legal holds, statutory recordkeeping, safeguarding and established institutional obligations can justify retaining specific records. We will explain applicable limits and restrict retained data to the necessary purpose. Information is anonymised only if people can no longer reasonably be identified; replacing a name with an account identifier alone is not anonymisation.

11. Security and personal data incidents

We use authentication, configured secure session cookies, permission checks and audit metadata to help protect records. Hosting configuration supports HTTPS. Access should be limited to authorised purposes. This policy does not certify complete endpoint coverage, encryption at rest, mobile Keystore use, disabled device backups or any independent security certification; those deployment and client controls require separate verification.

No storage or transmission method is completely secure. Protect passwords and OTPs, secure shared devices and report incorrect role assignments, unexpected records or suspicious alerts promptly. Do not send sensitive student records to an unverified support address.

If an incident affects personal information, we will investigate, contain it and coordinate with affected Institutions. Notifications to affected people, the Data Protection Board of India or other authorities will follow the applicable requirements and timelines in force. A notification will describe relevant risks, protective steps and contact information as required; this policy does not promise an unsupported fixed incident-notification deadline.

12. Your rights, choices and requests

Depending on applicable law and the provisions in force, rights can include access to a summary of your data and processing, correction and completion, erasure, withdrawal of consent, grievance redressal and nomination of another person to exercise rights upon death or incapacity. Any additional jurisdiction-specific right, such as portability, applies only where the relevant law provides it.

India’s DPDP Act and Rules have phased commencement. This notice does not represent every provision as already enforceable on its revision date. We will handle requests under applicable law and the commitments we make here. The official DPDP Rules, 2025 describe phased implementation; applicable commencement notifications and later amendments also need to be considered.

Email grievance@lumiowl.com with subject “Privacy request” or “Delete my account”, or ask your Institution to help. State the request, Institution, relevant account email and whether you act for a child or another person.
We will verify identity and any representative authority proportionately. Do not send a full identity document unless specifically requested through a secure method. If you no longer control your account email, contact us to arrange another verification route.
For institutional records, we may involve the responsible Institution and coordinate the response. Institution approval is not a blanket veto over your legal rights. We may redact other people’s information or explain a legally justified limitation.
We aim to acknowledge grievances within 48 hours and respond or resolve them within 30 days. A deletion operation may take the separately stated target period. Where a binding deadline differs, it takes priority; we will explain any permitted extension or unresolved limitation.

If unresolved, you may use the applicable statutory complaint mechanism, including the Data Protection Board of India where available and applicable, following any required prior grievance steps. You may also nominate a person where the relevant law permits; contact us to establish the required record and verification process.

Profile editing can correct some fields; academic, financial or employment changes may need Institution review. If there is a custody dispute, mistaken email match, duplicate profile, deceased account holder or disputed record, explain that context so we can verify authority without exposing another person’s data.

13. Changes and governing law

We will identify published revisions by date and version and give appropriate advance notice of material changes through the app, email or another suitable channel. Where a new purpose requires consent, we will seek it rather than infer it from continued use. Earlier processing remains subject to the applicable notice, lawful basis and legal obligations.

Indian law governs this policy. Subject to mandatory statutory rights and the jurisdiction of competent authorities, disputes may be brought before competent courts at Bengaluru, Karnataka. This clause does not remove a right to approach a regulator or another forum that applicable law makes available.

14. Contact and Grievance Officer

Lumiowl Private Limited
Grievance Officer: Karthik S S, Co-founder
Privacy and grievances: grievance@lumiowl.com
General enquiries: info@lumiowl.com
Website: lumiowl.com
Registered office: No. 107, First Floor, Jai Grand Apartments, 2nd Cross, Devasandra, Bangalore North, Bengaluru 560036, Karnataka, India
CIN: U62010KA2026PTC228076

For school-specific corrections, also contact your Institution’s authorised administrator. Contact us if you need this notice or the request process in an accessible format or an applicable language.

SchoolApp.One · Lumiowl Private Limited · Privacy policy, version 2026-10-19.