The Data Protection Policy (hereinafter "DPP") governs the receipt, storage, usage, transfer, and disposal of Information, including the data vended and retrieved through the EcartAPI Services API. This DPP is applicable to all systems that store, process, or otherwise handle data vended and retrieved from the EcartAPI service. This DPP supplements the ECARTAPI.COM Terms and Conditions (“Terms”). Failure to comply may result in suspension or termination of EcartAPI Services API access.
The following definitions shall have the following meanings with respect of the EcartAPI Data Protection Policy:
EcartAPI Services API: means any application programming interface (API) offered by EcartAPI for the purpose of helping EcartAPI Authorized Users to programmatically exchange data.
API Materials: means Materials we make available in connection with the EcartAPI Services API, including APIs, documentation, specifications, software libraries, software development kits, and other supporting materials, regardless of format.
Application: means a software application or website that interfaces with the EcartAPI Services API or the API Materials.
Authorized User: means a user of EcartAPI systems or services who has been granted an authorization to use the applicable systems or services.
Customer: means any person or entity who has granted access to their e-commerce platform via EcartAPI authentication services.
Developer: means any person or entity (including you, if applicable) that uses the EcartAPI Services API or the API Materials for a Permitted Use on behalf of an Authorized User.
Information: means any information that is exposed through the EcartAPI Services API, EcartAPI Portals, or EcartAPI public-facing websites. This data can be public or non-public, including Personally Identifiable Information about EcartAPI 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 a Customer or Authorized User. This includes but is not limited to, a Customer or Authorized User'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 containing Information.
2. 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 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:
2.1 NETWORK PROTECTION
Developers must implement network protection controls including network firewalls and network access control lists to deny access to unauthorized IP addresses. Developers must implement network segmentation, anti-virus and anti-malware software on end-user devices. Developers must restrict public access only to approved users and carry out data protection and IT security training for everyone with system access.
2.2 ACCESS MANAGEMENT
Developers must establish a formal user access registration process to assign access rights for all user types and services by ensuring that a unique ID is assigned to each person with computer access to Information. Developers must not create or use generic, shared, or default login credentials or user accounts and prevent user accounts from being shared. Developers must implement baselining mechanisms to ensure that at all times only the required user accounts access Information. 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. Developers must review the list of people and services with access to Information at least quarterly. Developers must ensure that access is disabled and/or removed within 24 hours for terminated employees.
2.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 authorized operators following the principle of least privilege. Access to Information must be granted on a "need-to-know" basis.
2.4 CREDENTIAL MANAGEMENT
Developers must establish minimum password requirements for personnel and systems with access to Information. Password requirements must be a minimum of twelve (12) characters, not include any part of the user’s name, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each. Developers must establish a minimum password age of 1-day and a maximum 365-day password expiration for all users. Developers must ensure that Multi-Factor Authentication (MFA) is required for all user accounts Developer must ensure that API keys provided by EcartAPI are encrypted and only required employees have access to them.
2.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).
2.6 RISK MANAGEMENT AND INCIDENT RESPONSE PLAN
Developers must have a risk assessment and management process that is reviewed by the Developer's senior management annually, which includes, but is not limited to, assessment of potential threats and vulnerabilities as well as likelihood and impact in order to track known risks. 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 EcartAPI, define incident response procedures for defined incident types, and define an escalation path and procedures to escalate Security Incidents to EcartAPI. 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 EcartAPI (via email to [email protected]) within 24 hours of detecting a Security Incident. It is the Developer’s sole responsibility to inform relevant government or regulatory agencies as required by applicable local laws. 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 evidence or records collected, and such documentation must be made available to EcartAPI upon request (if applicable). If a Security Incident occurred, Developers cannot represent or speak on behalf of EcartAPI to any regulatory authority or customers unless EcartAPI specifically requests in writing that the Developer do so.
2.7 REQUEST FOR DELETION
Developers must permanently and securely delete Information upon and in accordance with EcartAPI ́s notice requiring deletion within 30 days of EcartAPI ́s requests unless the data is necessary to meet legal requirements, including tax or regulatory requirements. 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 EcartAPI ́s notice. If requested by EcartAPI, the Developer will certify in writing that all Information has been securely destroyed.
2.8 DATA ATTRIBUTION
Developers must store Information in a separate database or implement a mechanism to tag and identify the origin of all data in any database that contains Information.
3. ADDITIONAL SECURITY REQUIREMENTS SPECIFIC TO PERSONALLY IDENTIFIABLE INFORMATION
The following additional Security Requirements must be met for Personally Identifiable Information ("PII"). If an EcartAPI Services API request contains PII, or PII is combined with non-PII, then the entire data store must comply with the following requirements:
3.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, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements, including tax or regulatory requirements. Developers may retain data for over 30 days after order delivery only if required by law and only for the purposes of complying with that law. Per sections 2.5 (“Encryption in Transit”) and 3.4 (“Encryption at Rest”) at no point should PII be transmitted or stored unprotected.
3.2 DATA GOVERNANCE
3.3 ASSET MANAGEMENT
Developers must maintain baseline standard configuration for the information system and 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 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. Developer must implement data loss prevention (DLP) controls in place to monitor and detect unauthorized movement of data.
3.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.
3.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
3.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. Developers must review logs in real-time (e.g. SIEM tool) or on a bi-weekly basis. All logs must have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs must not contain PII unless the PII is necessary to meet legal requirements, including tax or regulatory requirements. Unless otherwise required by applicable law, logs 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 and processes to detect if Information is extracted from or can be found beyond its protected boundaries. Developers should perform investigation when monitoring alarms are triggered, and this should be documented in the Developer's Incident Response Plan.
3.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 at least every 180 days, penetration test at least every 365 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. Developer must have appropriate procedures and plans to restore availability and access to PII in a timely manner in the event of a physical or technical incident.