3.1.2 Operational integrity

Operational integrity addresses the human and procedural practices that maintain product security throughout development, deployment, operation and retirement. It ensures that security is treated as a continuous, lived experience, for developers and users alike, rather than a one-time checklist completed during the design phase.

This category includes the following principles.

• Life-cycle management. Security responsibilities extend beyond initial development. Components must be maintained, updated and eventually retired in a controlled manner, taking the expected duration of use into account. The practical application of life-cycle management, including how secure by design and secure by default principles are applied from design and development through to decommissioning, is explored in Section 2.
• User-centric design. Security mechanisms must be usable and understandable even for everyday users. Poor usability often leads to insecure workarounds or misconfigurations. For example, if a system requires the user to perform complex manual configuration to enable encryption, they may skip the step or apply it incorrectly. On the other hand, providing a simple, guided set-up that enables encryption automatically reduces the chance of misconfiguration and encourages the use of the security feature.
• Secure coding and verification practices. Developers should follow established secure coding standards to prevent common vulnerabilities. Early identification and mitigation of insecure code ensure that weaknesses are not built into the system. For example, developers can use SAST tools (18) while coding to identify vulnerabilities and software composition analysis to detect vulnerable third-party libraries. They can then apply dynamic testing tools (19) (DAST) before deployment to uncover runtime issues. These practices ensure that code-related vulnerabilities are identified early and not after the product is released.
• Logging, monitoring and alerting. Security depends on visibility. Systems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs. Rather than simply collecting data, monitoring should be designed to detect suspicious behaviours such as repeated failed authentication attempts, privilege escalation, unexpected configuration changes and unusual outbound connections.
• Configuration and change management. Secure operation requires configurations to be controlled, consistent and auditable. Baseline hardening standards should be defined (e.g. secure defaults, disabled unused services and enforced encryption settings) and applied through repeatable mechanisms such as templates and infrastructure as code to reduce drift. Changes to systems should follow a governed process that includes review, testing, approval and rollback plans, particularly for security-sensitive components.
• Incident response and recovery. Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality. This requires defined internal roles, escalation paths and decision-making authority for security events, as well as documented playbooks for containment and customer communication.
• Vulnerability and patch management. Vulnerability and patch management should be practical, repeatable and prioritised by risk. Manufacturers need a simple way for customers and researchers to report issues (e.g. a dedicated security email address and a basic disclosure process) and an internal process to triage findings quickly and decide what needs urgent action.
• Supply-chain controls. Developers and manufacturers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys and the channels used to distribute updates. At a minimum, source code and CI/CD modification rights should be limited to named individuals, protected with MFA and reviewed through lightweight peer approval for changes to security-critical areas. Software bills of materials (SBOMs) should be generated and maintained to support dependency transparency, vulnerability management and product life-cycle security.

1. Przegląd

1.1 Odwołania

1.2 Zidentyfikowane wymagania

1.3 Powiązane regulacje

2. Zidentyfikowane wymagania

3. Powiązane regulacje

• ENISA -