Data Protection Policy

This Data Protection Policy is the technical and operational counterpart to our Privacy Policy. It is written for the procurement teams, security engineers, and counsel who evaluate Boxpress as a vendor and ask the questions GDPR Article 32 ("security of processing") and SOC 2 are built around. We name algorithms, retention windows, and processes specifically so that nothing is left to interpretation.

1. Encryption

1.1 At rest

Sensitive fields are encrypted at the application layer with AES-256-GCM before they touch the database. The encryption key is held in environment configuration outside the database and rotated on a documented schedule. Fields covered include:

• Integration API keys (FluidPay, Stripe, Resend, etc.)
• Magic-link signing secrets (per-tenant)
• Age-verification provider credentials
• EIN (employer identification number)
• Federal TTB permit numbers
• State tobacco license numbers
• TOTP MFA secrets
• OAuth refresh tokens for connected accounts

Database backups are encrypted with the cloud provider's AES-256 native encryption in addition to application-layer encryption on sensitive fields. A database compromise alone does not yield plaintext values for the fields above.

1.2 In transit

• TLS 1.3 minimum on all public endpoints. TLS 1.2 is allowed only for legacy webhook sources we cannot upgrade unilaterally; this is logged and reviewed.
• HSTS preload with max-age=63072000; includeSubDomains; preload.
• Secure cookies: HttpOnly + Secure + SameSite=Lax (or Strict where session semantics permit).
• Internal traffic between application containers and the database stays inside Railway's private network and is encrypted in transit.

2. Multi-Tenant Isolation (Pattern 2 Strict)

Every Boxpress customer install runs against a dedicated Postgres database, on a dedicated Railway service. There is no shared application database with row-level-security separating tenants. There is no "tenant_id" column anyone could forget to filter on. Tenants are physically separate at the database connection level.

• One Postgres database per Boxpress install.
• One application container per install for runtime separation.
• Per-tenant connection strings; no shared admin connection across tenants.
• R2 buckets scoped per tenant for object storage; signed URLs scoped to the tenant's prefix.
• Per-tenant API rate limits and resource quotas to prevent noisy neighbors from affecting other installs.

If your competitor is also a Boxpress customer, your data and theirs never sit in the same database. They never sit on the same database server in many cases (depends on Railway placement).

3. Access Controls

3.1 Per-tenant rotating magic-link secrets

When Boxpress engineering needs to access a customer install for support, the access token is signed with that install's unique magic-link secret, not a shared master secret. Properties:

• Per-tenant secret stored encrypted at rest (AES-256-GCM).
• Token expiry: 5 minutes from issue.
• Single-use enforcement via JTI (JWT ID) tracking; replay attempts are rejected.
• Every magic-link issuance and use is logged with user, tenant, timestamp, and IP. Logs are immutable.
• Customer-side admins can rotate their install's magic-link secret on demand (immediately invalidates outstanding support tokens).

This is the answer to "what stops one compromised employee credential from accessing every tenant?" - one compromised credential cannot impersonate any tenant for which it has not been explicitly authorized to mint a token.

3.2 Audit logging

Every administrative action inside an install is recorded to an immutable audit log: who, what, when, from where. Customer-side admins can review their own install's audit log in the admin UI. Boxpress employee actions are recorded against the named employee, not against an anonymous "system" user.

3.3 Internal access controls

• Production access limited to a small named team. Onboarding and offboarding are documented and logged.
• All employee accounts require MFA on every system that supports it.
• Quarterly review of who has production access; over-provisioned access is removed.
• Production deploys go through code review and CI before reaching customer environments.

4. Authentication and Account Security

• Password hashing: Argon2id with project-tuned cost parameters. We do not use unsalted MD5/SHA1 hashes anywhere.
• MFA: optional TOTP second factor. Recovery codes generated on enrollment, encrypted at rest, single-use.
• Account lockout: 10 failed login attempts triggers a 30-minute lockout. Failed attempts are logged with IP for security review.
• Session expiry: 14 days of inactivity, or browser close (whichever comes first). Active sessions can be terminated by the user from the admin UI.
• Password reset: single-use, time-limited (15 minutes), invalidated on use or after new login.

5. Backup and Disaster Recovery

• Daily automated snapshots of every per-tenant Postgres database.
• 30-day retention on snapshots for all tiers.
• Cross-region replication available on the Scale tier for additional resilience.
• Recovery objectives: RPO 24 hours, RTO 4 hours for full-region failover. We document and test these.
• Restore tests are performed at least quarterly against a test install to verify backup integrity.

6. Incident Response

We treat security incidents the way we said we would treat deplatforming: a real conversation, on time, with detail.

• Initial notification: within 24 hours of confirmed unauthorized access to customer data, we email affected customers with what we know.
• Full disclosure: within 72 hours per GDPR Article 33: nature of the breach, categories and approximate number of records affected, likely consequences, measures taken or proposed.
• Post-incident report: within 30 days of resolution, root cause analysis, timeline, remediation, and preventive measures.
• Regulator notification: handled by us where we are the controller, supported with documentation where the customer is the controller.

7. Sub-Processor Management

Boxpress maintains a formal list of sub-processors. The current list (with category, location, and purpose):

7.1 Infrastructure

• Railway (US, EU) - application runtime hosting and per-tenant Postgres databases.
• Cloudflare (Global) - CDN, DDoS protection, DNS, R2 object storage for media uploads and generated PDFs.

