Cybersecurity Risk Management Procedure

Methodology for identifying, analysing, assessing and treating risk

Document Number: DOC-002
Version: ▸ 1.0
Status: DRAFT
Issue Date: ▸ DD/MM/YYYY
Next Review: ▸ DD/MM/YYYY
Owner: ▸ CISO / Person responsible for cybersecurity
Approved by: ▸ Board / CEO
Legal Basis: Art. 21(2)(a) NIS2; ISO/IEC 27005:2022
Parent Document: DOC-001

1. Purpose and Scope

This procedure describes the cybersecurity risk management methodology applied by the organisation. It provides a systematic approach to identifying, analysing, assessing and treating risks that could affect the confidentiality, integrity or availability of information and services.

The procedure applies to:

All information systems supporting key/important services,
The organisation's IT/OT infrastructure,
Processes and services delivered by suppliers (supply chain).

ℹ️

Risk assessment results are recorded in DOC-003 Risk Register. The procedure is applied at least once a year and after significant changes to the IT environment.

2. Risk Assessment Methodology

2.1 Choice of methodology

▸ Organisation completes – choice of methodology

The organisation applies the following risk assessment methodology:

▸ [Select one or describe your own]: OCTAVE Allegro / FAIR / ISO 27005 / NIST SP 800-30 / own methodology based on likelihood × impact matrix

2.2 Rating scale

The organisation uses a ▸ [3/4/5]-level scale min. 3-level for likelihood and impact ratings:

Table 1 – Likelihood scale

Value	Level	Description	Indicative frequency
1	Very low	Event highly unlikely	▸ [e.g. once in 10 years]
2	Low	Event unlikely	▸ [e.g. once in 3–5 years]
3	Medium	Event possible	▸ [e.g. once in 1–3 years]
4	High	Event probable	▸ [e.g. once a year]
5	Very high	Event very probable or recurring	▸ [e.g. several times a year]

Table 2 – Impact scale

Value	Level	Financial impact (indicative)	Operational impact	Reputational impact
1	Minimal	▸ below [X currency]	No or minimal disruption	No noticeable effect
2	Minor	▸ [X] – [Y currency]	Short-term internal disruption	Local / internal
3	Moderate	▸ [Y] – [Z currency]	Disruption visible to customers	Local media attention
4	Serious	▸ [Z] – [W currency]	Significant disruption to key services	National media attention
5	Critical	▸ above [W currency]	Loss of ability to operate	International media attention, NIS2 fine

2.3 Risk level calculation

Risk (R) = Likelihood (L) × Impact (I)

Score: 1–25 (5-level scale) or 1–9 (3-level scale)

Table 3 – Risk matrix (example 5×5)

L \ I	1 Minimal	2 Minor	3 Moderate	4 Serious	5 Critical
5 – V. High	5	10	15	20	25
4 – High	4	8	12	16	20
3 – Med.	3	6	9	12	15
2 – Low	2	4	6	8	10
1 – V. Low	1	2	3	4	5

Green 1–6: Acceptable Yellow 7–12: Monitor Orange 13–16: Treatment required Red 17–25: Urgent action

3. Risk Management Process – Steps

Step 1: Context establishment

Before beginning the risk assessment, define:

Scope of assessment (system, process, service, whole organisation),
Business objectives and regulatory requirements,
Risk acceptance criteria (see section 4),
Resources engaged in the assessment.

▸ Organisation completes – external context

External context: ▸ [description of the organisation's regulatory, industry and geographic environment]

Internal context: ▸ [description of the organisation's structure, processes and IT/OT systems]

Step 2: Asset identification

Information asset inventory is conducted in accordance with DOC-020 Asset Register. Asset categories:

Category	Examples
Data	Customer data, operational data, personal data, financial data, technical documentation
Software	Operating systems, business applications, SCADA/ICS software, custom software
Hardware	Servers, network devices, workstations, OT/IoT devices
Services	Cloud services, network connections, third-party supplier services
Personnel	Employees with administrative privileges, key personnel
Locations	Server rooms, offices, industrial premises

Step 3: Threat and vulnerability identification

For each asset, threats and associated vulnerabilities are identified:

Threat category	Example threats
Malicious software	Ransomware, viruses, trojans, spyware, rootkits
Network attacks	DDoS, man-in-the-middle, SQL injection, XSS
Human error	Accidental data deletion, misconfiguration, phishing
Insider threats	Data theft by employee, sabotage, unauthorised access
Technical failures	Hardware failure, software bugs, power loss
APT attacks	Advanced targeted attacks, espionage campaigns
Physical threats	Equipment theft, fire, flood, physical sabotage
Supply chain	Supplier software compromise, hardware backdoor

Step 4: Analysis and risk assessment

For each identified threat:

Estimate likelihood (L) of occurrence per Table 1,
Estimate impact (I) on CIA (confidentiality, integrity, availability) per Table 2,
Calculate risk level R = L × I,
Factor in existing controls (residual risk),
Compare residual risk against acceptance criteria from section 4.

Step 5: Risk treatment

Based on the assessment, select one of the following treatment strategies:

Strategy	Description	When to use
Modification (treatment)	Implement additional controls to reduce risk	Risk > acceptance threshold; action is cost-effective
Acceptance	Conscious acceptance of risk without further action	Risk ≤ acceptance threshold or treatment cost disproportionately high
Avoidance	Cease the activity or eliminate the cause of risk	Critical risk; no cost-effective countermeasures available
Transfer	Cyber insurance, SLA agreements with suppliers	Financial risk that can be transferred

▸ Organisation completes – risk treatment plans

For each risk above the acceptance threshold, a Risk Treatment Plan (RTP) is created containing: countermeasure, responsible person, implementation deadline and effectiveness metric. RTPs are documented in DOC-003.

Step 6: Risk communication

Risk assessment results are:

Reported to the Board at least every ▸ [6 months]max. 12 months,
Considered when making investment decisions,
Communicated to system owners and the CISO.

Step 7: Monitoring and review

The risk register (DOC-003) is updated:

Regularly every ▸ [12 months]max. 12 months – NIS2,
After every significant incident,
After deployment of new systems or infrastructure changes,
After changes in legislation.

4. Risk Acceptance Criteria

⚠ Critical – Board must approve acceptance criteria

The organisation's Board approves the following risk acceptance thresholds:

Risk level (R)	Classification	Required action	Approved by
1–6	Low (Acceptable)	Monitoring, no mandatory action	▸ CISO
7–12	Medium (Monitor)	RTP within ▸ [90 days], quarterly review	▸ CISO + system owner
13–16	High (Treatment required)	RTP within ▸ [30 days], Board report	▸ Board
17–25	Critical (Urgent)	Immediate action, report within ▸ [72h]	▸ Board (urgent)

Approval dates and signatures of the relevant decision-makers are maintained in the DOC-003 register.

5. Documentation and Records

Document/Record	Form	Storage	Retention
Risk Register	DOC-003 (HTML + export)	▸ [location – document system / sharepoint / file]	▸ min. 5 yearsmin. 5 years – NIS2
Risk Treatment Plans	Annex to DOC-003	▸	▸ min. 5 years
Risk assessment reports	PDF/Word document	▸	▸ min. 5 years

6. Change History

Version	Date	Author	Description	Approved by
▸ 1.0	▸ DD/MM/YYYY	▸ First Last Name	▸ Initial release	▸ Board

DOC-002 Risk Management Procedure | v1.0 | NIS2/ISMS