Incident Response Plan

1. Purpose

This plan defines how Paylithix Inc. detects, responds to, contains, and recovers from security incidents that could affect the Gatelithix Gateway Cardholder Data Environment (CDE) or compromise cardholder data. It satisfies PCI DSS 4.0.1 Requirement 12.10.

2. Scope

This plan covers all suspected or confirmed security incidents affecting:

• The CDE (Token Vault Service, PCI VPC, PCI Cloud SQL, Cloud KMS keys)
• Connected systems (Gateway API, Connector services, Admin dashboard)
• Cardholder data in any form (encrypted PAN, tokens, card metadata)
• Authentication and authorization systems (Auth0, GCP IAM, API keys)
• Third-party service providers that process or could affect cardholder data

2.1 Incident Definition

A security incident is any event that:

• Results in or could result in unauthorized access to cardholder data
• Compromises the confidentiality, integrity, or availability of CDE systems
• Violates security policies defined in this policy framework
• Indicates unauthorized PAN storage on any system outside the vault (PCI DSS 12.10.7)

3. Roles and Responsibilities

3.1 Incident Response Team

3.2 24/7 Contact List

This contact list is maintained with current information and tested annually (last verified: 2026-04-16).

On-call: PagerDuty alert routes to thibault@paylithix.com for SEV-1 and SEV-2. Benoit Boisset (benoit@paylithix.com) is escalation contact if IC unreachable within 15 minutes.

Escalation rule: If the primary contact does not respond within 15 minutes, escalate to the backup. If neither responds within 30 minutes, escalate to the next person in order.

Contact list last verified: 2026-04-16. See compliance/evidence/2026-04-16/irt-contact-list.md for full verification record.

4. Detection

4.1 Monitoring and Alerting Sources

4.2 Alert Triage

When an alert fires or a potential incident is reported:

1. The first responder (whoever receives the alert) performs initial triage within 15 minutes.
2. Triage determines severity level (see Section 4.3) and whether to activate the full incident response process.
3. All alerts involving potential cardholder data exposure default to Severity 1 until investigation proves otherwise.

4.3 Severity Classification

5. Response Procedures

5.1 Phase 1: Identification (0—30 minutes)

1. Acknowledge the alert and log the start time.
2. Assign an Incident Commander (ISO is default; escalate per contact list if unavailable).
3. Open an incident channel (dedicated Slack channel or call).
4. Gather initial facts:
   • What systems are affected?
   • Is cardholder data potentially exposed?
   • What is the attack vector or failure mode?
   • Is the incident ongoing or historical?
5. Classify severity per Section 4.3.
6. Begin incident log documenting all actions with timestamps.

5.2 Phase 2: Containment (30 minutes — 2 hours)

Short-term containment (stop the bleeding):

Long-term containment:

1. Patch or remediate the root cause vulnerability.
2. Verify containment is effective (attack is not continuing through other paths).
3. Preserve evidence: do not destroy logs, database snapshots, or container images involved in the incident.

5.3 Phase 3: Eradication (2—24 hours)

1. Identify and remove the root cause (vulnerability, misconfiguration, compromised credential).
2. Apply patches, configuration changes, or code fixes.
3. Verify the fix through testing in a non-production environment before deploying to production.
4. Scan for indicators of compromise (IOCs) across all CDE and connected systems.
5. Verify no unauthorized PAN storage exists on any system outside the vault (PCI DSS 12.10.7).

5.4 Phase 4: Recovery (24—72 hours)

1. Restore affected systems to normal operation.
2. Re-enable disabled accounts or services only after verifying the root cause is addressed.
3. Increase monitoring sensitivity for the affected systems for a minimum of 30 days.
4. Verify all security controls are functioning:
   • Firewall rules match policy
   • KMS key access restricted to vault service account
   • Audit logging is active
   • TLS is enforced on all connections
5. Confirm no residual unauthorized access exists.

5.5 Phase 5: Notification

