Privacy Policy

1. Who we are and what this policy covers

StarLightERP is a multi-tenant, cloud-hosted Enterprise Resource Planning platform operated by StarLight Enterprise, a company based in India ("StarLight Enterprise", "we", "us", "our"). Our public website and application are available at https://starlighterp.com.

This Privacy Policy explains how we handle personal data when you:

• use the StarLightERP web application, including any business package your organisation has subscribed to;
• visit our public website, or a public job posting published on the careers portal for one of our customers;
• open a public payment link page issued from the platform;
• connect a third-party service to the platform, such as a Google Gmail, Microsoft 365 or IMAP mailbox;
• contact us for support, sales or a privacy request.

The platform is organised into business packages. The packages available today are core (platform services, users, mail, payments, imports, background jobs and help), finance (general ledger, accounts payable and receivable, contract accounting and billing), sales and distribution, product administration (including inventory and pricing), controlling, plant maintenance, human resources (including recruitment, time and attendance, and payroll data), cross (workflow approvals) and education. What personal data exists in a given account depends on the packages your organisation uses and on the data it chooses to load.

We process personal data in accordance with the Information Technology Act, 2000 and the rules made under it, and the Digital Personal Data Protection Act, 2023 (the "DPDP Act"). This policy is governed by, and will be interpreted under, the laws of India.

Where your organisation subscribes to StarLightERP under an agreement with us, that agreement and any data processing terms in it govern the commercial and processing arrangements between your organisation and us. As between your organisation and us, that agreement prevails over this policy to the extent of any conflict.

That agreement does not, and cannot, reduce the rights you have as an individual under the DPDP Act or any other applicable law.

If you do not agree with this policy, please do not use the platform.

This policy is published in English. You may ask us to give you its contents in any language specified in the Eighth Schedule to the Constitution of India. Write to support@starlighterp.com and tell us which language you want, and we will provide it.

2. Our role: when we are a data fiduciary and when we are a processor

We wear two hats, and it matters which one applies to you.

We act as a data processor for tenant business data. Each customer organisation that subscribes to StarLightERP gets its own isolated tenant database. The personal data your organisation enters, imports or generates in that tenant, for example records about employees, students, parents and guardians, customers, vendors and job candidates, belongs to your organisation. Your organisation is the data fiduciary (in other laws, the controller) and decides why and how that data is used. We process it as a data processor, on your organisation's documented instructions, to provide the service and to support it.

There is one narrow exception. Where Indian law requires us to retain or disclose data, for example to answer a lawful order or to keep tax and accounting records, we act on our own account and are the data fiduciary for that limited activity. We will tell our customer about any such requirement unless the law prevents us from doing so. Apart from that, we do not decide the purposes of processing tenant business data and we do not use it for our own purposes.

We act as a data fiduciary for our own data. For the data we need to run our business we determine the purposes ourselves and we are the data fiduciary. This covers account and login data for the users we register, subscription and billing records, invoices and payment status, support tickets and correspondence, and technical logs from the website and application.

If your data was uploaded by a school, an employer or another organisation, please contact that organisation first. As a processor we usually cannot verify your identity, judge the correctness of a record, or delete or change data inside a customer tenant without that customer's instruction. If you write to us at support@starlighterp.com we will acknowledge you, tell you which customer holds the data where we can lawfully do so, and forward or assist with your request. We will also help our customer respond to you, as required by our contract with them and by law.

3. Information we collect

We collect the following categories of information.

• Account and identity data. The username, password (stored only as a hash), display name, e-mail address, contact number, preferred language, profile photograph where uploaded, the tenants you may access, and your roles and permissions. Users may belong to several tenants and choose one after signing in.

• Tenant business data entered or imported by our customer. Whatever our customer loads into its tenant. This commonly includes employee and payroll-related records, time and attendance records, job candidate records including CVs and offer details, customer and vendor master records, contact persons, and, in the education package, records about students and their parents or guardians such as admission and enrolment details, attendance, examination marks, fee assessments and payments, supporting documents and photographs. Students are frequently minors. This data is supplied by our customer, not by us.

