Information Security Program

1. Information security policy

Ownership

Navexa's founder owns this program and is accountable for security decisions, access grants, incident handling and policy updates. Anyone who later joins Navexa with access to production systems must read and follow these policies before access is granted.

Principles

• Collect only the data needed to sync orders, products and inventory and to ship.
• Give each person and system the least access it needs.
• Encrypt data in transit everywhere and encrypt credentials and buyer contact details at the application level.
• Keep production changes reviewable: every change goes through version control and CI, and deploys only from tagged releases.
• Delete data when the seller relationship that justified it ends.

Review

We review this program at least once a year, and also after any security incident or any material change to our infrastructure or to the data we process. Each review updates the version and dates at the top of this page.

2. Access control policy

Least privilege

Access to personal data is granted only to people whose work requires it, at the lowest level that does the job. Today one person, the founder, has access to production infrastructure, the production database, source code and cloud consoles.

Authentication

• Two-factor authentication is required on every account with access to Navexa systems: DigitalOcean, GitHub, Cloudflare, Google (Firebase) and Stripe.
• Shared logins are not allowed. Each person uses their own named account.
• Production application credentials (database passwords, API keys, marketplace app credentials) are stored encrypted with SOPS or in the CI secret store. Source code lives in private repositories that only the founder can access.

Application access

• Every API request is bound to one seller account, and queries are filtered by that account. A seller cannot see another seller's data.
• Sellers control their own team's access with four roles: Read, Write, Admin and Owner.
• Navexa staff look at a seller's data only to provide support the seller asked for, to fix a problem, or to meet a legal obligation.

Granting and removing access

The founder approves every grant of production access. Access is removed the same day a person leaves or no longer needs it, and any credentials they could have seen are rotated. The list of people with production access is reviewed at each annual review.

3. Data classification and encryption policy

• All data in transit uses TLS 1.2 or higher.
• At rest, the managed database and its backups are encrypted by DigitalOcean, and the fields listed above are encrypted again by our application before storage.
• Restricted and confidential data must not be copied to personal devices, email or chat, except a single record needed to answer a seller's support request.

4. Endpoint security policy

Every computer used to access Navexa systems must have:

• Built-in malware protection turned on. Our computers run macOS, which provides XProtect anti-malware scanning and Gatekeeper application verification.
• Full-disk encryption (FileVault) turned on.
• Automatic operating system security updates turned on.
• A password and an automatic screen lock.

A lost or stolen device is reported to the founder immediately, and every credential stored on it is rotated.

5. Vulnerability management policy

• Dependabot scans our Go, JavaScript and CI dependencies weekly. Alerts for critical and high-severity vulnerabilities are fixed ahead of feature work.
• Every code change must pass our automated tests in CI before it merges.
• We use managed services (database, cache, Kubernetes) so the provider patches the underlying systems.
• Sentry alerts us to backend errors, which we review for signs of abuse as well as bugs.
• Anyone can report a vulnerability to [email protected]. We acknowledge reports within 2 business days.

6. Incident response policy

A security incident is any event that could compromise the confidentiality, integrity or availability of seller or buyer data: for example a leaked credential, unauthorised access, or data sent to the wrong party.

Roles

• Incident lead: Navexa's founder. Runs the response, decides on containment, and sends all notifications.
• Reporters: anyone (staff, sellers, marketplaces, researchers) reports suspected incidents to [email protected].

Channels

• Inbound: [email protected].
• Outbound: email to the account owner of each affected seller, and to the affected marketplace through its partner contact channel (for TikTok Shop, the email and Partner Center contact registered for our app).

Procedure

1. Record the report and start an incident log with times and actions.
2. Contain: revoke or rotate affected credentials, disable affected integrations or accounts, block the access path.
3. Assess which sellers, buyers and data fields are affected.
4. Notify: within 72 hours of confirming a breach of personal data, email affected sellers and the marketplace the data came from, describing what happened, which data was involved, what we have done and what they should do. We also notify regulators or individuals where the law requires it.
5. Remediate the cause and confirm the fix in production.
6. Within 2 weeks of closing the incident, write a post-incident review and update these policies if needed.

7. Personal data protection policy

Purpose limitation

Buyer data received from a seller's store or marketplace (name, email, phone, shipping address, order contents) is used only to fulfil that seller's orders: syncing the order, buying the shipping label, sending tracking back to the marketplace, and supporting the seller. We do not sell buyer data, use it for advertising or marketing, or combine it across sellers.

Who processes it

• DigitalOcean: hosting, database and file storage (United States).
• EasyPost and the carrier chosen for a shipment: the label's ship-to name, address and phone.
• Sentry: backend error reports, which can include details of the order being processed when an error occurs.

Google (Firebase Authentication), Stripe, PostHog and Cloudflare process data about Navexa's own users (sellers), not marketplace buyer data.

Retention and deletion

• Buyer data is kept only while the seller's connection to that store or marketplace is active.
• When a seller disconnects (for TikTok Shop, when the seller deauthorizes our app), syncing stops immediately. 30 days later we delete the connection's credentials and all its orders, buyer details, products, inventory, shipments and label files, unless the seller reconnects first.
• Database backups expire after 7 days, so deleted data leaves backups within 7 days of deletion.
• Packing slips are deleted automatically 7 days after they are created.

Requests

When a seller, a marketplace such as TikTok Shop, or a buyer asks us to provide, correct or delete a buyer's personal data, we do it within 30 days. Requests go to [email protected]. Where a buyer contacts us directly, we confirm the request with the seller whose order it is.

Updates

This policy is reviewed with the rest of the program at least once a year and whenever we add a new data source or processor. Our public Privacy Policy is updated at the same time.