Risk Assessment Methodology

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

Was this helpful?