• Billing and subscription data. The packages and bundle subscribed, billing cycle (monthly, quarterly, half-yearly or annual), proration and invoice records, tax identifiers where Indian GST applies, payment status, and payment references returned by the payment gateway. We do not receive or store full card numbers, CVV codes or net-banking credentials.

• Mailbox content from a connected mailbox. Where a user connects a mailbox, the message headers, addresses, subject, body, attachments, folder or label information and read status that are needed to show and use that mailbox inside the platform, together with the links a user creates between a message and a business record.

• Technical and usage data. IP address, browser and device information, request and error logs, session and sign-in timestamps, background job execution records, and the audit information stored on business records showing who created or changed a record and when, plus audit trails on sensitive changes.

• Support communications. The messages, screenshots and diagnostic details you send us when you ask for help, and our replies.

• Uploaded files and scanned documents. Files, images, scans and attachments uploaded to a tenant, including documents processed by the optical character recognition and document understanding features.

4. How and why we use information

We use personal data for these purposes.

• To provide and operate the platform: create and maintain tenants and user accounts, authenticate you, apply role and package based access control, and let you select your tenant.
• To process and reconcile business transactions, such as invoices, receipts, payments, payouts and recurring mandates.
• To deliver notifications you or your organisation configure, including e-mail, in-app messages and transactional SMS such as one-time passwords.
• To generate documents, reports, exports and analytics, and to run scheduled and background jobs such as billing runs, dunning, mailbox synchronisation and search indexing.
• To provide support and investigate faults. Where a request concerns a connected mailbox, our access is limited as described in the sections on Google user data.
• To keep the platform secure and reliable: detect, prevent and investigate abuse, unauthorised access, fraud and incidents, maintain audit trails and backups, and monitor performance using logs and aggregated statistics.
• To meet legal, tax, accounting and regulatory obligations, and to establish or defend legal claims.

Under the DPDP Act, personal data may be processed only with consent, or for one of the legitimate uses listed in Section 7. The Act has no separate ground of necessity for a contract. Our position is as follows.

• Consent. Where we are the data fiduciary, for example for account, subscription, billing and support data, we rely on your consent where consent is required.
• Voluntarily provided data (Section 7(a)). Where you give us your data for a specified purpose, such as contacting support, and have not objected, we process it for that purpose.
• Employment purposes (Section 7(i)). Where our customer processes employee data for employment purposes, or to safeguard itself from loss or liability, that use belongs to our customer as employer.
• Legal obligations (Sections 7(d) and 7(e)). We process where Indian law obliges us to disclose information to the State, or to comply with a judgment, decree or order.
• Where our customer is the data fiduciary, the basis it relies on under the Act, on whose instructions we process the data.

For data in a tenant, establishing consent or a legitimate use is our customer's responsibility as data fiduciary. Our terms require it to do that and to notify the individuals concerned.

We do not sell personal data, and we never use it for advertising or marketing profiles.

5. Google user data: scopes and the Limited Use requirements

If you connect a Google account to the Mail app, we ask Google only for the permissions that feature needs. We request these scopes:

• openid: to complete the Google sign-in and confirm which Google account is being connected.
• email: to read the e-mail address of that account, so the mailbox is identified correctly and mail is sent from the right address.
• https://www.googleapis.com/auth/gmail.modify: to load your messages into the in-app inbox, to send messages and replies from the ERP, to mark messages read or unread, to add or remove labels, to move a message to trash, and to link a message to a business record such as an invoice or a candidate.

This is the narrowest scope that supports the feature. The Mail app is a working mailbox, not a viewer, so a read-only scope would not allow sending, replying, labelling or filing. We do not request the full-access Gmail scope, which also permits permanent deletion of mail, and we request no Gmail settings scope, because the Mail app never changes your Gmail settings or filters.

Our commitments for data received from Google APIs are:

• We limit our use of Google user data to providing and improving the user-facing features that are prominent in the StarLightERP interface, namely the Mail app inbox, composing, replying and sending, labelling and filing, and the links between a message and a business record.
• We never sell Google user data, and we never transfer or sell it to advertising platforms, data brokers or information resellers.
• We transfer it to others only: to provide or improve those prominent features, and then only to the providers that host and operate the platform for us; for security purposes, such as investigating a bug or abuse; to comply with applicable law; or in a merger, acquisition or sale of assets, and then only with your prior explicit consent.
• We never use it for advertising of any kind.
• We do not transfer, sell or use it to create, train or improve any artificial intelligence or machine learning model, including generalised or non-personalised models.

