Privacy Policy — IdeaScore

This Privacy Policy explains how IdeaScore handles personal data: what we collect, why, who we share it with, how long we keep it, and the rights you have. It is published at /legal/privacy and forms part of our Terms of Service.

1. Who We Are

IdeaScore is offered by CMS Group, a sole proprietorship of Chaudhary Shivam Panwar, GSTIN 05EKTPP4834G1ZO, with its principal place of business at 01, Teachers Colony, Sahaspur, Dehradun, Uttarakhand 248197, India ("IdeaScore", "we", "us", "our").

Privacy questions and requests: privacy@ideascore.online
Grievance Officer: Dibyendu Ganguly, grievance@ideascore.online, +91 89173 60065 (see section 15 and the Grievance Officer page)

2. Definitions

In this policy:

"Applicable Data Protection Law" means every law on the protection of personal data that applies to the processing in question, including the Digital Personal Data Protection Act, 2023 ("DPDP Act") and the rules made under it, as amended and notified from time to time ("DPDP Rules"); the Information Technology Act, 2000 and the rules made under it; and, where they apply, the EU General Data Protection Regulation 2016/679 ("GDPR"), the GDPR as it forms part of UK law ("UK GDPR") and the UK Data Protection Act 2018.
"Customer" means an organisation (for example a university, incubator, accelerator, foundation or company) that has an account with us and runs programmes on the Service.
"Customer Data" means the personal data and other content that a Customer, its Users or its applicants put into the Service, or that the Service generates for a Customer, in the course of running the Customer's programmes.
"Personal data" means any data about an individual who is identifiable by or in relation to that data. Under the DPDP Act the individual is the "Data Principal"; under the GDPR, the "data subject". We use "you" for that individual.
"Data Fiduciary" (DPDP Act) or "controller" (GDPR) means the person who decides why and how personal data is processed. "Data Processor" (DPDP Act) or "processor" (GDPR) means a person who processes personal data on a fiduciary's or controller's behalf.
"Service" means the IdeaScore web application (including https://app.ideascore.online and any organisation's own hostname that points to it), the public demo at https://try.ideascore.online, the IdeaScore API, our integrations, and our website at https://ideascore.online.
"IdeaScore AI" means the artificial-intelligence features of the Service, described in our AI Use Statement.
"User" means a person who signs in to the Service on a Customer's behalf: owners, administrators, programme staff, evaluators, jurors, mentors and others the Customer invites.
"Applicant" means a person who applies to, or takes part in, a Customer's programme (for example a founder, student, team member or researcher), whether or not they sign in.

3. Our Two Roles

The law treats us differently depending on whose data it is and why we hold it.

3.1 When we act for a Customer (Data Processor / processor). Applications, evaluations, scores, decisions, programme content, Applicants' details, Users' work inside a Customer's organisation, and everything else in a Customer's organisation is Customer Data. The Customer decides why and how that data is processed; we process it only on the Customer's documented instructions, under our Data Processing Agreement. For Customer Data, the Customer is the Data Fiduciary (controller) and we are its Data Processor (processor).

If you applied to a programme, were invited to evaluate one, wrote a reference for an Applicant, or are the contact for an organisation that applied, the organisation that runs the programme is responsible for your data. Its own privacy notice applies, and requests about your data should go to it first. If you contact us instead, we will pass your request to the Customer without delay and help the Customer answer it (see section 9.4).

3.2 When we act for ourselves (Data Fiduciary / controller). We decide why and how we process:

account and contact details of the people who sign up for, buy, or administer a subscription (for example an organisation's owner or billing contact);
billing, payment and tax records;
security records we keep to protect the Service as a whole (for example sign-in history, abuse and fraud signals, and error reports);
support conversations with us;
enquiries, trial requests and correspondence sent to us; and
visits to our website and public pages.

For this data we are the Data Fiduciary (controller), and this policy is our notice to you under section 5 of the DPDP Act and Articles 13 and 14 of the GDPR.

4. What We Collect

4.1 Data you or your organisation give us

Category	Examples	Whose data
Account details	Name, email address, role, organisation, profile photo (optional), password (stored only as a one-way bcrypt hash), language and display preferences	Users
Two-step sign-in	Authenticator secret (encrypted at rest when configured) and recovery codes (stored only as hashes)	Users who turn it on
Application content	Answers to the Customer's application form (for example names, contact details, team members, institution, idea or project descriptions, financial or traction information the form asks for), uploaded files such as pitch decks, links such as pitch videos; for a conference, the authors and co-authors (names, affiliations, email addresses, ORCID iD), the presenting author and their biography, and the conflicts of interest the authors declare, which reviewers do not see; on an award nomination, the nominator's, nominee's and endorser's details, of which the jury does not see the nominator's name, contact details or answers about themselves, or any email address or phone number on the nomination	Applicants, and the people they name (Customer Data)
References	When a Customer's programme asks for references, the Applicant gives each referee's name, email address and role, and the Service emails the referee a single-use link that expires after 21 days. The referee's answers, letter and declaration (or the fact that the referee declined) are kept with the application. The Applicant sees only whether a reference has arrived, never what it says. The Customer's owners and administrators, and the people it allows to check eligibility, read it in full; evaluators assigned to the application, and staff who can read every evaluation, read it with the Applicant's and the referee's names and contact details removed. Whoever asks IdeaScore AI to summarise the references, IdeaScore AI receives them with those names and contact details removed. References are deleted on the same schedule as answers marked as sensitive (see "How long they are kept" below), or sooner when the Customer deletes the sensitive answers of everyone not given an award; the request's status and dates are kept without the referee's details, and the emails sent to the referee are redacted at the same time.	Referees and Applicants (Customer Data)
Applying organisations	When an organisation applies to a Customer's programme (for example an implementing agency applying to a company's CSR programme): its name, type and year of registration, its registration numbers (for example CSR-1, 12A and 80G), a contact person's name, email address and phone number, the project and its budget, and documents such as its registration acknowledgement, audited accounts and earlier utilisation certificates, which may name its trustees, directors, auditors or signatories. If the project goes ahead: instalment plans, records of each release with a payment reference (no bank account details), utilisation certificates and impact reports.	Contact persons, and people named in the documents (Customer Data)
Evaluation content	Scores, comments, rubric answers, conflict-of-interest declarations, decisions, letters, notes, interview and pitch-day schedules, mentoring records, honorarium records (amounts and payment references; no bank details)	Users and Applicants (Customer Data)
Communications	Emails the Service sends for a Customer (recipient, subject and body), announcements, support tickets and replies	Users, Applicants
Billing details	Billing contact, organisation name, billing address, GSTIN or other tax identifier, orders, invoices, payment status	Customer contacts
Enquiries	Name, email, organisation and message in a trial request, contact form or email to us	Prospective customers

We do not ask for, and the Service is not designed to hold, card numbers, bank account numbers, government identity numbers or biometric data.

Landing pages and downloads are written and uploaded by the Customer, who is responsible for them. Images uploaded for a landing page are re-encoded and their embedded metadata (such as camera location) is removed.

Sensitive answers. A Customer's form may ask for information that the law treats as sensitive or as a special category of personal data, such as family income, category or caste, disability or health (for example in a scholarship, to check eligibility), and for the certificates that prove it. The Customer decides whether to ask for it and why. It is Customer Data, the Customer is the Data Fiduciary (controller) for it, and the Customer is responsible for having a lawful basis for it and for telling Applicants (section 5.1). Where a question is marked as sensitive in the Service, the Service protects the answers as follows. The scholarship template marks its income, category and disability questions, and the certificates for them, in this way, and the Customer can mark any other question it adds to its own form with the "Sensitive" switch in the form builder.

Who sees them. Only the Customer's owners and administrators, the people the Customer allows to check eligibility for that programme, and the Applicant who gave them (on a team application, the lead Applicant, not the other members). They are not shown to evaluators who score applications, in blind review, in the committee's shortlist (except to the people who check eligibility), or in exports or live spreadsheet links made or last changed by anyone else, and they are not copied onto the team's record when an application is approved. A person with an open conflict of interest recorded against an Applicant cannot open that Applicant's certificates. The only exception is the Customer's owner, where nobody else without a conflict can check eligibility for that programme: the owner must confirm first, and each such opening is recorded in the audit log.
IdeaScore AI. They are left out of what IdeaScore AI receives when it scores or summarises applications, answers questions in chat or runs its other helpers. There is one exception: a person allowed to check eligibility may ask IdeaScore AI to explain which of the programme's published eligibility rules an application meets, and IdeaScore AI then receives only the answers those rules check, without the Applicant's name or contact details.
How long they are kept. For Applicants who receive an award, until 12 months after the award ends (the end of the scholarship year the Customer records, moved on by one year for each further year of a multi-year award). For everyone else, until 90 days after the results (the results date the Customer records, or the date the Customer confirms the awards). If the Customer has not recorded those dates, the periods run from the programme's end date instead (12 months for each year of the award, or 90 days); a programme with no end date counts from its form's closing date plus 12 months, or, failing that, from 24 months after the last activity on the programme's applications. On that basis, an application still waiting for a decision is kept until it is decided, but not beyond 24 months after the last activity on the programme's applications, or the date above if that is later; and nothing is deleted on that basis until 30 days after the Service first checked the programme's applications for deletion. Deletion is automatic. It removes the answers and every certificate uploaded for them, including certificates the Applicant replaced, and the references for the same application (which are never deleted before that 30-day period has passed). The Customer can delete them sooner: in a scholarship, for one Applicant, for everyone, or for everyone not given an award (which also deletes those Applicants' references), and in any programme with its tools for anonymising applications. A programme under a legal hold waits until the hold ends.

