Skip to main content

Application Requirements Catalogue

The security requirements catalogue is one of the pillars of the SbD-ToE model. It works as a structured reference that ensures every application, project or system adopts controls suited to its risk level, type and operational context. The SbD-ToE catalogue provides the canonical reference identifiers (AUT-001, LOG-003, etc.) - stable, project-independent and aligned with external frameworks. Each organisation must build its own catalogue from this base, and each project instantiates the applicable requirements as traceable operational tags (SEC-L2-AUT-MFA). The distinction between the two systems and the instantiation model are described in Taxonomy and Traceability.

A formal catalogue makes it possible to:

  • Guarantee proportionality of the demands (L1, L2, L3), avoiding both overload and gaps;
  • Ensure traceability between risk, requirement, control and evidence;
  • Integrate security requirements into the development, audit and maintenance processes;
  • Serve as a common base for curation, evolution and organisational adaptation.

This chapter includes a catalogue consolidated from multiple recognised sources (ASVS, MSTG, NIST SSDF, IEC 62443, among others). It is meant to be adapted and curated by each organisation or project, so as to stay aligned with the context and the state of the art. It is not immutable: it is a living document and must be maintained regularly and kept up to date.

📌 How to apply this catalogue in SbD-ToE​

  1. Proportional selection:
    Each requirement indicates the risk level(s) at which it is mandatory or recommended (L1, L2, L3).

  2. Continuous curation:
    Periodic review and adaptation of these requirements is recommended, adding or adjusting according to the type of application, emerging threats and business context.

  3. Operational integration:
    The catalogue must be incorporated into the backlog processes, the definition of acceptance criteria, testing and validation, as well as into technical documentation and audits.

  4. Evolution and coverage:
    New requirements can (and must) be added on the basis of lessons learned, incidents, new standards or changes of context.

📚 Quick reference to the base requirements​

The proportional application of requirements by technical domain can be consulted in the
Base Requirements Catalogue (annex to this chapter):

For a quick reference to the proportional application of requirements by risk level, see the annex “Base Requirements Catalogue” at the end of this chapter.

📌 Closing Note​

The catalogue must be understood as a living, adaptable reference - the starting point for defining the concrete requirements of each organisation or project, and for the effective integration of security across the entire software lifecycle.

For validation, acceptance criteria and evidence, see the requirements validation section.