The next section sets out who can read Google user data, where it is stored, how long we keep it, and how to disconnect or revoke access.

StarLightERP's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The policy is available at https://developers.google.com/terms/api-services-user-data-policy.

6. Google user data: access, storage, retention and revoking access

Gmail message content, metadata and attachments obtained through the API are stored on servers we operate, in a platform mail store, and in our routine backups. Every stored message is tagged to your organisation's tenant and to the mailbox it came from, and is readable only by users of that tenant who are entitled to that mailbox. We use it only to render your in-app mailbox and the links you create to business records. OAuth tokens are stored encrypted.

Access inside your organisation is controlled by role. Your in-app mailbox is visible to you, and a message you link to a business record becomes visible to colleagues authorised to see that record. Only link a message you are content for them to read. The commitments in this policy about people reading Google user data are about our own personnel.

Gmail content is never sent to any third-party artificial intelligence or large language model provider, and is never used to build an index or model that another tenant can query.

No one at StarLight Enterprise reads Google user data, unless: we have obtained and recorded your explicit agreement to view specific messages, files or other data; it is necessary for security purposes, for example investigating a bug or abuse; it is necessary to comply with applicable law or regulation; or the data, including anything derived from it, has been aggregated and anonymised and is used for our internal operations in accordance with applicable law. In ordinary support our personnel do not read your Gmail content. If a request cannot be resolved without looking at a specific message, we will ask you first, act only on the messages you agree to, and log that access.

You can disconnect a Google mailbox at any time from the Mail app. Disconnecting stops synchronisation at once and deletes the stored tokens. You can also revoke our access at https://myaccount.google.com/permissions. When you revoke access there, synchronisation stops and we delete the tokens as soon as we detect the revocation. Revoking access at Google does not by itself delete mail already synchronised.

Synchronised Gmail content stays available to your tenant until your organisation deletes it, until it is deleted on request, or until the tenant is deleted under this policy's retention rules. Write to support@starlighterp.com to have it deleted, and we will remove it from the live system within 30 days of verifying the request. Copies in backups are removed when those backups cycle out.

7. Microsoft 365 and IMAP mailbox connections

Microsoft 365 and Outlook. If you connect a Microsoft account, we use Microsoft Graph and request these scopes: openid, email, offline_access, User.Read, Mail.ReadWrite and Mail.Send.

• openid and email identify the account being connected and give us its e-mail address.
• User.Read reads the basic profile of the signed-in account, such as display name and e-mail address, so the mailbox is labelled correctly.
• offline_access allows the connection to keep working in the background without asking you to sign in again for every synchronisation.
• Mail.ReadWrite loads messages into the in-app inbox and lets you mark them read or unread, move them between folders, move them to deleted items, and link them to a business record.
• Mail.Send sends new messages and replies from within the ERP.

Generic IMAP and SMTP. If you connect a mailbox by IMAP and SMTP, you supply the server host names, ports, security settings, user name and password. We use them only to read the folders of that mailbox into the in-app inbox and to send mail on your instruction.

For all mailbox connections:

• Access is limited to the single mailbox you connect. We do not use a mailbox connection to reach other accounts, other tenants or the wider directory of your organisation.
• Tokens and mailbox passwords are stored encrypted and are used only to operate that connection.
• Message content is stored on servers we operate, in a platform mail store. Each message is tagged to the tenant and the mailbox it belongs to, and is visible only to users of that tenant who are entitled to that mailbox. It is used only to render the in-app mailbox and the links to business records.
• Mailbox content is never sold, never used for advertising, and never used to create, train or improve any artificial intelligence or machine learning model.

You can disconnect a mailbox at any time from the Mail app, which stops synchronisation and deletes the stored credentials or tokens. For Microsoft accounts you can also revoke our access from your Microsoft account portal. For an IMAP mailbox, change the mailbox password on your mail server. To have already-synchronised mail deleted from the platform mail store, write to support@starlighterp.com.

8. Service providers and other recipients

