Data Protection Policy

• Firewalls and ACLs: Network firewalls and access control lists are deployed to restrict inbound and outbound traffic to authorized connections only.
• Network segmentation: Production systems are segmented from development and corporate networks. Intrusion detection and prevention systems (IDS/IPS) monitor for threats in real time.
• Anti-malware: Endpoint protection and anti-malware software is deployed on all systems and updated monthly at minimum. Tamper protection controls prevent unauthorized disablement of anti-virus/anti-malware software.
• Access restriction: Access to systems containing Amazon Information is restricted to Approved Users only, enforced through network-level controls.
• Secure coding practices: We follow secure coding standards (OWASP Top 10) and conduct code reviews before deployment. No credentials, API keys, or secrets are hardcoded in source code.
• Annual security training: All personnel with access to Amazon Information complete annual data protection and IT security training covering data handling, incident response, and privacy obligations.

• Unique user IDs: Every individual with system access is assigned a unique user ID. Generic, shared, or default login credentials are prohibited.
• Formal registration: User access is provisioned through a formal registration and de-registration process with documented approval.
• Account lockout: Accounts are locked after 10 unsuccessful login attempts.
• Quarterly access reviews: Access lists are reviewed quarterly to verify that only currently authorized personnel retain access.
• Termination protocol: Access is disabled within 24 hours of employee termination or role change that no longer requires access.

All access rights are granted on a strict need-to-know basis using fine-grained controls. Personnel are assigned the minimum permissions necessary to perform their job functions. Database-level Row-Level Security (RLS) policies enforce data isolation between organizations.

• Role-Based Access Control (RBAC): Permissions are assigned by role, not individual, ensuring consistent enforcement.
• Elevated access: Administrative or elevated access requires additional approval and is time-limited where possible.
• Service accounts: Service accounts are restricted to the specific resources and operations they require.

Password Requirements

• Minimum length: All passwords must be a minimum of 14 characters.
• Complexity: Passwords must contain at least one character from each of the following four categories: (1) uppercase letters (A-Z), (2) lowercase letters (a-z), (3) numbers (0-9), and (4) special characters (e.g., !, @, #, $, %, ^, &, *).
• Name restriction: Passwords must not contain any part of the user's name, username, or email address.
• Minimum password age: 1 day - passwords cannot be changed more than once per day to prevent rapid cycling.
• Maximum password expiration: 365 days - passwords must be changed at least annually.
• Password history: The system enforces a 10-password history, preventing reuse of recent passwords.
• Password storage: All passwords are cryptographically hashed using bcrypt/scrypt. Plaintext passwords are never stored or transmitted.

Multi-Factor Authentication

• MFA required: Multi-Factor Authentication is mandatory for all user accounts across all systems covered by this policy.
• MFA methods: We support TOTP-based authenticator apps and hardware security keys.

API Key Management

• Encryption: All API keys, SP-API tokens, and credentials are encrypted at rest using AES-256 and accessible only to employees who require them for their role.
• Rotation: API keys and associated credentials are rotated at minimum once every 12 months.
• No exposure: API credentials are never hardcoded, committed to repositories, or exposed in client-side code.

• TLS 1.2+: All data transmissions use TLS 1.2 or higher. Older protocols (SSL, TLS 1.0, TLS 1.1) are disabled.
• All endpoints: Encryption is enforced on all internal and external endpoints, including API communications, web interfaces, and database connections.
• Secure file transfer: Where file transfers are required, SFTP or SSH-2 protocols are used.
• No unencrypted PII: Personally identifiable information is never transmitted over unencrypted channels.
• Message-level encryption: Where channel encryption terminates in untrusted hardware or third-party infrastructure, message-level encryption is applied to protect data end-to-end.
• Certificate management: TLS certificates are managed and renewed before expiration. Certificate pinning is used where applicable.

Risk Management

• Annual risk assessments: Formal risk assessments are conducted annually and reviewed by senior management to identify threats, vulnerabilities, and required controls.
• Scope: Assessments cover all systems that process, store, or transmit Amazon Information, including third-party services.
• Remediation tracking: Identified risks are documented with remediation plans, owners, and target dates.

Incident Response Plan

• Documented plan: We maintain a documented incident response plan with defined roles, responsibilities, procedures, and escalation paths.
• Review cadence: The plan is reviewed every 6 months and after any major infrastructure change or security incident.
• Detection: Continuous monitoring and logging are employed to detect potential security incidents in real time.

Incident Handling

• Amazon notification: Any Security Incident involving Amazon Information is reported to Amazon at [email protected] within 24 hours of detection.
• User notification: Affected users are notified per applicable law (PIPEDA: as soon as feasible; GDPR: within 72 hours; CCPA: without unreasonable delay).
• Investigation: All incidents are investigated and documented, including description of the incident, remediation actions, and corrective controls implemented.
• Chain of custody: Chain of custody is maintained for all evidence collected during incident investigation.
• Incident Management Point of Contact: A designated Incident Management Point of Contact is responsible for coordinating response efforts and Amazon communication.

• Amazon-initiated deletion: Upon notice from Amazon to delete Information, all applicable data is permanently and securely deleted within 30 days.
• User-initiated deletion: Users may request deletion by emailing [email protected] with the subject line "Data Deletion Request". Requests are processed within 30 days.
• SP-API revocation: Upon revocation of SP-API access through Amazon Seller Central, all associated SP-API data is deleted within 30 days.
• Scope of deletion: Deletion covers all live instances, backups, archives, and disaster recovery stores. All live instances are deleted within 90 days of notice.
• Deletion standard: Data sanitization follows NIST SP 800-88 guidelines (Clear, Purge, or Destroy methods as appropriate to the storage medium).
• No anonymization substitute: Anonymization is not used as a substitute for deletion. When deletion is requested, data is permanently removed.
• Written certification: Upon request, we will certify deletion in writing, confirming that all applicable data has been permanently removed from our systems.
• Non-PII retention: Non-personally identifiable Amazon data is deleted within 18 months unless legally required to retain.
• Legal retention: Where required by law, minimal data may be retained in encrypted cold storage solely for legal compliance, with documentation of the legal basis.

All Amazon-sourced data is stored with clear attribution to identify its origin:

• Source tagging: Every record sourced from Amazon SP-API is tagged with a data source identifier and the originating selling partner account, enabling precise tracking and deletion.
• Logical separation: Amazon data is logically separated from non-Amazon data through database schemas, Row-Level Security policies, and source tagging, ensuring it can be independently identified, managed, and deleted.
• No commingling: Amazon Information is not commingled with data from other sources in a way that would prevent independent identification and deletion.