Security Overview
On this page
1. Architecture
OrgAlyne is built as a multi-tenant SaaS application: a single application and database serve every customer organization, with strict logical isolation between tenants (see Multi-tenant isolation below). This is the same architectural pattern used by most modern SaaS products, and lets us ship security fixes and improvements to every customer at once rather than maintaining separate deployments.
2. Encryption
- In transit: all traffic between your browser and OrgAlyne is encrypted via TLS.
- At rest: data is encrypted at rest using our infrastructure providers' standard encryption for managed databases and object storage.
- Passwords: stored as salted bcrypt hashes; OrgAlyne staff cannot view your plaintext password.
- Sessions: authentication uses short-lived access tokens plus a rotating refresh token stored in an httpOnly cookie, reducing the impact of a leaked token.
3. Access control
Access within OrgAlyne is governed by role-based permissions (Organization Admin, Executive Leader, Board Member, Committee Chair, Committee Member, Read Only), enforced on the server for every request, not just hidden in the interface. This means that even if someone found a way to make a request a role shouldn't be able to make, the server independently re-checks their actual permissions before acting on it.
4. Multi-tenant isolation
Every record in OrgAlyne is tagged with the organization it belongs to, and every request is re-verified against your organization's actual membership records before any data is returned or changed. A login token alone is never sufficient. This is tested directly: our internal test suite specifically attempts to access one organization's data using another organization's credentials, including simulated tampering, and confirms it is rejected.
5. Audit logging
OrgAlyne maintains an audit log of security- and governance-relevant events, including sign-ins, permission changes, record creation/edits/deletion, status overrides, approvals, decisions, report submissions, file uploads, data exports, AI-generated content saved to official records, and subscription changes. Organization Administrators can review and export their organization's audit log.
6. Backups and recovery
Production data is backed up on a regular automated schedule through our managed database provider, with point-in-time recovery capability. [Placeholder: confirm and publish the specific backup frequency and retention window, and periodically test restoration, once production infrastructure is finalized.]
7. Sub-processors
We rely on a small number of infrastructure providers to operate the Service, which may include: application hosting, managed PostgreSQL database hosting, object storage for uploaded files and logos, transactional email delivery, and payment processing. [Placeholder: publish the specific named sub-processor list once vendors are finalized; many customers, especially larger nonprofits and associations, will specifically ask for this list during procurement.]
8. Incident response
[Placeholder: describe the company's actual incident response process and customer-notification commitments once a formal process exists; do not publish a specific notification-time commitment, e.g. "within 72 hours," unless the business is operationally prepared to meet it.]
9. Responsible disclosure
If you believe you've found a security vulnerability in OrgAlyne, please report it to security@orgalyne.com [Placeholder: confirm final contact address, and consider standing up a formal responsible-disclosure/bug-bounty policy as the company matures]. Please do not publicly disclose the issue until we've had a reasonable opportunity to investigate and address it, and please avoid accessing or modifying other customers' data while testing.