Risk Assessment Methodology
ISMS Copilot uses a structured, repeatable risk assessment methodology to identify, assess, evaluate, and treat information security risks. This…
ISMS Copilot uses a structured, repeatable risk assessment methodology to identify, assess, evaluate, and treat information security risks. This methodology satisfies ISO 27001 requirements (Clauses 6.1.1, 6.1.2, 6.1.3, 8.2, 8.3) and produces consistent, comparable results across assessment cycles.
This page describes our risk assessment methodology — how we identify, score, and treat risks. The actual risk register contents are confidential and maintained in our secure repository.
Risk Categories
We assess risks across four categories covering the full spectrum of threats to our platform and users:
- Security Risks — Unauthorized access, data breaches, credential compromise, system manipulation
- Operational Risks — Service availability, third-party dependencies, business continuity, capacity
- Compliance Risks — Regulatory violations, contractual breaches, certification gaps, audit findings
- AI-Specific Risks — LLM hallucination, prompt injection, AI data handling, model bias, provider governance
Risk Assessment Process
Our risk assessment follows a five-step process:
- Context Review — Review organizational context, threat intelligence, incident history, and platform changes (Clause 4)
- Risk Identification — Identify assets at risk, threats, vulnerabilities, and potential consequences (Clause 6.1.2)
- Risk Analysis — Score each risk on likelihood and impact using the scales below (Clause 6.1.2)
- Risk Evaluation — Calculate risk score and classify severity (Clause 6.1.2)
- Risk Treatment — Select treatment option and implement controls (Clause 6.1.3)
Likelihood Scale
| Score | Level | Definition | Indicative Frequency |
|---|---|---|---|
| 1 | Rare | Could occur only in exceptional circumstances | Less than once per 5 years |
| 2 | Unlikely | Could occur but not expected | Once per 1-5 years |
| 3 | Possible | Could occur at some point | Once per year |
| 4 | Likely | Expected to occur in most circumstances | Multiple times per year |
| 5 | Almost Certain | Expected to occur frequently or is already occurring | Monthly or more frequently |
Factors considered: Whether the threat vector is actively exploited in similar platforms, existing controls that reduce likelihood, historical incident data, attacker motivation and capability.
Impact Scale
| Score | Level | Definition | Examples |
|---|---|---|---|
| 1 | Negligible | Minimal or no impact | Cosmetic issue, single-user inconvenience for minutes |
| 2 | Minor | Limited impact; quickly recoverable | Brief service degradation, minor data inconsistency (no breach) |
| 3 | Moderate | Noticeable impact; requires effort to resolve | Partial outage for hours, loss of non-critical feature |
| 4 | Major | Significant impact on operations, data, or reputation | Extended outage, data breach affecting multiple users, regulatory notification required |
| 5 | Catastrophic | Severe impact threatening business viability | Mass data breach, total service loss, regulatory enforcement action |
Factors considered: Number of users or data records affected, whether confidential or restricted data is exposed, regulatory notification obligations, recovery time and cost, impact on customer trust.
Risk Scoring Matrix
Risk Score = Likelihood x Impact (scale of 1-25)
| Score Range | Risk Level | Action Required |
|---|---|---|
| 20-25 | Critical | Immediate mitigation required; CEO approval for any delay |
| 15-19 | High | Address within 48 hours; treatment plan required |
| 8-14 | Medium | Address within 1-2 weeks; schedule for next sprint |
| 1-7 | Low | Monitor and review; address opportunistically |
Risk scores are automatically calculated from our structured risk definitions, reducing manual errors and ensuring consistency across assessment cycles.
Risk Treatment Options
For each risk above the acceptable threshold, we select one of four treatment options:
| Treatment | Definition | When Used |
|---|---|---|
| Mitigate | Implement controls to reduce likelihood and/or impact | Default option; most risks are treated this way |
| Accept | Acknowledge the risk and monitor without additional controls | When cost of mitigation exceeds potential impact, or residual risk is within tolerance |
| Transfer | Shift the risk to a third party | When a provider is better positioned to manage the risk |
| Avoid | Eliminate the risk by removing the activity or asset | When the risk is unacceptable and cannot be adequately mitigated |
Risk Acceptance Criteria
- Low risks (1-7) may be accepted by the Engineering Lead
- Medium risks (8-14) require CEO awareness; may be accepted with documented rationale
- High and Critical risks (15+) require explicit CEO approval with documented justification, compensating controls, and a review date
Risk Register Structure
All risks are documented as structured data files organized by category (Security, Operational, Compliance, AI-Specific). Each risk entry captures:
- Unique identifier, category, and asset affected
- Risk description and threat vector
- Likelihood and impact scores
- Assigned risk owner
- Mitigation strategy and implemented controls
- Review date and status
- Framework alignment (ISO 27001, SOC 2)
Risk register contents — including specific identified risks, scores, and treatment details — are confidential. This page describes our methodology; the actual register is maintained in our secure, version-controlled repository with restricted access.
Risk Review Cadence
| Activity | Frequency |
|---|---|
| Risk register validation | Weekly (automated) |
| High/Critical risk review | Bi-weekly |
| Full risk register review | Quarterly |
| Trigger-based assessment | On event (incident, new feature, architecture change, regulatory change) |
Residual Risk
After controls are applied, each risk has a residual risk level scored using the same methodology but reflecting the post-control state. Residual risk is documented in the risk register, reported in the management review, and any residual risk above Medium requires documented acceptance with a review date.
Alignment with Incident Severity
Our risk scoring aligns with our incident severity classification to ensure consistent response:
| Risk Score | Risk Level | Incident Severity | Response SLA |
|---|---|---|---|
| 20-25 | Critical | S0 | Same-day containment + mitigation |
| 15-19 | High | S1 | 48-hour mitigation |
| 8-14 | Medium | S2 | 1-2 weeks |
| 1-7 | Low | S3 | Backlog / monitor |