Security

Passwordless by default

Most people sign in with a one-time code or a sign-in link sent to their email, so there is no password to reuse or leak. One-time codes are stored hashed and expire.

Passwords, where used

Stored as bcrypt hashes, never in a readable or reversible form. We cannot see your password and cannot tell you what it is.

Google sign-in

Available as an option. We receive only your name, email address and profile image.

Sessions

Signed session tokens with a bounded lifetime. Administrative sessions are shorter-lived and can be revoked centrally, which ends access immediately rather than at expiry.

Every authorisation decision in the platform goes through a single evaluator rather than being scattered across screens. It is a pure function: given who is asking, what they want to do, and what they want to do it to, it returns a decision and a reason. Permissions are re-read from the database on every request — a session token carries an identity, never a role or a privilege level, so revoking access takes effect on the next request rather than when a token expires.

Reporting lines inside an organisation are structural information for display only. They are never a route to inherited permission: no authorisation decision walks a management hierarchy.

Where organisations embed our assessment in their own product, their data is isolated at the database level using row-level security, not only by application logic. One organisation’s records cannot be read through another’s, even if an application-layer check were missed.

Partner API keys are stored as hashes, so a copy of our database does not yield usable keys. API access is rate-limited per organisation, enforced in shared storage so the limit holds across all running instances rather than per-server.

• All traffic to and from the platform is encrypted in transit over TLS.
• Personal-data columns are explicitly annotated in our database schema, so it is possible to answer precisely what personal data exists and where.
• Administrative access to an individual's record is written to an append-only audit log.
• Deletion is a real cascade across every table holding that person's data — not a hidden flag. It is not reversible.
• Assessment results carry an expiry so a stale reading is not presented as current.

What we hold, why, and for how long is set out in the Privacy Policy.

If you believe you have found a security issue, email team@kirnova.com with the subject line Security. Include enough detail to reproduce it.

We will acknowledge within 48 hours and keep you updated until it is resolved. Please give us a reasonable opportunity to fix an issue before disclosing it publicly, and do not access, modify or delete data belonging to anyone else while investigating. We will not pursue action against anyone who reports in good faith and follows those two conditions. We do not currently run a paid bug-bounty programme.

If a personal data breach occurs, we notify each affected person and the Data Protection Board of India, as the DPDP Act requires.

Stated plainly, because you would find out during a vendor review anyway and a page that hides it is worth less than one that does not.

• We hold no third-party security certification — no SOC 2, no ISO 27001. Nothing on this page has been independently audited.
• We have not commissioned an external penetration test.
• Multi-factor authentication is not yet available for administrator accounts. The groundwork exists; the enrolment flow does not.
• We do not currently offer a customer-managed encryption key option or a data residency guarantee.

If any of these is a requirement for your organisation, tell us at team@kirnova.com — knowing which ones actually block a deal is how they get prioritised.