What protects your books, and what does not yet

✅ In place today

• Walled-off data. Every organization's data is isolated by Postgres row-level security, enforced by the database itself, not only by application code. Inside an organization, each entity is isolated the same way, one level narrower.
• An audit trail nobody can edit. Changes to key records are written to an append-only audit log. The database rejects any update or delete against it, so a logged entry can never be edited or removed after the fact.
• Passwords are hashed with bcrypt, never stored in plain text. Sign in with Google is available too.
• HTTPS only. The website and the app are served over an encrypted connection with a valid certificate; browsers are told to never use plain HTTP here.
• Login protection. Repeated failed sign-in attempts are slowed down, and an email tells you when your account is used from a new device.
• Your data, your decision. You can permanently delete your own account and all its data from Settings.
• Least privilege on the server. The app runs as its own small system user, not as the server's administrator.

⚠️ Known gaps

• Encryption at rest. The production database runs on the app server's own disk, which has no operating-system-level disk encryption. Whether the hosting provider encrypts the underlying physical storage has not been confirmed. The straightforward fix is a managed database service with an explicit encryption-at-rest guarantee.
• No formal incident-response drill. The process below is written but has not been run as a practice exercise.
• No SOC 2 or ISO 27001 certification. Not pursued; these matter when a customer or partner requires one.

If something goes wrong

1. Contain. A compromised credential or key is rotated immediately; a compromised server process is stopped before anyone investigates.
2. Assess. What data could have been read or changed, for which organizations and entities, using the audit log that cannot have been tampered with.
3. Fix the root cause before reopening access.
4. Notify affected users if their data was actually exposed: what happened, what data, what was done. An early "we are aware and investigating" beats silence.
5. Write it down afterwards: what happened, root cause, what changed to prevent a repeat.

Report a security problem

Email nikhil.joshi@techwomb.com with steps to reproduce. Please do not test against real customer data. The same address is published in the site's security.txt file (/.well-known/security.txt).