Incident Response Plan

Owner: Account Administrator · Last reviewed 2026-11-14 · Review cycle: every 6 months

1. Scope and definitions

A security incident is any actual or suspected unauthorised access to, disclosure of, alteration of, or loss of Amazon information or of the credentials used to obtain it. Examples include a leaked SP-API refresh token, an unexpected administrator login, a compromised hosting or AWS account, exposed database credentials, or evidence of data exfiltration.

2. Roles and responsibilities

3. Detection

• Hosting runtime logs, HTTP status and error trends, and the /health endpoint.
• Login rate-limit events, repeated authentication failures and unexpected session activity.
• Notifications from the hosting provider, AWS and Amazon Seller Central.
• Alerts from the local agent when synchronisation or label retrieval fails unexpectedly.

4. Immediate response (first 24 hours)

1. Record the time of discovery, affected systems, data categories involved and the initial observations. Preserve relevant logs before making changes.
2. Contain: disable the affected application or take it offline, revoke all active sessions, block offending source addresses at the hosting edge, and stop the local agent if its credentials may be involved.
3. Rotate credentials: SP-API refresh token and LWA client credentials, AWS access keys, database password, ADMIN_PASSWORD_HASH, ADMIN_TOTP_SECRET and the agent token. Rotation invalidates existing sessions and renders the old values unusable.
4. Assess scope: determine which data was accessible, whether any Amazon information left our systems, and whether any PII was involved.
5. Notify Amazon at security@amazon.com within 24 hours of discovery. Include the date and time of discovery, a description of the incident, the affected systems and data categories, containment measures already taken, and a contact for follow-up. Do not wait for a complete root cause analysis before sending the initial report; send updates as facts become available.
6. Notify other parties where legally required, using the regulator and customer communication procedures applicable to the data involved.

5. Recovery

• Verify that rotated credentials work and that no old credential remains valid.
• Review and patch the root cause before restoring service; re-enable the agent only after the hosting environment is confirmed clean.
• Restore from provider-managed encrypted backups if data integrity is in doubt.
• Delete any incidental PII involved within 30 days in line with the Data Retention policy.

6. Post-incident review

Within 14 days of closure, document the root cause, timeline, data affected, notifications sent and preventive actions. Update the Security statement, this plan and the Privacy Policy where the incident changes any stated practice.

7. Testing and review cadence

• This plan and the contact list are reviewed every six months and after every material change to the application or the incident.
• The 24-hour reporting path to security@amazon.com is verified at each review.
• Session revocation and credential rotation are exercised at least annually.
• Records of reviews and incidents are retained by the Account Administrator.

8. Contacts