Data Protection Policy

Rugged TUFF abides by the policies from Amazon’s DPP Below.

The Data Protection Policy (“DPP”) governs the receipt, storage, usage, transfer, and disposal of the data vended and retrieved through the Amazon Selling Partner APIs (including the Marketplace Web Service APIs). This policy is applicable to all systems that store, process, or otherwise handle data vended and retrieved from the Selling Partner APIs. This Policy supplements the Amazon Selling Partner API Developer Agreement and the Acceptable Use Policy. Failure to comply may result in suspension or termination of Selling Partner API access.

1. General Security Requirements

Consistent with industry-leading security, Developers will maintain physical, administrative, and technical safeguards, and other security measures (i) to maintain the security and confidentiality of Information accessed, collected, used, stored, or transmitted by a Developer, and (ii) to protect that his Information from known or reasonably anticipated threats or hazards to its security and integrity, accidental loss, alteration, disclosure, and all other unlawful forms of processing. Without limitation, the Developer will comply with the following requirements:

1.1. Network Protection. Developers must implement network protection controls including network firewalls, network access control lists to deny access to unauthorized IP addresses. Developers must implement anti-virus and anti-malware software on end-user devices. Developers must restrict public access only to approved users.
1.2. Access Management. Developers must assign a unique ID to each person with computer access to Information. Developers must not create or use generic, shared, or default login credentials or user accounts. Developers must implement baselining mechanisms to ensure that at all times only the required user accounts access Information. Developers must review the list of people and services with access to Information every 90 days, and remove accounts that no longer require access. Developers must restrict employees and contractors from storing Information on personal devices. Developers will maintain and enforce “account lockout” by detecting anomalous usage patterns and log-in attempts, and disabling accounts with access to Information as needed.
1.3. Least Privilege Principle. Developers must implement fine-grained access control mechanisms to allow granting rights to any party using the Application and the Application’s operators following the principle of least privilege. Access to Information must be granted on a “need-to-know” basis.
1.4. Password Management. Developers must establish minimum password requirements for personnel and systems with access to Information. Password requirements must be a minimum of 8 characters, contain upper and lower case letters, contain numbers, contain special characters, and rotated at least quarterly.
1.5. Encryption in Transit. Developers must encrypt all Information in transit with secure protocols such as TLS 1.2+, SFTP, and SSH-2. Developers must enforce this security control on all applicable internal and external endpoints. Developers must use data message-level encryption where channel encryption (e.g., using TLS) terminates in untrusted multi-tenant hardware (e.g., untrusted proxies).
1.6. Incident Response Plan. Developers must create and maintain a plan and/or runbook to detect and handle Security Incidents. Such plans must identify the incident response roles and responsibilities, define incident types that may affect Amazon, define incident response procedures for defined incident types, and define an escalation path and procedures to escalate Security Incidents to Amazon. Developers must review and verify the plan every six (6) months and after any major infrastructure or system change, including changes to the system, controls, operational environments, risk levels, and supply chain. Developers must notify Amazon (via email to 3p-security@amazon.com) within 24 hours of detecting Security Incident or suspecting that a Security Incident has occurred. Developers must investigate each Security Incident, and document the incident description, remediation actions, and associated corrective process/system controls implemented to prevent future recurrence. Developers must maintain the chain of custody for all evidences or records collected, and such documentation must be made available to Amazon upon request (if applicable). If a Security Incident occurred, Developers cannot represent or speak on behalf of Amazon to any regulatory authority or customers unless Amazon specifically requests in writing that the Developer do so.
1.7. Request for Deletion or Return. Developers must permanently and securely delete (in accordance or return Information upon and in accordance with Amazon’s notice requiring deletion or return within 72 hours of Amazon’s requests unless the data is required to comply with law. Secure deletion must occur in accordance with industry-standard sanitization processes such as NIST 800-88. Developers must also permanently and securely delete all live (online or network accessible) instances of Information 90 days after Amazon’s notice. If requested by Amazon, the Developer will certify in writing that all Information has been securely destroyed.

2. Additional Security Requirements Specific to Personally Identifiable Information

The following additional Security Requirements must be met for Personally Identifiable Information (“PII”). PII is granted to Developers for select tax and merchant fulfilled shipping purposes, on a must-have basis. If a Selling Partner API contains PII, or PII is combined with non-PII, then the entire data store must comply with the following requirements:

2.1. Data Retention. Developers will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders or to, (ii) calculate and remit taxes, and (iii) produce tax invoices. If a Developer is required by law to retain archival copies of PII for tax or similar regulatory purposes, PII must be stored as a “cold” or offline encrypted backup (e.g., not available for immediate or interactive use)
2.2. Data Governance. Developers must create, document, and abide by a privacy and data handling policy for their Applications or services, which govern the appropriate conduct and technical controls to be applied in managing and protecting information assets. A record of data processing activities such as specific data fields and how they are collected, processed, stored, used, shared, and disposed for all PII Information should be maintained to establish accountability and compliance with regulations. Developers must establish a process to detect and comply with privacy and security laws and regulatory requirements applicable to their business and retain documented evidence of their compliance. Developers must establish and abide by their privacy policy for customer consent and data rights to access, rectify, erase, or stop sharing/processing their information where applicable or required by data privacy regulation.
2.3. Asset Management. Developers must keep inventory of software and physical assets (e.g. computers, mobile devices) with access to PII, and update quarterly. Physical assets that store, process, or otherwise handle Amazon PII must abide by all of the requirements set forth in this policy. Developers must not store PII in removable media, personal devices, or unsecured public cloud applications (e.g., public links made available through Google Drive) unless it is encrypted using at least AES-128 or RSA-2048 bit keys or higher. Developers must securely dispose of any printed documents containing PII.
2.4. Encryption at Rest. Developers must encrypt all PII at rest using at least AES-128 or RSA with 2048-bit key size or higher. The cryptographic materials (e.g., encryption/decryption keys) and cryptographic capabilities (e.g. daemons implementing virtual Trusted Platform Modules and providing encryption/decryption APIs) used for encryption of PII at rest must be only accessible to the Developer’s processes and services.
2.5. Secure Coding Practices. Developers must not hardcode sensitive credentials in their code, including encryption keys, secret access keys, or passwords. Sensitive credentials must not be exposed in public code repositories. Developers must maintain separate test and production environments.
2.6. Logging and Monitoring. Developers must gather logs to detect security-related events to their Applications and systems. including success or failure of the event, date and time, access attempts, data changes, and system errors Developers must implement this logging mechanism on all channels (e.g., service APIs, storage-layer APIs, administrative dashboards) providing access to Information. All logs must have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs must not contain PII and must be retained for at least 90 days for reference in the case of a Security Incident. Developers must build mechanisms to monitor the logs and all system activities to trigger investigative alarms on suspicious actions (e.g., multiple unauthorized calls, unexpected request rate and data retrieval volume, and access to canary data records). Developers must implement monitoring alarms to detect if Information is extracted from its protected boundaries. Developers should perform investigation when monitoring alarms are triggered, and this should be documented in the Developer’s Incident Response Plan.
2.7 Vulnerability Management. Developers must create and maintain a plan and/or runbook to detect and remediate vulnerabilities. Developers must protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. Developers must conduct vulnerability scanning or penetration tests at least every 180 days and scan code for vulnerabilities prior to each release. Furthermore, Developers must control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who may perform those actions.

3. Audit and Assessment

Developers must maintain all appropriate books and records reasonably required to verify compliance with the Acceptable Use Policy, Data Protection Policy, and Amazon Marketplace Developer Agreement during the period of this agreement and for 12 months thereafter. Upon Amazon’s written request, Developers must certify in writing to Amazon that they are in compliance with these policies.
Upon request, Amazon may, or may have an independent certified public accounting firm selected by Amazon, audit, assess and inspect the books, records, facilities, operations, and security of all systems that are involved with a Developer’s application in the retrieval, storage, or processing of Information. Developers must cooperate with Amazon or Amazon’s auditor in connection with the audit or assessment, which may occur at the Developer’s facilities and/or subcontractor facilities. If the audit or assessment reveals deficiencies, breaches, and/or failures to comply with our terms, conditions, or policies, the Developer must, at its sole cost and expense, and take all actions necessary to remediate those deficiencies within an agreed-upon timeframe. Upon request, Developer must provide remediation evidence in the form requested by Amazon (which may include policy, documents, screenshots, or screen sharing of application or infrastructure changes) and obtain written approval on submitted evidence from Amazon before audit closure.

4. Definitions

“Application” means a software application or website that interfaces with the Marketplace APIs.

“Customer” means any person or entity who has purchased items or services from Amazon’s public-facing websites.

“Developer” means any person or entity (including you, if applicable) that uses the Marketplace APIs for the purpose of integrating or enhancing a third-party Selling Partner’s systems with the features and functionality permitted by Amazon to be accessed through the Marketplace APIs.

“Information” means any information that is exposed through the Selling Partner APIs, Amazon Portals, or Amazon’s public-facing websites. This data can be public or non-public, including Personally Identifiable Information about Amazon customers.

“Personally Identifiable Information” (“PII”) means information that can be used on its own or with other information to identify, contact, identify in context, or locate an Amazon , Customer or Selling Partner. This includes, but is not limited to, a Customer or Selling Partner’s name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, nine-digit postal code, or Internet-connected device product identifier.

“Security Incident” means any actual or suspected unauthorized access, collection, acquisition, use, transmission, disclosure, corruption, or loss of Information, or breach of any environment (i) containing Information, or (ii) managed by a Developer with controls substantially similar to those protecting Information.

“Selling Partner” means any person or entity (including you, if applicable) that is participating in one or more of the Amazon Selling Partner Services.

“Selling Partner APIs” means any application programming interface (API) offered by Amazon for the purpose of helping Amazon sellers to programmatically exchange data including but not limited to, listings, orders, payments, and reports.

“Selling Partner Services” means services provided or operated by Amazon that allow, enable, or assist a party to sell goods or services either to Amazon or in Amazon’s online or offline stores.

Copyright © 2009-2021 Amazon.com, Inc. or its affiliates. Amazon and Amazon.com are registered trademarks of Amazon.com, Inc. or its affiliates. All other trademarks are the property of their respective owners.