Scope and accountability
This policy covers the infrastructure of GRT Store Operations Management, SP-API and Yahoo! Shopping API data, authorization tokens and all related systems and devices. The policy requires accountable owners, annual security training, risk assessments and periodic reviews. The initial release requests no restricted roles and does not obtain restricted buyer PII such as names, street addresses, emails and phone numbers. In Japan, Orders API can still return postal codes without restricted roles; DPP classifies postal codes as PII. Orders v2026-01-01 searchOrders/getOrder use basic datasets without includedData; BUYER, RECIPIENT and PAYMENT are not requested. FULFILLMENT is also not requested; individual order shipping and fulfillment status is outside the display scope. FBA inbound shipment status comes from the separately listed Fulfillment Inbound API. Postal codes and other unneeded non-restricted location fields are discarded in memory before logs or storage. Unexpected restricted fields stop processing. FBA/FBM responses, free text and field combinations are reviewed before enablement. Seller identity and telemetry PII require applicable safeguards before enablement.
These operating standards align with the DPP update effective August 25, 2026.
Amazon: https://developer.amazonservices.com/policy-update-for-sp-api
Network, WAF and device protection
Our policy requires WAF protection for every public Web, API and OAuth ingress; firewalls, network segmentation and intrusion detection/prevention must restrict unnecessary traffic. Databases, workers and secrets must remain private. All data-handling device storage must be encrypted. Managed-device policies must enforce a screen lock within 15 minutes, prevent staff disabling malware protection, prohibit unapproved media and require automatic updates or at least monthly manual updates.
Amazon: https://developer.amazonservices.com/policy-update-for-sp-api
Least privilege, MFA and login controls
Our policy requires unique identities and MFA for all human users, including seller SaaS users, administrators and support. Shared accounts are prohibited. Permissions must be minimal, checked for every tenant/store request and reviewed quarterly. Departure or role change must remove unnecessary access within 24 hours. Accounts must lock for at least 30 minutes after no more than 10 consecutive failed logins. Authentication anomalies must be investigated and affected human or programmatic access disabled. Seller Central passwords must not be collected.
Amazon: https://developer.amazonservices.com/policy-update-for-sp-api
Encryption in transit, at rest and for credentials
Our policy requires certificate-validated TLS 1.2 or later, and AES-256 or approved equivalent encryption at rest for databases, objects, backups, all data-handling devices and credentials. KMS must separate key administration from data access and restrict decryption to necessary services. Tokens and secrets must not enter public sites, browsers, source code or logs. Programmatic credentials must rotate within 12 months; LWA client secrets within 180 days, with immediate action on suspected compromise.
Amazon: https://sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US
Logging and monitoring
Our policy requires timestamped authentication success/failure, access, changes and errors from service APIs, storage APIs and administrative dashboards. Retained logs must exclude secrets and all PII, except documented legal requirements. Logs must be access-controlled and tamper-resistant, with sanitized security logs retained for 12 months and reviewed in real time or at least every 14 days. Alerts must cover abnormal calls, volumes, canaries and exposure beyond protected boundaries including the dark web, without sending raw Amazon data; investigations must be recorded.
Amazon: https://sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US
Vulnerability assessment and penetration testing
Our company policy requires scans within every 30 days and after significant changes, code/dependency/secret scans before release, and methodology-based penetration tests within every 365 days. Internal/external networks, cloud configuration, Web applications, APIs, databases and object/file storage must be in scope. Critical findings must be fixed within seven days and High findings within 30 days of discovery. Owners, deadlines, remediation and retest evidence must be recorded.
Amazon: https://developer-docs.amazon.com/sp-api/docs/vulnerability-management
Incident Management Point of Contact (IMPOC)
Our policy requires an assigned IMPOC: 塩澤 元基 / Motoki Shiozawa, reachable through app@grtllc.jp. The role must coordinate detection, containment, investigation, evidence preservation, recovery and prevention. The plan must be tested every six months and after major changes. If we reasonably determine that a personal data breach has occurred, we immediately notify Amazon at security@amazon.com. If we suspect unauthorized third-party access to Amazon Information, we report to the same contact within 24 hours of becoming aware of the suspicion, never more than 24 hours, without waiting for confirmation, and provide updates as needed. The immediate personal data breach notice is not delayed until this deadline. Applicable statutory notifications must also be made.
Amazon: https://sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US
Amazon data retention and deletion within 30 days
Retention is defined by data class. For Amazon operational data, we apply the shortest of the published ceiling of 90 days, the class-specific ceiling, purpose expiry and applicable deletion deadline. Superseded snapshots have a 30-day ceiling, reviewed business history a 12-month class ceiling, temporary data 24 hours and backups seven days, all subject to that shorter rule. The 30-day deletion deadline following the earliest applicable trigger takes precedence. Credentials, sanitized security logs and legal records are separately classified; that does not permit longer storage of raw business data or PII.
Operational data must follow the class-based shortest-period rule above. Within 30 days of the earliest trigger, including revocation, contract termination, Amazon’s request or loss of entitlement, the deletion process must securely delete tokens, production data, replicas, caches, queues, exports, supplier copies, snapshots and backups. Collection, access and jobs must stop on revocation; delayed detection does not extend the deadline. Shorter applicable deadlines prevail.
Deletion and revocation records must be reapplied on restore and completion evidence retained. Only legally required records are separately retained for that legal purpose and deleted on expiry. Deletion certification must be provided if Amazon requests it. See the Privacy Policy.
Amazon: https://sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US
Common exceptions for statutory retention or foreign disclosure and outsourcing do not apply to Yahoo! Shopping purchaser information. Subscriber contract and billing records and public static-site delivery logs are separate data classes; their rules do not authorize purchaser-information retention. All production-data processing and access, including credentials, by employees and contractors is limited to Japan. We do not disclose or outsource production data outside Japan or allow access from outside Japan.
Supplier oversight
Our policy requires supplier security and foreign-environment review before data access and at least annually, with contractual safeguards and limited access. DLP must cover endpoints, network egress and transit before any PII system is enabled, including seller identity and telemetry. Alerts must be investigated; personal storage, removable-media exports and unapproved public links are prohibited. Printed PII must be securely destroyed. Privacy inquiries are routed through app@grtllc.jp.
Amazon: https://sellercentral.amazon.com/solution-provider/policy?policyType=DPP&locale=en_US
Yahoo! Shopping: information handling policy
We do not retain any Yahoo! Shopping purchaser personal information, without exception. Order numbers, related identifiers, products, statuses and inquiry text that may identify a purchaser are subject to the same restriction. They are excluded from databases, files, logs, caches, backups and persistent sessions. Other information supplied by LY Corporation through the Shopping Store API or test API is also not retained unless LY Corporation separately instructs its storage. Such instructions apply only to other information and never to purchaser personal information. Any instructed storage is limited to specified fields, purposes and periods.
Features involving purchaser information follow lawful store instructions and the non-retention obligation in Article 10. Temporary memory processing is limited to what is necessary, and information is discarded when processing ends. It is never recorded in databases, logs, caches, queues, files or backups. Purchaser-data storage, file exports and saved shipping labels are outside the feature scope.
API calls originate from controlled Japan-based servers and fixed outbound IP addresses. Production information is accessible only to Japan-based personnel. Overseas access, disclosure and outsourcing are prohibited. Access tokens are sent in the Authorization header, never in URL query parameters.
Yahoo! Shopping: emergency response
We promptly contact LY Corporation about incidents, provide information as instructed and assist its investigation. For faults caused by this service that prevent normal API operation, including incorrect display of retrieved information, we complete the response within six hours of occurrence. Billing-impacting faults or unauthorized intrusion trigger immediate temporary service suspension. We resume only after response completion and safety verification. Customers (stores) are notified within 24 hours of occurrence. If the impact is unclear, all potentially affected stores are notified. The status page publishes the latest fault and response information.
Owner: 塩澤 元基 / Motoki Shiozawa. Alternate: Motoki Shiozawa. Our policy requires filing the 24-hour emergency contact app@grtllc.jp / +81-50-5526-2688（24時間 / 24 hours） with LY Corporation in advance and updating changes. Risks to response deadlines are immediately escalated to the owner or alternate.