Incident Response Plan

Effective: September 18, 2026
Updated: September 18, 2026
Version: 2.1

On this page

This plan defines Tanqory’s end-to-end approach to handling security incidents—from detection and containment through eradication, recovery, notification, and continuous improvement. It covers data breaches, intrusions, malware/ransomware, denial-of-service, insider/third-party misuse, and physical events impacting systems. Follow this plan alongside the BCP, DR, Data Classification/Retention, Network Security, Vulnerability Disclosure/Bug Bounty, and contractual SLAs. If conflicts arise, the more specific/recent document or stricter law prevails.

1) Purpose, Scope, Principles

Objectives: reduce MTTD/MTTR; limit business and personal data impact; meet legal/contract notice timelines; preserve audit-ready evidence; and drive continuous improvement. Scope: cloud, network, applications, payment flows, customer/merchant/employee data, and processor/subprocessor environments (Production/Staging/Sandbox) under RBAC and least privilege. Principles: act fast; preserve evidence; notify those who must know; avoid unauthorized disclosure/negotiation; document decisions.

2) Governance, Roles, Decision Authority

CSIRT is led by an Incident Commander (IC, typically CISO or delegate) empowered to declare incidents and direct response. RACI: IC (Accountable), Technical Lead (Responsible), DPO (Accountable for privacy/legal), Legal (Review/Approve), Communications (Responsible for external messaging), Customer Support (Responsible for customer messaging), Executives/Board (Informed; approve for P1). Channels: PagerDuty (on-call), Slack #incident-response, Jira/Service Desk tickets, incident@tanqory.com, on-call phone for P1. Escalation: P1 to executives within 30 minutes; Board per BCP if required.

3) Severity and Escalation

Severity P1–P4 based on data/system/business impact: P1 critical (major PII/financial exposure, core outage, confirmed exfiltration); P2 high (significant impact requiring rapid containment); P3 medium (limited/contained); P4 low (informational/suspected). SLA to triage: P1 15m, P2 1h, P3 4h, P4 1d. SLA to start containment: P1 1h, P2 4h, P3 24h, P4 3d. Appendix A provides a severity matrix (record count, data sensitivity PII/PCI/PHI, system count, business impact).

4) Lifecycle (Detect → Analyze → Contain → Eradicate → Recover → Notify → Improve)

Detect: SIEM/IDS/IPS/WAF/EDR alerts, human reports, bug bounty; auto-ticket creation.
Analyze: collect evidence (logs, PCAP, memory/disk images) with chain of custody.
Contain: isolate hosts, block IP/domain/hash, disable accounts/keys, temporarily disable risky features; add durable fixes (patch/config/segmentation).
Eradicate: remove malware/backdoors, rotate keys/secrets, close persistence.
Recover: restore from clean, validated backups; integrity and malware checks; heightened monitoring 7–30 days.
Notify: stakeholders/regulators/customers per law/contract.
Improve: PIR, root cause, action items with owners/due dates.

┌──────────┐→┌──────────┐→┌────────────┐→┌──────────┐→┌──────────┐
│ DETECT   │ │ ANALYZE  │ │ CONTAIN    │ │ ERADICATE│ │ RECOVER  │
└──────────┘ └──────────┘ └────────────┘ └──────────┘ └──────────┘
      │                                           │
      ▼                                           ▼
┌──────────────┐                         ┌─────────────┐
│ NOTIFY       │◀───────────────────────│ IMPROVE/PIR │
└──────────────┘                         └─────────────┘

5) Evidence Preservation and Forensics

Store evidence encrypted with RBAC/KMS/HSM. Maintain chain of custody (collector, time, location, checksum). Avoid altering originals—use snapshots/images and validated forensic tools. Minimum artifacts: OS logs; network/flow/firewall/WAF logs; application logs; memory/disk images if needed; account/permission deltas; integrity hashes. Retain ≥3–5 years or longer per law/contract (finance/health may require more).

6) Containment, Eradication, Recovery

Short-term: isolate hosts/segments, disable suspect accounts/API keys, block IP/domain/hash, temporarily disable risky features. Long-term: patch/harden configs, rotate keys/passwords, add WAF/IDS rules, segment networks, add new detections/use-cases. Recover from clean backups with integrity/malware checks; heightened monitoring 7–30 days. Align RTO/RPO with BIA and contracts; if unmet, invoke BCP/DR and notify enterprise customers per SLA.

7) Regulatory, Customer, Contractual Notification

Follow statutory timelines: GDPR (72h to authority; prompt data subjects if high risk), SG PDPA (3 business days to PDPC for significant harm), US state breach laws, PCI DSS (brands/acquirer immediately). Sector rules (DORA/NIS2/finance/health) may be stricter—comply. If customer contracts impose tighter SLAs, those govern. Use durable media and log content/timestamps for PIR.