7.2 Payments

• Stripe(US) - SaaS subscription billing for Boxpress's own monthly fee.
• FluidPay (US) - payment processing for tenant cigar transactions. Boxpress does not see card data.

7.3 Communications

• Resend (US) - transactional and marketing email delivery.

7.4 Marketing automation (tenant sub-processor)

• Proof Points (US) - marketing automation engine. Stores customer email, phone, and contact data for tenants who use the marketing automation feature; fires workflows on Boxpress events.

7.5 Analytics (marketing site only)

• Google Analytics 4 (US) - aggregated traffic analytics on boxpress.io. IP anonymization on. 14-month data retention.
• Google Search Console (US) - SEO indexing tool. No user data collected.
• Microsoft Clarity (US) - heatmaps and session replay on boxpress.io. PII masking enabled (input fields, sensitive text, emails). Sessions retained 30 days at Microsoft.

7.6 Monitoring

• Sentry (US) - error monitoring. PII is scrubbed from error reports before they leave the application.

7.7 AI services

• Anthropic (US) - English-to-Spanish translation pipeline (admin tool only). Customer Data is not sent to Anthropic. Anthropic does not train models on data sent through the API.

7.8 Identity verification (BYO)

• Persona, Veriff, AgeChecker.net - age verification providers. Tenants bring their own account and are the data controller for the PII collected during verification. Boxpress is not the data controller for these flows; we orchestrate the redirect and receive a signed callback indicating the verification result.

7.9 Maps

• Mapbox (US) - public lounge map rendering on tenant sites.

7.10 Sub-processor change notifications

When we add a new sub-processor that processes Customer Data, we will notify active customers by email at least 30 days before the new sub-processor goes live. If you object, you can terminate your subscription before the change takes effect with a pro-rated refund of any prepaid fees beyond the termination date (this is a contractual addition to the standard cancellation rules in the Terms).

8. Data Processing Agreement (DPA)

We sign Data Processing Agreements for any customer that requests one. Our standard DPA covers:

• Subject matter, duration, nature, and purpose of processing
• Types of personal data and categories of data subjects
• Controller and processor obligations under GDPR Articles 28 and 32
• Sub-processor authorization and notification
• Standard Contractual Clauses (SCCs) for EU/UK to US transfers
• Data subject rights cooperation
• Breach notification obligations
• Audit rights (with reasonable scoping)
• Return or deletion of data on termination

To request a DPA, email [email protected].

9. Customer Data Control

• Export anytime: CSV from the admin UI; full Postgres dump on request (delivered within 72 hours, encrypted, time-limited download).
• Deletion on request: within 30 days of cancellation request, except where law requires longer retention (tax records, PACT Act records).
• No lock-in: we will answer schema and integration questions to help you migrate out.
• Backup deletion: Customer Data is purged from active backups according to the 30-day retention window; the data is gone within 30 days of the deletion request.

10. Penetration Testing and Adversarial Audits

• External penetration test: annually by a qualified third-party firm. Findings are categorized, prioritized, and resolved per documented severity SLAs (Critical: 24 hours, High: 7 days, Medium: 30 days, Low: 90 days).
• Internal red-team audits: ongoing. Our most recent adversarial security audit covered seven pillars (auth, input handling, access control, crypto/secrets, network/infra, business logic, data privacy) and surfaced 35 issues. All Critical and High findings were resolved within 24 hours; Medium and Low findings are tracked through the engineering backlog with named owners and target dates. A summary of the latest audit is available to enterprise customers under NDA.
• Continuous integration: dependency vulnerability scanning on every build; secret scanning in pre-commit and CI; static analysis on backend and frontend.

11. Vulnerability Disclosure

If you discover a security vulnerability in Boxpress, please report it to [email protected]. We commit to:

• Acknowledging your report within 48 hours.
• Providing a status update within 7 days, including triage outcome.
• Coordinating disclosure timing with you. We do not pursue legal action against good-faith researchers who follow responsible disclosure.
• Crediting you in any post-incident or transparency report unless you prefer to remain anonymous.

Out of scope: social engineering of Boxpress employees, physical attacks, automated scanning that creates noticeable load, denial of service.

12. Compliance Frameworks

• GDPR / UK GDPR: we process personal data per Articles 28 (processor obligations), 32 (security of processing), and 33 (breach notification). We sign SCCs for EU-US transfers.
• CCPA / CPRA: we honor California resident rights and Global Privacy Control signals where applicable.
• SOC 2: Type 1 in progress, target Q3 2026; Type 2 target Q1 2027. We do not claim existing certification.
• PCI DSS: Boxpress is a SAQ-A scope service - we do not store, process, or transmit cardholder data. Stripe and FluidPay handle PCI-relevant flows.
• HIPAA: not in scope. Boxpress does not process protected health information.

13. Document Control

This policy is reviewed at least annually and updated when controls materially change. Material changes trigger a 30-day notice to active customers and an archived prior version remains accessible.

14. Contact

Security disclosure: [email protected]
Privacy: [email protected]
Legal/DPA requests: [email protected]
General: [email protected]
Mailing: Boxpress LLC, [STREET], [CITY], [STATE] [ZIP], United States

All four addresses currently route to [email protected]. We will split them as the team grows.

Last updated: 2026-05-04