Skip to main content

Application Examples in the Governance Cycle

This annex provides practical and reusable examples for applying the concepts of governance and contracting operationally, aligned with the other elements of the SbD-ToE model.
It also includes the verification of mandatory training for critical functions (owners, approvers, validators), in accordance with Ch. 13.

📜 1. Example of an exception approval​

Title: [SEC] Approval of an exception to the input validation control for the "GestDoc" app

Justification:

The application uses a legacy framework without native support for automatic validation. The risk was mitigated with an external validation proxy and reinforced logging.

Risk level: L2

Controls replaced: VAL-002, VAL-006
Compensation applied: Validation in a proxy with schema + fuzzing tests

Exception validity: 60 days (L2, Low/Medium — Policy 05 §7)
Owner: paula.lima@empresa

Approvers: AppSec + product manager
Mandatory training validated: ✔️ Owners and approvers with active SbD training (Ch. 13)

📄 2. Example of supplier onboarding​

Title: [ONB] Supplier validation for an external payment integration ("XPay" service)

Risk classification of the system: L3

Onboarding checklist:

  • Security questionnaire completed
  • SBOM provided
  • Security contractual clauses signed
  • Incident response SLA < 24h
  • External validation of controls (in progress)

Integration owner: ana.gomes@empresa

Note: onboarding conditional on the delivery of test evidence before go-live
Mandatory training validated: ✔️ Owner and AppSec analyst with training in third-party validation (Ch. 13)

🔄 4. Example of a contract renewal with a review of requirements​

Title: [REV] Review of clauses and requirements at the renewal of the contract with supplier “DataStore”

Context:

Licensing contract for cloud storage software, used by L2 systems.

Actions carried out:

  • Update of the contractual clauses to reflect new requirements (EX-DAT-004, EX-BKP-002 — illustrative identifiers; they do not correspond to the Requirements Catalogue of Ch. 02)
  • Technical validation of the SBOM of the synchronisation agent
  • Formal acceptance of an SLA for mitigation of CVEs in <5 days
  • Updated training of the PO and of the DevOps / SRE team involved

Renewal owner: sofia.rodrigues@empresa

Date of the new signature: 2025-07-10
Mandatory training validated: ✔️ Documented in an internal repository (Ch. 13)

🧪 5. Example of a temporary exception with planned reassessment​

Title: [SEC] Exceptional approval for the absence of MFA in the build management tool

Justification:

The tool used (BuilderX) does not support multi-factor authentication. The risk was compensated with IP restriction and continuous logging.

Risk level: L3

Missing requirement: ACC-007 Compensation: Access limited via VPN + daily analysis of the logs

Approval: AppSec team + DevSecOps + CISO
Validity: 3 months with reassessment scheduled in the security backlog

Mandatory training validated: ✔️ CISO and technical owner with training in exceptions (Ch. 13)

🛠️ 6. Example of a supplier rejected after incomplete onboarding​

Title: [ONB] Rejection of supplier “CloudParser” for a data transformation pipeline

Risk classification of the application: L3

Reason for rejection:

  • Failure to deliver an up-to-date SBOM
  • Refusal of contractual clauses on audit
  • Inability to demonstrate an incident response channel

Decision: Rejected by the technical approval committee (AppSec, Owner, GRC)

Owner: miguel.pinto@empresa
Notes: viable alternative already identified (supplier “ParseVault”)

📆 3. Risk decision record template​

Suggested format: Jira / SharePoint / traceable Excel

FieldValue
Application nameapp-inventario
Risk levelL2
Requirements not appliedLOG-005, EX-AUD-003
Technical justificationNo infrastructure for extended retention; compensated with snapshots
Compensation appliedAlerts via SIEM + external backup
Owner and approvalnuno.ferreira@empresa + CISO
Validity of the decision3 months + scheduled reassessment
Mandatory training✔️ Both with valid internal certification (<12 months)

Illustrative identifiers (EX-…); they do not correspond to the Requirements Catalogue of Ch. 02.

✅ Recommendations​

  • These models must be normalised and reused across projects
  • They may be made available via templates in Confluence, Git or ALM
  • They must be associated with the application, supplier or release artefacts
  • The existence of these records supports audits, governance and executive decision
  • Mandatory training for critical functions (Ch. 13) must be verified before formal validations
  • Whenever part of the process is supported by automated mechanisms, the record must make explicit who validated and took on the final decision.