Risk management

Introduction

We work with a risk-based approach: risks are identified, analysed, assessed, addressed, and tracked. Risk assessment is based on a structured methodology combining probability and impact, supported by threat analysis and defined impact criteria. In addition, processes and procedures are in place for continuity (business continuity plan and business impact analysis), change management, and information classification, ensuring that information security and privacy risks are managed in a consistent and controlled manner.

Detailed explanation

Formal risk assessment method (probability × impact)

We use a structured methodology for risk identification, analysis, and prioritization. Risks are identified based on threats derived from the context and stakeholder analysis, combined with a standardized threat model for information security and privacy.

For each identified threat, probability is determined by assessing both the likelihood of occurrence and the likelihood that the threat results in an incident. Impact is determined using defined impact levels and includes factors such as financial loss, reputational damage, or loss of critical information.

Risk prioritization is based on the combination of probability and impact (Risk = Probability × Impact), after which appropriate risk treatment options are selected: accept, avoid, mitigate, or transfer.

Decisions, measures, and progress are recorded in a risk register and improvement plan in Jira, where implementation and effectiveness are periodically monitored and evaluated.

The methodology is embedded in three management cycles:

• continuous implementation of improvements and measures

• periodic (at least annual) risk assessment and evaluation during the management review

• annual internal audit assessing the state of the ISMS and identifying improvements

Business continuity plan (BCP) and Business impact analysis (BIA) register

The business continuity plan focuses on ensuring continuity of services in case of a disaster, acting as a safety net when preventive measures are insufficient. The focus is on recovery (“overcoming”) rather than prevention.

Key elements include:

• Cloud-first principle: critical data is not stored locally.

• BIA register (in Jira): applications and data are recorded, including CIA classification (confidentiality, integrity, availability), relevant legislation, and involved suppliers.

• Impact and criticality: based on CIA, an impact score is assigned. Applications with a score of 8 or higher are considered critical, and their suppliers are classified as critical suppliers.

• RTO/RPO: recovery objectives are defined per system-data combination, particularly for critical applications, and serve as input for continuity measures.

For critical applications, continuity relies on cloud providers and contractual arrangements (e.g. SLAs and terms and conditions). In addition, a fallback/disaster recovery environment is available via a hosting partner, including a manual failover procedure.

Different continuity scenarios have been defined (e.g. unavailability of applications, buildings, personnel, or suppliers). Testing is risk-based:

• the failover scenario for critical applications is tested periodically (twice a year)

• other scenarios are not tested periodically due to their low probability and/or limited impact

Change management

A change management procedure is in place for changes that may affect information security or privacy. The process includes the following phases: planning, assessment, review, approval, communication, implementation, documentation, and evaluation.

Changes can originate from various processes (e.g. incidents, audits, risk assessments, supplier changes) and are categorized into:

• changes to the ISMS

• changes to information processing facilities and internal systems (configuration changes)

• changes to products and services delivered to customers

For ISMS changes, actions are registered and tracked in the  Improvement List (Jira), including planning, responsibilities, and (if applicable) impact analysis. For system and configuration changes, impact analysis, approval, implementation, testing, and evaluation are performed. When ICT resources are introduced into production environments, the four-eyes principle applies.

Changes to products and services are managed through defined processes, with authorization and review steps depending on the type of change (e.g. support, bug fix, or feature development).

Emergency changes and changes that have caused issues are reviewed at least quarterly to support continuous improvement of the change management process.

Classification of information as part of risk management 

Information classification is an integral part of our risk management approach within the ISMS. As part of the BIA, information/data, systems and related suppliers are assessed based on availability, integrity, confidentiality, and privacy impact. This results in a structured classification and impact rating that supports the identification of critical information and systems.

Standardized classification categories and handling guidelines ensure that risks are appropriately managed and that information is processed in a consistent and controlled manner.

In section "Context and regulatory compliance" more