Security overview
Security is foundational to ImportPreflight. Import, trade, and product data can be sensitive; the pages below describe how we think about protection in a typical production deployment (Supabase, Vercel, and a Python host such as Fly.io). This is a draft trust narrative for your security questionnaire process — not a penetration-test report. Nothing here is a guarantee of future certification status.
Data encryption
In transit — Browsers and API clients use HTTPS (TLS 1.2+ in normal configurations). At rest — Supabase provides managed storage for the database and object storage; Vercel serves the front end. Each provider publishes encryption practices in their own documentation. Your team should pull the current statements and links for your due-diligence package. Backups, keys, and key rotation are handled under the operator's Supabase and cloud accounts; we do not print key material in this document.
Access control and isolation
Row-level security (RLS) is applied in the database so that, in a correctly configured deployment, a signed-in user can access only the data for their organization. The service role key is used by server-side components (API and background worker) and is not exposed to end users. Organization isolation is enforced in the data model: cross-organization visibility should not occur through normal app paths; moving users between orgs, if ever offered, would be explicit and admin-governed. Your CISO should confirm RLS policies for your project match this description.
Authentication
Supabase Auth handles user authentication. Passwords are stored under Supabase's standard practices (commonly using strong one-way password hashing; refer to Supabase documentation for the current algorithm and rotation story). Session tokens for the web app are typically JWT-based for the project configuration. Multi-factor authentication (MFA) — [CURRENT MFA STATUS — to be updated when MFA is enabled]. If MFA is not available today, your security questionnaire should state that clearly and add a timeline if you plan to enable it.
Infrastructure and subprocessors (illustrative)
Production often uses: Supabase (Postgres, Auth, Storage), Vercel (Next.js hosting), a Python API and worker on Fly.io or a comparable host, and Resend (or another provider) for email. Each vendor publishes SOC 2, ISO, or other assurance reports; download the current copies for your file. Do not claim "we are certified" in this page unless your own company and deployment actually hold the relevant certifications; many teams "inherit" some controls from vendors but still owe their own program.
Data residency
By default, a typical U.S.-hosted Supabase project stores primary data in U.S. regions. International expansion (EU or other regions) may be added later; update this text and your DPA when you have specific regions. Nothing on this page moves data for you—your configuration does.
Retention and deletion
Jobs and catalog files are generally retained for about 90 days after completion, subject to product settings and the operator's implementation—verify the live policy. Account deletion should trigger removal or de-identification of personal data on a ~30 day timeline where technically feasible, except where law or litigation requires a hold. See the Privacy Policy for the legal framing; your DBA and counsel align numbers.
Monitoring and incident response
We monitor application and infrastructure health through the cloud providers' standard tooling and our own application logging. If we become aware of a security incident that materially affects your data, we will aim to notify affected business contacts on a 72-hour target in many cases—your attorney must set the binding timeline to match breach-notification laws in your sector and regions (GDPR, state laws, etc. may require faster or more detailed notice). This 72-hour statement is a goal for a small team, not a global legal commitment, until counsel reviews.
Vulnerability reporting
Report security issues to [SECURITY_EMAIL] (set a dedicated inbox, e.g. security@yourdomain, with PGP if you publish a key). Please provide enough detail to reproduce, and allow reasonable time before public disclosure, in line with responsible-disclosure practice. Do not test against production without prior written permission if that could impact other customers; offer a safe staging path when you have one.
Compliance roadmap
[COMPLIANCE STATUS PLACEHOLDER — update as certifications are achieved.] A typical maturity path: documented controls, risk assessment, then SOC 2 Type II when customer demand and budget align. Do not claim a SOC 2 attestation for your company until a qualified auditor has issued a report. You may, if accurate, state that certain vendors maintain SOC 2 and link to their compliance pages.
User responsibilities
You are responsible for the accuracy of the catalogs you upload, for managing roles inside your org, and for your own device security. Use strong, unique passwords or SSO when you add it; report suspected compromise promptly through Contact or the address above.