A practical security posture for document signing.

FileSign is designed for business document signing workflows, where uploaded documents, recipient details, signing status, and audit records need careful handling.

This page describes the practical security posture expected for the product. It should be reviewed before launch against the final production configuration, vendor settings, contractual commitments, and legal requirements.

The security model should be evaluated around the real product surface: documents, recipients, workspaces, audit-trail events, account access, and the systems that move signing workflows forward.

Controls should prioritize confidentiality, authenticated access, operational reliability, and clear recovery paths over unsupported certification claims.

FileSign uses Supabase Auth as its authentication foundation, including email-based authentication and Google sign-in where enabled.

Account access is intended to be scoped by authenticated user and workspace context. Users are responsible for keeping credentials secure, controlling invitations, and removing access for people who no longer need it.

FileSign should be served over HTTPS in production through its hosting provider, helping protect traffic between the browser, application, and supporting services while in transit.

Sensitive provider credentials and server-side environment variables should not be exposed to client-side code. Any storage or database encryption-at-rest claims should be confirmed against the configured production providers before launch.

The expected infrastructure stack is Vercel for hosting and release workflows, Supabase for database, storage, and authentication foundations, and Resend for transactional email.

FileSign relies on these providers' platform security controls in addition to application-level safeguards. Provider-specific regions, retention settings, access policies, and contractual terms should be confirmed before production use.

Supabase is the expected system of record for product data. Database access should use least-privilege service credentials, server-side access patterns, and row-level security or equivalent policy controls where customer data is involved.

Administrative database access should be limited to authorized maintainers and used only for operational, support, security, legal, or reliability purposes.

FileSign should rely on configured provider backup and recovery features for production database and storage systems.

Backup schedules, restore testing, retention periods, and customer deletion behavior should be documented and reviewed before launch so operational expectations match the actual provider configuration.

FileSign may use application logs, provider logs, deployment telemetry, error reporting, and operational alerts to investigate reliability, abuse, security, and support issues.

Logs should avoid unnecessary sensitive content where possible. Access to logs should be limited to people who need them for support, operations, security, or incident response.

Security incidents should be assessed promptly, contained where possible, investigated for scope and impact, and followed by remediation appropriate to the issue.

If an incident affects customer data or legally protected information, FileSign should follow applicable notification obligations and communicate through appropriate customer or legal contacts.

Security researchers and customers should use the contact page to report suspected vulnerabilities. Reports should include the affected URL, steps to reproduce, potential impact, and any relevant screenshots or request details.

Please avoid accessing, modifying, deleting, downloading, or sharing data that does not belong to you. Do not perform denial-of-service testing, social engineering, spam, physical attacks, or destructive activity.

FileSign will aim to acknowledge credible reports, investigate in good faith, and remediate issues according to severity, exploitability, and operational risk.

This placeholder policy does not create a public bug bounty program, payment commitment, safe harbor beyond applicable law, or permission to test systems outside FileSign's own application surface.

FileSign may use third-party providers for hosting, database, storage, authentication, transactional email, analytics, logging, support, payments, and security tooling.

Expected providers include Vercel, Supabase, and Resend. Any additional subprocessors, data regions, contractual commitments, and customer-facing disclosures should be confirmed and published before launch.

Customers are responsible for using strong account practices, inviting only appropriate users and recipients, reviewing document content before sending, and ensuring signing workflows match their legal and operational requirements.

Customers should promptly remove access for former teammates, report suspicious activity, protect downloaded documents, and avoid sending sensitive information to unauthorized recipients.

Use the contact page for security reports, privacy requests, and legal inquiries.

Legal entity: <brand> LLC

Mailing address: 90 Gold Street, Floor 3, San Francisco, CA 94133