Data Protection Policy

This policy describes how Charming Holdings LLC collects, processes, stores, shares, and disposes of buyer data received from the online marketplaces where we sell. It is the internal operational counterpart to our public-facing privacy policy.

1. Data inventory and classification

2. Collection

Buyer data is collected only via the marketplaces' official APIs (Amazon SP-API, Walmart Marketplace API, eBay Trading API). We do not collect buyer data from any other source. Each API call is authenticated with credentials tied to our own seller account on that marketplace.

3. Processing

Processing is limited to the following purposes:

• Display the order's shipping details to the employee fulfilling it
• Print one shipping label per order
• Track fulfillment status (sourced, ordered, shipped, delivered)
• Reconcile refunds, fees, and profit for accounting

Buyer data is never used for marketing, profiling, analytics, machine learning, or any purpose other than fulfilling the specific order it belongs to.

4. Storage and encryption at rest

• All data is stored in a PostgreSQL database on a single Linux server in a private cloud.
• The columns storing PII (buyer name, address lines, email) are encrypted at the column level using PostgreSQL's pgcrypto extension with AES-256-CBC.
• The encryption key is stored in a chmod 600 binary file owned by root, outside the application source repository, and rotated annually.
• The underlying disk volume is encrypted with LUKS (AES-256-XTS).
• PostgreSQL accepts connections only from localhost (127.0.0.1); it is not reachable from the public internet.

5. Encryption in transit

• All web traffic uses TLS 1.2 or higher; HTTP redirects to HTTPS. The TLS chain is provided by Cloudflare.
• API calls outbound to marketplace APIs use HTTPS only.
• Database connections are localhost-only, so no cross-network encryption applies.

6. Access control

• Each user has a unique account in app_users with a bcrypt-hashed password (cost factor 12).
• Two roles exist: admin (currently 1 person) and employee (currently 3 people). Sharing accounts is prohibited by written policy.
• The application enforces role at the route handler before rendering any page. Employees see only the order ID and product fields they need to do their job; PII is filtered server-side before rendering.
• Multi-factor authentication (TOTP) is required for the admin account and available for employee accounts.
• Departing personnel have their accounts disabled within 1 business day.

7. Logging and monitoring

• All HTTP requests are logged by Flask plus systemd journald with timestamp, source IP, authenticated username, endpoint, and HTTP response code.
• Authentication and authorization events (login, password change, role change, PII export) are written to a dedicated audit log file retained for 12 months.
• Logs by design contain no PII; they reference order IDs only.
• The admin reviews the audit log every two weeks for anomalies (off-hours access, PII endpoint spikes, repeated failures from new IPs).
• fail2ban automatically blocks source IPs after 5 failed login attempts in 10 minutes.

8. Sharing

Buyer data is not sold, leased, or shared with any third party for marketing, analytics, brokerage, or advertising purposes. The only outside parties involved in handling buyer data are: the marketplaces themselves, the shipping carriers we hand packages to, and the infrastructure providers (cloud host, content-delivery network) that host or secure our systems.

9. Retention and disposal

• Buyer name and shipping address are automatically purged from our production database 90 days after the order's ship date. The 90-day window exists solely to support marketplace return and claim processes.
• Buyer email (when collected) is removed once the order is delivered.
• Order metadata (order ID, products, quantities, sale amount) is retained indefinitely for accounting and inventory analysis after PII is purged.
• Backups containing PII follow the same 90-day window; backups older than 90 days are pruned automatically.

10. Backup

• The database is dumped nightly (pg_dump), encrypted with AES-256-GCM, and uploaded to a Backblaze B2 bucket in a different US geographic region from the primary server.
• Backups are retained for 30 days, then automatically deleted.
• Restore-from-backup is tested quarterly.
• Recovery Time Objective (RTO): 4 hours. Recovery Point Objective (RPO): 24 hours.

11. Testing and development

• Development and testing run against a separate staging database populated only with synthetic test data generated by the Python Faker library. Production PII never enters the staging environment.
• Production bug investigations that may involve PII are conducted via read-only psql on the production server over SSH; all such sessions are logged.

12. Incident response

Refer to the Incident Response Plan for the detection, containment, notification, remediation, and recovery process. Security incidents involving marketplace data trigger notification to the affected marketplace's security team within 24 hours of detection.

13. Policy ownership and review

This policy is owned by the Incident Management Point of Contact (Betzalel Bree) and reviewed every six months. Changes are committed to our private repository with an audit trail of who changed what and when.