Acquisition lifecycle

For critical components, entities shall set and implement processes to manage acquisition risks from suppliers or service providers throughout the ICT service or product life cycle, based on point 2.1 risk assessment.

Systems shall be segmented into networks or zones according to the point 2.1 risk assessment, and the entity's systems and networks shall be segmented from third parties' systems and networks.

Employees, including management bodies, and direct suppliers and service providers must be aware of risks, informed of cybersecurity importance and apply cyber-hygiene practices.

What is Cyber hygiene?

User security practices supported by awareness raising under point 8.1.

What is Residual risk?

Risk remaining after controls or additional measures are applied; point 6.6 addresses its acceptance where a patch is unavailable or not applied.

What is Key management?

The governance of cryptographic keys across generation, distribution, storage, change, recovery, revocation, backup, destruction, auditing and controlled periods of use.

Securing the ICT Lifecycle, Networks and Workforce — Commission Implementing Regulation (EU) 2024/2690: Cybersecurity Measures and Significant-Incident Thresholds

The Lifecycle Security Baseline: Acquisition Through Change

Lifecycle security is continuous

Points 6 to 10 of the Regulation treat security as a lifecycle activity: acquire, develop, configure, change, test, patch and handle vulnerabilities. The measures are linked repeatedly to the point 2.1 risk assessment.

Point 6.1.1: Critical acquisitions

For components critical to network and information-system security, entities shall set and implement acquisition-risk processes based on point 2.1 risk assessment, covering suppliers and service providers throughout the lifecycle.

Point 6.1.2: What procurement processes include

The processes shall include security requirements, component information, secure-configuration information, compliance assurance, validation methods and records of validation results.

Support must be planned

The acquisition process shall address security updates for the entire lifetime of the ICT service or product, or replacement after its support period ends. This prevents unsupported critical technology becoming an unmanaged risk.

Secure Development, Configuration and Controlled Change

Point 6.2 covers the whole build process

Secure-development rules apply before development begins, whether work is in-house or outsourced. They shall cover specification, design, development, implementation and testing rather than only final security testing.

Security starts at specification and design

Every development or acquisition project undertaken by or for the entity requires security-requirements analysis during specification and design. The Regulation gives cybersecurity-by-design and zero-trust architectures as examples.

Secure configurations persist

Point 6.3 requires secure configurations to be established, documented, implemented and monitored. Processes and tools shall enforce them for new systems and systems already in operation throughout their lifetime.

Emergency does not erase accountability

Changes normally require documentation, risk-based testing and impact assessment before implementation. If emergency conditions prevent the regular procedure, the entity shall document the result and explain why it departed from the procedure.

Testing, Patching and Vulnerability Handling

Testing must be risk-based and evidenced

Point 6.5 requires a testing policy and procedures. The point 2.1 risk assessment determines the need, scope, frequency and type of tests; a documented methodology must cover components relevant to secure operation.

Critical test findings require action

For each test, entities shall document type, scope, time, results, criticality and mitigating actions. They shall apply mitigating actions when a finding is critical.

Patch exception is not a blanket waiver

Patches shall be timely, tested before production, sourced from trusted providers and integrity-checked. A patch may be withheld only where its disadvantages outweigh cybersecurity benefits, with documented and substantiated reasons.

Vulnerabilities connect multiple processes

Critical operational vulnerabilities must be addressed without undue delay. Handling must be compatible with change, patch, risk and incident-management procedures, and disclosure follows the applicable national coordinated policy.

Quiz: The Patch Decision

Check your understanding

A vendor releases a security patch. Installing it would stop a safety-critical operational system for several days, while compensating controls can substantially reduce exposure during that period. Which response best reflects point 6.6?

What does point 6.6 require in this scenario?

The entity may decide not to apply the patch if its disadvantages outweigh its cybersecurity benefits, but it shall duly document and substantiate the decision and implement additional measures with residual-risk acceptance.
The entity must always apply every patch immediately, regardless of operational or safety consequences.
The entity may ignore the patch permanently if it has a supplier support contract.
The entity may defer the patch without any record because compensating controls are available.

Show Answer

Answer: A) The entity may decide not to apply the patch if its disadvantages outweigh its cybersecurity benefits, but it shall duly document and substantiate the decision and implement additional measures with residual-risk acceptance.

Point 6.6.2 is a derogation from timely patching, not an automatic exemption. The disadvantages must outweigh the cybersecurity benefits, the decision must be duly documented and substantiated, and point 6.6.1(d) requires additional measures and residual-risk acceptance where a patch is unavailable or not applied.

Network Security: Architecture, Access and Modern Protocols

Architecture must be understandable and current

Point 6.7.2(a) requires entities to document network architecture in a comprehensible and up to date manner. Documentation supports security decisions, troubleshooting, review and evidence of control over the environment.

Allow only what operations need

Controls shall protect internal domains from unauthorised access and prevent unneeded access or communications. Unneeded connections and services shall be explicitly forbidden or deactivated.

Supplier access is authorised and time-limited

Service-provider connections are allowed only after an authorisation request and for a set period, such as a maintenance operation. This wording addresses both approval before access and a defined endpoint for that access.

Trusted channels between systems

Communication between distinct systems must use trusted, isolated channels with assured endpoint identification and protection against channel-data modification or disclosure. Isolation may be logical, cryptographic or physical.

