In the product (live)
Signing in
- Two-factor sign-in with an authenticator app (time-based codes). On new systems it is on for administrators from day one; switch it on for everyone or per role.
- Ten one-time recovery codes, so a lost phone does not lock a person out for good.
- Codes by e-mail, SMS or WhatsApp are available once those are set up.
- Sign in with Google, or single sign-on (SAML or OpenID Connect) through your identity provider.
- An account locks after 5 wrong passwords in a row, and one address may try at most 20 sign-ins in 5 minutes. Weak and commonly leaked passwords are refused.
- A session ends after 24 hours idle and after 14 days at most. People get an e-mail when their access changes or they sign in from a new place.
Who sees what
- Roles are enforced on the server, for every request. Hiding a menu is never what protects the data.
- A person sees only what their role allows. View-only means view-only: no edit buttons, and edits are refused on the server.
- Records can be limited further, for example to one company, sales territory or warehouse, or to a person’s own leave and salary slips.
- Typing an address you have no access to shows a friendly “no access” page.
Audit trail
- Every change to a tracked record is saved as a field-by-field history. Opening sensitive records is logged too.
- Exports, and each reveal of a hidden number, are logged in the same history.
- The history is tamper-evident: entries are chained, and a nightly check reports any entry that was changed or removed.
- History is kept for 8 years.
Personal data at rest
- An employee’s PAN, Aadhaar, passport, IBAN, UAN and bank account, a customer’s or supplier’s bank account number and a borrower’s CKYC number are encrypted with AES-256-GCM, with a fresh key for each value.
- These numbers are shown masked, like •••• 1234, on screens, lists and exports. Show works only for people with the right permission, and each reveal is logged.
- Passwords and API keys for connected services are kept in an encrypted store, and are removed from error logs.
- Backups are encrypted (AES-256), and their key is kept apart from the backups.
Web protections
- API calls are rate-limited per user (600 a minute) and more tightly for visitors who are not signed in.
- Every change needs a security token, which blocks forged requests from other websites.
- Strict security headers: a content security policy, HTTPS-only (HSTS for two years), no framing by other sites, and camera, microphone and location only for the system’s own pages.
- Uploads are limited to common document, sheet and image types up to 25 MB, and a renamed file is refused. Virus scanning of every upload can be switched on.
- The sign-in cookie is HttpOnly, Secure and SameSite.
- Inputs are checked: attempts to inject database commands are refused, and scripts in notes are removed when saved.
How each client system is set up
- A dedicated server for each client. Its firewall lets in only web traffic and our secure admin connection; the database and internal services are never reachable from outside.
- Automatic security updates for the server, and an address that keeps hitting the rate limits is blocked for a while.
- Separate secrets and encryption keys for each client.
- A health check every 5 minutes, and a daily encrypted backup copied off the server.
These steps are scripted and have been rehearsed on our test servers. The first pilot clients will be their first production use.
How we test
Before launch we ran internal reviews of:
- security across the product,
- attempts to get round permissions,
- the AI Assistant’s safety (attempts to inject instructions or pull out data),
- known vulnerabilities in the software we depend on.
Our latest security round, on 2 Nov 2026, logged 176 findings, none critical. Every high-severity finding in the product was fixed or mitigated, with a test that keeps each pattern out. Our test site’s HTTPS set-up is rated A+ by testssl. These were our own reviews, not an outside auditor’s.
Not done yet
- No ISO 27001 certificate.
- No SOC 2 report.
- No external penetration test (VAPT).
We will publish the date and scope here when any of these is done.
Report a security problem
If you find a vulnerability, tell us through the contact page and mark it “Security”. Please give us reasonable time to fix it before you make it public. We will tell you what we did about it.
Your part
- Keep two-factor sign-in on for administrators, and turn it on for finance roles.
- Run the Security review on the Administration home: ten checks, each failed one with its own fix button.
- Give each person only the roles they need.
- On your own server, keep the daily backup and the encryption keys somewhere other than the server.