Incident Response Plan

Document control

Field	Value
Owner	Ron Benisty — CTO & CSO (ron.b@iontwrks.com)
Status	Approved
Version	1.0
Classification	Confidential
Approved by	Ron Benisty — CTO & CSO
Approval date	2026-05-26 (Tuesday)
Last reviewed	2026-05-26
Review cycle	Annual — next review due May 2027
Parent policy	Secure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.5.24–A.5.28 (information-security incident management family) and SOC 2 Type II CC7.4 (responding to identified security events) + CC7.5 (recovery). Closes Gap 14 of the SSDLC gap analysis.

---

1. Purpose

Detect, contain, eradicate, recover from, and learn from security incidents — with sufficient evidence to satisfy SOC 2 Type II sampling and the breach-notification obligations of Amendment 13 and GDPR Article 33.

2. Scope

Any event that compromises (or threatens to compromise) the confidentiality, integrity, or availability of S.E.T systems or data, including:

• Credential compromise (GitHub, AWS IAM, WorkOS, Cloudflare, Logz.io, sub-processors).
• Malicious code in the codebase or its dependencies (Shai-Hulud-class events).
• Unauthorized access to AWS or GitHub.
• Data exfiltration from tenant schemas or S3 buckets.
• Denial of service exceeding Cloudflare's mitigation.
• Customer-data leak or accidental cross-tenant exposure.
• Supply-chain compromise of a sub-processor.

3. Severity classification

Severity	Definition	Response time	Notification
Sev 1	Active or confirmed compromise of customer data, prod credentials, or prod availability	Page on-call within 15 min	CTO & CSO + affected customers (see §7)
Sev 2	Compromise of internal credentials, nonprod data, or potential prod path with no current exploitation	≤ 1 hour	CTO & CSO + internal
Sev 3	Confirmed vulnerability with limited blast radius, no active exploitation	≤ 1 business day	CTO & CSO
Sev 4	Informational / suspicious event awaiting triage	≤ 5 business days	Internal triage

4. Detection sources

• Logz.io alerts — the primary alert pane (Observability §Tier 2): app errors, 5xx spikes, failed-login bursts at WorkOS, custom rules.
• AWS GuardDuty findings → Logz.io.
• RDS / Postgres anomalies → Logz.io.
• PagerDuty / Slack / on-call SMS — the human-notification path off Logz.io.
• Customer reports — security@binarynetworks.ai mailbox + in-app support.
• Third-party reports — bug-bounty programme (when launched) + responsible disclosure.

5. Response team & roles

Role	Default holder	Responsibility
Incident Commander (IC)	CTO & CSO	Single decision-maker for the duration; coordinates the response
Tech Lead	On-call S.E.T engineer	Drives containment, eradication, recovery
Comms Lead	CTO & CSO (or delegate)	Internal updates, customer notifications, regulatory comms
Scribe	Any team member	Maintains the incident timeline in real time (the §9 record)

Roles may collapse onto one person at MVP scale; the role-name discipline is still kept in the record so the timeline is auditable.

6. Response phases

1. Detect — alert triggers; IC opens an incident channel and the timeline record.
2. Triage — confirm scope, classify severity (§3), engage the right people.
3. Contain — stop the bleeding (revoke credentials, rotate keys, block IPs at Cloudflare, isolate Fargate tasks, disable WorkOS connections).
4. Eradicate — remove the root cause (patch, redeploy clean image, drop compromised resources).
5. Recover — restore service (Multi-AZ failover, RDS PITR, redeploy previous image — see Architecture §DR and Backup & Recovery).
6. Learn — within 5 business days of close, perform a Root-Cause Analysis and feed remediation back through Change Management.

7. Communication

Internal: dedicated incident Slack channel + email distribution. Cadence: every 30 min for Sev 1, hourly for Sev 2, daily for Sev 3–4.

External — customers: for any incident involving customer data, the Comms Lead notifies affected MSSPs within 72 hours of confirmation (Amendment 13 / GDPR Article 33), with at minimum: nature of the incident, categories of data, likely consequences, measures taken, contact for follow-up.

External — regulators: the Comms Lead files the required notification with the Israeli Privacy Protection Authority within 72 h where Amendment 13 applies, and with the relevant EU supervisory authority where GDPR applies.

External — sub-processors: if a sub-processor is the root cause, the Comms Lead engages their incident channel immediately and tracks their disclosure.

8. Forensics & evidence

• AWS CloudTrail (multi-region, Object-Locked S3) — immutable record of every AWS API call.
• Tenant audit_events tables — append-only customer-action history.
• Logz.io archive — application logs, traces, frontend errors (30 d hot + 7 y in S3 Glacier).
• VPC Flow Logs + GuardDuty findings — network and AWS-layer detection.
• GitHub audit log — source-control + workflow history.

Forensic captures are never modified; analysts work from copies pulled into the incident record.

9. The incident record (the evidence)

Every incident produces one durable record containing:

1. Incident ID + severity.
2. Timeline (Scribe-maintained): detection, decisions, actions, communications.
3. Affected systems / tenants / data categories.
4. Root cause + linked RCA document.
5. Remediation PRs + their status (per Change Management).
6. Customer / regulator notifications sent (timestamps + recipients).
7. MITRE ATT&CK classification — for each materially-distinct attacker action observed, the matching ATT&CK technique ID (e.g. T1078 valid accounts, T1486 data encrypted for impact). Provides a consistent vocabulary for cross-incident analysis and downstream detection-rule tuning. Complements the design-phase STRIDE view owned by the Security Requirements & Threat Modeling Policy.

Retained ≥ 24 months per the Evidence Collection & Retention Policy.

10. Drill cadence

• Quarterly tabletop — IC + Tech Lead + Comms Lead walk through a scripted scenario (ransomware, customer-data leak, supply-chain compromise, credential compromise). 60–90 minutes. Output: a one-page record + any process changes filed as PRs.
• Annual full drill — exercises the Architecture §DR procedure: region failover or restore from cross-region encrypted backup. Output: a DR-drill report retained ≥ 12 months.
• Drill cadence is non-negotiable — Type II will sample these records.

11. Integration with the rest of the SSDLC

• Sev 1 / Sev 2 incidents trigger an RCA — mandatory.
• Containment changes use the Change Management — Emergency tier — retroactive review within 1 business day.
• Failed restore tests are treated as Sev 2 — see Backup & Recovery §4.
• Compromised credentials trigger immediate revocation per Access Reviews §4.

12. Document change history

Version	Date	Author	Description of change	Approved by
1.0	2026-05-26	Ron Benisty (CTO & CSO)	Initial version — establishes the Incident Response Plan.	Ron Benisty (CTO & CSO)