2.2 Risk management activities

Risk management activities provide the foundation for implementing secure by design and default across the product life cycle. They ensure that security decisions are based on an informed and shared understanding of what needs to be protected, from whom and under what constraints.

In this report, ‘risk management’ concerns cybersecurity risks affecting the product and the users, operators, customers, data, services and systems that depend on it, taking into account the product’s intended purpose and reasonably foreseeable use. It does not refer to the manufacturer’s commercial or reputational risk.

These activities establish the context within which secure by design and default principles are applied. Their outputs directly informs:

• security requirements and architecture decisions;
• default configuration and ‘out of the box’ hardening;
• prioritisation of controls and assurance activities (e.g. testing depth, review gates);
• acceptable trade-offs inherent to the product’s intended use and deployment context;
• the ongoing operational security posture, including patching and end-of-life handling.

Risk management is typically initiated early, but it must be iterative: revisited at defined life-cycle gates (e.g. major release, supplier change, new deployment context) and triggered by significant events (e.g. newly disclosed vulnerabilities, threat shifts, incident learnings). Examples of risk management activities directly supporting secure by design and default decisions include:

• product context definition, including intended purpose, operating environment, users, data processed, and constraints
• establishing risk acceptance criteria, expressed as simple and practical guidelines to support consistent decision-making;
• high-level risk assessment focused on threat modelling, key assets, trust boundaries and risk treatment decisions.

Risk assessments should also be informed by evidence from deployed products, including customer and researcher reports, incident investigations, observed exploitation patterns and proportionate telemetry, where available and appropriate.

This report does not aim to define or replace a formal risk management framework. Rather, it aims to highlight common risk management activities and outputs that feed security decision-making.

To support SMEs, the following list is a sample set of activities that can drive secure by design and default decisions without creating heavy processes. The purpose of these activities is to translate product context and credible threats into testable security requirements, prioritise the relevant playbooks and determine the appropriate depth of controls and assurance activities, rather than applying every practice uniformly.

Table 2: Risk management activities for SMEs

dependencies (cloud, mobile app, third

parties).

Asset and adverse effect identification

modelling

conditions (e.g. misuse of software updates,

unauthorised administrative access and

exploitation of default credentials are not

acceptable) and establish criteria for

accepting residual risk. For example, the

accepted level of residual risk should not

undermine the essential cybersecurity

requirements, given the product’s intended

purpose and reasonably foreseeable use.

Security requirements baseline

include a formal pre-release gate to verify

compliance with the requirements defined

during the above activities. This review

should confirm checklist met, defaults

verified, known vulnerabilities triaged, high

risks treated / accepted with rationale;

decide go/no-go.

Change-triggered reassessment

Risk assessments can also support product-specific implementation of applicable cybersecurity requirements, assessment and treatment of identified vulnerabilities and evaluation of the security impact of significant changes to a product.

1. Prezentare generală

1.1 Referințe

1.2 Cerințe identificate

1.3 Reglementări asociate

2. Cerințe identificate

3. Reglementări asociate

• ENISA -