DepotKeeper Information Security Policy

Operator and scope

Operator: Nanjing Gugua Gugua Technology Co., Ltd. (“we”, “us” or “DepotKeeper”). This Policy applies to information and related technology assets processed through the DepotKeeper website, workspace, APIs and support services.

1. Security governance and review

We incorporate information security into day-to-day operations. A designated responsible person coordinates security matters, risk handling and policy maintenance. This Policy is reviewed at least annually and assessed promptly when material changes occur in systems, business, law or risk.

2. Access control and least privilege

The Service separates access by platform, warehouse, seller and authorised collaboration relationship. Users must access the Service through individual accounts. Administrators assign members, roles and permissions only where needed for business purposes and review accounts, invitations and relationships that are no longer required. Shared accounts, access-control bypasses and unauthorised credentials are prohibited.

3. Authentication and credential protection

Access to the workspace and APIs requires authentication. Passwords, session tokens, third-party authorisation tokens and other secrets must not be publicly disclosed, shared or committed to source repositories. Third-party tokens authorised for the Service are stored server-side with appropriate protection, and their use is limited where necessary.

4. Data classification and handling

We classify information by sensitivity as public, internal, confidential business information, or sensitive personal data. Account credentials, email addresses, telephone numbers, recipient names, delivery addresses, order information, operational logs, third-party authorisation tokens, database exports and backups are handled as confidential business information or sensitive personal data. The data owner, purpose, access role, retention period and deletion requirement must match the applicable classification. Confidential or sensitive data must not be copied to personal devices, public channels or unapproved third-party services without authorisation.

5. Protection of data in transit, at rest and in backups

Public Service access uses HTTPS/TLS in transit. Sensitive configuration, third-party authorisation information and operational data are access-restricted. Production data, database files, snapshots and backups must be protected with approved encrypted storage and key-management capabilities, with access to keys and backups limited to authorised personnel. Data is processed only to the extent needed to provide warehousing, inventory, order, fulfilment collaboration, support, recovery and legal-compliance activities.

6. System changes, vulnerabilities and logs

We record and validate changes to code, configuration and dependencies that affect the Service, and perform appropriate checks before release. We monitor known vulnerabilities, anomalies and security risks and prioritise remediation, mitigation or restriction of affected functionality according to risk. Security-relevant and operational traceability records are retained for a reasonable period to support investigation, recovery and audit.

7. Security incident response

If we identify suspected unauthorised access, a data breach, malicious activity, credential disclosure or another security incident, we investigate, contain, remediate and recover, assess the affected scope and retain necessary records. Where an incident affects personal information or service security, we take notification, remediation and follow-up measures required by applicable law and contract.

8. Personnel and service providers

Personnel with access to non-public information are subject to confidentiality obligations and access commensurate with their responsibilities. When using cloud hosting, email, storage, analytics or other service providers, we reasonably assess their service purpose and security measures and restrict processing to the provision of the agreed service.

9. Shopee Open Platform security rules

This section sets out the security requirements for applying for, developing and enabling a Shopee integration in DepotKeeper. Shopee integration is currently in the application and preparation stage. Available functionality, data fields and markets depend on actual availability, seller authorisation and Shopee approval. Before enabling the relevant functionality, we must implement the following controls and comply with the applicable Shopee Data Protection Policy, Platform Partner Rules and Terms of Service.

