The Incident Management Policy is the canonical definition of how botBrains detects, reports, triages, contains, and learns from information security incidents. It sets the lifecycle, severity model, roles, and record keeping that every responder follows. Policies that deal with downstream obligations link here rather than restate the process: the Breach Notification Policy covers regulatory and customer notification, and the Responsible Disclosure Policy covers how outsiders report vulnerabilities into this process.
botBrains is not yet ISO 27001 certified. We are preparing our ISMS and writing these policies as part of pursuing certification, and we fully intend to get our controls attested.
Scope
This policy applies to every security event affecting the confidentiality, integrity, or availability of botBrains systems or customer data, across all infrastructure (AWS, Hetzner, DigitalOcean, Modal, Vercel), model subprocessors, source control (GitHub), email, the password manager, and the botBrains platform. It covers events reported by team members, customers, subprocessors, and external researchers.
Definitions
A security event is an observable occurrence relevant to the security of botBrains data or systems. A security incident is an event that causes, or is likely to cause, loss or damage to the confidentiality, integrity, or availability of that data or systems. A personal data breach is an incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data; these trigger the Breach Notification Policy.
Reporting
Anyone who suspects an incident must report it to the CISO without delay and no later than 24 hours after discovery. Report by direct message or email to the CISO, or to security@botbrains.io. A report should describe what the reporter observed, when, how they discovered it, and which systems or data appear affected. Reporters preserve evidence (logs, screenshots, files) and avoid actions that could destroy it. Failure to report a known incident is itself a policy violation.
Automated signals also raise incidents. Sentry, Better Stack alerting, and dependency scanning (Dependabot) feed the CISO so that suspected issues surface without waiting on a human report. See the Logging and Monitoring Policy.
Severity
The CISO assigns a severity at triage, which sets response urgency.
| Severity | Meaning | Response |
|---|
| Critical | Active exploitation or confirmed compromise of customer data or production. | Immediate response, work continues until contained. |
| High | Exploitation likely or imminent, or sensitive data at direct risk (for example a lost unencrypted device, a credible vulnerability under active threat). | Same-day response. |
| Low or Medium | Unverified suspicion or limited issue with no clear data risk (for example a suspicious email, a single isolated alert, a lost full-disk-encrypted laptop). | Investigate and resolve in normal working time. |
Response lifecycle
botBrains follows an iterative lifecycle for every confirmed incident. The CISO acts as incident manager and may engage the co-founder as responder.
| Stage | What happens |
|---|
| Triage and classify | Confirm the event is an incident, assign severity, and decide who responds. |
| Escalate | For Critical and High severity, notify the CISO immediately and open the incident record. Where an internal person may be the cause, the CISO handles it discreetly and doesn’t discuss it more widely. |
| Contain | Limit the damage: isolate affected systems, revoke or rotate credentials, block the source. The Access Control Policy governs credential compromise. |
| Eradicate | Remove the root cause, for example patch the vulnerability, remove malware, or close the misconfiguration. |
| Recover | Restore affected systems and data to normal operation and confirm integrity. Restoration from backups follows the Backup Policy and Business Continuity and Disaster Recovery. |
| Notify | Determine notification obligations. If the incident involves personal data, follow the Breach Notification Policy. |
| Learn | After resolution, the CISO documents a root cause analysis and the lessons learned, and turns them into concrete follow-up actions. |
Record keeping
The CISO records every reported event and its response in a single incident log (Employees Only: Incident Log). Each entry captures a description, the severity, the timeline, the root cause, the evidence preserved, the mitigations applied, the current status, and any parties the CISO disclosed the incident to. The CISO completes a root cause analysis for every Critical incident and for any incident involving personal data. The CISO retains records for audit in line with the Data Retention Policy.
Roles
The CISO owns incident response, makes the final call on classification and breach determination, and closes incidents. The co-founder supports response when engaged. Customers report problems with their use of the service and confirm when the team resolves them. Detailed role definitions live in Roles and Responsibilities. Anyone who takes on an incident-response role completes incident-response training within 90 days of assuming that role and repeats it annually thereafter.
ISO 27001 mapping
This policy supports Annex A 5.24 (incident management planning), 5.25 (assessment and decision on events), 5.26 (response to incidents), 5.27 (learning from incidents), 5.28 (collection of evidence), and 6.8 (information security event reporting).
Enforcement and exceptions
Violations may lead to suspension of access and disciplinary action. The CISO must approve and record any exception with a reason and an expiry date.
Review
The CISO owns this policy, reviews it at least annually and on any material change, and exercises the response process at least annually. 