We do not sell personal data and we do not share it for advertising. We share it only where it is needed to run the service, and only with the following categories of recipient.

• Hosting and infrastructure providers, who supply the servers, storage, networking and backup capacity on which the platform runs.
• Our payment gateway. Card, UPI and net-banking payments and recurring UPI auto-pay mandates are processed by Razorpay, and payouts are made through RazorpayX. Payment credentials are submitted directly to the gateway, which handles them under its own privacy policy. We receive only the transaction reference, status and the limited details needed to reconcile the payment.
• Our SMS gateway provider, which delivers transactional SMS such as one-time passwords. It receives the mobile number and the message content.
• The mail providers that a user chooses to connect, namely Google, Microsoft or the mail server behind a generic IMAP and SMTP mailbox. Those providers already hold the mailbox concerned and act under their own terms.
• A public-web search provider used by the recruitment sourcing feature to surface publicly available candidate profiles. It receives only the recruiter's search terms.

Each provider we engage is bound by contract to keep the data confidential, to apply appropriate security measures, to process it only on our instructions and for the purpose we engaged it for, and to return or delete it when the engagement ends.

We may also disclose personal data:

• where disclosure is required by law, by a court order, or by a lawful request from a government or regulatory authority;
• where it is necessary to enforce our terms, to investigate suspected fraud or abuse, or to establish, exercise or defend legal claims; and
• in connection with a merger, acquisition, financing or sale of all or part of our business. In that case we will require the recipient by contract to handle the transferred data on terms no less protective than this policy, and we will tell affected customers in the application or by e-mail before the transfer takes effect. Data obtained from a connected Google mailbox is not included in such a transfer unless we first obtain the explicit consent of the user who connected that mailbox, as the Google API Services User Data Policy requires. Content from a connected Microsoft or IMAP mailbox is treated in the same way. For information received from Google APIs, the sections on Google user data prevail over this bullet.

9. Artificial intelligence features

StarLightERP includes optional features that use artificial intelligence: optical character recognition on scanned documents, document understanding and field extraction, speech-to-text, translation, and retrieval-augmented search over records and documents inside your tenant.

These features run on infrastructure that we host and operate ourselves. Your documents, records, images, audio and search queries are processed on our own servers.

• We do not send customer content to any third-party large language model provider or to any external artificial intelligence service.
• We do not use customer content to create, train, fine-tune or improve models that are made available to other customers or to anyone outside your tenant.
• Content processed by these features is held in your organisation's tenant database and in the per-tenant file storage on our servers, subject to the same access control, audit trails and retention rules as the rest of your data. The processing itself is carried out by inference services that we run ourselves, and the content is not made available to another tenant.
• Search indexes built for retrieval-augmented search are built per tenant and are queried only within that tenant.
• Where one of these features is run on mail from a connected mailbox, the additional limits in the sections on Google user data also apply.

Artificial intelligence output can be wrong or incomplete. Extracted fields, transcriptions, translations and search answers are suggestions that should be reviewed by a person before they are relied on. Where a feature proposes a change to a business record, the change is applied only after a user confirms it, and the resulting change is recorded in the audit information on that record.

10. Cookies, local storage and similar technologies

We use strictly necessary technologies only. We do not use advertising or analytics cookies of any kind, we do not use any cross-site tracking technology, and we do not allow third parties to place tracking cookies through the application.

What we set:

• An authentication cookie. When you sign in, we set a session and refresh-token cookie. It is marked httpOnly, so it cannot be read by scripts in your browser, and it is transmitted over an encrypted connection. Its only purpose is to keep you signed in and to let you move between screens and between the tenants you are entitled to access without signing in again. It is cleared when you sign out and it expires after a limited period.
• Browser local storage for preferences. We store your chosen interface language and screen preferences, such as saved table layouts, visible columns and similar display settings. These items stay in your browser and are used only to render the interface the way you left it.

If you block or delete the authentication cookie, you will not be able to sign in or stay signed in, and the application will not work. If you clear local storage, the application will still work but your language choice and screen preferences will be reset to their defaults.

You can manage cookies and local storage through your browser settings.

11. Data retention

How long we keep tenant business data is driven by our customer's subscription.

