Governance Model for Security by Design

🌟 Objective

To establish a formal structure of decision, validation and accountability that makes it possible to apply, coherently and sustainably, the practices defined in the SbD-ToE model across the whole organisation.

This model ensures that:

• Risk classification guides formal decisions;
• The application of requirements is demanded, not optional;
• Risk acceptance, exceptions and compensations are traceable;
• There is a clear chain of technical, functional and executive accountability.

This model assumes that the authority to decide, approve exceptions or accept risk always resides in explicitly defined organisational roles.

The technical execution of those decisions may be supported by automated processes or mechanisms, but the responsibility for and legitimacy of the decision remain human, explicit and traceable.

---

👥 Roles and responsibilities

The practical application of the SbD-ToE depends on well-defined roles, formally assigned and kept up to date.

Role / Function	Main responsibilities
AppSec / Security	Define minimum criteria, approve applied controls, validate exceptions, consolidate evidence
Architecture	Ensure that risk decisions translate into coherent technical options
Product Manager	Prioritise security requirements, propose compensations or accept impact
DevOps Team	Apply controls in the pipeline, monitor technical compliance
GRC / CISO	Oversee risk decisions, maintain policies and adoption indicators
Procurement / Legal	Incorporate security requirements and clauses into contracts with suppliers

✅ These roles must be described in formal policies and internal governance models.

---

🛠️ How to apply

📌 Typical decisions with formal governance

• Risk acceptance when minimum controls are not applied;
• Approval of exceptions to practices of the technical chapters;
• Validation of compensations (e.g. alternative or temporary mitigation);
• Approval of suppliers with security deviations or gaps;
• Escalation of deviations detected in release or production.

🗂️ Evidence and traceability

Each decision must include:

• Identification of the application, risk and controls;
• Technical and organisational justification;
• Person responsible for the decision (name and function);
• Validity (temporary or permanent);
• Reference to the evidence (scanner, review, exception form).
• Identification of the processes or technical mechanisms involved in executing the decision, where applicable.

A formal system (Jira, versioned wiki, SharePoint, etc.) may be used for structured recording.

---

🔁 Typical governance cycle

1. Risk classification assigned (Ch. 1);
2. Selection of the applicable minimum requirements (Ch. 2);
3. Validation of the effective application of controls;
4. Recording of exceptions or compensations;
5. Formal approval (according to criticality);
6. Periodic review or planned audit.

This cycle repeats per release, project, contract or change of risk.

---

📄 Recommended documentation

• Security by Design Policy (roles, principles and obligations);
• Risk Decision Model (risk levels and approval authority);
• Exceptions template (mandatory fields and evidence);
• Register of owners per application/project.

---

✅ Good practices

• Formalise the model in writing and with executive validation;
• Require the justification and formal approval of exceptions;
• Clearly assign the security owner per project;
• Consolidate decisions in a traceable repository;
• Periodically review active decisions and exceptions.

---

🔗 Cross-references

Document / Chapter	Relationship with this model
Chapter 01 - Risk Management	Starting point: risk classification
Chapter 02 - Requirements	Defines the applicable requirements per level
Chapter 06 - Secure Development	Implies formal validations
addon/06-validacao-continuada.md	Applies the logic of reassessment and exceptions
addon/12-processo-excecoes.md	Canonical exception process and chain of authority

---