Data Protection Policy

1. Scope & Data Classification

This policy governs how 4TR collects, processes, stores, and disposes of Amazon Information retrieved through the Selling Partner API (SP-API), including:

• Order information: order IDs, items, quantities, prices, status
• Customer PII (for shipping fulfillment only): buyer name, shipping address, phone, email
• Listings & inventory: SKUs, ASINs, titles, prices, stock levels
• Financial events: Amazon fees, payouts, adjustments
• Authentication tokens: OAuth refresh and access tokens (encrypted)

Data is classified as Confidential (customer PII, tokens) or Internal (listings, financial events). Public/marketing data is out of scope.

2. Processing Records

As required by GDPR Article 30, we maintain records of all processing activities:

• Categories of data subjects (Amazon Sellers, their end customers)
• Categories of personal data (order PII for shipping)
• Categories of recipients (sub-processors listed in §6 below; carriers when labels are purchased)
• Retention periods (§5)
• Technical and organizational security measures (§4)

Records are reviewed at least annually by the Lead IMPOC.

3. Lawful Basis & Purpose Limitation

We process Amazon Information solely to deliver the service the seller has authorized: order synchronization, inventory management, listing maintenance, financial reporting, and shipping label purchase. Amazon Information is never used for advertising, profiling, model training, sale to third parties, or any purpose unrelated to the seller's operations.

4. Encryption & Key Management

At rest

• OAuth tokens: application-layer AES-256 encryption via PostgreSQL pgcrypto (pgp_sym_encrypt), with environment-isolated keys (separate keys for sandbox and production)
• Database storage: Supabase Postgres on AWS RDS with AES-256 disk-level encryption
• Key management: Supabase Vault (KMS abstraction over PostgreSQL pgsodium). Keys are never embedded in application code.
• Decryption functions: restricted to service_role only via PostgreSQL GRANT EXECUTE

In transit

• TLS 1.2+ enforced on every connection (Vercel HTTPS, Supabase, all marketplace and carrier APIs)
• HSTS enforced via Vercel Edge Network

5. Data Retention & Disposal

• Amazon customer PII (shipping addresses, contact details): automatically purged 30 days after order shipment via a daily scheduled job. City, country, and postal code are anonymized; name, line 1/2, email, and phone are deleted.
• Tax-relevant order data: retained for the period required by applicable tax law (5–10 years), without customer PII
• OAuth tokens: deleted within 24 hours of integration disconnect
• Account data: retained while active; 90-day soft delete window after closure; then hard-deleted
• Audit logs: minimum 12 months, append-only
• Backups: overwritten on a 7-day rolling basis

Disposal is irreversible: hard-deleted rows are removed from active tables, and after the backup rollover window (≤7 days) are unrecoverable.

6. Access Control

• Multi-tenant isolation: every tenant-scoped database table has Row-Level Security policies enforcing company_id matching
• Need-to-know: production access is limited to the Lead IMPOC; access by additional engineers is granted via individual GitHub accounts with SSO into Vercel and Supabase dashboards
• MFA: Multi-factor authentication is required for all administrator accounts (TOTP or hardware security keys)
• Password policy: minimum 12 characters with complexity requirements, enforced at the auth provider level
• Service accounts: use scoped API keys with the principle of least privilege; rotated periodically
• Sub-processors: see §6.1

6.1 Sub-Processors

Cross-border transfers outside the EEA are protected by Standard Contractual Clauses (GDPR Article 46).

7. Network & Endpoint Security

• No public ingress to databases. Supabase Postgres is accessible only via authenticated PostgREST / pgbouncer.
• Vercel Edge Network provides WAF, DDoS mitigation, and rate limiting
• Service role keys stored as encrypted environment variables (never in source code)
• Developer endpoints (Supabase Dashboard, Vercel Dashboard, GitHub) require SSO + MFA
• Network segmentation: production and sandbox use separate Supabase projects with separate encryption keys
• Endpoint controls: developer workstations use macOS FileVault full-disk encryption; production access is never performed from personal mobile devices

8. Vulnerability Management

• Dependency scanning: GitHub Dependabot runs weekly; security updates are auto-PR'd
• Static analysis: GitHub CodeQL runs on every push and pull request, with weekly full scans (security-extended + security-and-quality query packs)
• Secret scanning: Gitleaks + GitHub Secret Scanning on every push
• Dependency audits: npm audit --audit-level=high blocks PRs with high/critical vulnerabilities; daily scheduled scans
• Penetration testing: annual external penetration test; findings tracked as GitHub Issues with severity-based SLAs
• Remediation SLAs: Critical = 7 days; High = 30 days; Medium = 90 days; Low = next release
• Tracking: all findings tracked as GitHub Issues using the security-finding template with mandatory target dates and a verification checklist

9. Logging & Monitoring

• Application logs: Vercel runtime logs with anomaly alerts
• Database logs: Supabase Postgres logs (query, error, auth)
• Security audit log: append-only security_audit_log table records token decryption, admin actions, bulk operations, auth failures, PII purges. Minimum 12-month retention.
• Bi-weekly review: the Lead IMPOC reviews security_audit_log and GitHub Security tab every two weeks
• GitHub audit logs: records all code, infrastructure, and access changes

10. Backup & Disaster Recovery

• Automated daily backups with 7-day retention (Supabase Pro)
• Point-in-Time Recovery (PITR) with 5-minute granularity
• Geographic separation: backups stored in AWS regions separate from the primary database
• RTO (Recovery Time Objective): ≤ 4 hours
• RPO (Recovery Point Objective): ≤ 5 minutes (with PITR)
• Restore testing: quarterly via staging environment

11. Change Management

• All production changes deploy via Vercel Git integration from the main branch
• Pull requests require: automated CI checks (TypeScript, lint, build, npm audit, CodeQL, secret scan)
• Pre-production validation: every PR builds a Vercel Preview deployment
• Database migrations are version-controlled in supabase/migrations/ and applied via Supabase CLI or MCP with audit trail
• Roles: code authoring (engineer) and merge approval (maintainer) are separated

12. Testing with PII

Production Amazon Information is never copied to development, staging, or testing environments. Sandbox uses Amazon SP-API sandbox endpoints with synthetic test data only. Production database access for debugging is limited to non-PII fields; any PII access requires explicit approval and is recorded in the security audit log.

13. Credential Protection

• All secrets stored as encrypted environment variables in Vercel
• OAuth tokens double-encrypted: application-layer (pgcrypto) + storage-layer (AWS)
• Pre-commit and push-time secret scanning via Gitleaks + GitHub Secret Scanning
• .env files are excluded from version control via .gitignore
• API keys for sub-processors are rotated at least annually or immediately on personnel change

14. Incident Response

We maintain a documented Incident Response Plan with the following key parameters:

• Roles defined: Lead IMPOC, Technical Owner, Communications
• Six-phase response: Detection → Triage → Containment → Eradication → Recovery → Post-mortem
• Amazon notification: within 24 hours of detection to security@amazon.com for incidents involving Amazon Information
• Customer notification: without undue delay; within 72 hours for GDPR personal data breaches
• Review cadence: Incident Response Plan reviewed every 6 months
• Tabletop exercises: annual simulation

15. Incident Management Point of Contact (IMPOC)