• While a subscription is live, we keep the data in the tenant for as long as our customer keeps it there. Our customer controls creation, correction and deletion of records inside its own tenant.
• After a subscription ends or is terminated, we keep the tenant in a suspended state for a wind-down period of [WIND-DOWN PERIOD] so that our customer can export its data or reactivate the service. After that period, the tenant data is deleted or irreversibly anonymised, unless our customer has asked in writing for a longer retrieval window or the law requires us to keep it.
• Where our customer instructs us to delete specific data earlier, we act on that instruction.

Other retention rules:

• Technical logs, error logs and security logs are kept for a limited period, ordinarily not more than 90 days, and are then deleted or reduced to aggregated statistics that do not identify anyone. Logs kept for an open security investigation are retained until it closes.
• Billing, invoicing, tax and accounting records are kept for the periods Indian law requires. Books of account are kept for eight financial years under the Companies Act, 2013. Records required under the goods and services tax law are kept for seventy-two months from the due date of the annual return for the year concerned. These periods run past the wind-down period above. We keep those records for that purpose only, and we do not use them for anything else.
• Support correspondence is kept for as long as needed to handle the request and to evidence what was done.
• Account records for users who no longer have access are deactivated rather than kept active, and are deleted or anonymised together with the tenant they belong to.
• Mailbox credentials and OAuth access and refresh tokens are deleted immediately when a mailbox is disconnected. Mail already synchronised into the platform mail store follows the tenant retention rules above, or is deleted earlier on request.

Backups are kept on a rolling cycle and are overwritten in the ordinary course. Data deleted from the live system may persist in a backup until that backup is cycled out, which happens within 35 days, and it is not restored into the live system except as part of a disaster recovery.

12. How we protect information

We apply technical and organisational measures appropriate to the data we handle.

• Encryption in transit. Traffic between your browser and the platform, and between the platform and the services it connects to, is protected with TLS.
• Tenant isolation. Each customer organisation has its own separate database, and business data from one tenant is not reachable from another. A small number of platform-level services, such as the mail store that serves connected mailboxes, hold records for more than one tenant in a single store. There, every record carries its tenant and every read and write is scoped to it by the backend.
• Password protection. Passwords are stored only as salted hashes. We cannot read them and will never ask you for your password.
• Encrypted credentials. OAuth tokens, mailbox passwords and integration keys are stored encrypted.
• Access control. Access to functions and data is granted by role and by the packages a tenant has subscribed to. A user sees only the tenants and functions assigned to them.
• Audit trails. Business records carry who created and last changed them and when, and sensitive changes are recorded in audit trails.
• Restricted administrative access. Staff access to production systems is limited to those who need it, granted on a least-privilege basis, subject to confidentiality, and logged.
• Backups and monitoring. We take regular backups and monitor availability, errors and suspicious activity.

No method of transmission over the internet or of electronic storage is completely secure. Keep your password confidential, do not share accounts, and tell us at once at support@starlighterp.com if you believe an account has been compromised.

If a personal data breach occurs in data for which we are the data fiduciary, we will intimate each affected individual without delay, describing the nature and extent of the breach, when it occurred, its likely consequences, what we have done and the steps you can take to protect yourself. We will also intimate the Data Protection Board of India without delay, and give the Board the detailed information it requires within 72 hours of our becoming aware of the breach.

Where we act as a data processor, we will notify our customer without delay so that it can meet its own duties, and we will assist it.

We will also report incidents to the Indian Computer Emergency Response Team where the Information Technology Act, 2000 and the directions under it require, within the timelines set.

13. Where data is stored and transferred

Personal data in StarLightERP is stored on infrastructure operated for StarLight Enterprise. Our primary hosting location is India.

Data may also be processed in any country in which a provider named or described in this policy operates. In practice this can involve:

• the hosting and infrastructure provider that runs our servers, storage and backups;
• the payment gateway that processes payments and payouts, which stores payment system data in India as the Reserve Bank of India requires;
• the SMS gateway that delivers transactional messages;
• the mail provider behind a mailbox that a user chooses to connect, which already holds that mailbox; and
• the public-web search provider used by the recruitment sourcing feature.

