Incident Response Plan

Effective date: 2026-05-12 Last reviewed: 2026-05-12 Next review: 2026-11-12 (six-month cadence) Applies to: T-Code Manager (tcodemanager.com), SellerSKU, and all systems handling Amazon Information operated by Welch Commerce Systems

This plan defines the steps Welch Commerce Systems takes to detect, contain, notify, investigate, and remediate security incidents affecting customer data, Amazon Information, or our infrastructure.

1. Roles and responsibilities

Role	Person	Responsibilities
Incident Management Point of Contact (IMPOC)	Todd Welch ([email protected])	Owns incident from detection to closure. Single point of contact for Amazon, customers, and external parties during an incident.
Backup IMPOC	Same as IMPOC during sole-operator phase; will be updated when team grows.	Acts in IMPOC's absence.
Lead Developer	Todd Welch	Executes containment and remediation actions in code and infrastructure.
Customer Communication Lead	Todd Welch	Drafts and sends customer notifications.

A single individual may hold multiple roles. The IMPOC is the load-bearing role: every incident starts and ends with IMPOC sign-off.

2. Incident classification

Severity	Definition	Examples	Notification target
Critical	Confirmed unauthorized access to Amazon Information, customer credentials, or PII; confirmed data exfiltration; production system compromise	Database breach, leaked refresh tokens, exposed buyer PII	Within 24 hours: [email protected], affected customers
High	Likely-but-not-confirmed unauthorized access; vulnerability with active exploit attempts; loss of integrity or availability	Active brute force on auth endpoints, dependency CVE with exploit in the wild, prolonged outage	Within 24 hours to [email protected] if Amazon Information is at risk; customer notification within 72 hours
Medium	Vulnerability discovered without evidence of exploitation; misconfiguration with theoretical exposure	Newly disclosed CVE in a dependency, missing security header, log retention gap	Internal tracking; customer notification only if evidence emerges of exposure
Low	Minor process gap, audit finding, false-positive alert	Logging volume anomaly, documentation drift	Internal tracking only

3. Response phases

3.1 Detection

Sources that may surface an incident:

Application monitoring and Railway alerts
Amazon SP-API error responses indicating revoked or invalid auth at scale
Customer reports via [email protected]
External vulnerability disclosures (researcher emails, CVE feeds, GitHub security advisories)
Internal code review or audit findings

Acknowledge within 1 hour of detection during business hours; within 4 hours outside business hours. Acknowledgment goes to the IMPOC and creates an incident record with a unique ID.

3.2 Containment

Goal: stop the bleeding before fixing the root cause.

Initial containment actions (executed by IMPOC or Lead Developer):

Revoke compromised credentials (LWA refresh tokens, API keys, customer passwords as appropriate).
Rotate any secrets that may have been exposed.
Disable affected user accounts pending investigation.
Block hostile IP addresses or scope of attack via Railway-level controls.
Take affected services offline if continued operation would worsen the incident.
Preserve forensic state: do NOT delete logs, do NOT roll back compromised systems before evidence collection.

3.3 Notification

Amazon notification: Within 24 hours of detection of any Critical or High severity incident affecting Amazon Information, send notification to [email protected]. Include incident ID, summary, scope of affected data, time of detection, current containment status, and IMPOC contact.

Customer notification: Within 72 hours of detection (or as soon as legally permitted if law enforcement requests delay), notify affected customers via the email associated with their account. Customer notification includes: nature of the incident, scope of their data affected, what we have done in response, what they should do, and our contact for follow-up.

Public notification: If the incident requires broader public disclosure under applicable law, the IMPOC drafts and the Lead Developer reviews before publication on tcodemanager.com.

3.4 Investigation

Goal: determine root cause and full scope.

Investigation steps:

Preserve and analyze application logs, audit logs, database query logs, infrastructure logs.
Identify the vulnerability or process gap that allowed the incident.
Map the full scope of affected data and accounts.
Determine attacker actions, dwell time, and any data accessed or exfiltrated.
Document findings with timestamps, evidence references, and conclusions.

3.5 Remediation

Goal: prevent recurrence.

Remediation steps:

Patch the vulnerability or close the process gap.
Rotate all potentially exposed credentials, even if not confirmed compromised.
Verify the fix in a staging environment if applicable.
Deploy the fix via the standard change management process.
Re-enable affected services after IMPOC sign-off.

Critical-severity remediation target: 7 days from detection. High-severity: 30 days from detection. These match Amazon's required SLAs.

3.6 Post-mortem

