Incident response

Version: 1.0
Last Reviewed: 2026-03-07
Review Cadence: Quarterly (plan review) / Annually (tabletop exercise)
Classification: Internal — Shareable with Customers Under NDA
Owner: Perceive8 Engineering & Security

---

Table of Contents

1. Purpose & Scope
2. Incident Classification
3. Incident Response Team
4. Incident Response Phases
5. Communication Plan
6. Data Breach Procedures
7. Evidence Preservation
8. Post-Incident Review Template
9. Incident Log Template
10. Contact Information & Escalation
11. Review & Testing Schedule

---

Purpose & Scope

This document defines Perceive8's process for detecting, responding to, and recovering from security incidents. It applies to all incidents affecting:

• Perceive8 production infrastructure and services
• Customer data (audio recordings, transcripts, analysis results, PII)
• Internal systems and credentials
• Third-party services that process Perceive8 customer data

Definitions

Term	Definition
Security Incident	Any event that compromises the confidentiality, integrity, or availability of Perceive8 systems or customer data
Data Breach	A security incident that results in unauthorized access to, disclosure of, or loss of personal data
Incident Commander (IC)	The person responsible for coordinating the incident response
Affected Party	Any customer, user, or data subject impacted by the incident

---

Incident Classification

Severity Levels

Severity	Name	Definition	Examples (Perceive8-Specific)	Response Time	Update Cadence
S1	Critical	Confirmed data breach or active exploitation; unauthorized access to customer data	Unauthorized access to customer audio recordings or transcripts; database credential compromise; authentication bypass allowing cross-user data access; ransomware or data exfiltration	15 minutes	Every 30 minutes
S2	High	Service outage or security control failure with potential for data exposure	Complete API outage; authentication system failure; JWT signing secret compromise; API key hash database exposure; webhook delivery to unverified domains	30 minutes	Every 1 hour
S3	Medium	Partial service degradation or security control weakness identified	Partial feature failure (e.g., streaming unavailable); rate limiting bypass; elevated error rates; single AI provider outage affecting processing; audit logging failure	4 hours	Every 4 hours
S4	Low	Minor issues with no immediate security impact	Cosmetic UI bugs; non-critical dependency vulnerability disclosed; minor performance degradation; documentation errors in security docs	1 business day	Daily

Severity Escalation Criteria

An incident should be escalated to a higher severity if:

• The scope of impact expands (more users/data affected than initially assessed)
• Containment measures are ineffective
• Evidence of active exploitation is discovered
• Customer data exposure is confirmed (any severity → S1)
• Regulatory notification obligations are triggered
• Media attention or public disclosure occurs

Severity De-escalation Criteria

An incident may be de-escalated if:

• Root cause is identified and contained
• Impact is confirmed to be narrower than initially assessed
• No customer data was accessed or exposed
• Service is restored and stable

---

Incident Response Team

Roles and Responsibilities

Role	Responsibility	Assigned To
Incident Commander (IC)	Overall coordination; decision authority; communication approval	CTO or senior engineer on-call
Technical Lead	Root cause investigation; containment implementation; remediation	Senior backend engineer
Communications Lead	Customer notifications; status page updates; regulatory notifications	CEO or designated communications person
Evidence Custodian	Log preservation; forensic data collection; chain of custody	Designated engineer (IC assigns)
Scribe	Real-time incident documentation; timeline maintenance	Any available team member (IC assigns)

On-Call Rotation

Current State: Perceive8 does not yet have a formal on-call rotation. The founding engineering team monitors alerts and responds to incidents as they arise.

Planned: Implement PagerDuty or Opsgenie-based on-call rotation with defined escalation paths.

Escalation Path

L1: Engineer who detects the issue
 └→ L2: Senior Engineer / Tech Lead (within response time SLA)
     └→ L3: CTO (for S1/S2 incidents or if L2 cannot resolve)
         └→ L4: CEO (for S1 incidents requiring customer/regulatory communication)

---

Incident Response Phases

Phase 1: Detection & Identification

Objective: Confirm that a security incident has occurred and assess initial severity.

Detection Sources

Source	Examples
Automated Monitoring	Error rate spikes, health check failures, unusual traffic patterns
Audit Logs	Unexpected access patterns, failed authentication spikes
Customer Reports	Reports of unauthorized access, data exposure, service issues
Team Discovery	Engineer notices anomaly during development or review
External Reports	Security researcher disclosure, vendor notification
Dependency Alerts	CVE notifications for dependencies

