Risk Assessment Methodology

Document Number: ISMS-RM-RAM-01

Classification: Internal

Version: 0.1.0

Effective Date: February 25, 2026

Author: Lucas Shin — Security Director

Approved By: Richard Williams — CISO

Next Review Date: February 2027

1. Purpose

This document defines the risk assessment methodology used within the Cybercraft Information Security Management System (ISMS). It establishes the criteria, scales, and processes for identifying, analysing, evaluating, and treating information security risks in accordance with ISO/IEC 27001:2022 Clauses 6.1.2 and 6.1.3.

This methodology provides the basis for the Risk Register, which serves as the single repository for all identified risks, their analysis, treatment decisions, and ongoing monitoring.

2. Scope

This methodology applies to all information assets, processes, and systems within the ISMS scope, including:

Microsoft 365 cloud services and tenant configurations
BYOD endpoints (macOS, Windows, iOS, Android) used to access corporate data
SaaS applications (Category A, B, C per Application & Data Governance Policy)
Personnel, processes, and organisational information
Third-party and supplier relationships

3. Risk Assessment Process

The risk assessment follows a structured five-step process aligned with ISO 31000:

Identify — Enumerate risks by considering threats, vulnerabilities, and affected assets
Analyse — Determine inherent likelihood and impact (before controls)
Evaluate — Calculate risk score and classify risk level to prioritise treatment
Treat — Select and implement treatment options; record in Risk Register
Monitor & Review — Periodic reassessment per the PDCA cycle (§10)

4. Risk Identification

4.1 Sources

Risks are identified through:

Security architecture analysis (documented in [Domain Context] Security Architecture)
ISMS gap analysis against ISO 27001 Annex A controls
Incident history and near-miss reports
Changes in technology, regulation, or business context
Vendor and third-party security assessments
Industry threat intelligence and advisory sources

4.2 Documentation

Each identified risk is recorded in the Risk Register with:

Risk Title — Short descriptive name
Risk ID — Unique identifier (format: R-NNN)
Category — Domain classification (Identity & Access, Data Protection, Endpoint Security, Application Security, Supply Chain, Operations, Governance, Compliance)
Description — Detailed explanation of the risk scenario, including threat, vulnerability, and potential consequence
Primary Asset — The information asset, system, or process at risk

5. Risk Analysis

5.1 Likelihood Criteria

Level	Rating	Description
1	Rare	May occur only in exceptional circumstances. No history of occurrence.
2	Unlikely	Could occur but not expected. Has occurred elsewhere in similar organisations.
3	Possible	Might occur. Has occurred previously or is a known threat vector.
4	Likely	Will probably occur. Occurs regularly in similar environments.
5	Almost Certain	Expected to occur frequently. Is occurring or has recently occurred.

5.2 Impact Criteria

Level	Rating	Description
1	Negligible	No measurable impact on operations, finances, or reputation.
2	Minor	Minor operational disruption. Limited to a single user or process. Recoverable within hours.
3	Moderate	Noticeable operational disruption. May affect client service delivery. Recoverable within 1 business day.
4	Major	Significant disruption. Client data or service compromised. Requires incident response. May trigger regulatory notification.
5	Critical	Severe or prolonged disruption. Loss of critical business data. Regulatory breach or legal action. Existential threat to business.

5.3 Risk Score Calculation

Score range: 1 to 25

5.4 Risk Level Classification

Risk Level	Score Range	Action Required
🟢 Low	1 – 5	Accept with standard controls. No additional treatment required.
🟡 Medium	6 – 10	Documented treatment decision required. Monitor and review quarterly.
🟠 High	12 – 16	Priority treatment required. Treatment plan with target date and owner assigned.
🔴 Critical	20 – 25	Immediate action required. Escalate to CISO and CEO. Treatment plan within 5 business days.

5.5 Risk Matrix

Likelihood ↓ Impact →	1 Negligible	2 Minor	3 Moderate	4 Major	5 Critical
5 Almost Certain	5 Low	10 Medium	15 High	20 Critical	25 Critical
4 Likely	4 Low	8 Medium	12 High	16 High	20 Critical
3 Possible	3 Low	6 Medium	9 Medium	12 High	15 High
2 Unlikely	2 Low	4 Low	6 Medium	8 Medium	10 Medium
1 Rare	1 Low	2 Low	3 Low	4 Low	5 Low

6. Risk Evaluation

Risks are evaluated based on both inherent risk (before controls) and residual risk (after controls):

Inherent risk is assessed first to understand the baseline threat level
Current controls are documented and their effectiveness evaluated
Residual risk is calculated after accounting for implemented controls
Treatment decisions are based on the residual risk level

Priority for treatment:

Critical and High residual risks are prioritised for immediate or planned treatment
Medium residual risks require a documented treatment decision
Low residual risks are accepted with existing controls

7. Risk Treatment

Per the Information Security Policy (ISMS-POL-ISP-01) §6.2, identified risks shall be treated through one of four options:

Option	Description	Approval
Mitigate	Implement additional controls to reduce likelihood or impact to an acceptable level	Security Director
Accept	Accept the residual risk with documented rationale and business justification	Per §8 acceptance criteria
Transfer	Transfer risk via insurance, contractual arrangement, or outsourcing	CEO + CISO
Avoid	Discontinue the activity or remove the asset that creates the risk	CEO + CISO

Each treatment decision is recorded in the Risk Register with:

Treatment option selected
Treatment description (specific actions to be taken)
Responsible owner
Target completion date
Current status (Not Started → In Progress → Implemented → Verified)

8. Risk Acceptance Criteria

Residual Risk Level	Acceptance Authority	Requirements
🟢 Low	Security Director	Accepted by default with standard controls. No additional documentation required.
🟡 Medium	CISO	Documented rationale required. Reviewed quarterly.
🟠 High	CEO + CISO	Formal risk acceptance statement. Business justification. Compensating controls documented. Reviewed quarterly.
🔴 Critical	CEO + CISO	Formal risk acceptance with executive sign-off. Must demonstrate that treatment is not feasible or cost-proportionate. Reviewed monthly.

9. Roles and Responsibilities

Role	Person	Responsibility
Security Director	Lucas Shin	Conduct risk assessments, maintain Risk Register, propose treatment plans, implement technical controls, report risk status
CISO	Richard Williams	Approve risk treatment decisions, accept medium-level residual risks, conduct annual risk review with management
CEO	Farah Herbert	Accept high/critical residual risks, allocate resources for risk treatment, strategic risk oversight
All Personnel	—	Report identified risks and security incidents to the Security Director

10. Review and Update Cycle

Trigger	Activity	Responsible
Annual	Full risk reassessment aligned with ISMS management review	Security Director + CISO
Quarterly	Review Risk Register status, verify treatment progress, reassess accepted risks	Security Director
Significant Change	Reassess affected risks upon new client engagement, platform migration, personnel change, or architectural decision	Security Director
Post-Incident	Assess whether incident reveals new or changed risks; update Risk Register accordingly	Security Director

11. Document Control

Version	Date	Author	Changes
0.1.0	2026-02-25	Lucas Shin	Initial release — established risk assessment methodology aligned with ISO 27001:2022 Clause 6.1.2/6.1.3 and Information Security Policy §6

Review Schedule

Annually: Full methodology review aligned with ISMS management review
Ad-hoc: Upon significant changes to risk landscape, organisational context, or regulatory requirements

[End of Document]