Security and Incident Response Policy
Safeguards, vulnerability reporting and breach handling
Template - not legal advice. This document was drafted for Indoria Technologies Private Limited to match how the software actually works. Company details are filled in. Have an advocate in India review it before launch, especially the Digital Personal Data Protection Act 2023 sections, the handling of students under 18, and the limitation of liability.
1. Safeguards in place
- Encrypted connections (HTTPS, HSTS) with certificates managed by Caddy or nginx.
- Optional two-step sign-in (authenticator app) for every user; passwords stored with scrypt and per-user salt; minimum length 10, common passwords blocked; account locks for 15 minutes after 8 failures.
- Session tokens and one-time tokens stored only as SHA-256 hashes; HttpOnly, SameSite cookies; all sessions end on password change or reset.
- CSRF protection, content security policy with no inline scripts, clickjacking protection.
- Every data access is checked against the user's organisation and role; administrators cannot read private file content.
- Audit log of sign-ins and administrative actions; rate limits on sensitive endpoints.
- Daily backups kept off the server; operating-system updates applied monthly or sooner for critical issues.
2. Reporting a vulnerability
Write to contact@indoriamunim.in with steps to reproduce. We will acknowledge within 2 working days and keep you informed. Please do not access other people's data, disrupt the service or publish details before we have fixed the issue. We will not take action against good-faith research that follows these rules. No money rewards are offered at present; with the researcher's consent we credit them by name once the issue is fixed.
3. Incident response
| Phase | Actions | Owner |
|---|---|---|
| 1. Detect and triage | Alert from logs, user report or researcher; decide severity (Low / High / Critical) within 2 hours | Engineer on duty |
| 2. Contain | Revoke sessions, suspend accounts or organisations, block IPs, rotate secrets, take the service offline if needed | Security lead |
| 3. Assess | What data, which organisations, how many people, how long; preserve logs | Security lead |
| 4. Notify | Tell affected organisations without undue delay (target 48 hours after confirmation) and the Data Protection Board and affected persons as the DPDP Act and Rules require; CERT-In within 6 hours of noticing a reportable cyber incident under the CERT-In Directions of 2022 | Grievance Officer + Management |
| 5. Recover | Fix root cause, restore from backup if needed, verify with tests | Engineering |
| 6. Learn | Written post-incident review within 10 working days; update controls and this policy | Security lead |
Verify the current reporting formats and deadlines with counsel; they change.
Addendum: seal key (1.3)
- The seal key (seal.pem) is a secret. Keep file mode 600, include it in backups, never commit it to Git.
- Signer links are bearer tokens stored only as hashes; cancelling a request invalidates them.
- Loss or leak of the seal key: generate a new one, record the date, and tell customers that seals made before the date can no longer be proven by this server if the key is lost, or may be forgeable if it leaked.