A question the Customer adds to its own form without that mark is handled as ordinary application content, and these protections do not apply to it. Only a person allowed to check eligibility can remove a question marked as sensitive from the form, or turn its mark off. A question removed from the form keeps these protections for the answers already given. When the mark is turned off, the answers in applications made before that keep these protections; answers in applications made after it are not covered by them.

Blind review of conference papers. In a conference the Customer reviews double-blind or single-blind (any review mode other than open), reviewers read the abstract and the other written answers with the authors' and co-authors' names, affiliations and contact details removed, and the manuscript as a copy in which the names and contact details of the programme's people, including the co-authors, are blacked out. The manuscript must be a file uploaded to the Service, not a link, and the link to supplementary material is not shown to reviewers. A manuscript that cannot be masked is kept from reviewers; it is never shown to them as uploaded. The authors are asked to remove their names and affiliations from the manuscript themselves, and these limits apply: an affiliation written in the manuscript is not masked, text inside images cannot be read, and other links written in the answers are not changed. The Customer's owners and programme administrators can see the paper as submitted, and so can people the Customer allows to read both every submission and every evaluation. People allowed to read every evaluation see the authors' details; people allowed to read every submission but not every evaluation see the paper as reviewers do.

4.2 Data collected automatically

Category	What and why
Sign-in history	Each sign-in to an existing account, successful or not (including a wrong password, a wrong two-step code and a sign-in refused while the account is locked): the time, the outcome, the method (for example password, Google or Microsoft, or two-step), the IP address and the browser's description of itself. It is kept to protect accounts and investigate misuse. The User sees their own history, and the Customer's owner can see each of its Users' histories, with the IP address shortened (for example `103.21.45.x`) and the browser summarised (for example "Chrome on Windows"); the full values stay on our servers. Attempts for an email address that has no account are not recorded here.
Audit log	Changes, sign-ins, exports and downloads inside an organisation, with who did it and when, the IP address, browser and device details, and a session and request identifier. Customers see the IP address masked more strongly (for example `103.21..`) and the device summarised; the session and request identifiers and the full browser details are not shown to them. Our own staff can read the full entries, for security investigations and support.
Sessions	A session identifier in a secure, http-only cookie, with the session's start, expiry, IP address and browser, so you can see and end your signed-in sessions. A User's session record is deleted when the User signs out or ends it, and expired sessions are cleared by routine clean-up.
Time zone	While a User is signed in to the Service, the app sends the time zone set in the User's browser (its standard name, for example `Asia/Kolkata`) once in each session, and we keep it on the User's account with the time it was recorded. It comes from the browser's own setting: we do not work it out from the IP address, and it shows only a broad region, not a location. It is used for the Customer's programmes: programme staff who can open a programme's settings see how many of its evaluators are in each time zone, as counts without names, so that deadlines and sessions suit them; a time zone is named only when at least three evaluators are in it, and smaller groups are shown as one combined number. No screen shows a particular User's time zone to the organisation's owner, other staff or our support staff, and it is left out of account lists and data exports. It is not recorded while our support staff use "View as". It is Customer Data (section 5.1), and Applicants' time zones are not recorded. A User can stop it being recorded at any time with "Share my time zone with programme staff" in Settings, under Preferences: turning it off removes the time zone we hold straight away, and no new one is kept until it is turned back on. To object in any other way, see section 9.4.
Error reports	When the app hits an error in your browser: the message, the page route (without its query string), the app version, the browser type and, if you are signed in, your user and organisation. Token-like values and obvious secrets are removed before storage.
Application-form analytics	When someone views a Customer's public application form or its landing page, the Service counts views, time on the page, how far down the page people scroll, clicks on its buttons and links, how quickly the page loads, starts, stages reached, questions touched and submissions, with a coarse device type, browser family, referring site and campaign tags. IP addresses are not stored. A visitor is counted by a hash of the IP address, browser and programme that is salted with a random value changed every day; the salt is deleted after two days and the hash after 30 days, after which only counts remain. If your browser sends Do Not Track or Global Privacy Control, you are counted without any visitor identifier; on a landing page such visits are counted at most three times a day per network address (for IPv6, per /64 network), using a tally held only in the Service's working memory for at most three days and never stored, and no load-time or time-on-page sample is kept for them.
Downloads	When someone downloads a file a Customer shares on its public page or applicant portal, the Service counts the download and the number of distinct people per day using a daily salted hash (as for application-form analytics) that is also keyed with a secret kept outside the database; it does not keep a list of who downloaded what. When a browser sends Do Not Track or Global Privacy Control, the download is counted without any visitor identifier, at most three times a day per network address (or signed-in applicant) and file, using a tally held only in the Service's working memory for that day and never stored. For signed-in applicants the Service remembers when they last opened the downloads list, so it can show what was added since.
Sign-in protection	To slow down password guessing, we keep short-lived counts of sign-in, two-step and password-reset attempts for each email address, network and browser, which are deleted automatically when the period they count ends. When a wrong password is entered, the account records a coded mark of the network it came from (never the IP address itself), kept with the account's count of failed sign-ins and cleared with it at the next successful sign-in, password reset or unlock. These marks let a temporary lock caused by wrong passwords still accept the right password from a network that sent none of them, or from a browser that has signed in to the account before, which the `iscore_device` cookie recognises (see the Cookie Notice). These counts also let the right password through from a network that has not tried that email recently when others have used up its attempts.
Bot check	When the Service's bot check is switched on, the forms to request a trial, to ask for a password-reset link, to submit an application, to save an application with an email address, to ask for a link to continue a saved application, and to ask for a public voting link show a check run by Cloudflare Turnstile, which acts as our sub-processor. To tell people from automated programs, Cloudflare reads signals from your browser and device (for example the browser's description of itself) and your IP address, under its own Turnstile privacy terms. When you send the form, we pass Cloudflare the result of the check and your IP address to confirm it, and Cloudflare tells us whether the check passed, for which form, on which site and when. We use that answer only to accept or refuse that request and do not store it. If the check cannot confirm you, the form is not sent and you can try again.
Server and network logs	Our hosting and network providers record requests (including IP addresses) for security and operations, for as long as their own services keep such logs. Email addresses are masked in our server logs and email bodies are never written to them.