• Shop authorisation and access isolation: connect only shops the seller is entitled to manage through the official Shopee authorisation flow, requesting only the permissions needed for order, product, inventory and fulfilment collaboration. Shop and order data must be separated by seller, warehouse and their valid collaboration relationship. Members may access only the data required for their assigned responsibilities.
• Purpose limitation and data minimisation: process Shopee data only for authorised order processing, inventory synchronisation, picking, packing, shipping, tracking, returns collaboration and necessary support. The data must not be sold, rented, used for advertising or profiling unrelated to fulfilment, or disclosed to unauthorised third parties.
• Buyer information permissions: recipient names, telephone numbers, email addresses, delivery addresses and shipping labels containing this information are treated as sensitive personal data. Access unmasked fields only when Shopee grants the relevant personally identifiable information (PII) permission, the seller authorises access and there is a necessary business purpose. Without approval, use only platform-permitted masked data or restrict the affected functionality, without attempting to bypass platform restrictions.
• Credentials and environment protection: application keys, access tokens and refresh tokens must be stored under server-side access controls and encryption, with key access restricted. They must not appear in the frontend, public URLs, source repositories or ordinary logs. Production and test credentials and data must be separated. Development and review demonstrations must use test data, and sensitive data must be transmitted over HTTPS/TLS.
• APIs, push notifications and audit: validate signatures, sources and validity of API interactions and push notifications in accordance with official Shopee specifications. Prevent duplicate notifications or replays from causing duplicate fulfilment, stock changes or other writes. Retain necessary authorisation, access and operational records while avoiding complete tokens or unnecessary buyer information in logs.
• Retention, deletion and entrusted processing: handle data according to business necessity, seller instructions, applicable law and the Shopee retention and deletion periods for that data. When authorisation expires, is revoked or the service ends, stop new access and delete or irreversibly anonymise data no longer needed within the applicable deadlines. Where retention is legally required, restrict its use and access. Clear backups through controlled rotation and reapply deletion requirements after restoration. Entrusted service providers may process data only as necessary, under instructions and confidentiality obligations.
• Security assessment and incident response: before requesting permissions that require a security assessment, verify the requirements for the relevant market, data scope, testing provider and report validity. Complete actual testing, risk remediation and necessary retesting, and submit genuine reports. For a suspected incident involving Shopee data, investigate, contain and preserve evidence, and notify Shopee, affected customers or relevant authorities within applicable platform, contractual and legal deadlines.

This Policy describes security-management requirements. It is not a penetration test report, third-party security certification or evidence of Shopee approval.

10. Amazon SP-API data-protection requirements

This section defines protection requirements for Amazon Information used in seller-authorised fulfilment collaboration with home-based and small warehouses. Request only roles needed for actual functionality. Brand Analytics, advertising and cross-seller analysis are not current use cases. Access to unmasked buyer information requires the corresponding restricted approval and implementation and validation of the following controls.

• Networks and endpoints: databases, caches and internal file services must not be directly exposed to the public internet. Administrative access must use controlled identities and necessary network restrictions. Production and test access must be separated; developer endpoints must be covered by access, disk-encryption and security controls. Real buyer data must not be used as development samples or stored in public directories.
• Encryption and keys: Amazon Information in databases, files, exports, archives and backups must use at least AES-128 or equivalent protection. Keys must be managed through a controlled key-management service, with restricted use, administration and backup access and documented rotation and revocation. Credential encryption or a private bucket alone does not establish encryption of all Information.
• Backups and recovery: use restricted encrypted backups and geographically separated recovery copies. Record locations, successful backup times, retention and recovery owners. Define RPO/RTO and record measured results from isolated recovery exercises. Live replication is not a substitute for recoverable backups.
• Logs and investigations: retain security logs for applicable personal-data processing for at least 12 months, recording identity, time, action and outcome. Centrally monitor anomalous logins, access and system changes. Exclude plaintext credentials and unnecessary order personal data; document alert scope, evidence, response and conclusions.
• Accounts and credentials: newly set or changed passwords must have at least 12 characters, mixed case, numbers and symbols and exclude names and email account names. Approved accounts handling Amazon Information must also meet applicable MFA, password-history and lifecycle requirements, revoke invalid credentials and use least privilege. Email-code login as an alternative to a password is not MFA.
• Vulnerabilities and releases: maintain security checks and remediation records for code, dependencies and runtime systems. Check relevant code before release, scan applicable systems at least every 30 days, remediate critical risks within 7 days and high risks within 30 days, and perform applicable annual penetration and security assessments. Notify Amazon of incidents involving its Information within 24 hours where required.
• Sharing and deletion: recipients are limited to actual seller-authorised fulfilment warehouses, necessary entrusted technical providers and legally required recipients. Record their names, data categories, purpose, method and authorisation. Stop new access after revocation and apply deletion requirements to live copies, exports, archives and backups, reapplying them after recovery.

These requirements must be implemented before the relevant processing is enabled. Application statements must match actual implementation and evidence. This Policy does not assert Amazon approval or replace configuration, recovery exercises, penetration testing or third-party certification.

11. Contact and policy updates

To report a security concern, suspected vulnerability, unusual access or security incident, email support@depotkeeper.com. We may update this Policy and will publish the current version on this page. Material changes will receive additional notice where reasonably appropriate.