ISMS/00-governance/risk-assessment-and-treatment-methodology.md

Title: Risk Assessment and Treatment Methodology Document ID: [GOV-RISK-METH-001] Version: 0.1 Draft Status: Draft Owner: CISO (Paul Jenkins) Approver: CEO (Paul Hague) Classification: Internal Effective date: [DD Month YYYY] Review date: [DD Month YYYY]

Risk Assessment and Treatment Methodology

Purpose

This document defines the method BlackDice should use to identify, assess, treat, accept, and review information security risks within the ISMS scope.

Scope

This methodology applies to information security risks affecting in-scope business processes, services, systems, suppliers, information assets, and supporting activities.

Method Overview

Risk assessment should be carried out using a repeatable process that records:

• the asset, service, process, or change under assessment
• the threat or source of harm
• the vulnerability or control weakness
• the potential business or security impact
• the likelihood of occurrence
• the resulting risk rating
• the proposed treatment decision and target state
• the assigned risk owner and review date

The method should be usable for strategic risks, operational risks, project risks, supplier risks, and control exceptions.

Risk Identification

Risk identification should consider, where relevant:

• confidentiality, integrity, and availability impacts
• service resilience and operational disruption
• customer, contractual, and regulatory obligations
• cloud platform and Kubernetes security risks
• CI/CD and software change risks
• data handling, information transfer, and supplier dependencies
• human error, misuse, insider threat, and process failure

Risk sources may be identified through workshops, project reviews, architecture changes, audit findings, incidents, supplier reviews, and periodic control assessments.

Risk Analysis

Likelihood and impact scales must be defined by BlackDice during tailoring. Until then, assessments should use a documented scale such as Low, Medium, and High, or a numeric scale agreed by [Role].

Impact analysis should consider:

• customer harm or service degradation
• compromise of sensitive or business-critical information
• legal or contractual consequences
• financial loss
• reputational damage
• recovery effort and operational disruption

Risk Evaluation

BlackDice must define risk acceptance criteria so assessors can determine whether a risk is:

• acceptable without further treatment
• acceptable subject to monitoring
• requiring treatment before acceptance
• requiring escalation to management

Where risk exceeds the approved tolerance threshold, treatment or formal acceptance by the appropriate authority is required.

Risk Treatment Options

Risk treatment decisions may include:

• mitigate through new or improved controls
• avoid by changing the activity or design
• transfer or share through contractual or insurance mechanisms
• accept based on informed approval

Treatment plans should identify the actions required, accountable owner, target date, and dependencies.

Residual Risk and Acceptance

Residual risk must be reassessed after planned treatment has been defined or implemented. Formal risk acceptance must be documented where residual risk remains above routine operating thresholds or where a control gap is knowingly retained.

Roles and Responsibilities

• The risk methodology owner must maintain this document.
• Risk owners must ensure risks are assessed and treated appropriately.
• Assessors must apply the approved method consistently and record sufficient evidence.
• Management must review significant risks and approve risk acceptance where required.

Records and Outputs

The primary records produced by this methodology are expected to include:

• risk assessment records
• risk treatment plans
• accepted risk decisions
• updates to the risk register
• links to related exceptions, incidents, audits, or change records

Monitoring and Review

Risk assessments should be reviewed at planned intervals and when material change occurs, including major system changes, new suppliers, security incidents, or significant business changes.

The methodology itself should be reviewed at least annually to ensure it remains suitable and proportionate.

Related Documents

• ISMS Scope Statement
• Information Security Policy
• Risk Register Template
• Risk Assessment Procedure
• Statement of Applicability Template

Version Control

Version	Date	Description of Change	Author
0.1 Draft	[DD Month YYYY]	Initial draft.	[Name or Role]