Security Policy

This policy covers the dataCorpGroup web application, its backend services, and the marketplace integrations (Amazon, Shopify, TikTok Shop) that run behind it. It sets out the controls we maintain and commit to, and it is reviewed and updated at least twice a year, or sooner if our infrastructure or practices meaningfully change.

For what personal data we collect and why, see our Privacy Policy. This page focuses on how that data, and seller data more broadly, is protected.

Access to seller data follows the principle of least privilege. Every account is scoped to its own data by design every seller’s records, sessions, and connected shops are isolated from every other seller’s at the database layer, not filtered after the fact in application code.

• Role-based access control governs what an authenticated user, team member, or administrator can see and do.
• Administrative access to production systems is restricted to engineers who need it for their current work, not granted by default.
• Actions taken on an account are recorded in an audit log, so access and changes can be reviewed after the fact.
• Account deletion requires a two-factor authentication code for any account that has 2FA enabled.

We classify data into three tiers credentials (passwords, marketplace access and refresh tokens), personal data (seller account details, buyer-anonymized order information), and operational data (product listings, mapping configuration) and apply protection accordingly.

• Marketplace access and refresh tokens are encrypted at rest with AES-256-GCM before they are stored; a database export alone is not enough to act on a connected seller account.
• Passwords are never stored in plain text they are hashed with bcrypt.
• All traffic between your browser, our servers, and connected marketplaces runs over HTTPS/TLS.
• Two-factor authentication (TOTP) is available for every account on the platform.

Production databases and internal services are not publicly reachable; only the HTTPS application API is exposed.

• Security HTTP headers are applied to every response (including a content-security policy).
• Incoming requests are sanitized against injection and cross-site scripting before they reach application logic.
• Rate limiting is enforced on authentication, public form, and bulk-import endpoints to blunt abuse and credential-stuffing attempts.
• Cross-origin requests are restricted to a configured allowlist of known application origins.
• Inbound webhooks (e.g. from TikTok Shop) are signature-verified before being processed, and duplicate deliveries are de-duplicated rather than reprocessed.

Company devices are protected with antivirus, and account security is enforced by the application itself:

• Every company computer runs antivirus software (Microsoft Defender on Windows) with real-time protection enabled.
• Two-factor authentication (TOTP) is available for every account.
• Passwords must be at least 8 characters and contain at least one letter and one number, on signup and on every password change.

We run automated dependency audits against our backend and frontend package manifests on a recurring basis, not only when an incident prompts one. Findings are triaged by severity: critical and high-severity issues are prioritized for patching, and issues that require a breaking upgrade are scheduled and tracked rather than deferred indefinitely.

Application-layer input is validated and sanitized by default, reducing the blast radius of any single dependency issue while a patch is rolled out.

When a security issue is identified whether by internal monitoring, a dependency advisory, or an external report a small on-call group investigates it first: scope, affected data, and whether it is ongoing.

• Confirmed incidents are triaged by severity and assigned an owner responsible for containment and remediation.
• Access credentials or tokens believed to be exposed are rotated immediately, independent of the rest of the investigation.
• A short written summary is kept for every confirmed incident: what happened, what was affected, and what changed afterward to prevent a repeat.

If we confirm that seller or personal data was accessed or disclosed without authorization, we notify affected sellers and, where legally required, the relevant regulator without undue delay and in any case within 72 hours of confirming the breach, consistent with common data-protection notification timelines.

That notification describes what happened, what data was involved, what we have done in response, and what the seller can do to protect themselves.

We collect the minimum data needed to operate the features a seller uses. Full detail on what is collected and why is in the Privacy Policy. On this page, the relevant commitments are:

• We help sellers delete, update, or export the data we hold about their account and connected stores on request.
• At the end of a contractual relationship, or when an account is deleted, we remove the associated records rather than retaining them indefinitely.
• We do not request marketplace scopes we do not need for example, order and customer scopes are only requested where a feature genuinely requires them.

When we update this page we change the “Last updated” date at the top. Material changes that reduce the protections described here will not be made silently.

Security questions, vulnerability reports, or a partner security review request write to us and a real person on our team will respond, usually within two business days.