Transition plans are required

Entities shall plan a secure, appropriate and gradual full transition to latest-generation network-layer protocols, and modern interoperable e-mail standards. They shall also establish measures to accelerate both transitions.

Segmentation and Malware Defense in a Real Environment

Segmentation follows risk assessment

Systems shall be divided into networks or zones in line with point 2.1 risk-assessment results, and the entity's systems and networks shall be segmented from third parties' systems and networks.

Keep critical systems in secured zones

Access is based on assessed security requirements. Systems critical to operations or safety shall remain in secured zones, while communications within and between zones are restricted to operational or safety needs.

Separate high-risk functions

The Regulation requires a DMZ, separation of administration from operational networks, segregation of administration channels, and separation of production from development and testing systems, including backups.

Malware defense is detection or prevention

Entities shall protect systems from malicious and unauthorised software and in particular implement measures that detect or prevent its use. Detection-and-response software is required where appropriate, with risk-based regular updates.

Measuring Controls and Building Cyber Hygiene

Point 7 asks: are measures effective?

Entities shall establish, implement and apply a policy and procedures assessing whether cybersecurity risk-management measures are effectively implemented and maintained, not merely written down or purchased.

Define the measurement system

The policy shall identify what is measured, valid methods, timing, the responsible monitor, the timing of analysis and evaluation, and the person responsible for analysing and evaluating results.

Cyber hygiene reaches beyond employees

Awareness obligations cover employees, management bodies, and direct suppliers and service providers. The aim is awareness of risks, understanding cybersecurity importance and application of cyber-hygiene practices.

Awareness must repeat and evolve

The programme shall recur over time, include new employees, align with security policies, cover threats and contacts, and be updated at planned intervals for changing hygiene practices, threats and organisational risks.

Role-Specific Training and Cryptography

Training is based on the role

Entities shall identify employees whose roles need security-relevant skills and expertise, and ensure regular network and information-system security training. Training needs for roles and positions must be set using criteria.

Training content has three stated areas

Training must be relevant to job function, assessed for effectiveness, and cover secure configuration and operation, known cyber threats, and behaviour when security-relevant events occur. Transfers into relevant roles also trigger training.

Cryptography protects three properties

Cryptography policy and procedures shall support adequate and effective protection of data confidentiality, authenticity and integrity, aligned with asset classification and the point 2.1 risk assessment.

Agility is conditional

Approved protocols, algorithms, cipher strength, solutions and usage practices shall be specified, following a cryptographic agility approach where appropriate. The Regulation does not make agility unconditional in this clause.

Key management is a complete lifecycle

Where appropriate, key management covers creating, issuing, distributing, storing, changing, recovering, revoking, backing up, destroying, auditing and time-limiting keys, rather than treating encryption as a one-time configuration.

Flashcards: Exact Obligations to Recall

Flip each card

Use these cards to practise the Regulation's precise triggers and requirements.

Acquisition lifecycle: For critical components, entities shall set and implement processes to manage acquisition risks from suppliers or service providers throughout the ICT service or product life cycle, based on point 2.1 risk assessment.
Patch exception: An entity may choose not to apply a patch only when its disadvantages outweigh cybersecurity benefits. It shall duly document and substantiate the reasons.
Segmentation rule: Systems shall be segmented into networks or zones according to the point 2.1 risk assessment, and the entity's systems and networks shall be segmented from third parties' systems and networks.
Awareness audience: Employees, including management bodies, and direct suppliers and service providers must be aware of risks, informed of cybersecurity importance and apply cyber-hygiene practices.
Cryptographic agility: Protocols, algorithms, cipher strength, solutions and usage practices are approved and required following, where appropriate, a cryptographic agility approach.
Annual personnel review: Assignments of personnel to the roles in point 1.2, and their human-resource commitment, shall be reviewed at planned intervals and at least annually, then updated where necessary.

Human Resources Security: Responsibilities, Checks and Consequences

Responsibilities depend on role and applicability

Employees and direct suppliers or service providers shall understand and commit to security responsibilities wherever applicable, appropriate to the service and job, and in line with the entity's network and information-system security policy.

Hiring and annual role review

Qualified-hiring mechanisms may include checks, vetting, certification validation or written tests. Personnel role assignments and committed human resources shall be reviewed at planned intervals and at least annually.

Background checks are proportionate

Background verification is required to the extent feasible and where necessary. Criteria identify sensitive roles, and checks occur before duties begin while considering law, ethics, business needs, assets, accessed systems and risk.

Security duties can outlive employment

Continuing security responsibilities after termination or role change shall be contractually defined and enforced. A disciplinary process for security-policy violations shall be established, communicated and maintained.

Final Quiz: Identify the Accurate Statement

Apply the wording carefully

Choose the statement that accurately reflects points 7 to 10 of Commission Implementing Regulation (EU) 2024/2690.

Which statement is correct?

Background verification is required for every person in every circumstance, without considering feasibility, role or applicable laws.
Cybersecurity awareness is only required for technical employees because management bodies are addressed solely by training rules.
The effectiveness-assessment policy shall determine what is monitored and measured, methods for valid results, timing and responsible persons for monitoring, analysis and evaluation.
Cryptographic agility is mandatory for all entities in all circumstances, regardless of the wording of point 9.2(b).