We do not use advertising cookies, third-party analytics or tracking pixels. See the Cookie Notice.

4.3 Data from other sources

Google or Microsoft sign-in. If your organisation turns these on and you choose them, the provider tells us your account identifier and verified email address, which we use to match you to the account your organisation already created for you.
Your organisation. Users are usually added by their organisation's owner or administrator, who gives us your name, email and role.
Integrations your organisation connects. Data that arrives through the IdeaScore API, Zapier, Make or an import a Customer runs.
Payment providers. Razorpay or Stripe tell us whether a payment succeeded, failed or was refunded, with a payment reference. They do not give us full card or bank details.

5. Why We Use It, and Our Lawful Basis

5.1 Customer Data

We process Customer Data only to provide the Service to the Customer and as the Customer instructs: to collect and store applications, run evaluations and rounds, send the Customer's emails, generate reports, run IdeaScore AI when the Customer uses it, keep the Service secure, back it up, and give support the Customer asks for. The Customer is responsible for the lawful basis (under the DPDP Act, usually the Data Principal's consent or a legitimate use under section 7; under the GDPR, usually Article 6(1)(b), (e) or (f)) and for giving Applicants and Users its own notice.

We never use Customer Data to train artificial-intelligence models, to advertise, or to build profiles for any purpose of our own.

