How we protect your data

Every organization's data is isolated at the database engine using PostgreSQL row-level security (RLS). The organization identifier is enforced on every read and write, and the policies are set to FORCE so they apply even to the table owner. A query that forgets the organization scope returns nothing rather than leaking across tenants. Uploaded files are namespaced by organization ID in object storage and authorized on every request.

All traffic to the application is served over TLS. The database and object storage are encrypted at rest by our infrastructure providers. Passwords are never stored in plain text - we keep only a bcrypt hash with a high work factor and cannot recover the original.

• Role-based permissions (owner, admin, editor, viewer) enforced at a single gate on every mutation.
• Rate limiting on authentication, signup, invite acceptance, uploads, and exports to deter abuse.
• Same-origin request checks and modern HTTP security headers.
• Magic-byte file-type sniffing on uploads - the browser's claimed content type is not trusted.

The database is backed up automatically on a regular schedule, with a documented restore procedure that is drilled against a throwaway instance. Backups are retained on a rolling window as part of normal disaster-recovery rotation.

Sensitive changes - to bills, assessments, protests, and comparables - are written to an append-only audit log with a before/after diff. Platform-operator actions are recorded in a separate cross-tenant trail, and any administrative access to a customer organization is logged and surfaced in-app while it is active.

No system is perfectly secure. If you discover a vulnerability, please email security@miskari.com with details so we can investigate. If we become aware of a personal data breach likely to affect you, we will notify you and the relevant authorities without undue delay, as described in our Privacy Policy.