Where personal data is transferred outside India, we transfer it only to countries that are not restricted for such transfers under the DPDP Act and the notifications issued under it, and we stop transfers to a country if it becomes restricted.

Some Indian laws impose stricter limits than the DPDP Act on where particular categories of data may be held, and those limits continue to apply. Section 16(2) of the DPDP Act preserves them. In particular, payment system data is handled by our payment gateway in accordance with Reserve Bank of India requirements, which require such data to be stored in India. We do not hold full card numbers, CVV codes or bank credentials in any location.

We use appropriate safeguards for every transfer. Each recipient is engaged under a written contract that requires confidentiality, appropriate security measures, processing only on our documented instructions and only for the agreed purpose, restrictions on onward transfers, assistance with data principal requests and breach notification, and return or deletion of the data when the engagement ends.

If you would like more detail about where data relating to your organisation is hosted, write to support@starlighterp.com.

14. Children and student data

The education package is bought by schools, academies and similar institutions. The institution uses it to run admissions, enrolment, attendance, examinations, fees and related records.

A school using the education package may enter data about students, who are frequently minors, and about their parents or guardians. That data is entered by the school, on the school's decision, into the school's own isolated tenant. The school is the data fiduciary for it. We act only as a processor, on the school's instructions.

Under the DPDP Act, a child is an individual who has not completed eighteen years of age. The duties described below apply to every student below that age, whatever the class or programme, and to any student who is a person with disability and has a lawful guardian. A school should establish which of its students are children before entering their data, because the requirement for verifiable parental consent turns on that.

• The school is responsible for giving notice to parents and guardians and for obtaining verifiable consent from the parent or lawful guardian of a child, and from the lawful guardian of a person with disability, as required by the DPDP Act, before that data is entered or processed. Our subscription terms require the school to obtain and maintain those consents.
• We do not knowingly collect personal data directly from a child through any public page. Our public pages are the website, job postings on the careers portal and payment link pages, and they are not directed at children. If we learn that a child has submitted personal data to us directly through a public page, we will delete it.
• We do not use children's data for tracking, for behavioural monitoring, or for targeted advertising. We run no advertising on the platform at all.
• Access to student records inside a tenant is controlled by the school through roles and permissions, and changes to sensitive records are recorded in audit trails.

If you are a parent or lawful guardian and you want to see, correct or delete data about your child, please contact the school first. The school holds the records and can verify your relationship to the child. If you write to us at support@starlighterp.com, we will acknowledge your request, pass it to the school where we can lawfully identify the relevant tenant, and support the school in acting on it. We will act on your request directly only where the school instructs us to do so or where the law requires it.

15. Your rights and how to exercise them

Subject to the conditions in the DPDP Act, you have the following rights.

• Access. Obtain a summary of the personal data we process about you, the processing activities involved, and the identities of other data fiduciaries and processors it has been shared with.
• Correction. Have inaccurate or misleading data corrected, and incomplete data completed or updated.
• Erasure. Have your data erased where it is no longer needed for the purpose it was collected for and no law requires it to be kept.
• Grievance redressal. Use the grievance channel below before approaching the Data Protection Board of India.
• Nomination. Nominate someone to exercise your rights on your behalf if you die or become incapable.
• Withdrawal of consent. Where processing rests on your consent, you may withdraw it at any time, and withdrawing is as easy as giving it. Use the setting in the application where you gave it, or write to us. Withdrawal does not affect earlier processing, and a feature or the account may no longer be available.
• Consent Manager. The Act lets you manage and withdraw consent through a Consent Manager registered with the Board. We do not currently operate through one, and will say so here if that changes.

Where you withdraw consent, or once the purpose we hold your data for is no longer served, we will erase it and have our processors do the same, without waiting for a request, unless a law requires us to keep it.

How to exercise a right:

• For data held inside a customer tenant, contact the organisation that holds it: your school, your employer or the business you deal with. It is the data fiduciary, and we will forward any request you send us where we can lawfully identify the tenant.
• For your StarLightERP account, subscription, billing or support data, write to support@starlighterp.com.

We acknowledge requests within 7 working days and resolve them within one month of receipt. We may ask for information to verify your identity first, so we do not disclose or change data on the word of the wrong person. We may decline or limit a request where the law allows it, and will explain why.