5.2 Data we control

Purpose	DPDP Act basis	GDPR basis (where it applies)
Creating and running the Customer's account, subscription and billing	Consent given when the account is created or the order is placed; legitimate use where you voluntarily provide the data for that purpose (section 7(a))	Contract (Art. 6(1)(b))
Invoicing, GST and accounting records	Consent given when the order is placed, and legitimate use under section 7(d) and (e) where the law requires us to disclose records to the State or a court orders it	Legal obligation (Art. 6(1)(c))
Security: sign-in history, audit records, rate limiting, abuse and fraud prevention, error reports	Legitimate use where permitted; otherwise consent, given when you use the Service; and compliance with law, including directions of CERT-In	Legitimate interests in keeping the Service and its users safe (Art. 6(1)(f)); legal obligation where it applies
Support	Consent, given when you contact us	Contract or legitimate interests
Answering enquiries and trial requests	Consent, given when you contact us	Steps before a contract (Art. 6(1)(b)) or legitimate interests
Telling Customers about changes to the Service, these terms or their account	Consent; legitimate use	Contract; legitimate interests
Marketing emails about IdeaScore	Consent, which you can withdraw at any time	Consent (Art. 6(1)(a)), or legitimate interests for existing business customers where the law allows
Complying with law, court orders and lawful requests from authorities	Legitimate use under section 7(d) (an obligation under law to disclose information to the State) and section 7(e) (compliance with a judgment, decree or order)	Legal obligation (Art. 6(1)(c))
Establishing, exercising or defending legal claims	As permitted by section 17 of the DPDP Act	Legitimate interests (Art. 6(1)(f))

