The Risk Management Policy sets the methodology botBrains uses to identify, assess, treat, and accept information security risks. It’s the canonical reference for how we reason about risk across the ISMS, and other policies link here rather than restate the method.
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 all assets, systems, processes, and third parties within the scope of the ISMS: the botBrains SaaS platform, its supporting cloud infrastructure, our source code and pipelines, company devices, and the personal data we process on behalf of customers. It covers both team members and any contractors who act on our behalf.
Roles
The CISO (Liam van der Viven) owns this policy and the risk management process, and is the default risk owner unless a specific risk goes to the co-founder. Risk acceptance for anything above the automatic-acceptance threshold requires CISO sign-off. See Roles and Responsibilities for the full accountability model.
Methodology
We follow a four-step cycle: identify, assess, treat, and monitor.
Identify. We catalogue the assets in scope and the threats and vulnerabilities that apply to each, drawing on incidents, vulnerability scans, supplier reviews, and changes to our systems or environment. We record each risk in the risk register with a named risk owner.
Assess. We score each risk on likelihood and impact against the confidentiality, integrity, and availability of customer data, personal data, and business-critical systems. The overall rating is the product of the two scores.
| Score | Likelihood | Impact |
|---|
| 1 | Rare (under 10% over the company’s life) | Negligible: no personal or customer data affected, not reportable. |
| 2 | Unlikely (10-35%) | Minor: limited internal data, no personal-data breach, brief degradation. |
| 3 | Possible (35-65%, within a year or two) | Moderate: possible personal-data exposure, short outage, a controller may need notifying under the DPA. |
| 4 | Likely (65-90%, within a year) | Major: breach reportable to a supervisory authority under GDPR Article 33, outage beyond the RTO. |
| 5 | Almost certain (over 90% or recurring) | Severe: large-scale breach with high risk to individuals under GDPR Article 34, prolonged outage, regulatory fines. |
| Option | When we use it |
|---|
| Mitigate | Apply or strengthen a control to reduce likelihood or impact. |
| Transfer | Shift the risk to a third party, for example through a supplier contract or insurance. |
| Avoid | Stop or change the activity that creates the risk. |
| Accept | Knowingly retain the risk where treatment would cost more than the potential impact. |
Risk register
The risk register is the single record of all current and previously treated risks, their owners, scores, treatment decisions, and review dates. The CISO maintains it in Notion (Employees Only: Risk Register). The Statement of Applicability (SoA) documents the selection of Annex A controls and the justification for including or excluding each one, and the outcomes of this process drive it.
botBrains has not yet produced a formal documented risk register or SoA. Building both is a prerequisite for certification and is tracked in our roadmap. Review
The CISO reviews this policy and performs a full risk assessment at least annually, and on material change such as a significant new feature, a new subprocessor, a major incident, a change to applicable law, or a change in our infrastructure. The Supplier Management Policy covers supplier-driven risk.
ISO 27001 mapping
This policy supports ISO/IEC 27001:2022 Clauses 6.1 (actions to address risks and opportunities), 8.2 (information security risk assessment), and 8.3 (information security risk treatment), and Annex A control 5.7 (threat intelligence). 
