This page describes, factually, how IdeaScore protects the data our customers trust us with, and how to report a security problem to us. It is published at /legal/security. The measures form Annex 2 of our Data Processing Agreement.
1. How We Protect Data
Encryption
- In transit. Every page and API call uses HTTPS. Browsers are told (HSTS) never to fall back to an unencrypted connection.
- At rest. Our database and file-storage providers encrypt the disks that hold customer data.
- Backups. Every night we back up each organisation's database, encrypted with AES-256-GCM before it leaves the server, to a separate storage bucket with its own access credentials. Each archive is checked against a manifest of checksums before upload and again before any restore. There is no unencrypted backup mode, and the key is held separately from the backups. We keep 30 daily and 12 monthly copies.
- Secrets. Passwords are stored only as bcrypt hashes. Authenticator secrets for two-step sign-in are encrypted at rest. API keys, invitation tokens and recovery codes are stored only as hashes.
Separation and access
- A database for each organisation. Each customer's records live in their own database, never mixed with another customer's.
- Roles. Each organisation decides who sees and does what (owners, administrators, evaluators and others, with custom roles where enabled). Evaluators and applicants never see IdeaScore AI scores or rationales.
- Our staff. When our support team needs to see an organisation as a user sees it, "View as" is read-only, limited to 60 minutes, requires a reason, cannot reach security settings, billing, user management, API keys, exports or any download, and is recorded in the customer's own audit log, including each document it opens.
Sign-in
- Passwords are checked for strength, for personal details, and against known breached passwords. The breach check uses the Pwned Passwords k-anonymity range service: only the first five characters of a SHA-1 hash of the password leave our servers; the password never does.
- Two-step sign-in with an authenticator app and ten single-use recovery codes. An organisation can require it for owners and administrators.
- Google and Microsoft sign-in, where an organisation enables it, use OpenID Connect with state, nonce and PKCE, and only sign in people the organisation has already added.
- Sessions are held in secure, http-only cookies, last 7 days (at most 30 with activity), and can be reviewed and signed out from other devices. Ten failed sign-ins lock an account for 15 minutes. While a lock caused by wrong passwords runs, the right password is still accepted from a network that sent none of them, or from a browser that has signed in to the account before.
Records
- Audit log. Sign-ins, changes, exports and downloads are recorded with who, when, IP address and device. Customers see IP addresses masked (for example
103.21.*.*) and devices summarised; full details stay on our servers for security investigations. Each organisation can set how long its audit log is kept. - Sign-in history for each user, kept for 180 days.
Abuse protection
- Rate limits on sign-in, two-step verification, password reset, applicant sign-in links, public form events, trial requests, imports and the API.
- Upload size limits and daily upload limits for each organisation, each signed-in applicant and signed-out visitors, request validation, signed and verified payment and outbound webhooks, and replay protection.
- Our network provider protects the Service against denial-of-service attacks.
Engineering
- Secrets live in the hosting environment, never in the database or source code.
- Production builds ship without source maps or development tools.
- Each release passes automated tests, including tests of the safeguards above.
- Customer data is never used to train AI models, and IdeaScore AI receives only what a request needs.
Your data, your way out
- An organisation's owner can export everything (programmes, applications, evaluations, scores, decisions, people, audit log and files) as one ZIP file, through a link that is valid for 10 minutes; the file is deleted 24 hours after it is built.
2. What We Ask of Customers
Security is shared. Please: require two-step sign-in for owners and administrators; give people the narrowest role they need; remove users who leave; keep API keys secret and rotate them if exposed; review your audit log; and report anything suspicious to [email protected].
3. Incidents
If we become aware of a breach affecting customer personal data, we notify the affected customer without undue delay, and within 48 hours, with what we know and what we are doing, as set out in our Data Processing Agreement. We also report to the Data Protection Board of India, affected individuals and CERT-In where the law requires.
4. Reporting a Vulnerability
We welcome reports from security researchers.
How to report. Email [email protected] with a description of the issue, the steps to reproduce it, the affected address or feature, and its likely impact. Please do not include real personal data in your report beyond what is necessary.
What we do. We will acknowledge your report within 3 business days, keep you informed of progress, and tell you when the issue is fixed. With your permission, we will thank you publicly. We do not currently run a paid bug bounty.
Please:
- test only against your own account, or the public demo at https://try.ideascore.online, which holds fictional data only;
- stop and tell us as soon as you reach data that is not yours, and do not keep, copy, change or disclose it;
- not degrade the Service for others: no denial-of-service, load or volume testing, spam, or automated scanning that sends large amounts of traffic;
- not use social engineering, phishing or physical attacks against our staff, customers or providers;
- not test third-party services we use (for example our hosting, email or payment providers); report to them directly; and
- give us reasonable time (normally 90 days) to fix the issue before disclosing it publicly.
Safe harbour. If you make a good-faith effort to follow this policy, we will consider your research authorised, we will not take legal action against you or ask law enforcement to investigate you for it, and if a third party takes action against you for research done under this policy, we will make it known that you acted with our authorisation. This safe harbour is limited to what we can authorise: it does not bind third parties, and it does not apply to activity that breaches this policy or the law in a way unrelated to good-faith security research.
Out of scope. Reports that need a rooted or compromised device, missing best-practice headers with no demonstrated impact, self-cross-site scripting, clickjacking on pages without sensitive actions, rate-limit reports without a demonstrated impact, and reports from automated tools without a working proof of concept.
5. security.txt
We publish the following at https://app.ideascore.online/.well-known/security.txt (RFC 9116):
6. Contact
Security reports: [email protected]. Other questions: [email protected].