SAMMY works best on screens 1024px wide or larger.
SR: Are security requirements clearly defined, structured, and prioritized in your requirements artifacts?
  • Teams derive security requirements that address the outcomes applicable to the assessed product in accordance with Annex 1 Part 1 CRA (access control, encryption, data minimization, factory reset, etc.)
  • Requirements are specific, measurable, actionable, relevant and time-bound (SMART)
  • You have an agreed upon structured notation for security requirements
Description

The Cyber Resilience Act (Annex I, Part I) sets out essential cybersecurity requirements that every product with digital elements must satisfy. These have been further operationalized as security outcomes in the harmonised standards developed by CENELEC, covering areas such as access control, encryption and confidentiality of stored and processed data, integrity of stored, processed, and transmitted data, data minimization, attack surface reduction, secure provisioning, secure data deletion, and the ability to return the product to a secure state . Without clearly defined security requirements, organizations cannot systematically verify that these obligations are met, nor can they demonstrate traceability from regulatory intent through design to implementation.

Translate the outcomes of the product risk assessment and threat modeling activities into specific, testable security requirements at the component level. Requirements must address the essential cybersecurity requirements and security outcomes applicable to the assessed product, and must be formulated in a way that is specific, measurable, actionable, relevant, and time bound (SMART). This ensures that each requirement can be unambiguously verified during testing and review.

Capture security requirements using an agreed upon structured notation and maintain them within the project's requirements artifacts alongside functional and non functional requirements. Ensure requirements are prioritized based on risk and are traceable to the risk assessment and threat model that informed them, so that coverage gaps and rationale can be reviewed at any point during the product lifecycle.