Security

Backups & recovery

• Automated database backups every six hours, scheduled at 00:00, 06:00, 12:00, and 18:00 UTC by a dedicated Railway service.
• Stored off-site in a private Backblaze B2 bucket that is separate from our database provider. This provides a recovery copy if the database provider is unavailable. Recovery depends on a successful backup; changes made after the latest recoverable backup may be lost.
• Encrypted in transit (TLS) and encrypted at rest by the storage provider.
• Integrity-verified on every run: gzip checksum plus row-count sanity checks on core tables (organizations, campaigns, donations, audit logs).
• Limited retention with automatic deletion of old files - we keep what we need to recover, not a permanent archive.
• Failure alerting: if a backup run fails, an email alert is sent to the operations address immediately.

Payment security

• All payments are processed by Stripe. ScanRaise never stores, transmits, or sees full card numbers or bank account details.
• Stripe hosts Checkout and is certified as a PCI DSS Level 1 service provider. Full card numbers do not touch ScanRaise servers. Stripe's certification does not by itself certify ScanRaise or replace any validation ScanRaise must complete for its own scope.
• For connected campaigns, donations are processed through the organization's Stripe Connect account according to Stripe's payout schedule. Approved platform-mode campaigns are collected through ScanRaise's Stripe account and paid monthly by check or bank transfer. ScanRaise charges a 2.5% platform fee in either mode.
• Every inbound Stripe webhook is cryptographically signature-verified before it can change state in our system.

Account security

• No reusable password. Sign-in uses a one-time email magic link or a passkey (WebAuthn), such as Touch ID, Face ID, or Windows Hello.
• Passkeys are phishing-resistant. A magic-link URL is a temporary bearer credential and must be protected until it expires or is used.
• Session cookies are HttpOnly, HMAC-signed, and scoped to scanraise.com. The signed payload contains readable session and account metadata. The signature prevents alteration, and the corresponding server-side session can be revoked.
• Automatic inactivity timeouts: 30 minutes for organization users, 15 minutes for platform admins.
• Rate limits on every authentication endpoint: magic-link requests are capped at 5 per minute per IP.

Schools, students, and student data

• ScanRaise is listed in the SDPC resource registry. A registry listing is not the same as certification, district approval, or an executed data privacy agreement.
• Under-13 tracking and fitness features are gated on a recorded parental-consent grant. Submitted raw tracking fields are application-encrypted, and the live database deletes the protected raw payloads after the stated retention window.
• Roster templates and Clever imports format names as first name and last initial. Other roster paths can accept organizer-supplied display names, so organizers must review names before publishing participant pages.
• These controls are designed to support a school's FERPA obligations. Each school or district must evaluate its use, direct-control requirements, annual notice, permitted purpose, redisclosure limits, and applicable data privacy agreement.
• Clever and ClassLink sign-in integrations are built, with production availability dependent on the provider and district rollout.
• We do not sell or share student data with advertisers, marketers, or data brokers. Ever.
• Districts and schools can submit an access or deletion request. The current scope and known limitations are described in the Privacy Policy.

Transport & platform

• Plain HTTP requests redirect to HTTPS, and HTTPS responses send an HSTS policy. We do not claim that scanraise.com is currently included in browser preload lists.
• Strict Content-Security-Policy on every HTML response: no inline scripts, no unsafe-eval, whitelisted origins only.
• Full pages use X-Frame-Options: DENY and frame-ancestors 'none'. The published donation widget route is the only framing exception and permits secure HTTPS parent pages while keeping all other routes locked.
• Other hardened response headers include X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy.
• The April 14, 2026 security review included static source analysis, read-only production probes, a Worker CSP review, mutation tests, and a pytest regression suite. The published record does not describe an independent third-party or exhaustive outside-in penetration test.

Email integrity

• SPF, DKIM, and DMARC are all configured and passing on our sending domains, so receiving mail servers can verify that an email really came from ScanRaise.
• All transactional email (magic links, donation receipts, notifications) is sent through a verified sender. We don't hand your donor list to third-party marketing tools.

Insurance

• StanHattie LLC, which operates ScanRaise, carries General Liability and Errors & Omissions coverage through Next Insurance. Verify coverage.

Reporting a vulnerability

Found something that looks off? Email support@scanraise.com with [Security] in the subject line. We don't run a paid bug bounty yet, but we read every report, triage quickly, and credit responsible disclosure here when the reporter consents.