This policy is written for the DPDP Act and other Indian law, and StarLightERP is offered on that basis. Where our customer is subject to another country's privacy law, it is responsible for its own obligations under that law, and as its processor we will reasonably assist it. We do not undertake to grant rights under a foreign law directly to individuals.

16. Public pages: careers portal and payment links

Careers portal. Where a customer uses the human resources package, its job postings can be published on a public careers page. That page is publicly accessible and can be indexed by search engines. Do not put anything in a posting or an application that you do not want to be seen by the hiring organisation.

When you apply for a job you may submit your name, e-mail address, telephone number, CV or resume, and any other details the posting asks for. Later, an offer and your acceptance of it may also be recorded.

• The application goes into the tenant of the organisation that published the posting. That organisation is the data fiduciary for it and decides how long to keep it and who inside the organisation can see it.
• We process the application on that organisation's behalf. We do not use it for our own purposes, share it with other customers, or sell it.
• The recruitment sourcing feature lets a recruiter search for candidate profiles that are publicly available on the web, through a search provider. The provider receives only the search terms the recruiter submits.
• Where a recruiter saves a sourced profile into a tenant, that copy becomes part of that organisation's records and that organisation is the data fiduciary for it. Your rights over that copy are unaffected. You may ask that organisation to correct or delete it, or write to support@starlighterp.com and we will pass the request on.
• We do not treat a profile as outside the DPDP Act merely because it appears on a public page. The Act stops applying only where you made the data public yourself, or where another person was required by law to make it public.
• We cannot remove a profile from the website that publishes it. That has to be taken up with that website.
• To access, correct or delete your application, contact the organisation you applied to. Write to support@starlighterp.com if you need help reaching them.

Payment link pages. A payment link page collects only what is needed to complete that transaction, such as the reference of the invoice or bill being paid, the payer name and contact details where the merchant requires them, and the amount. Card details, UPI identifiers, net-banking credentials and UPI auto-pay mandate authorisation are entered on the payment gateway and go directly to the gateway. We do not receive or store full card numbers, CVV codes or bank credentials. We receive only the reference and status needed to mark the invoice or bill as paid in the merchant's tenant.

17. Changes to this policy

We may update this policy from time to time, for example when we add a feature, engage a new category of service provider, or when the law changes.

The current version is always published at https://starlighterp.com. When we make a change, we update the effective date shown at the top of the policy.

Where a change is material, for example a new purpose of processing, a new category of recipient, a change in how long we keep data, or a change to how a connected mailbox is handled, we will give notice before it takes effect. Notice will be given in the application, by e-mail to the administrative contact of the customer organisation, or both.

We encourage you to review this page from time to time. Your continued use of the platform after a change takes effect means that you have read the updated policy. Where a change requires your consent under the DPDP Act, we will ask for it separately, and we will not rely on continued use as consent.

18. Contact us and grievance redressal

For any question, concern or request about this policy or about how we handle personal data, write to us at support@starlighterp.com.

We have appointed a Grievance Officer under the Information Technology Act, 2000 and the DPDP Act.

• Grievance Officer: Upendra Verma
• E-mail: support@starlighterp.com
• Address: StarLight Enterprise, 70, Avadh Vihar, Near Sector 14 Old Power House, Indira Nagar, Lucknow, Uttar Pradesh 226015, India

To help us act quickly, please include your name, the e-mail address or username you use with StarLightERP, the name of the organisation or school whose records your request concerns, and a clear description of what you are asking for.

We will acknowledge your grievance within 7 working days of receiving it. We will redress it within one month of receipt, as required by the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, and within the period required by the DPDP Act and the rules under it.

If a matter is complex, or if we must consult the customer organisation that holds the data, we will keep you informed of progress and will still respond within that one month period, either with the outcome or with the position reached and the reason for it. We may ask you for information to verify your identity before we act.

If your request concerns data that a school, employer or other customer organisation loaded into its own tenant, please raise it with that organisation first, because it is the data fiduciary. We will assist and will forward your request where we can lawfully identify the tenant concerned.

If you are not satisfied with our response, or if we do not respond within the period above, you may complain to the Data Protection Board of India in the manner prescribed under the Digital Personal Data Protection Act, 2023.