Method for deriving abuse and misuse cases — cross-functional workshop, adversarial user stories and integration into the requirements backlog. Adversarial elicitation technique that feeds the threat model and the security requirements; it complements structured threat modelling, it does not replace it.
Reinforced recommendations for environments with greater regulatory demands or maturity
The Manual's requirements that apply under context CTX-NIS2, by level and grade, with each floor that the regime elevates and its legal basis.
The Manual's requirements that apply under context CTX-DORA, by level and grade, with each floor that the regime elevates and its legal basis.
The Manual's requirements that apply under context CTX-AIA-RE, by level and grade, with each floor that the regime elevates and its legal basis.
The Manual's requirements that apply under context CTX-RGPD, by level and grade, with each floor that the regime elevates and its legal basis.
The Manual's requirements that apply under context CTX-CRA, by level and grade, with each floor that the regime elevates and its legal basis.
Minimum mandatory requirements by application criticality classification
Canonical catalogue of SbD-ToE application security requirements, organised by technical domain, with applicability by risk level (L1–L3) and minimum acceptance criteria for validation, audit and integration into backlogs.
Structured identification, analysis and mitigation of threats during the development lifecycle
Foundations, objectives and framing of the chapter dedicated to secure architecture in the software lifecycle
Specifics of exception management in the context of the application requirements of Ch. 02
Recommendations for writing secure code by language and stack, including prohibited patterns and validated good practices
Prescription for the controlled use of automated generation tools (including AI) in development, without changing the application requirements
Integration of Secure Architecture practices throughout the development cycle
Integration of requirements practices throughout the phases of the development lifecycle
Integration of threat modelling throughout the development cycle
Rationale and logical structure of the requirements themes used in the catalogue
How to replace the manual threat → requirement mapping using platforms such as IriusRisk, while maintaining traceability with Chapter 2
Technical and process indicators for assessing the coverage, traceability and effective validation of the security requirements applied by risk level, with mapping to the cross-cutting SbD-ToE governance dimensions.
How to link identified threats to the formal requirements defined in Chapter 2
Case study illustrating the application of requirements throughout the lifecycle
Why this chapter is exceptional, which sources support the IaC requirements catalogue and how to create/adapt the organisational catalogue
Policies that underpin the definition, exception and validation of requirements
Two complementary identification systems - the canonical SbD-ToE catalogue and the project's operational tags - and how to articulate them across the lifecycle.
This document has been integrated into addon 07 - Requirements Validation. See validacao-requisitos.
This document has been integrated and expanded in addon 07 - Requirements Validation. See validacao-requisitos.
Binary, auditable checklist for controlling the application of the secure architecture requirements
Mandatory per-project verifications to guarantee the application of the defined requirements
Organisational policy that defines how security requirements must be selected, documented, traced, validated and maintained throughout the lifecycle of each application, proportionally to its classified risk level.
Complete model for validating the requirements of the SbD-ToE catalogue - principles, methods by requirement type, lifecycle moments and a detailed plan by domain with operational tag, recommended method and expected evidence.
Canonical catalogue of threat modelling requirements (THR-001 to THR-007), with applicability by risk level and acceptance criteria for threat identification, formal disposition, requirement derivation and methodological traceability.
How to build and maintain a traceability matrix that links identified risks, canonical requirements, project operational tags, technical controls and auditable evidence.
Practical upskilling for technical teams that develop, review or operate IaC projects securely