Data Protection & Information Security Policy

Effective July 13, 2026 · Shaazford Global LLC

This document describes the technical and organizational measures Shaazford Global LLC applies to protect data processed by Shaazford OS. It answers marketplace developer-program security questionnaires (including the Amazon SP-API Data Protection Policy) and gives clients a plain account of how their data is handled. Security contact: info@shaazford.com.

1. Scope & data we process

Shaazford OS is a multi-tenant operations platform operated by Shaazford Global LLC. Each customer organization is an isolated tenant. Through the platform we may process operational business data (projects, tasks, documents, messages, time logs, client accounts, invoices), ecommerce performance metrics (product-level sales, units, sessions, conversion, ad spend and inventory, pulled from connected stores or uploaded via CSV), account data (name, email, role, hashed credentials), and integration credentials (OAuth/API tokens for services a user connects).

We do not collect or store buyer/consumer personally identifiable information (PII). Marketplace pulls are limited to non-restricted roles — aggregate product sales, traffic and inventory. We do not request order-level buyer names, shipping addresses, or contact details, and we request the narrowest scopes needed.

2. Hosting, data location & network security

• Hosted on a dedicated Hostinger VPS (Ubuntu) operated solely by Shaazford Global LLC.
• The application runs in Docker containers behind the Caddy reverse proxy; data is stored in SQLite on a Docker-managed volume. Each customer workspace is a separate tenant, isolated at the query layer.
• Network security: a host firewall (ufw) default-denies inbound traffic except SSH/HTTP/HTTPS; fail2ban provides intrusion detection/prevention against brute-force attempts; ClamAV and rkhunter provide anti-malware/rootkit scanning; the application runs in isolated Docker networks; and unattended-upgrades applies OS security patches automatically.

3. Encryption

• In transit: all traffic is served over HTTPS/TLS (TLS 1.2+), certificates auto-renewed by Caddy; HTTP redirects to HTTPS. Outbound provider calls use HTTPS.
• At rest: stored integration credentials are encrypted with AES-256-GCM using a key held only in the server environment (never in source control). Passwords are stored as bcrypt hashes. Derived access tokens are short-lived and not persisted.

4. Access control

• Role-based access control — Owner/Admin, Operator, Manager, Member, Client, Guest; users see only what their role and share grants permit.
• Tenant isolation — one tenant can never read another tenant's data.
• Authentication — email/password (bcrypt) or Google SSO, with optional workspace-enforced two-factor authentication (TOTP) and brute-force lockout.
• Password policy — new/changed passwords require a 12-character minimum with a special character (plus a letter and a number), combined with MFA and a 365-day rotation policy; password age is tracked per user.
• Sessions — server-side sessions with signed cookies; users can view and revoke active devices. An optional IP allow-list can restrict sign-in.

5. Credential handling

• Credentials are validated on connect, encrypted, and stored against the connecting user's account.
• Credentials and access tokens are never written to logs and are not exposed in API responses or the UI.
• Disconnecting an integration deletes the stored credentials immediately.

6. Data retention & deletion

Operational and metric data is retained while the workspace/account is active. Integration credentials are deleted on disconnect. On a verified deletion request or account termination, associated data is deleted from the live database within a commercially reasonable period and purged from backups on the normal rotation cycle.

7. Backups & resilience

Nightly on-box database backups (consistent, integrity-checked, compressed SQLite snapshots retained 14 days) plus a weekly off-box backup of the latest snapshot. Backups carry the same at-rest encryption for credential fields as the live database.

8. Logging, monitoring & audit

An append-only audit trail records security-relevant actions (logins, permission/role changes, integration connect/disconnect, approvals, exports). Application logs exclude secrets and tokens. Server access is restricted to authorized administrators via SSH key authentication.

9. Subprocessors

We do not sell data, and we do not share client data with any party other than the subprocessors above in service of the product.

10. Incident response

We maintain a written Incident Response Plan with defined roles, a 6-month review cadence, and a 24-hour notification target. Suspected incidents are reported to the Incident Response Lead and triaged immediately; affected credentials are rotated/revoked and integrations disconnected. Where an incident involves Amazon Information, we notify Amazon at security@amazon.com within 24 hours of detection; affected sellers/clients are notified without undue delay. A root-cause review follows every incident.

11. Organizational measures

Access to production systems and credentials is limited to authorized personnel on a need-to-know basis, protected by SSH keys and, where applicable, 2FA. Personnel maintain confidentiality of any data they can access. Secrets are managed via server environment configuration and excluded from source control.

12. Compliance posture

We align with widely accepted data-protection principles (lawfulness, purpose limitation, data minimization, integrity and confidentiality). This is a policy statement, not a claim of formal certification (e.g. SOC 2, ISO 27001). Clients requiring contractual data-processing terms should contact us at info@shaazford.com.