Incident Response Plan

1. Purpose

Defines procedures for detecting, responding to, and recovering from security incidents affecting Meridian Seven systems, data, and services.

2. Scope

All security incidents including: unauthorized access, data breaches, service outages, malware, DoS attacks, insider threats, supply chain compromises, and vulnerability exploitation.

3. Severity Levels

SEV-1 — Critical

Confirmed data breach involving customer data, complete production outage, active exploitation of a critical vulnerability, or ransomware.

Metric	Target
Response time	15 minutes
Triage	1 hour
Containment	4 hours
Resolution	24 hours
Postmortem due	5 business days

Notify: CTO, CISO, all engineering, legal counsel, affected customers, regulators (if applicable).

SEV-2 — High

Partial production outage, confirmed compromise without known data exfiltration, unauthorized access to internal systems, or critical vulnerability with active exploitation in the wild.

Metric	Target
Response time	1 hour
Triage	2 hours
Containment	8 hours
Resolution	48 hours
Postmortem due	5 business days

Notify: CTO, CISO, affected engineering teams, affected customers (if service impact is visible).

SEV-3 — Moderate

Degraded performance, minor security event (failed brute-force, single-account compromise), high-severity vulnerability requiring remediation, or non-critical outage.

Metric	Target
Response time	24 hours
Triage	48 hours
Containment	5 business days
Resolution	10 business days
Postmortem due	Optional (CISO discretion)

Notify: CISO, relevant engineering team.

SEV-4 — Informational

Suspicious but unconfirmed activity, low-severity vulnerability, or policy violation without security impact.

Metric	Target
Response time	72 hours
Triage	5 business days
Resolution	Next sprint or 30 days

Notify: CISO for tracking only.

4. Detection Sources

Source	What It Detects	Alert Channel
CrowdStrike	Endpoint threats, malware, suspicious processes, lateral movement	CrowdStrike console, weekly review
GCP Cloud Monitoring	Uptime check failures, application errors, anomalous traffic, alert policy violations, SSL issues	Slack notification channel (#security-alerts)
Dependabot	Vulnerable dependencies	GitHub notifications, weekly security review
Google Workspace	Suspicious sign-in, admin changes, DLP violations	Google Admin alerts, email
1Password Watchtower	Compromised credentials, weak passwords, expiring certs	1Password dashboard, weekly review
User Reports	Phishing, suspicious emails, unusual behavior	Slack #security-alerts, email to CISO

5. On-Call and Escalation

Role	Person	Contact
Primary On-Call	CTO	GCP Cloud Monitoring alert via Slack notification channel
Escalation Backup	CISO	Notified via Slack if no ack in 15 min

Escalation sequence:

0 min: GCP Cloud Monitoring alert policy fires, Slack notification channel posts to #incidents, CTO notified
15 min (no ack): CISO notified via Slack
30 min (no ack): Both CTO and CISO notified simultaneously
Upon ack: incident commander updates the #incidents thread with acknowledgment status

SEV-1/2: all stakeholders notified within 24 hours. SEV-1 with customer data access: initiate breach notification per Section 8.

6. Incident Response Process

6.1 Detection and Reporting

Any person who detects or suspects an incident reports immediately to the CISO via Slack #security-alerts or email. Monitoring-detected incidents are surfaced via GCP Cloud Monitoring alert policies to Slack. User-reported incidents are logged as GitHub Issues using the Incident Response template as fallback.

6.2 Triage

CISO (or designated incident commander) confirms severity (GCP Cloud Monitoring alert policies include severity labels; override if warranted)
Incident commander assembles response team:
- SEV-1/2: CISO, CTO, relevant engineering leads, legal (if data breach)
- SEV-3: CISO, relevant engineer(s)
- SEV-4: CISO tracks only
Incident Report created from template
Dedicated Slack channel created for SEV-1/2: #incident-YYYY-MM-DD-brief

6.3 Containment

Immediate (stop the bleeding):

Revoke compromised credentials; rotate secrets via Doppler
Isolate affected systems (disable network access, suspend services)
Block malicious IPs/domains via Cloudflare WAF
Suspend compromised user accounts
Enable enhanced logging on affected systems

Short-term (stabilize):

Deploy temporary fixes or patches
Implement additional monitoring on the attack vector
Redirect traffic away from affected systems if needed
Preserve forensic evidence before making changes (snapshots, log exports)

6.4 Investigation

Collect and preserve:
- Application and infrastructure logs (GCP Cloud Logging — Cloud Run, Cloudflare)
- Endpoint telemetry (CrowdStrike)
- Access logs (Google Workspace admin audit, GitHub audit)
- Database audit logs (Supabase)
- Network and WAF logs (Cloudflare)
Establish timeline of events
Identify attack vector and scope of compromise
Determine what data (if any) was accessed or exfiltrated
Identify root cause

6.5 Eradication and Recovery

Remove root cause (patch vulnerability, remove malware, close access vector)
Rotate all potentially compromised credentials
Restore from known-good backups if necessary
Verify system integrity before returning to service
Phased recovery with enhanced monitoring
Confirm normal operations and close the incident

7. Communication Plan

7.1 Internal Communication

Audience	SEV-1	SEV-2	SEV-3	SEV-4
CTO	Immediate (phone)	Immediate (Slack)	Daily summary	Weekly summary
Engineering	Immediate (Slack)	Within 1 hour	As needed	N/A
All Staff	Within 4 hours	Within 24 hours	N/A	N/A
Legal	Immediate (phone)	Within 4 hours	N/A	N/A

7.2 External Communication

Audience	When	Method	Responsible
Affected Customers	Within 72 hours of confirmed breach	Email, status page	CTO + Legal
Regulators	Per regulation (GDPR: 72 hours)	Formal written notice	Legal + CISO
Law Enforcement	If criminal activity suspected	Formal report	Legal + CISO
General Public	Only if required by regulation	Status page, blog post	CTO

7.3 Communication Principles

Only CTO or CISO may authorize external communications about security incidents
All external communications reviewed by legal counsel before release
Do not speculate about scope or cause in early communications
Update GCP Cloud Monitoring status dashboard for any customer-visible impact
Maintain internal communication log in the Incident Report

8. Postmortem Requirements

Mandatory for all SEV-1 and SEV-2 incidents; due within 5 business days of resolution
Optional for SEV-3; not required for SEV-4

Postmortem must include:

Incident timeline (detection through resolution)
Root cause analysis (5 Whys or equivalent)
Impact assessment (users, data, services, duration)
What went well; what could be improved
Preventive actions with owners and due dates
Follow-up items tracked in GitHub issues; SEV-1/2 postmortems authored via Slack modal, stored as GitHub issue comments, and pulled by nightly evidence automation to evidence/logs/

Postmortems are blameless — focus on systems and processes, not individuals. Reviewed by CTO, CISO, and incident team.

9. Notification Obligations

9.1 Customer Notification

Customers notified within 72 hours of a confirmed breach affecting their data. Notification must cover: what happened, what data was affected, what Meridian Seven is doing, what the customer should do, and a contact for questions.

9.2 Regulatory Notification

GDPR: supervisory authority within 72 hours; affected individuals without undue delay
State breach notification laws: per applicable state requirements
Contractual obligations: per customer agreements and DPAs

10. Training and Testing

All engineering staff must be familiar with this plan
Tabletop exercises conducted annually
Plan reviewed and updated annually or after any SEV-1/2 incident

Meridian Seven — Confidential