26 docs tagged with "risco"

This annex presents non-mandatory but highly recommended practices for organisations that wish to reach higher levels of maturity and auditability in risk management applied to the software lifecycle.

🎯 Objective

Determining the criticality of applications in order to apply proportionality in security controls

Minimum mandatory requirements by application criticality classification

Organisational policy that defines the mandatory axis-based risk classification model (Exposure, Data, Impact), the moments of application, the review criteria and the formal recording requirements for all applications developed or operated by the organisation.

Formal, cross-cutting and authoritative process for the management of exceptions to security requirements and controls in SbD-ToE

Structured identification, analysis and mitigation of threats during the development lifecycle

🎯 Objective

Proportional application of the monitoring and response controls according to the application's risk classification.

The following examples illustrate different legitimate ways of classifying applications in SbD-ToE, demonstrating:

Specifics of exception management in the context of the application requirements of Ch. 02

Specifics of exception management in the context of the secure architecture requirements (ARC-001..013)

Applying criticality classification throughout the development lifecycle

Why — determining the criticality of applications in order to apply proportionality in security controls

Technical and process indicators for assessing the quality, coverage and currency of application risk classification, with thresholds per risk level and mapping to SbD-ToE cross-cutting governance dimensions.

This matrix defines the minimum floor of security controls expected, by technical domain, according to the application's risk level (L1–L3), as determined in Chapter 01.

Organisational policy that defines the mandatory cadence and the review triggers for the application risk classification, ensuring that the criticality level and the associated controls remain appropriate to the technical and business context throughout the entire lifecycle of the application.

Definition of automated policies in the pipeline with security gates that vary according to the risk level of the application.

Risks introduced by pervasive automation in the CI/CD pipeline and the corresponding control, validation and evidence measures

Practices such as canary releases, blue/green and staged rollout to mitigate risk in critical deployments.

The effective adoption of Chapter 01 - Risk Management - requires the existence of formal organisational policies that frame, legitimise and sustain the application of the practices described in this chapter.

Eight key risk indicators for reporting to the CISO, senior management and the board. Focus on risk exposure and response capability, aggregating the technical indicators of the SbD-ToE domains into an actionable executive reading.

Security practices for continuous integration and delivery pipelines, with a focus on automation, traceability and control proportional to risk

Strategies for prioritising tests based on risk and ensuring effective coverage of the requirements.

Mapping known threats is an essential mechanism for validating the risk analysis, ensuring that the identified risks reflect real, plausible and documented attack vectors.

Training path adapted to the risk level (L1–L3) and to the technical profile of each member of staff.