🧱Capítulo Basilar

This chapter is considered foundational in the Security by Design – Theory of Everything (SbD-ToE) model. Its application is mandatory to guarantee the coherence, traceability and effectiveness of the remaining security practices.

The foundational chapters constitute the technical and methodological foundation of the model. The absence or partial application of any one of them compromises the overall integrity of SbD-ToE, making the coherent adoption of the operational and governance practices unfeasible.

Application Criticality Classification

This chapter defines and prescribes how to classify applications according to their criticality, so as to allow the proportional application of requirements, controls, validations and security evidence throughout the entire lifecycle.

In SbD-ToE, classification does not aim to label technologies or tools, but rather to characterise application risk sufficiently to support consistent technical and organisational decisions.

Automation and decision-support tools (including AI) are treated as a normal part of the modern SDLC and must be considered in the classification whenever they alter exposure, data, impact or the way decisions and validations are carried out.
Their presence does not create new risk categories, but it influences the internal attributes of the risk and, consequently, the controls required.

This chapter suggests a simple, direct and economically viable classification model, suited to most application contexts.
The organisation may, however, opt for an existing alternative model (for example DRP/BIA or another formal risk analysis method), provided that its results can be mapped to the context of application development.

The central objective of the manual is to:

1. Classify applications consistently, to ensure adequate proportionality;
2. Provide clear, fast and traceable mechanisms for doing so, without excessive dependence on heavy processes or specific tools.

📌 Criticality classification is the entry point for the chapters:
Chapter 02 – Requirements,
Chapter 04 – Architecture,
Chapter 07 – CI/CD and
Chapter 10 – Testing.

---

🧠 Conceptual note: risk and attributes

SbD-ToE treats risk as a single concept, regardless of its technical or procedural origin.
What varies are the attributes of the risk - such as origin, mechanism, detectability, reproducibility and evidentiability - which directly influence the applicable requirements and controls.

📌 See: Risk Attributes

---

🧭 Note: regulatory context

Risk level L1–L3 measures the application's own risk. Independently of it, the application may be under a regime that makes some requirements mandatory at any level: a financial entity under DORA, a product with digital elements under the CRA or a high-risk AI system under the AI Act, for example. For this reason, the classification record also declares the applicable regulatory contexts, with the evidence that grounds them, and reviews them at the same points at which it reviews the classification.

The requirement catalogues do not change with the regime. What each context requires above the level (each floor, with the Article that grounds it) is in the normative cross-check, on each regulation's “Applicable requirements” page.

📌 See: Normative cross-check

---

🧪 Practical prescription: what, who, how, when, why and to what end

📌 What must be done

1. Classify the application according to exposure, sensitive data and impact, as proposed in the manual, or adopt another equivalent model;
2. Explicitly consider how automation and decision support (incl. AI) influence the relevant risk attributes;
3. Document the classification, the assumptions and the evidence used;
4. Apply minimum controls based on the level assigned;
5. Review the classification at key points of the lifecycle;
6. Apply formal criteria for risk acceptance, where necessary.

---

⚙️ How it must be done

• Use the Classification Model;
• Or an alternative model adopted by the organisation (e.g. Adoption of DRP/BIA);
• Where automated/assistive tooling exists (incl. AI), assess its impact on the risk attributes and calibrate E/D/I accordingly;
• Incorporate the Risk Classification Lifecycle;
• Apply the Risk Acceptance Criteria;
• Consider real threats through the Threat Mapping by Risk Level;
• Record decisions in a versioned repository, a risk tool or traceable documentation.

---

📆 When to apply

• During the initial phase of the project or the definition of the architecture;
• Whenever there are relevant changes: new functionality, data, exposure or integrations;
• When automation/assistance mechanisms (incl. AI) with an impact on the risk attributes are introduced or changed;
• At major releases or critical milestones (e.g. production);
• After relevant security incidents;
• Periodically, in line with Policy 04 (annual at L1, half-yearly at L2, quarterly at L3), and at each architecture or security roadmap review.

Periodic review of the risk classification directly supports intermediate maturity practices in SAMM, DSOMM and SSDF.

---

👥 Who is involved and how

Role	Contribution
Developer / Tech Lead	Propose the classification, identify relevant changes
AppSec Engineer	Validate the model applied, adjust the risk level, apply the matrix
Software Architects	Review technical implications, flows and exposure
Product Owner / Executive Management	Approve risk acceptance, assess the impact of exceptions
GRC / Compliance	Ensure traceability and normative alignment
QA	Validate compliance with the requirements per risk level before go-live

✅ All contributions must be recorded and versioned for traceability and audit purposes.

---

🎯 Why / To what end

• Guarantee proportionality in the security controls applied;
• Reduce costs by avoiding over-protection or unnecessary exposure;
• Support normative compliance and audits;
• Inform strategic decisions (roadmap, budgeting, outsourcing);
• Promote continuous improvement and risk visibility.

📌 The proportional application of controls may be guided by the
Controls Matrix by Risk.

---

🧪 Risk Classification Lifecycle

Risk classification is not a one-off event, but a continuous process. It must be reviewed:

• On changes to architecture, exposure, data or automation/assistance;
• Before critical releases;
• Periodically (annual at L1, half-yearly at L2, quarterly at L3 — Policy 04);
• After relevant incidents or detections.

📌 See: Risk Classification Lifecycle

This continuous reassessment ensures that the controls applied remain proportional and up to date.

---

✅ Risk Acceptance Criteria

Not every identified risk requires additional mitigation. Some may be formally accepted, provided that they meet clear criteria:

• Compatibility with the application's L1–L3 level;
• Residual value within the defined thresholds;
• Sufficient evidence of the controls applied;
• Formal documentation of the decision and of the review deadline.

📌 See: Risk Acceptance Criteria

---

🛡️ Mapping Threats to Risks

To ensure that the classification reflects the technical reality, it is essential to map known threats (e.g. STRIDE, MITRE ATT&CK) to the adopted risk model.

📌 See: Threat Mapping by Risk Level

---

📜 Relevant Organisational Policies

The practical application of this chapter requires formal policies that ensure standardisation, traceability and governance of risk:

Policy	Mandatory?	Application	Minimum expected content
Application Risk Classification Policy	✅ Yes	All projects and product teams	Classification model; moments of application; formal record.
Residual Risk Acceptance Policy	✅ Yes	Security, management, product owners	Acceptance criteria; those responsible; validity; traceable evidence.
Periodic Risk Review Policy	✅ Yes	The whole organisation	Minimum frequency; mandatory triggers; documentation.
Decision Traceability Policy	⚠️ Optional	Regulated or auditable contexts	Versioning; link to architecture, requirements and controls.

📌 See the details in the manual's policy annex.