Security Overview
Security is foundational to a multi-tenant platform handling distribution, payment, and contract data. This overview describes the technical and organizational controls Restock, Inc. uses to protect the Service and Customer Data. Because Restock is approaching launch, we mark each control as Live (in place today) or Planned (on our near-term roadmap) so you have an honest picture.
1. Encryption
Live All connections to the Service are encrypted in transit using TLS 1.2 or higher. Customer Data held on our systems is encrypted at rest using AES-256, leveraging our managed Postgres provider (Supabase) and cloud storage. Encryption keys are managed by the underlying platform with rotation.
Restock also runs local-first: some Customer Data is written to browser storage on the device a user is working on and is never transmitted to us. That data is protected by the device and its operating system, not by the measures above, and it is outside our backups. Which categories these are, and what that means for retention and deletion, is set out in Privacy Policy §7 and DPA §10.
2. Authentication and multi-factor authentication
Live User authentication is handled through our managed auth provider. Passwords are stored only as salted hashes; we never store plaintext passwords. Planned Multi-factor authentication (MFA) for all users and enforced MFA / SSO (SAML, OIDC) for Enterprise workspaces are on our roadmap.
3. Tenant isolation
Live The Service is multi-tenant. Each workspace's data is logically isolated and enforced at the database layer using Postgres Row Level Security (RLS), so queries are scoped to the authenticated tenant and one customer cannot access another's data. Application-layer authorization provides defense in depth.
4. Access control
Live Internal access to production systems and data follows the principle of least privilege; only personnel who need access for operations or support are granted it, and access is role-based. Planned Periodic access reviews, just-in-time access elevation, and formal offboarding checklists are being formalized.
5. Secrets management
Live API keys, database credentials, and other secrets are stored in managed secret stores and environment configuration, not in source code. Secrets are scoped per environment and rotated when staff changes or on suspected exposure.
6. Backups and disaster recovery
Live Our managed database provider performs automated backups with point-in-time recovery. Planned A documented disaster recovery plan with defined RPO/RTO targets and periodic restore testing is in progress.
7. Logging and monitoring
Live The Service maintains an append-only audit log. Today it records operator actions — in particular, when Restock staff sign in to a customer workspace to provide support, with the actor, the target account, the stated reason, and the time. Database policies reject updates and deletes on the audit log for every application role, so entries cannot be edited or removed after the fact through the product; the underlying service credential used for migrations bypasses row-level security, as it must. Infrastructure and application logs support troubleshooting and security investigations. Planned Writing authentication events and customer-side data changes into the same audit log, and centralized log aggregation with alerting and anomaly detection.
8. Vulnerability management and responsible disclosure
Live We monitor the dependencies we build with for known vulnerabilities and apply patches on a risk-prioritized basis. We welcome reports from security researchers under our responsible disclosure process — see the Trust Center for how to report and our safe-harbor commitment. Planned Independent third-party penetration testing is scheduled prior to general availability.
One exception worth naming. Several browser features load JavaScript at runtime from public CDNs (unpkg, jsDelivr, cdnjs, esm.sh, and Sentry's CDN) rather than from our own origin, and those tags do not currently carry subresource-integrity hashes. That means a change at the CDN would reach a user's browser without being caught by the dependency monitoring above. The affected features are map rendering, PDF and spreadsheet export, document parsing in the contract builder, barcode scanning, error reporting, and — on every page that signs a user in — the Supabase JavaScript client itself, which is fetched from esm.sh at a floating major version rather than a pinned build. Planned Pinning these to integrity-checked versions, or serving them from our own origin.
9. Compliance
Planned SOC 2 Type II is in progress, with controls tracked continuously in Drata; our target for completing the observation period is Q4 2026. Live Our practices are designed to align with GDPR and CCPA/CPRA; see the Privacy Policy and DPA.
10. Payment security
Live Payments are processed by Stripe, a PCI DSS Level 1 service provider. Full payment card numbers are entered directly into Stripe's elements and never touch Restock's servers. Restock does not store full card numbers; we retain only payment metadata such as the last four digits, card brand, and transaction identifiers.
11. People and vendors
Live Personnel with access to production are bound by confidentiality obligations. Planned Recurring security awareness training and a formal vendor security review program for sub-processors are being implemented. Our current sub-processors and their due-diligence status are listed in the Trust Center. A second group of third parties — public routing, map tile, font, and code-CDN endpoints that the browser calls directly — is used under those providers' own public terms without a negotiated agreement or a vendor review. Those are listed, and labelled as such, in Annex III of the DPA.
12. Reporting and contact
To report a security concern or vulnerability, email security@restock.supply and follow the disclosure guidance in the Trust Center. We aim to acknowledge reports promptly and coordinate on remediation and disclosure.