Incident Response Policy
| Owner | [Security Owner — to be named: founder/CTO] |
| Approved by | [signatory] |
| Effective date | [set on approval] |
| Review cadence | Annual; one tabletop exercise per year |
| Version | 0.1 — DRAFT |
| TSC mapping | CC7.3–CC7.4 |
1. Purpose
Section titled “1. Purpose”Define how the Company detects, responds to, communicates about, and learns from security incidents — including data breaches.
2. What is an incident
Section titled “2. What is an incident”Any event that compromises (or threatens to compromise) the confidentiality, integrity, or availability of customer data or Company systems: unauthorized access, credential exposure, tenant-isolation failure, fraudulent or erroneous ERP write, malware, vendor breach, or extended outage.
3. Severity tiers
Section titled “3. Severity tiers”| Sev | Definition | Initial response target |
|---|---|---|
| SEV1 | Confirmed breach of customer data, or full outage | Immediate; Security Owner engaged at once |
| SEV2 | Probable compromise, partial outage, or active exploitation | < 1 hour |
| SEV3 | Contained issue, suspicious activity, or single-tenant impact | < 1 business day |
4. Process
Section titled “4. Process”- Report. Anyone who suspects an incident reports it immediately via the
designated channel (
#security/ Security Owner). No blame for reporting. - Triage & declare. The Security Owner assigns a severity and an incident lead.
- Contain. Limit blast radius — revoke credentials, disable affected accounts/flags, isolate systems. Established runbooks are the de-facto procedures here, e.g. secret rotation and the Neon pooler runbook.
- Eradicate & recover. Remove the cause and restore service (see the BCP/DR Policy for recovery mechanisms).
- Communicate. See §5.
- Post-incident review. Within 5 business days, a written post-mortem: timeline, root cause, and corrective actions (blameless).
5. Breach notification
Section titled “5. Breach notification”If an incident is confirmed to involve unauthorized access to customer data, the Company notifies affected customers without undue delay and within the timeframe required by contract and applicable law (target: 72 hours of confirmation). The Security Owner owns the notification decision and content.
6. Testing
Section titled “6. Testing”The Company runs at least one incident-response tabletop exercise per year, documents it, and feeds lessons back into this policy. (This produces the operating-instance evidence a Type II audit requires.)
7. Review
Section titled “7. Review”Reviewed at least annually by the Security Owner.