Incident Response Plan¶

Purpose¶

This plan defines how Trove identifies, classifies, responds to, and recovers from security incidents. It covers a broader range of incidents than the Breach Response Plan - including platform outages, unauthorised access, compromised credentials, DDoS attacks, and malware - not just data breaches.

If an incident involves or is suspected to involve a personal data breach, this plan should be followed alongside the Breach Response Plan.

Incident Response Team¶

Role	Person	Responsibility
Lead	Joshua Curci - CTO	Leads the technical investigation and response
Executive	Sheree Andersen - CEO	Informed at the outset; approves external communications
Executive	Johnny Reid - COO	Informed at the outset; supports operational response

Incident Classification¶

All incidents are classified by severity to determine the urgency and scale of the response.

P1 - Critical¶

Immediate response required at any time, including outside business hours.

Platform completely unavailable to customers or brands
Active security intrusion or unauthorised access to production systems
Suspected or confirmed data breach involving personal information
Compromised credentials with active access to production or AWS
Ransomware or destructive malware detected on systems

P2 - High¶

Response required within business hours the same day.

Significant platform degradation affecting a subset of customers or features
Compromised credentials identified and access revoked but under investigation
DDoS attack in progress but platform still partially operational
Suspicious activity detected in logs that suggests an attempted intrusion
Third-party integration failure causing significant customer impact

P3 - Medium / Low¶

Response required within the next business day.

Minor service disruption or degraded performance not impacting core functionality
Suspicious activity detected but assessed as low risk
A single customer reporting an isolated issue with no wider impact
Policy or configuration drift identified during routine review

Incident Types¶

Type	Examples
Platform outage	Site down, API unavailable, database unreachable
Unauthorised access	Intrusion into admin portals, AWS console, GitHub, or DuploCloud
Compromised credentials	Stolen or leaked passwords, API keys, or access tokens
DDoS attack	Volumetric or application-layer attack disrupting availability
Malware	Malicious code deployed to infrastructure or a staff device
Data breach	Unauthorised access to or disclosure of personal information - see also Breach Response Plan

Detection & Alerting¶

Incidents may be detected through the following sources:

Source	What It Monitors
Sentry	Application errors, crashes, and performance issues
Uptime monitoring	Platform availability - alerts when the site or API becomes unreachable
AWS CloudWatch	Infrastructure metrics, logs, and alarms for AWS services
Team reports	Staff or customers reporting unusual behaviour directly

Any alert or report that suggests a security incident should be treated as a potential P1 or P2 until assessed otherwise.

Response Phases¶

Phase 1 - Identify¶

Timeframe: Immediate

The team member who detects the incident notifies the CTO immediately via Slack direct message or phone call
The CTO makes an initial assessment and assigns a severity classification (P1 / P2 / P3)
For P1 and P2 incidents, the CEO and COO are notified immediately
A dedicated Slack channel is opened (e.g. #incident-[date]) to coordinate the response and maintain a log of actions

Phase 2 - Contain¶

Timeframe: As fast as possible - within minutes for P1

Stop the incident from spreading or causing further damage:

Compromised credentials - immediately revoke access tokens, rotate passwords, and disable affected accounts across all systems (AWS IAM, GitHub, Google Workspace, DuploCloud)
Unauthorised access - isolate affected systems, revoke active sessions, and block suspicious IPs at the infrastructure level
Platform outage - identify the failing component and begin failover or rollback procedures
DDoS - engage AWS Shield or configure rate limiting and IP blocking via CloudFront or WAF
Malware - isolate the affected device or service immediately; do not attempt to clean in place without guidance

Preserve all logs and evidence - do not delete or alter anything related to the incident.

Phase 3 - Eradicate¶

Timeframe: After containment is confirmed

Remove the root cause of the incident:

Patch the exploited vulnerability or misconfiguration
Remove malicious code, backdoors, or unauthorised access
Rotate all potentially exposed credentials, API keys, and secrets - even if not confirmed as compromised
Audit access logs to identify the full scope of unauthorised activity
If a data breach is suspected or confirmed, escalate to the Breach Response Plan

Phase 4 - Recover¶

Timeframe: After eradication is confirmed

Restore normal operations safely:

Bring affected systems back online from known-good state or backups
Verify platform functionality across all key workflows before declaring the incident resolved
Monitor closely for any recurrence in the 24–48 hours following recovery
Notify affected customers once the facts are confirmed - the CTO drafts, CEO approves before sending

Phase 5 - Review¶

Timeframe: Within 2 weeks of resolution

Conduct a post-incident review covering:

Full timeline of the incident from detection to resolution
Root cause analysis
What worked well in the response
What should be done differently
Technical or process changes required to prevent recurrence

Document outcomes and assign owners for all follow-up actions.

Customer Communication¶

Scenario	Who communicates	Channel
Platform outage affecting all customers	CTO drafts, CEO approves	Email to affected brands
Incident affecting a specific customer	CTO drafts, CEO approves	Direct email to brand contact
Suspected data breach	Follow Breach Response Plan	Email

Do not communicate externally about an incident until the facts are sufficiently confirmed. Premature or inaccurate communications create more risk than a short delay.

Incident Log¶

All incidents must be recorded regardless of severity. Retain records for a minimum of 3 years.

Field	Detail
Incident ID
Date & time detected
Date & time resolved
Severity classification	P1 / P2 / P3
Incident type
Description
Systems affected
Root cause
Containment actions taken
Eradication actions taken
Customers notified	Yes / No
Data breach triggered	Yes / No - if Yes, see Breach Response Plan
Post-incident review completed	Yes / No

Review Cycle¶

This plan should be reviewed annually and updated after any significant incident.

Last reviewed: April 2026 Owner: CTO