Incident Response Plan
This Incident Response Plan describes how SecondBrain Solutions Pty Ltd ("we", "us") detects, classifies, contains, and communicates about security incidents affecting Bank Pricing Agent by Sharp AI (the "Service"). It complements our Privacy Policy and Security Overview.
This is the public summary of our incident response practices. Internal runbooks and contact escalation chains are not published for security reasons.
1. What Counts as an Incident
We treat any of the following as a security incident requiring response:
- Confidentiality: Unauthorised access to credentials, loan scenarios, or submission history
- Integrity: Unauthorised modification of stored data or in-flight requests
- Availability: Sustained outage or degradation that prevents normal use
- Authentication: Compromise or suspected compromise of the bot identity or service accounts
- Third-party: A security incident at Microsoft Azure or a bank portal that materially affects the Service
- Notifiable: Any event likely to meet the "eligible data breach" threshold under the Notifiable Data Breaches (NDB) scheme
2. Detection
We detect incidents through:
- Azure platform monitoring. Azure Monitor and Container Apps health checks, Key Vault access logs, abnormal traffic alerts
- Application logging. Request/response patterns, authentication failures, unexpected error rates
- External reports. Incidents reported by clients, brokers, banks, Microsoft, or security researchers
If you believe you have identified a security incident, please contact us immediately at james@secondbrain.com.au.
3. Severity Classification
Once detected, incidents are classified within 1 business hour:
| Severity | Definition | Examples |
|---|---|---|
| P1, Critical | Confirmed unauthorised access to credentials or PII; widespread outage; regulatory notification likely required | Credential vault compromise; cross-tenant data leak |
| P2, High | Suspected unauthorised access; localised outage; data integrity at risk | Failed authentication anomalies; partial outage |
| P3, Moderate | Material degradation without immediate data risk | Performance regression; non-credential auth issue |
| P4, Low | Operational issue with no data or availability impact | Logging anomaly; recoverable error |
Severity may be revised during response as we gather more information.
4. Containment, Eradication, Recovery
For each confirmed incident, we follow these phases:
4.1 Containment (immediate, hours)
- Isolate affected systems or accounts
- Revoke compromised credentials (forcing rotation if needed)
- Disable affected pathways if safe to do so
4.2 Eradication (hours to days)
- Identify and remove the root cause
- Apply patches, configuration changes, or code fixes
- Verify the underlying issue cannot recur via the same path
4.3 Recovery (after eradication)
- Restore normal service operation
- Validate data integrity
- Monitor for re-occurrence at heightened sensitivity for an appropriate period
4.4 Post-incident review
Within 10 business days of recovery, we complete a written post-incident review covering: timeline, root cause, what worked, what didn't, and committed corrective actions. Internal-only; relevant findings are communicated to affected parties as part of notification.
5. Notification
5.1 Affected individuals and organisations
For incidents involving unauthorised access to or loss of personal information, we will notify affected individuals and the client organisation as soon as practicable, and in any case within 72 hours of becoming aware of the incident where reasonably possible.
Notifications will include:
- A description of the incident (without compromising ongoing investigation or other affected parties)
- The categories of information affected
- Steps we have taken in response
- Recommended actions you can take (e.g., rotate credentials)
- Our contact for further information
5.2 Regulators
Where an incident meets the NDB threshold, we will notify the Office of the Australian Information Commissioner (OAIC) in accordance with the statutory timeline (currently as soon as practicable).
5.3 Microsoft
For incidents affecting our Microsoft Teams integration or potentially affecting other Microsoft tenants, we will notify Microsoft via the appropriate Partner Center and Bot Framework channels.
5.4 Banks
For incidents involving bank portal credentials, we will coordinate with the affected bank(s) regarding broker notification and credential rotation.
6. Cooperation
We cooperate fully with:
- Lawful requests from regulators, including the OAIC
- Investigations by Microsoft regarding Teams platform incidents
- Affected banks regarding portal credential incidents
- Court orders and law enforcement requests where legally required
7. Continuous Improvement
After each incident (P1 or P2), corrective actions identified in the post-incident review are tracked to closure. Higher-priority incidents result in changes to detection, monitoring, code, or process. We periodically review this Incident Response Plan and update it as our practices mature.
8. Reporting an Incident to Us
To report a suspected security incident in the Service:
Email: james@secondbrain.com.au
Subject line: "Security Incident, Bank Pricing Agent"
Phone: +61 481 761 659 (urgent issues)
For non-urgent security questions, you can also contact us via the channels in our Privacy Policy.
This summary describes our incident response practices in general terms. Specific runbooks, contact chains, and technical procedures are maintained internally and are not published for security reasons.