Identification Checklist

• What systems or data are potentially affected?
• When did the incident begin (or when was it first observed)?
• Is the incident ongoing or has it concluded?
• What is the initial severity assessment?
• Who discovered the incident and how?
• Is customer data potentially exposed?
• Are any regulatory notification obligations likely triggered?

Actions

1. Assign Incident Commander — The first senior engineer aware of the incident assumes IC role until formally handed off.
2. Create Incident Channel — Open a dedicated communication channel (Slack channel, video call) for the incident.
3. Begin Incident Log — Start documenting timeline using the Incident Log Template.
4. Classify Severity — Use the severity table to assign initial severity.
5. Notify Stakeholders — Per the Communication Plan.

Phase 2: Containment

Objective: Limit the scope and impact of the incident. Prevent further damage.

Short-Term Containment (Immediate)

Action	When to Use
Rotate compromised credentials	API keys, JWT secrets, database passwords, provider keys compromised
Block suspicious IP addresses	Active attack from identifiable source
Disable compromised user accounts	Account takeover confirmed
Revoke compromised API keys	API key exposed or misused
Scale down or isolate affected service	Service is being exploited
Enable maintenance mode	Widespread exploitation requiring full service pause
Disable webhook delivery	Webhooks delivering data to unauthorized endpoints

Long-Term Containment

Action	When to Use
Deploy patched application version	Vulnerability in application code
Update infrastructure configuration	Misconfiguration identified
Implement additional access controls	Access control gap exploited
Add monitoring for attack pattern	To detect recurrence
Rotate all secrets of affected type	Scope of credential compromise unclear

Containment Decision Matrix

Scenario	Containment Action
Compromised JWT signing secret	Rotate secret → redeploy → all existing JWTs invalidated
Exposed API key (single key)	Delete the key → notify key owner → issue new key
Database credential compromise	Rotate database password → redeploy all services
AI provider key compromise	Rotate key with provider → update env var → redeploy
Cross-user data access bug	Deploy hotfix or take endpoint offline → audit access logs
Webhook delivering to wrong domain	Disable webhook → verify domain ownership → re-enable

Phase 3: Eradication

Objective: Remove the root cause of the incident.

Actions

1. Identify Root Cause — Determine exactly how the incident occurred.
2. Remove Threat — Eliminate the vulnerability, misconfiguration, or compromised component.
3. Verify Removal — Confirm the root cause has been fully addressed.
4. Scan for Persistence — Check for backdoors, additional compromised accounts, or lingering access.

Root Cause Categories

Category	Examples	Eradication Approach
Code Vulnerability	Auth bypass, injection, IDOR	Code fix + deploy + regression test
Misconfiguration	Open CORS, missing auth on endpoint	Configuration fix + deploy + audit similar configs
Credential Compromise	Leaked secret, weak password	Rotate all potentially affected credentials
Dependency Vulnerability	CVE in library	Update dependency + deploy + scan for exploitation
Social Engineering	Phished credentials	Reset credentials + security awareness + MFA
Infrastructure Issue	Provider breach, DNS hijack	Work with provider + verify integrity

Phase 4: Recovery

Objective: Restore normal operations and verify system integrity.

Recovery Checklist

• All compromised credentials have been rotated
• Patched/fixed version is deployed to production
• All services are operational and passing health checks
• Monitoring confirms normal behavior patterns
• No indicators of ongoing compromise
• Affected customers have been notified (if applicable)
• Status page updated to reflect resolution

Recovery Actions

1. Restore Services — Bring services back online in a controlled manner.
2. Verify Integrity — Confirm data integrity; check for unauthorized modifications.
3. Monitor Closely — Increase monitoring sensitivity for 48-72 hours post-recovery.
4. Confirm with Customers — If customers were notified, confirm resolution.
5. Update Status Page — Mark incident as resolved.

Phase 5: Post-Incident Review

Objective: Learn from the incident and improve defenses.

Timeline: Post-incident review must be conducted within 5 business days of incident resolution.

See Post-Incident Review Template for the full template.

Key Activities

1. Timeline Reconstruction — Build a complete, accurate timeline from detection to resolution.
2. Root Cause Analysis — Identify the fundamental cause (not just the proximate trigger).
3. Impact Assessment — Determine the full scope of impact (users, data, duration).
4. Action Items — Define specific, assigned, time-bound improvements.
5. Documentation — Publish the post-incident review internally.
6. Follow-Up — Track action items to completion.

---

Communication Plan

Internal Escalation

