Security
Security claims should be narrow enough to verify.
This page describes controls visible in the current application code and says where operational evidence is still required.
Updated 31 August 2026
01
How is member data separated from the public site?
Member pages and data routes are denied by default unless a user is signed in. The underlying pages and APIs also perform their own authentication or ownership checks. Gated responses are marked private, no-store and noindex.
02
How are accounts handled?
Clerk provides authentication. FundDaddy stores the account identifier and selected profile fields needed by its own database. Ownership checks protect saved lists, portfolio records, profile claims and other account-scoped data.
03
What data-safety controls are visible in the code?
- Public pages exclude partner names, email addresses and phone numbers.
- CSV exports neutralize spreadsheet formulas from imported fields.
- Webhook signatures and scheduled-job secrets are checked before processing.
- Profile ownership, edits and erasure operations keep review or audit records.
- Blob deletion uses a durable outbox so interrupted deletion can be retried.
04
What is FundDaddy not claiming?
No SOC 2 or ISO 27001 certification, penetration-test cadence, hosting-region promise, backup policy, encryption-at-rest configuration or incident-response service level is stated here because current operational evidence was not supplied.
05
How do I report a vulnerability?
Use the route published in security.txt. A monitored security email must still be configured before private vulnerability reporting is fully operational. Do not include customer data in an initial report.