Surdi Family Office handles sensitive personal financial data for a single family and its authorized advisors. This policy documents the administrative, technical, and physical controls used to identify, mitigate, and monitor information-security risks. It is reviewed at least annually by the account owner.
1. Scope
This policy covers the Surdi Family Office application, its database, its server-side functions, and the linked-provider integrations (Plaid, SnapTrade, CoinStats). It applies to every user granted access to the application.
2. Access control
- Public sign-up is disabled. Users are provisioned individually by the account owner.
- Roles are enforced server-side: owner, family, advisor, accountant, bookkeeper. Advisors, accountants, and bookkeepers are read-only.
- Row-level security is enabled on every application table. Sensitive columns (provider access tokens, third-party API user secrets) are not readable by application users under any role — only server-side service credentials can read them.
- Access is reviewed at least annually and immediately upon role change or offboarding.
3. Authentication
- Email/password authentication managed by Supabase Auth.
- Passwords are checked against the HaveIBeenPwned breach database and rejected if compromised.
- Passwords are stored only as salted hashes by the auth provider — never in plaintext.
- Multi-factor authentication is available and can be enforced for privileged roles on request.
4. Encryption
- In transit: TLS 1.2+ (TLS 1.3 preferred) on all client, server, and provider connections. HTTP Strict Transport Security is enabled with a 2-year max-age and
includeSubDomains; preload. - At rest: database storage and backups are encrypted by the hosting provider.
- Secrets: API keys and provider secrets are stored in server-side secret storage and are never shipped to the browser bundle.
5. Application security
- Standard security response headers on every request: HSTS,
X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy, and a Content-Security-Policy. - Input validation on server functions using typed schemas.
- Scheduled jobs and webhooks are authenticated with dedicated shared secrets, compared using timing-safe equality.
- Dependencies are updated regularly; the codebase is scanned for common vulnerabilities before release.
6. Third-party providers
We rely on the following subprocessors, each of which maintains its own security program:
- Supabase — database, auth, secrets (SOC 2 Type II).
- Cloudflare / Lovable — hosting, TLS, DDoS protection.
- Plaid — bank aggregation (SOC 2 Type II, ISO 27001).
- SnapTrade — brokerage aggregation.
- CoinStats — crypto aggregation.
7. Monitoring & incident response
- Application errors and failed sync jobs are logged server-side and reviewed.
- Authentication events are logged by the auth provider.
- In the event of a suspected security incident, the account owner will (a) contain the incident by revoking affected credentials and disabling affected accounts, (b) assess the scope, (c) notify affected users without undue delay, and (d) notify Plaid and other providers as their agreements require.
8. Physical & environmental
The application has no on-premises infrastructure. All compute and storage is operated by the providers listed above in their physically secured data centers.
9. Vendor management
New subprocessors are reviewed for security posture before integration. Existing subprocessors are re-reviewed annually or when materially changed.
10. Data retention & deletion
See the Data Deletion & Retention Policy.
11. Policy review
This policy is reviewed at least once per year by the account owner and revised when controls, providers, or applicable laws change materially.
12. Contact
Report a security concern to bensurdi@gmail.com.