Skip to main content

Advanced Recommendations - Risk Management

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.

These recommendations complement the mandatory practices of Chapter 01 and may be adopted progressively according to:

  • The applicable regulatory context;
  • The organisation's risk appetite and tolerance;
  • The intended maturity level (e.g. ISO 27001, SOC 2, PCI-DSS);
  • The strategic objectives for visibility and governance.

1. Integration with GRC Tools​

  • Integrate the risk classification and acceptance model with corporate GRC (Governance, Risk & Compliance) tools, such as:
    • ServiceNow Risk
    • Archer GRC
    • Riskonnect, among others.
  • This integration makes it possible to:
    • Align technical decisions with organisational risks;
    • Support internal and external audit processes;
    • Guarantee centralised traceability of decisions.

2. Structured Justifications for Risk Acceptance​

  • Adopt a formal model of informed risk acceptance, with the following minimum fields:
    • Description and impact of the risk;
    • Reason for acceptance;
    • Alternatives considered;
    • Compensations applied (if any);
    • Person responsible for the decision and temporal validity;
  • It must be versioned, traceable and auditable.

3. SLA for Risk Classification Review​

  • Establish maximum deadlines for the formal review of the classification, such as:
    • L3: reassessment every 90 days;
    • L2: every 180 days;
    • L1: up to 365 days.
  • Automate alerts and tasks in the security backlog.

4. Decision Support with Risk Visualisation​

  • Use visualisation tools for:
    • Heat matrices (heatmaps) per application or team;
    • Dashboards cross-referencing risk vs control applied;
    • Visual alerts for expired classifications.
  • This facilitates communication with management, audit and non-technical stakeholders.

5. Versioning and Auditing of Classifications​

  • Keep a historical record of all classifications with:
    • Timestamp and author;
    • Reason for the change;
    • Cross-reference to the release or technical change;
    • (Optional) Digital hash for integrity verification.
  • Essential for compliance with ISO 27001, SOC 2, NIS2 and similar.

6. Alignment with the Organisation's Risk Appetite​

  • Define risk levels (L1/L2/L3) aligned with the organisation's formal appetite.
  • This allows:
    • Customisation by application type (e.g. SaaS, internal, regulated);
    • Support for the budgetary prioritisation of controls;
    • Coherence between accepted risk and security investment.

7. Cross-Review between Teams (Peer Review)​

  • Establish a process of cross-validation of classifications by other teams (e.g. between products, AppSec, architecture).
  • Benefits:
    • Reduced individual bias;
    • Increased collective maturity;
    • Promotion of consistency and good practice.

8. Specialised Technical Training​

  • Include in training plans:
    • Technical risk assessment applied to the SDLC;
    • Reading and interpreting the classification axes;
    • Documentation and traceability for audits.
  • Preferably linked to the training tracks by profile defined in Ch. 13.

📌 Final Note​

These practices are not mandatory for minimum compliance with the SbD-ToE model, but they are highly recommended for organisations that wish to:

  • Increase the efficiency and visibility of risk management;
  • Obtain gains in maturity, traceability and auditability;
  • Reduce dependence on informal processes in critical security decisions.

✅ Their adoption may be gradual, aligned with the organisation's capacity and with the applicable regulatory requirements.