8) Communications and Stakeholder Engagement

Internal comms via designated Slack/phone/email only; no personal/unlogged channels. External comms via Communications/Legal using approved scripts (confirmed facts, actions taken, user/customer steps, contact channel). Media requires Communications Lead/executive approval. Honor legal holds/court orders; log reasons. Notify vendors/subprocessors when involved and require support per contract.

9) Key Playbooks

Ransomware: disconnect network (do not power off), block spread, isolate patient zero, collect notes/hashes/IOCs, rotate exposed keys, restore from clean backups, no payment unless executive+legal approve; check for double extortion exfil.
Data Breach: confirm scope/records, close leak path (API/storage/key), preserve evidence, assess legal notice, notify customers/data subjects/regulators, consider identity protection where appropriate.
DDoS: enable scrubbing/shielding/rate limits, coordinate CDN/ISP, update status page, tune thresholds post-event.
Credential/API Key Compromise: suspend accounts/keys, force password/MFA reset, revoke tokens/sessions, review historical activity, notify users with guidance.
Third-Party/Subprocessor Incident: notify provider immediately, request RCA per SLA, assess data/service impact, notify customers/regulators per contract/law, consider failover/replacement if non-compliant.

10) Training, Exercises, Metrics

Quarterly CSIRT drills; annual org-wide training on incident/phishing reporting. Tabletop at least twice/year; simulation/failover annually; Red/Blue Team annually. Record outcomes, approvers, and completed improvements. Track MTTD, MTTR, MTTC, recurrence, SLA adherence, regulator/customer notifications; review quarterly to refine rules/tooling.

11) Records, Retention, Review

Log all incidents in the central system with timestamps, owners, decisions, outcomes. Retain initial/interim/final reports and PIRs ≥3–5 years or longer per law/contract. Review this plan at least annually or after P1s, major tech changes, or new laws/standards (e.g., EU AI Act delegated acts, NIS2, DORA, US breach laws). Provide audit mappings (ISO 27001/27002, ISO 22301, NIST SP 800-61r2, PCI DSS 4.0, SOC 2) on request.

12) Enforcement, Legal, SLA

Staff and vendors must comply; violations may lead to discipline/termination/contract action and legal remedies. If enterprise contracts set stricter response/notification SLAs, follow the Order Form/contract schedules. If disclosure is legally restricted (court/government order), limit to what is required and document rationale.

Appendix A: Severity and SLA (Example)

Level	Description	Examples	Response Start	Initial Containment	Internal Reporting	Comms Cadence
P1 Critical	Core system/data outage; confirmed large exfiltration	Ransomware, major PII/financial leak	15 min	1 hour	Exec in 2h; regulator ≤24h if required	Every 60–120 min
P2 High	Significant impact; business degraded	Server intrusion, suspected partial leak	1 hour	4 hours	Exec within 24h	Every 4–6 hours
P3 Medium	Limited/contained	Single-host malware, misconfig	4 hours	24 hours	Summary in 3 days	Daily
P4 Low	Informational/suspected	Port scans, failed logins	1 day	3 days	Monthly report	As needed

Appendix B: Notification Timelines (Key Laws)

GDPR: 72h to authority; prompt data subjects if high risk.
SG PDPA: 3 business days to PDPC for significant harm; prompt data subjects.
US state breach laws: follow state-specific timing/content/channel.
PCI DSS/brands: notify brands/acquirer immediately for card data.
DORA/NIS2/other sector rules: add sub-appendices when in force; stricter timelines govern.
If regulator/contract imposes tighter timing, that governs.

Appendix C: Contacts and Escalation

Incident Commander (on-call): PagerDuty
Security Operations: security@tanqory.com
Incident intake/urgent: incident@tanqory.com
Data Protection Officer: dpo@tanqory.com
Customer/public comms: communications@tanqory.com or published status channel
No personal/unlogged channels except emergency phone for P1
Status page: https://status.tanqory.com
Order Form/SLA references (enterprise): https://legal.tanqory.com/order-forms

Appendix D: Glossary

CSIRT, DPO, MTTD, MTTR, MTTC, PIR, RBAC, SIEM, WAF, EDR, IOC, RTO/RPO (see BIA/BCP).

Appendix E: Standards Mapping (Audit Aid)

ISO 22301 (Business Continuity) — ties to BCP/DR and RTO/RPO.
NIST SP 800-61r2 — Detect–Analyze–Contain–Eradicate–Recover–Post-Incident.
NIS2/DORA — incident reporting/resilience (add detail as rules finalize).
FedRAMP/HIPAA — government/health incident evidence/notification (add per contract).
SOC 2 (CC7) / PCI DSS 4.0 (Req.12.10) — incident governance/testing/evidence.
GDPR/PDPA/other privacy laws — see Appendix B timelines; map additional countries as enacted.