Severity	Notify Immediately	Notify Within 1 Hour	Notify Within 24 Hours
S1	CTO, CEO, all engineers	Legal counsel	Board (if applicable)
S2	CTO, senior engineers	CEO	All engineers
S3	Senior engineer on-call	CTO (if unresolved after 4h)	Team standup
S4	—	—	Team standup

Customer Notification

Notification Triggers

Customers must be notified when:

• Their data was accessed by unauthorized parties
• A service outage exceeds 4 hours
• A security vulnerability may have exposed their data
• Regulatory requirements mandate notification

Notification Timelines

Regulation	Notification Deadline	Recipient	Details
GDPR (Art. 33)	72 hours from awareness	Supervisory authority	If breach involves personal data of EU residents
GDPR (Art. 34)	Without undue delay	Data subjects	If breach is likely to result in high risk to rights/freedoms
HIPAA	60 days from discovery	HHS + affected individuals	If breach involves PHI; <500 individuals: annual log; ≥500: immediate
CCPA/CPRA	Without unreasonable delay	Affected California residents	If breach involves unencrypted personal information
State Breach Laws	Varies (typically 30-60 days)	Affected residents + state AG	Per applicable state law
Contractual (DPA)	Per DPA terms (typically 48-72h)	Customer DPA contact	Per individual customer DPA

Notification Channels

Channel	Use Case
Email	Primary notification channel for affected customers
Status Page	Service availability updates (no sensitive details)
In-App Banner	Urgent notices for active dashboard users
Direct Call	S1 incidents affecting enterprise customers

Status Page Updates

Severity	Status Page Update
S1	Immediate; updated every 30 minutes
S2	Within 30 minutes; updated every hour
S3	Within 4 hours; updated every 4 hours
S4	Not required

---

Data Breach Procedures

Breach Assessment Checklist

When a potential data breach is identified, complete this assessment:

Scope Assessment

• What types of data were potentially exposed?
  • Audio recordings
  • Transcripts
  • Analysis results / AI insights
  • User account information (email, name)
  • API keys (hashed or plaintext?)
  • Billing / payment information
  • Webhook configurations
  • Internal system data
• How many users/data subjects are potentially affected?
• What is the geographic distribution of affected users? (EU, California, etc.)
• Is the data encrypted? (in transit, at rest, field-level)
• Was the data actually accessed, or only potentially accessible?
• Is the exposure ongoing or has it been contained?

Risk Assessment

• Could the exposed data be used for identity theft?
• Could the exposed data cause financial harm?
• Could the exposed data cause reputational harm to data subjects?
• Does the exposed data include special categories (health data, biometric data)?
• Is the data publicly accessible or limited to a specific threat actor?

Regulatory Assessment

• Are any affected users EU residents? → GDPR notification required
• Are any affected users California residents? → CCPA notification required
• Does the data include PHI under a BAA? → HIPAA notification required
• Are any affected users minors? → COPPA/FERPA considerations
• Which state breach notification laws apply?
• Do any customer DPAs have specific notification requirements?

Data Subject Notification Template

Subject: Security Notice from Perceive8

Dear [Customer Name],

We are writing to inform you of a security incident that may have affected 
your data on the Perceive8 platform.

WHAT HAPPENED
[Clear, factual description of the incident]

WHEN IT HAPPENED
[Date/time range of the incident]

WHAT DATA WAS INVOLVED
[Specific types of data potentially affected]

WHAT WE'VE DONE
[Actions taken to contain and remediate the incident]

WHAT YOU CAN DO
[Recommended actions for the customer, e.g.:]
- Rotate any API keys that may have been exposed
- Review your account activity for unauthorized access
- [Additional recommendations specific to the incident]

ONGOING MEASURES
[Steps being taken to prevent recurrence]

CONTACT US
If you have questions or concerns, please contact our security team:
- Email: [email protected]
- [Additional contact methods]

We take the security of your data seriously and sincerely apologize for 
this incident.

[Name]
[Title]
Perceive8

Regulatory Notification Template (GDPR Article 33)

PERSONAL DATA BREACH NOTIFICATION
Per GDPR Article 33

To: [Supervisory Authority]
From: Perceive8 ([legal entity details])
Date: [Date]
Reference: [Incident ID]

1. NATURE OF THE BREACH
   [Description of the breach, including:]
   - Categories of data subjects affected: [e.g., platform users]
   - Approximate number of data subjects: [number]
   - Categories of personal data: [e.g., email addresses, audio recordings]
   - Approximate number of records: [number]