Where we rely on consent, you can withdraw it as easily as you gave it, by writing to privacy@ideascore.online or using the setting in the Service. Withdrawal does not affect processing that already happened. If you withdraw consent needed to run an account, we may no longer be able to provide that part of the Service.

We do not make decisions about you that produce legal or similarly significant effects based solely on automated processing. IdeaScore AI's suggestions are reviewed by the Customer's people, who make the decisions (see section 11 and the AI Use Statement).

We share personal data only as follows:

Sub-processors that host, store, deliver or secure the Service for us, under written contracts that bind them to protect the data and use it only to provide their service. The current list, with what each one does and where, is at /legal/subprocessors.
The Customer you work with or applied to. A Customer's Users see Customer Data according to the roles the Customer sets.
Integrations a Customer chooses to connect, such as its own systems through the IdeaScore API or webhooks, Zapier, Make, or Slack and Microsoft Teams channels. The Customer decides what is sent; the receiving service's own terms then apply.
Payment providers (Razorpay in India, Stripe elsewhere), to take payments and handle refunds.
Professional advisers (for example lawyers, accountants and auditors) under a duty of confidentiality.
Authorities, when the law requires it, including a court order, a lawful direction under the Information Technology Act, 2000, or a request from CERT-In or the Data Protection Board of India. Where the law allows, we tell the Customer first.
A successor business, if IdeaScore is transferred, merged or restructured. The successor must keep to this policy or give you notice of any change.

We do not sell personal data, and we do not share it for cross-context behavioural advertising. See our statement.

7. International Transfers

We are based in India. The Service's data is stored in Mumbai, India (database) and the Asia-Pacific region (uploaded files and encrypted backups), and processed in Singapore (application) and Tokyo, Japan (email). Our network provider carries each request through the location nearest to the visitor, and some of our providers, including those for IdeaScore AI, payments, sign-in and our own mailbox, process data in other countries. Personal data is therefore transferred outside India. Each provider, what it does and where, is listed at /legal/subprocessors.

