Encryption, access control, audit logging, backups, and the practices behind them. Documented in plain language so you can decide for yourself.
Your data is encrypted everywhere it sits and everywhere it moves.
The production SQLite database is encrypted at rest with SQLCipher, using AES-256 in CBC mode with per-database keys. The encryption key is stored separately from the database file. Both the operational database and the internal audit database use independent keys.
All traffic between your browser and Rispah is HTTPS-only. We send the Strict-Transport-Security header with a two-year max-age and the preload directive, so browsers refuse to fall back to HTTP even on a fresh visit.
Daily database backups are uploaded to Amazon S3 with server-side encryption (SSE-S3). Backup files themselves are also SQLCipher-encrypted before upload, so the key is required to read them even if the S3 object were somehow exposed.
Strong defaults. Mandatory 2FA where it matters. Sessions hardened against the common attack classes.
Workspace owners and admin users are required to enroll a TOTP authenticator (Google Authenticator, 1Password, Authy, etc.) at first login. The owner role cannot bypass this. Member-role users can opt in.
Recovery codes are issued at enrollment for the case where a device is lost.
Passwords are stored as Werkzeug PBKDF2-SHA256 hashes with per-user salts. Plain-text passwords are never written to the database or to logs.
Repeated failed login attempts trigger account lockout. The lockout requires a signed unlock token delivered out-of-band before the account can sign in again, preventing automated password guessing from succeeding.
Session cookies are Secure (HTTPS-only), HttpOnly (no JavaScript access, blunts XSS-driven session theft), and SameSite=Lax (blunts CSRF on cross-site subresource requests). CSRF tokens are also issued per session by the flask-wtf protection layer.
API and form endpoints are rate-limited at the application layer. Write-heavy and authentication-heavy endpoints carry a stricter cap than read endpoints.
Workspace owners can see who did what, when. Administrative actions are recorded to an internal audit log that cannot be modified by application users.
Item creates, moves, edits, comments, file uploads, member invitations, role changes, and form submissions are all recorded with actor, timestamp, and target. The activity log surfaces on each board's Dashboard view, with the last 50 events.
Every authentication event, billing event, and sensitive write (workspace deletion, role escalation, Stripe webhook) is also recorded to a separate sb_audit_log table that the application never deletes from. The internal audit prune job retains 12 months and rotates older entries to cold storage.
The production database is backed up daily and uploaded to S3 in us-west-2. Backups are SQLCipher-encrypted with their own key and also server-side-encrypted by S3. Backup integrity is verified after each upload.
The restore path is exercised against a fresh host before each major release. Restore steps and target RTO/RPO are documented in our internal Backup & Restore runbook.
If you cancel your subscription, the workspace remains available to you for 30 days so you can resubscribe without loss. After 30 days, the workspace is deleted from the production database. Rolling backups containing the deleted workspace age out of S3 within the next 90 days.
The internal audit log retains a record that the workspace existed and was deleted (without the workspace content itself) for 12 months, to support compliance and security investigations.
Files attached to items are stored on the application host filesystem (not in the database), under access-controlled paths. Direct URL access to upload files requires an authenticated session on the owning workspace; deny rules in nginx block any attempt to fetch them directly by path.
Critical (CVSS 9.0+ or actively exploited): 7 calendar days. High (7.0 to 8.9): 30 days. Medium (4.0 to 6.9): 90 days. Low: best effort, reviewed each quarter.
On or around the first of each month, the team runs pip list --outdated against the production virtual environment and reviews GitHub Security Advisories and PyPI advisories for pinned packages. Decisions (defer, schedule, upgrade) are recorded.
A nightly scan runs pip-audit against the production environment and alerts the team on any non-low-severity finding. The scan results are appended to the security log.
Production runs on AWS Lightsail in us-west-2 (Oregon). Backups are stored in S3 in the same region. Rispah does not move data outside the United States.
The production host runs Ubuntu LTS with UFW firewall (only ports 22, 80, 443 allowed inbound from the public internet), fail2ban on SSH, and an unprivileged service user that owns the application files and database. The application runs under systemd with NoNewPrivileges, PrivateTmp, and ProtectSystem=strict for defense in depth.
Application secrets (database encryption key, session key, Stripe webhook secret, etc.) are loaded from an EnvironmentFile readable only by the service user. Secrets are not committed to source control, not logged, and not transmitted to third parties beyond the integration vendors that require them.
Rispah uses a small number of vendors for billing, email, and (optionally) financial-account aggregation. Each is listed below with what it sees.
Payment processing only. Stripe sees your billing email, payment method, and subscription state. Stripe does not see your workspace contents.
Hosts the application server and stores encrypted backups. AWS is the underlying infrastructure provider; it does not have application-level access to your data.
Sends authentication emails (password reset, account unlock), digest emails, and team-invitation emails. The body of these emails contains your workspace name and the recipient's email; it does not include item content unless the recipient explicitly subscribed to that digest.
Email [email] with a subject line of "Security report". Include reproduction steps, affected endpoints, and any proof-of-concept material. We acknowledge receipt within two business days and aim to triage within five.
Please do not file public GitHub issues, post on social media, or test against other customers' data. Test only against your own workspace, or use a free trial account for testing.
Good-faith security research conducted within these boundaries is welcome, will not be retaliated against, and will not result in legal action. We commit to coordinating disclosure with you and to credit the reporter publicly (if desired) after the issue is resolved.
Denial-of-service attacks, social-engineering of staff, physical attacks, and any testing that affects other customers' availability or data are out of scope and may result in account termination.