2. DATA PROTECTION OFFICER / CONTACT
   Name: [Name]
   Email: [email protected]
   Phone: [Phone]

3. LIKELY CONSEQUENCES
   [Description of likely consequences of the breach for data subjects]

4. MEASURES TAKEN
   [Description of measures taken or proposed to:]
   a) Address the breach
   b) Mitigate possible adverse effects

5. ADDITIONAL INFORMATION
   [Any additional relevant information]

   [ ] This notification is made within 72 hours of becoming aware 
       of the breach
   [ ] If not within 72 hours, reasons for delay: [explanation]

Provider Notification (Subprocessor Breach)

If a breach involves a subprocessor:

1. Assess Impact — Determine what Perceive8 customer data the subprocessor had access to.
2. Coordinate with Provider — Obtain breach details, scope, and remediation timeline.
3. Notify Customers — If customer data was affected, follow standard notification procedures.
4. Review Subprocessor — Evaluate whether to continue using the subprocessor.
5. Update Subprocessor List — If the subprocessor is replaced, update Subprocessors.

---

Evidence Preservation

Preservation Priorities

When a security incident is detected, preserve evidence in this order:

1. Volatile Data — Running processes, network connections, memory contents
2. Logs — Application logs, audit logs, access logs, system logs
3. Database State — Relevant database records, query logs
4. Configuration — Current configuration files, environment state
5. Network Data — Traffic captures if available

Preservation Procedures

Evidence Type	Preservation Method	Retention
Application Logs	Copy to secure, isolated storage	Minimum 1 year
Audit Log Entries	Database export to isolated storage	Minimum 1 year
Database Records	Point-in-time snapshot or targeted export	Duration of investigation + 1 year
Configuration Files	Copy with timestamps	Duration of investigation
Screenshots	Timestamped captures	Duration of investigation
Communication Records	Preserve incident channel logs	Duration of investigation + 1 year

Chain of Custody

For each piece of evidence:

• Record who collected it and when
• Record the hash (SHA-256) of the evidence file
• Store in a location accessible only to the incident response team
• Document any access to or modification of the evidence
• Maintain a chain of custody log

Evidence Log Entry

Evidence ID: [EVD-YYYY-MM-DD-NNN]
Incident ID: [INC-YYYY-MM-DD-NNN]
Collected By: [Name]
Collection Time: [ISO 8601 timestamp]
Description: [What the evidence is]
Source: [Where it was collected from]
SHA-256 Hash: [hash]
Storage Location: [where it is stored]
Access Log:
  - [timestamp] [name] [action]

---

Post-Incident Review Template

# Post-Incident Review: [Incident Title]

**Incident ID:** [INC-YYYY-MM-DD-NNN]
**Date of Incident:** [Date]
**Date of Review:** [Date]
**Severity:** [S1/S2/S3/S4]
**Incident Commander:** [Name]
**Review Participants:** [Names]

## Executive Summary
[2-3 sentence summary of what happened, impact, and resolution]

## Timeline
| Time (UTC) | Event |
|-----------|-------|
| [time] | [event] |
| [time] | [event] |

## Root Cause
[Detailed description of the root cause]

## Impact
- **Users Affected:** [number]
- **Data Exposed:** [types and volume]
- **Duration:** [start to resolution]
- **Service Impact:** [description]
- **Financial Impact:** [if applicable]

## What Went Well
- [item]
- [item]

## What Could Be Improved
- [item]
- [item]

## Action Items
| # | Action | Owner | Due Date | Status |
|---|--------|-------|----------|--------|
| 1 | [action] | [name] | [date] | [ ] Open |
| 2 | [action] | [name] | [date] | [ ] Open |

## Lessons Learned
[Key takeaways for the team]

## Follow-Up Schedule
- [ ] Action items reviewed: [date]
- [ ] All action items completed: [target date]
- [ ] Process improvements validated: [target date]

---

Incident Log Template

Use this template to maintain a real-time log during incident response:

# Incident Log: [Brief Description]

**Incident ID:** INC-[YYYY-MM-DD]-[NNN]
**Severity:** [S1/S2/S3/S4]
**Status:** [Investigating / Identified / Monitoring / Resolved]
**Incident Commander:** [Name]
**Scribe:** [Name]

## Summary
[Brief description — updated as understanding evolves]

