SOLUTION CABLES INC PRIVACY POLICY – YOUR PRIVACY RIGHTS

Effective Date: August 15, 2023. Last Updated: November 7, 2023

SCOPE

This Privacy Policy (“Policy”) describes how SOLUTION CABLES INC (“we,” or “us”) treats personal information we collect about you, primarily when an order is placed. We respect and value your privacy, and commit to protecting the personal data we gather.

If you are an California resident, please click here for SOLUTION CABLES INC’s California Privacy Policy. If you are an EU resident, please click here for SOLUTION CABLES INC’s EU Privacy Policy.

TYPES OF PERSONAL INFORMATION WE COLLECT

The primary time we collect personal information is when an order is placed. Here are the types of personal information we may collect during that time:

  • Identifying Information
  • Payment Information
  • Account Information

HOW WE USE YOUR PERSONAL INFORMATION

We use the collected personal information primarily to process and fulfill your order, ensure timely delivery, and provide any after-sales support that may be needed.

DATA COLLECTION

Data is collected, processed, stored, used, shared, and disposed according to the following security requirements.

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 an PCCABLES Services 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, (ii) calculate and remit taxes, (iii) produce tax invoices, or (iv) meet legal requirements, including tax or regulatory requirements. If a Developer is required by law to retain archival copies of PII for tax or other 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 of for all PII 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 an 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.

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 accessible only 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 unless the PII is necessary to meet legal requirements, including tax or regulatory requirements. 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 to detect if Information is extracted from its protected boundaries. Developers should perform an 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.