Within 14 days of incident closure, the IMPOC drafts a post-mortem documenting:

Timeline of detection, containment, notification, investigation, remediation
Root cause
Contributing factors
What worked well
What did not work and why
Action items to prevent recurrence (with owners and target dates)

The post-mortem is reviewed by the Lead Developer and Backup IMPOC. Action items are tracked in the standard issue tracker until closed.

4. Specific scenarios

Database hack or unauthorized database access

Detect via Railway logs, anomalous query patterns, or external report.
Contain: revoke database credentials, rotate connection strings, disable any compromised application tokens, apply Railway-level network restrictions.
Notify: Amazon (24h), affected customers (72h).
Investigate: preserve logs, identify entry vector (compromised credentials, SQL injection, infrastructure exploit), map scope of accessed records.
Remediate: patch vulnerability, rotate ALL secrets even if not confirmed compromised, restore from clean backup if integrity is in question.
Post-mortem within 14 days.

Leaked credentials (refresh tokens, API keys, ENCRYPTION_KEY)

Detect via secret-scanning alerts, customer report, or external researcher.
Contain: rotate the leaked credential immediately. For LWA refresh tokens, also notify the affected customer to re-authorize. For ENCRYPTION_KEY rotation, follow the documented key-rotation procedure (re-encrypt all Fernet-encrypted fields under the new key in a single transaction).
Notify: Amazon (24h) if Amazon-related; affected customers (72h).
Investigate: how the credential was exposed (commit to public repo, log leak, third-party vendor breach, insider).
Remediate: close the exposure path; add detection so the same path cannot recur silently.
Post-mortem within 14 days.

Data leak (PII exposure)

Detect via customer report, log review, or external disclosure.
Contain: take the exposing surface offline (broken endpoint, leaky log target, misconfigured share); disable any associated accounts; capture forensic state.
Notify: Amazon (24h), affected customers (72h), and any regulatory authority required by applicable privacy law.
Investigate: determine which records were exposed, for how long, who could have accessed them, and any evidence of actual access.
Remediate: fix the root cause, add monitoring for the same pattern, audit similar surfaces for the same defect.
Post-mortem within 14 days.

Account takeover (a customer reports their account was accessed by an attacker)

Detect via customer report or anomalous login pattern.
Contain: lock the account, force password reset, invalidate all active sessions, audit recent activity for unauthorized changes.
Notify: the affected customer (immediately); Amazon (24h) only if Amazon Information was accessed.
Investigate: how the credential was obtained (phishing, credential reuse, our auth bug); audit for similar compromises across other accounts.
Remediate: if our auth had a defect, patch it; otherwise, work with the customer to harden their auth (MFA enrollment, password reset across services).
Post-mortem within 14 days for our-side defects; customer-side credential reuse incidents may not require a full post-mortem.

5. Communication templates

Amazon notification template

Subject: [TCM Incident IRM-YYYY-MM-DD-NNN] Security incident notification

To: [email protected]

Welch Commerce Systems is reporting a security incident affecting Amazon Information.

Incident ID: IRM-YYYY-MM-DD-NNN
Detection time (UTC): [timestamp]
Reported by: [source]
Severity: [Critical / High]

Summary: [1-3 sentence description]

Scope of Amazon Information affected: [data types and approximate record count]

Current status: [containment in progress / contained / under investigation / remediated]

Actions taken so far:
- [bullet list]

Next steps:
- [bullet list]

IMPOC: Todd Welch, [email protected], [phone if available]

We will provide an update within [N] hours / when material changes occur.

Customer notification template

Subject: Security incident notification: [brief description]

Dear [Customer name],

We are writing to inform you of a security incident affecting your T-Code Manager account.

What happened: [1-2 paragraph plain-English description]

What information was involved: [specific data types, scope]

When: [detection date, duration if known]

What we are doing: [containment, remediation]

What you should do: [account actions, password reset, re-authorization with Amazon]

If you have questions, please contact us at [email protected]. We take this seriously and will provide updates as our investigation progresses.

Sincerely,
Todd Welch
Welch Commerce Systems

6. Plan maintenance

This plan is reviewed every six months by the IMPOC and Lead Developer. Reviews include:

Confirming roles are current (people, contact info)
Tabletop exercise: walk through one of the specific scenarios above
Update procedures based on changes in infrastructure, dependencies, or applicable law
Verify that the IMPOC contact email ([email protected]) is monitored and tested via a dummy report

Material changes to this plan are versioned. Previous versions are retained for at least 12 months for audit purposes.

Next scheduled review: 2026-11-12.

Security Policy