How Orbitra Protects Your Data

Governance

We maintain documented information security, data handling, classification and privacy policies, reviewed at least annually and after any material platform change. Data is classified on collection and buyer personal information is handled at the highest tier

Network protection

Databases, queues and internal services run in private subnets with no public IP and no route from the internet. Administrative access is only via VPN or bastion with multi-factor authentication. Security groups deny all inbound traffic by default, permitting only required ports from allow-listed sources. Datastores require TLS and authentication and are bound to private networks. Public traffic terminates at a web application firewall and load balancer exposing HTTPS on port 443 only. Developer endpoints run host firewalls with no inbound access.

Access control and devices

Everyone with access has a unique named account provisioned through single sign-on with mandatory multi-factor authentication; shared logins are prohibited. Access is granted by role on a least-privilege basis, requires documented business need and manager approval, and production database and buyer-PII access is limited to a small named group. Entitlements are reviewed quarterly and revoked within 24 hours of a role change or departure, and every access is logged against a named user.

Access is only permitted from company-managed devices under mobile device management, which enforces full-disk encryption, screen lock and an endpoint detection and response agent, and blocks USB mass storage and removable-media writes. Device compliance is checked at sign-on, so an unmanaged personal device cannot authenticate to production. Blocked transfer attempts and non-compliant devices raise real-time alerts, triaged within 24 hours.

Encryption and key management

All data in transit is encrypted with TLS 1.2 or above; plain-text HTTP is redirected and unsupported, and internal service-to-service traffic is encrypted too. Data at rest is encrypted with AES-256 across database volumes, object storage and every attached disk, and buyer personal information is encrypted a second time at the application layer with AES-256-GCM, so it is unreadable even to someone with database-level access. Keys and application secrets live in a managed key management and secrets service, never in source code, configuration files or container images; key access is IAM-restricted to the services that need it, rotated at least annually, and every key use is logged and auditable.

Backups and recovery

Backups are AES-256 encrypted with managed keys, taken daily with continuous point-in-time recovery, and replicated to a second geographic region separate from the primary. They inherit production access controls, are never stored unencrypted or on removable media, and follow production’s retention and deletion schedule. Restore procedures are documented and tested at least twice yearly into an isolated environment with integrity validation.

Data retention and deletion

Buyer personal information is deleted within 30 days of shipment, unless a tax authority or marketplace rule requires a specific record to be kept longer. Catalog, listing and order records are deleted within 30 days of account closure. Operational logs are kept 90 days and security audit events 12 months. Deletion covers primary storage and backups within the backup rotation window; where a backup cannot be selectively edited the data is removed as that backup expires and stays encrypted and access-controlled until it does.

Logging and monitoring

Application, database, authentication and infrastructure logs — including every access to buyer personal information and every administrative action — ship to a centralised, append-only logging platform, retained 90 days for operational events and 12 months for security audit events. Automated alerts fire on anomalous logins, privilege escalation, unusual volumes of personal-data queries, configuration changes and endpoint or firewall detections, routed to an on-call responder. Investigations correlate logs by user, IP and request identifier, and findings are documented.

Incident response

We maintain an incident response plan with defined roles, reviewed every six months and exercised against realistic scenarios. On a confirmed incident we triage from automated alerting to an on-call responder, assign severity and notify the Incident Management Point of Contact, contain by isolating hosts and revoking tokens, keys and credentials, preserve logs and system state for forensics before remediation changes them, eradicate the root cause rather than the symptom, recover from verified clean backups under heightened monitoring, then notify and review.

Affected merchants are notified without undue delay and within 48 hours. Where Amazon Information is involved we notify security@amazon.com within 24 hours of detection, and regulators and data subjects as the law requires. Every post-incident review produces corrective actions with a named owner and due date, tracked to closure.

Vulnerability management

We scan for vulnerabilities on a defined cycle and commission independent penetration testing annually against the production application and its infrastructure. Every finding becomes a ticket with a severity, named owner and due date in a remediation register reviewed at a recurring security meeting. Closure requires verification by re-scan or retest — not a developer’s assertion — and items breaching their deadline escalate to engineering leadership.

Secure development and credentials

Every code change requires peer review and must pass blocking automated gates before merge: static analysis, dependency and software-composition scanning, secret scanning and linting, with builds failed on critical or high findings. Changes are evaluated in a dedicated test environment before production under a formal change management process defining who tests, verifies, approves and deploys. At runtime we patch operating systems, containers and dependencies monthly and apply critical patches within 7 days.

API client secrets, refresh tokens, API keys and database credentials live in a managed secrets manager, injected as runtime environment variables, never hard-coded or committed to source control, tickets, logs or chat. Repositories enforce secret scanning and pre-commit hooks that block commits containing secrets. Secrets access is IAM-restricted and audit-logged, rotated at least every 90 days and immediately on suspected exposure. Passwords are enforced centrally at a 12-character minimum with mixed case, number and symbol, screened against breached-credential lists, no reuse of the previous ten, and lockout after repeated failures, with multi-factor authentication mandatory on every account.

Personal information in testing

Buyer personal information is never copied into development, test, staging or QA environments. Testing uses synthetic fixtures and marketplace sandboxes, or anonymised and pseudonymised data. Non-production systems hold no production credentials and have no network route to production databases, and personal information retrieved for an order is never written to logs, error traces or analytics. Any exception requires masking, engineering lead approval, execution only in production, and is itself logged.

Sub-processors

We use a small number of service providers, each assessed before onboarding, reviewed periodically, and bound by a written contract with confidentiality and security obligations at least as strict as our own. None receives more data than its function requires and none may use your data for its own purposes. The current list is published in our Privacy Policy, and we give advance notice before adding one.

Reporting a vulnerability

If you believe you have found a security issue, email admin@orbitracommerce.com with enough detail to reproduce it. We acknowledge within one business day, keep you updated, and will not pursue anyone who reports a genuine issue in good faith, avoids accessing other merchants’ data, and gives us reasonable time to fix it before disclosing publicly. Please do not run automated scanning or load testing against production without asking first.