Security Policy
Effective April 22, 2025
FileValet is purpose-built to handle sensitive taxpayer information (SSTI) for CPA firms. Every architectural decision is made with the assumption that the data on the platform is high-value and that a breach would have serious regulatory consequences. This page describes the technical and operational controls we have in place.
1. Authentication
Passkeys (WebAuthn) — primary: The default and preferred authentication method. Private keys are stored on your device using your platform’s secure enclave (Touch ID, Face ID, Windows Hello, hardware security key). Private keys are never transmitted to FileValet servers. We store only the public credential.
Email OTP — fallback: One-time codes sent to a verified email address as a fallback when passkey enrollment is not yet complete or the device is unavailable. OTP codes expire after five minutes and are single-use.
Magic links — prohibited: Magic links are disabled across all account types. They are susceptible to forwarding and email-based interception attacks.
Session management: Sessions are server-managed and short-lived. High-sensitivity actions (e.g., inviting new users, modifying organization settings) require step-up re-authentication; elevated sessions expire after 15 minutes regardless of activity.
MFA mandatory: Multi-factor authentication is required for all accounts as mandated by the FTC Safeguards Rule (16 CFR Part 314). There is no mechanism to disable MFA.
2. Database-level tenant isolation
Multi-tenant data isolation is enforced at the Postgres engine level, not application logic. Every tenant-isolated table in FileValet has:
- An
organization_id UUID NOT NULLcolumn on every row ENABLE ROW LEVEL SECURITYFORCE ROW LEVEL SECURITY— applies to the table owner role, preventing privileged bypass- A
tenant_isolationRLS policy that restricts every SELECT, INSERT, UPDATE, and DELETE to rows matching the authenticated session’s organization
This means cross-tenant data leakage is impossible at the database level, even in the event of an application-layer vulnerability. Staff are additionally restricted by a client-assignment policy: they can only query records for clients explicitly linked to their account.
3. Encryption
In transit: All traffic uses TLS 1.2 or higher. File uploads bypass our application servers entirely — the browser receives a short-lived presigned S3 URL and uploads directly to AWS. The file content is never transmitted through FileValet’s infrastructure.
At rest — files: AWS S3 Server-Side Encryption (SSE-S3, AES-256) applied to all objects. Bucket-level encryption with public access blocked at the bucket and account level.
At rest — database: Neon Serverless Postgres encrypts all data at rest using AES-256 on NVMe storage. Encryption keys are managed by Neon’s KMS.
4. Malware scanning
Every file uploaded to FileValet is automatically scanned by AWS GuardDuty Malware Protection for S3. Uploads trigger an event-driven scan pipeline via S3 event notifications and SNS webhooks. Files that fail the scan are quarantined before they can be downloaded by any user. The webhook payload is Zod-validated server-side before any state is mutated.
5. Vendor abstraction and supply chain controls
FileValet enforces a strict abstraction firewall: no business logic in server actions, API routes, or React components imports vendor SDKs directly. All vendor interactions (auth, storage, email) flow through typed service interfaces backed by dependency injection. This design limits the blast radius of third-party SDK vulnerabilities and makes it possible to rotate vendors without touching product code.
6. Audit logging
All file access operations — views, downloads, uploads, shares, and deletions — are logged with a user identifier, timestamp, and action type. Logs are retained for the full seven-year IRS Pub 4557 period. They are append-only and cannot be modified or deleted through the application interface.
Application error events are reported to Sentry with PII stripped before transmission. No personal data (names, email addresses, tax identifiers) appears in error payloads.
7. Role-based access control
| Role | Scope | Admin actions |
|---|---|---|
| Organization Admin | Full org data | Yes — invite, manage, delete |
| Staff | Assigned clients only | No |
| Client | Own data only | No |
Role is validated server-side on every request. Client-side state is never trusted for authorization decisions.
8. Regulatory compliance
IRS Publication 4557 — Safeguarding Taxpayer Data
7-year soft-delete retention on all SSTI records. Mandatory audit logs on all file access operations. Encryption at rest and in transit. MFA required for all accounts. Access limited to need-to-know via RBAC and RLS.
FTC Safeguards Rule (16 CFR Part 314)
MFA mandatory and enforced at the infrastructure level. Zero cross-tenant data leakage enforced by Postgres RLS. Annual risk assessments and access reviews conducted by the FileValet security team. Incident response plan in place with defined notification timelines.
SOC 2-adjacent practices
Change management via pull request review with required approvals. Secrets managed through Doppler — no plaintext credentials in source control or environment files. Dependency updates monitored via Dependabot. Railway health-check rollback prevents broken deployments reaching production traffic.
9. Vulnerability disclosure
If you discover a security vulnerability in FileValet, please report it responsibly by emailing security@filevalet.app. We will acknowledge receipt within 24 hours and aim to remediate critical vulnerabilities within 72 hours. We ask that you do not publicly disclose vulnerabilities until we have had a reasonable opportunity to address them. We do not currently offer a bug bounty program.
Email security@filevalet.app for vulnerability reports and security questions.