5.6 Phase 6: Post-Mortem (Within 2 weeks of resolution)

Every SEV-1 and SEV-2 incident shall have a formal post-mortem. SEV-3 incidents have post-mortems at the IC’s discretion.

6. Post-Mortem Template

The post-mortem document shall include:

# Incident Post-Mortem: [Title]

**Date of Incident:** YYYY-MM-DD
**Severity:** SEV-[1/2/3]
**Incident Commander:** [Name]
**Duration:** [Time from detection to resolution]
**Cardholder Data Impacted:** [Yes/No, scope if yes]

## Timeline
- HH:MM — [Event or action taken]
- ...

## Root Cause
[Description of the fundamental cause]

## Impact
- Systems affected: [list]
- Data affected: [description, scope]
- Merchants affected: [count, names if applicable]
- Duration of exposure: [time]

## What Went Well
- [Item]

## What Could Be Improved
- [Item]

## Action Items
| Item | Owner | Due Date | Status |
|------|-------|----------|--------|
| [Action] | [Name] | YYYY-MM-DD | Open |

## Lessons Learned
[Summary of what the team learned]

7. Annual Tabletop Exercise

1. The ISO shall conduct at least one tabletop exercise per year to test this incident response plan (PCI DSS 12.10.2).
2. The exercise shall simulate a realistic scenario (e.g., compromised API key leading to unauthorized vault access, ransomware targeting CDE infrastructure, insider threat).
3. All incident response team members must participate.
4. The exercise shall test:
   • Alert detection and triage process
   • Escalation and communication procedures
   • Containment decision-making
   • Evidence preservation procedures
   • Notification procedures
5. After each exercise, the IC shall document findings, update the IRP if needed, and record the exercise with date, participants, scenario, and outcomes.
6. Exercise schedule: October of each year (6 months offset from policy review).

8. Evidence Preservation

During any security incident:

1. Do not delete, modify, or overwrite logs, database records, or container images related to the incident.
2. Capture Cloud Logging exports for the incident timeframe to a separate, access-restricted GCS bucket.
3. Create Cloud SQL database snapshots before any remediation changes.
4. Record all incident response actions in the incident log with timestamps.
5. Preserve evidence for at least 12 months or as required by legal counsel.
6. Chain of custody: document who accessed evidence, when, and for what purpose.

9. Training

1. All incident response team members shall receive incident response training upon assignment and annually thereafter (PCI DSS 12.10.4).
2. Training shall cover:
   • This incident response plan and procedures
   • Evidence collection and preservation techniques
   • Detection of unauthorized activity indicators
   • Use of monitoring and logging tools (Cloud Logging, Cloud Monitoring, Auth0 logs)
   • Communication and escalation procedures
3. Training completion is documented and retained for the duration of the individual’s IR team membership plus one year.

10. Plan Maintenance

1. This plan shall be reviewed at least annually and updated as needed (PCI DSS 12.10.2).
2. The plan shall be updated after:
   • Every SEV-1 or SEV-2 incident (incorporating lessons learned)
   • Every tabletop exercise (incorporating findings)
   • Significant changes to CDE architecture
   • Changes to incident response team membership
   • Industry developments or new threat intelligence
3. All plan updates require ISO approval and are tracked in the document history.

11. Compliance and Enforcement

1. All personnel are required to report suspected security incidents immediately. Failure to report a known incident is a policy violation.
2. Interference with incident investigation or evidence destruction is a critical violation subject to termination and potential legal action.
3. The IC has authority to take any necessary containment action during an active incident, including shutting down services.

12. Related Documents

• Information Security Policy (POL-001) — Parent policy
• Access Control Policy (POL-002) — Account compromise response
• Network Security Policy (POL-003) — Network-level containment
• Key Management Policy (POL-004) — Key compromise procedures
• Data Classification Policy (POL-007) — Data categories and handling
• PCI DSS 4.0.1 Requirement 12.10

13. Document History