Incident Response Plan
Version 1.0 · Last reviewed: June 2026
Owner: Calum Batey
Version: 1.0
Review cadence: Annually, and after any incident.
1. Purpose and scope
This plan defines how PathIQ detects, responds to, and recovers from security incidents affecting the confidentiality, integrity, or availability of customer or personal data. It applies to all PathIQ systems, staff, and sub-processors.
2. What is an incident
A security incident is any event that compromises, or may compromise, the security of customer or personal data or PathIQ systems. Examples include unauthorised access, data exposure or loss, malware, account compromise, or a significant service outage with security implications.
3. Severity levels
| Level | Description | Example |
|---|---|---|
| High | Confirmed or likely unauthorised access to, or loss of, personal data | Exposed database, compromised admin account |
| Medium | Security control failure with limited or no confirmed data impact | Misconfiguration detected and contained |
| Low | Minor event, no data impact | Isolated failed-login spike, blocked attack |
4. Roles
- Incident Lead (Calum Batey): coordinates the response, makes containment and notification decisions.
- Technical responders: investigate, contain, and remediate.
- Customer contact: manages communication with affected customers.
For a team of three, one person may hold multiple roles; the Incident Lead has final responsibility.
5. Response phases
- Detect & report: Anyone who suspects an incident reports it immediately to the Incident Lead. Sources include alerts, audit logs, provider notifications, and customer reports.
- Triage & classify: The Incident Lead confirms whether it is an incident, assigns a severity, and starts an incident record (timeline, actions, evidence).
- Contain: Limit impact. Revoke credentials, isolate affected services, block malicious access, and rotate secrets as needed.
- Eradicate & recover: Remove the cause, patch the vulnerability, restore from clean backups (MongoDB Atlas point-in-time recovery), and verify integrity before returning to normal operation.
- Notify: See Section 6.
- Review: Within 10 business days, conduct a post-incident review covering root cause, what worked, corrective actions, and updates to controls and this plan.
6. Notification
- Customers: Affected customers are notified without undue delay (target: within 72 hours of confirming an incident affecting their data), with follow-up updates until resolution. Notification is consistent with any contractual obligations to the customer.
- Regulator (Notifiable Data Breaches scheme): If an eligible data breach is likely to result in serious harm and cannot be remediated, PathIQ will notify affected individuals and the Office of the Australian Information Commissioner (OAIC) as required.
- Sub-processors: If an incident originates with a sub-processor, PathIQ coordinates with them and relays relevant information to affected customers.
7. Evidence and records
All incidents are logged with a timeline, actions taken, and decisions made. Audit logs and provider logs are preserved to support investigation. Records are retained for at least 12 months.
8. Contacts
- Incident Lead: Calum Batey (cal@pathiq.com.au)
- Provider support: MongoDB Atlas, Google Cloud, Netlify, Stripe, Anthropic (via respective support/trust channels)
- OAIC: oaic.gov.au