Under the DPDP Act, personal data may be transferred outside India except to a country or territory the Central Government restricts by notification under section 16. We will not transfer personal data to a restricted country or territory.
IdeaScore AI processes data outside India; no India-only processing is offered. The Service tells each Customer where IdeaScore AI processes applications, and an owner or administrator must accept processing outside India once before the first run.
Under the GDPR and UK GDPR, India does not have an adequacy decision. When personal data from the European Economic Area, the United Kingdom or Switzerland reaches us, we rely on the European Commission's Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), with the UK International Data Transfer Addendum and Swiss amendments where needed, as set out in our Data Processing Agreement. We also put appropriate safeguards in place with our sub-processors. You can ask for a copy of the relevant safeguards at privacy@ideascore.online.

8. How Long We Keep It

We keep personal data only as long as we need it for the purpose we collected it for, or as the law requires. Then we delete it or make it anonymous.

Data	How long
Customer Data	For the life of the Customer's subscription, subject to the Customer's own deletion and retention settings (for example automatic anonymisation of old programmes, and audit-log retention). After the subscription ends, as set out in section 12 of the Terms of Service.
Answers marked as sensitive (section 4.1)	For Applicants who receive an award, 12 months after the award ends; for everyone else, 90 days after the results. Without those dates, the periods run from the programme's end date, else its form's closing date plus 12 months, else 24 months after the last activity on its applications; on that basis an application still waiting for a decision is kept until it is decided (at the latest 24 months after the last activity on the programme's applications, or the usual date if later), and nothing is deleted until 30 days after the Service first checked the programme. Then deleted automatically, with the certificates uploaded for them. Sooner if the Customer deletes them. Longer while a legal hold applies.
References (section 4.1)	As for answers marked as sensitive for the same application, but never before 30 days after the Service first checked the programme; sooner if the Customer deletes the sensitive answers of everyone not given an award. The referee's name, email address, role, answers, letter and declaration are then deleted, and the emails sent to the referee are redacted; the request's status and dates are kept.
Application drafts saved on our servers (when an Applicant saves a form to finish later)	60 days after the last save; an expired draft can no longer be opened and is cleared by routine clean-up. Deleted sooner when the Applicant deletes it, or when the Applicant's data is deleted at their request, including copies saved under their email address from another browser.
Sign-in history	180 days after each sign-in, then deleted automatically; deleted sooner when the User's account is permanently removed.
Users' session records (with IP address and browser)	Until the User signs out or ends the session, or it expires (at most 30 days after it started); expired sessions are then cleared by routine clean-up.
Sign-in protection counts and network marks	Counts: deleted automatically when the period they count ends. Network marks: cleared at the next successful sign-in, password reset or unlock of the account.
Time zone recorded from a User's browser	Only the latest value and when it was recorded: it is replaced when the browser reports a different time zone, kept with the User's account, and deleted when the User turns off "Share my time zone with programme staff", when the account is deleted, or with the rest of the Customer Data.
Audit log	As long as the Customer keeps it. A Customer's owner can set an audit retention period of 12, 24 or 36 months, after which older entries are deleted automatically, except the entries of a programme under a legal hold, which are kept until the hold is released; otherwise it is kept for the life of the organisation and deleted with the rest of the Customer Data after the subscription ends.
IdeaScore AI chats	Deleted automatically 12 months after they were last used; Users can delete their own chats at any time.
Help assistant conversation log	180 days.
Log of emails sent by the Service	90 days in our operations log. A copy of messages sent to an Applicant may also be kept with the Customer's records until the Customer deletes or anonymises them.
Browser error reports	90 days after the error was last seen.
Form-analytics visitor hashes	30 days; daily salts two days; then only counts remain.
Landing-page visitor hashes	30 days; then only counts remain. Load-time and time-on-page samples (no identifier): 90 days.
Downloads visitor hashes	30 days; then only counts remain. Last-visit marker: until the programme is deleted or the applicant's data is erased.
Full organisation export files	Deleted 24 hours after they are built.
Applicant data-request copies	Available for download from the Applicant's portal for 14 days, then deleted.
Records of data requests and our answers	24 months after we answer; then the requester's name, email address and reason are removed and an anonymised record is kept (longer while a legal hold applies; see below).
Encrypted backups	Daily backups for about 30 days and monthly backups for about 12 months, then deleted. A storage rule deletes any copy older than 40 days (daily) or 400 days (monthly) even if our own clean-up fails.
Billing, invoices and tax records	For the period the law requires, including the Central Goods and Services Tax Act, 2017 and the Income-tax Act, 1961 (generally at least eight years).
Enquiries and support conversations	Up to three years after the last contact, unless they become part of a Customer's account records.

When you ask for a copy of your data or for its deletion, we keep a record of your request and our answer for 24 months after we answer it. After that we remove your name, email address and the reason you gave, and keep only an anonymised record of what was asked, the outcome, and who answered and when. A request linked to a programme under a legal hold is kept until the hold ends.

When data is deleted or anonymised in the live Service, copies inside backups are not changed; they disappear as those backups expire under the schedule above. We do not restore deleted data from a backup except to recover from an incident, and if we do, we re-apply deletions made since that backup.

Where the DPDP Rules or other law require a longer or shorter period for a class of data or logs, we follow the law.

9. Your Rights

9.1 Rights under the DPDP Act

As a Data Principal you have the right to:

access information about your personal data: a summary of the data we process and what we do with it, and the identities of the other Data Fiduciaries and Data Processors we have shared it with, with a description of what was shared (section 11);
correction, completion, updating and erasure of your personal data (section 12). We will erase data unless keeping it is necessary for the specified purpose or for compliance with law;
grievance redressal, through our Grievance Officer (section 13), before you approach the Data Protection Board of India;
nominate another person to exercise your rights if you die or become incapable (section 14); and
withdraw consent at any time, where we rely on consent (section 6(4)).

You can manage your consent directly with us, or, once Consent Managers registered with the Data Protection Board are available, through a Consent Manager of your choice. We will work with a registered Consent Manager when you use one.

The DPDP Act also sets out duties for Data Principals (section 15), including not to impersonate another person, not to suppress material information, and not to register false or frivolous grievances.

If the GDPR or UK GDPR applies, you also have the right to access, rectification, erasure, restriction of processing, data portability, and to object to processing based on legitimate interests (Articles 15 to 21), and the right not to be subject to a decision based solely on automated processing that significantly affects you (Article 22). You can complain to the supervisory authority where you live or work.

9.3 Other places

If you live elsewhere, you may have similar rights under your local law. Write to privacy@ideascore.online and we will help.

9.4 How to exercise your rights

If the data is Customer Data (for example your application, a reference you wrote for an Applicant, or your work as an evaluator for an organisation), the Customer is the Data Fiduciary. Contact the organisation first. Applicants can also ask for a copy of their data, or for it to be deleted, from their own applicant portal; the request goes to the organisation, which must answer it within 30 days. Records a programme must keep about a funded project, such as signed utilisation certificates, compliance documents, and report attachments or photos, stay with the project when the rest of an Applicant's data is deleted; such a file that came with the Applicant's application or from their applicant account is then stored under a neutral name ("Project document"), and its contents are kept as they are. If you write to us, we pass your request to the Customer and help it respond.
If we are the Data Fiduciary, email privacy@ideascore.online. We may ask you to confirm your identity, for example by replying from the email address on the account. We aim to respond within 30 days, and sooner where the DPDP Rules set a shorter period.

We do not charge for a request, unless it is manifestly unfounded or excessive and the law allows a reasonable fee.

10. Children's Data

The Service is a tool for organisations. It is not directed at children, and we do not knowingly collect children's data for our own purposes.

Some Customers run programmes for students, and some Applicants may be under 18 (a "child" under the DPDP Act) or under the age of digital consent in their country (16 under the GDPR unless a Member State sets a lower age, which may be no lower than 13). In those cases:

the Customer, as Data Fiduciary, must obtain verifiable consent from the child's parent or lawful guardian before the child's data is collected, in the manner the DPDP Rules require, and must not use the Service for any processing that is likely to cause a detrimental effect on a child's well-being;
the Customer must not use the Service to track or behaviourally monitor children or to target advertising at them; and
the Service itself does none of these things: it does not advertise, profile or track Applicants.

If you believe a child's data has been given to us without the required consent, write to privacy@ideascore.online and we will work with the Customer to address it.

11. IdeaScore AI

When a Customer uses IdeaScore AI, the text of applications it chooses to evaluate (form answers, text extracted from pitch decks, the rubric and the Customer's instructions) is sent to our AI engine provider (or, when it cannot answer, our second AI engine provider; both are listed at /legal/subprocessors) to produce scores, rationales, summaries and answers. Before anything is sent, we swap out the names and contact details of the people in the Customer's programme: names are replaced with labels and contact details and ID numbers are removed, within the limits set out in the AI Use Statement (for example, text inside images cannot be read, a name written in an unusual way may not be recognised, and when the Customer uses Deep Research, IdeaScore AI also reads public web pages, which may name an Applicant's founders). Customer Data is never used to train or improve any model, ours or anyone else's. Our AI engine providers may keep inputs and outputs for a limited time to check for safety and misuse, as their terms allow; we do not promise that a provider keeps nothing. IdeaScore keeps its own copy of AI answers only as long as section 8 describes. Answers marked as sensitive are left out of what IdeaScore AI receives, except for the eligibility explanation described in section 4.1. The Customer's people review the output and make every decision. Details are in the AI Use Statement.

Telling Applicants. Where a Customer uses IdeaScore AI to help assess, score or rank applications, the Service tells the Applicants concerned: the application form says, before submission, that the Customer may use IdeaScore AI to help its reviewers read and score applications; the applicant portal says whether IdeaScore AI has helped assess the Applicant's application; and decision letters sent through the Service say so where IdeaScore AI scored the Applicant's application in the round concerned. Where IdeaScore AI is switched off and has not been used on an application, no such statement is made. These notices do not replace the Customer's own notice to Applicants (section 3.1). An Applicant with questions about how IdeaScore AI was used, or who does not want it used on their application, should contact the programme's organisers, who decide (section 9.4).

12. Security

We protect personal data with reasonable security practices and procedures, appropriate technical and organisational measures, as required by section 8(5) of the DPDP Act, section 43A of the Information Technology Act, 2000 and the rules under it, and Article 32 of the GDPR. They include encryption in transit (HTTPS, with browsers told never to fall back to an unencrypted connection), a separate database for each organisation, hashed passwords, optional and enforceable two-step sign-in, role-based access, audit logs, rate limits, and nightly backups encrypted with AES-256-GCM. Our providers encrypt the disks that hold our databases and files. More detail is on our Security page.

No system is perfectly secure. If a personal data breach happens, we will notify the Data Protection Board of India and each affected Data Principal as the DPDP Act and DPDP Rules require, report to CERT-In where its directions require, and, where we act for a Customer, tell the Customer without undue delay so it can meet its own obligations, including under Article 33 of the GDPR.

13. Cookies and Similar Technologies

We use only cookies and browser storage that the Service needs to work, and to remember your preferences. We use no advertising or third-party analytics cookies. See the Cookie Notice.

14. Changes to This Policy

We may update this policy. Each version has a number and an effective date, and earlier versions remain available on request. If a change is material, we will tell Customers' owners by email or in the Service at least 30 days before it takes effect, unless the change is required sooner by law. Where we rely on your consent and a change requires fresh consent, we will ask for it.

15. Contact, Grievances and Complaints

Privacy questions and requests: privacy@ideascore.online
Grievance Officer (Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 and section 13 of the DPDP Act): Dibyendu Ganguly, grievance@ideascore.online, +91 89173 60065. We acknowledge a grievance within 24 hours and resolve it within 15 days of receipt. Details: /legal/grievance.
Postal address: CMS Group, 01, Teachers Colony, Sahaspur, Dehradun, Uttarakhand 248197, India.

If you are not satisfied with our answer, you may complain to the Data Protection Board of India in the manner the DPDP Rules provide, after first using our grievance process as section 13(3) of the DPDP Act requires. If the GDPR or UK GDPR applies, you may also complain to your local supervisory authority.