## Affected Systems
- [ ] API
- [ ] Database
- [ ] Object Storage
- [ ] Streaming
- [ ] Webhooks
- [ ] Dashboard
- [ ] AI Providers
- [ ] Authentication
- [ ] Other: [specify]

## Timeline

| Time (UTC) | Author | Entry |
|-----------|--------|-------|
| [HH:MM] | [name] | Incident detected: [description] |
| [HH:MM] | [name] | IC assigned: [name] |
| [HH:MM] | [name] | Severity classified as: [S1-S4] |
| [HH:MM] | [name] | Containment action: [description] |
| [HH:MM] | [name] | [ongoing entries...] |

## Containment Actions Taken
- [ ] [action and result]
- [ ] [action and result]

## Customer Impact
- Affected users: [number or "assessing"]
- Data exposure: [yes/no/assessing]
- Service impact: [description]

## Communications Sent
| Time | Channel | Audience | Message Summary |
|------|---------|----------|----------------|
| [time] | [channel] | [audience] | [summary] |

## Open Questions
- [ ] [question]
- [ ] [question]

## Next Steps
- [ ] [action] — [owner]
- [ ] [action] — [owner]

---

Contact Information & Escalation

Internal Contacts

Role	Contact	Availability
CTO	[Name — internal directory]	S1/S2: 24/7; S3/S4: business hours
CEO	[Name — internal directory]	S1: 24/7; S2: business hours
Senior Engineers	[Names — internal directory]	Per on-call rotation
Legal Counsel	[Contact — internal directory]	S1: 24/7; S2+: business hours

External Contacts

Purpose	Contact
Supabase Support	[Support channel per plan]
Railway Support	[Support channel per plan]
AI Provider Security	Per provider security contact pages
Domain Registrar	Per registrar support
Legal / Privacy Counsel	[External counsel contact]

Customer-Facing Contacts

Purpose	Contact
Security Incidents	[email protected]
Privacy Inquiries	[email protected]
General Support	[email protected]
Status Page	[status page URL]

---

Review & Testing Schedule

Document Review

Activity	Frequency	Next Due	Owner
Incident Response Plan review	Quarterly	2026-06-07	CTO
Contact information verification	Quarterly	2026-06-07	Engineering Lead
Escalation path validation	Quarterly	2026-06-07	CTO
Notification template review	Semi-annually	2026-09-07	Communications Lead

Testing

Activity	Frequency	Next Due	Owner
Tabletop exercise (S1 scenario)	Annually	2026-09-07	CTO
Tabletop exercise (S2 scenario)	Annually	2027-03-07	Engineering Lead
Communication drill	Annually	2026-09-07	Communications Lead
Credential rotation drill	Semi-annually	2026-06-07	Engineering Lead

Tabletop Exercise Scenarios

The following scenarios should be used for annual tabletop exercises:

1. Scenario A — Data Breach: An attacker exploits an authentication bypass to access customer audio recordings and transcripts across multiple accounts. Discovered via customer report.

2. Scenario B — Credential Compromise: The JWT signing secret is accidentally committed to a public repository. Discovered via automated secret scanning alert.

3. Scenario C — Subprocessor Breach: An AI transcription provider notifies Perceive8 that they experienced a breach affecting data processed in the last 30 days.

4. Scenario D — Ransomware: The database is encrypted by ransomware. Backups are available but may be up to 24 hours old.

5. Scenario E — Insider Threat: An admin user's account is used to export data for multiple customers outside of normal business processes.

---

Appendix: Regulatory Reference

Regulation	Breach Definition	Notification Deadline	Authority	Reference
GDPR	Breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data	72 hours (authority); without undue delay (data subjects if high risk)	Lead supervisory authority	Art. 33, 34
HIPAA	Acquisition, access, use, or disclosure of PHI in violation of the Privacy Rule	60 days (individuals); 60 days (HHS if ≥500); annual (HHS if <500)	HHS OCR	45 CFR §164.404-408
CCPA/CPRA	Unauthorized access and exfiltration, theft, or disclosure of unencrypted personal information	Most expedient time possible, without unreasonable delay	California AG	Cal. Civ. Code §1798.82
COPPA	Unauthorized access to children's personal information	Per FTC guidance	FTC	16 CFR Part 312

See also:

• GDPR Readiness
• HIPAA Review
• CCPA/CPRA Readiness
• COPPA/FERPA Review
• BAA Workflow

---

Document History

Version	Date	Author	Changes
1.0	2026-03-07	Perceive8 Engineering	Initial release

---

This document is reviewed quarterly. Next scheduled review: 2026-06-07.