Organisational Traceability Policy
1. Objective
This policy defines the requirements for the traceability of security practices at organisational level - the set of mechanisms that make it possible to demonstrate, at any moment, the compliance status of each application with the requirements of SbD-ToE, to identify those responsible for each security decision, and to present auditable evidence to internal auditors, external auditors or regulators.
Compliance without traceability is a statement of intent, not a verifiable security posture. Traceability turns scattered practices into structured evidence: it makes it possible to detect deviations before incidents, to support risk decisions with historical data, and to demonstrate maturity objectively. Without an organisational traceability mechanism, the real security status of applications remains invisible to management and to audit.
The objective of this policy is to ensure that:
- Each application has a compliance repository that reflects the real status of SbD-ToE practices
- Each application classified as L2/L3 has a formally designated security owner
- Periodic compliance validations are run with a cadence proportionate to the risk level
- All compliance evidence is auditable, versioned and linked to the decision that originated it
- The organisation has aggregated visibility of the security status of its portfolio
2. Scope and applicability
| Level | Applicability |
|---|---|
| L1 | Basic; classification record and technical owner; annual review |
| L2 | Mandatory; compliance repository per application; designated Security Champion; half-yearly validation; dashboard recommended |
| L3 | Mandatory; complete versioned repository; trained Security Champion; quarterly validation; dashboard mandatory; formal evidence for audit |
3. Compliance repository per application
Each application must have a compliance repository - a structured, versioned and auditable artefact that consolidates the compliance status with all applicable SbD-ToE chapters.
3.1 Format and minimum content
The repository may be implemented as a versioned YAML or Markdown file in a code repository, a GRC tool, or a compliance management system. The specific format is not prescribed - auditability and accessibility are the determining requirements.
| Field | Description | Applicability |
|---|---|---|
application.id | Unique identifier of the application | Mandatory |
application.level | Criticality level (L1/L2/L3) and date of last classification | Mandatory |
owner.security_champion | Identity of the designated Security Champion | L2/L3 |
owner.tech_lead | Identity of the responsible Tech Lead | Mandatory |
compliance.chapters[] | Status per SbD-ToE chapter (Ch. 02–13): Sim / Não / Exceção | Mandatory |
compliance.evidence[] | Links to evidence per chapter (reports, scans, reviews) | L2/L3 |
exceptions[] | Active exceptions with a reference to the exception register | L2/L3 |
last_validated | Date of and person responsible for the last validation | Mandatory |
next_validation | Scheduled date for the next validation | Mandatory |
3.2 Updating
The repository must be updated:
- After each periodic compliance validation
- After each significant change of architecture, criticality level or owner
- After an exception is resolved or approved
- After a major release or a relevant security event
4. Formal designation of security owners
For each application classified as L2 or L3, there must be a formally designated Security Champion, with documented and recorded security responsibilities.
4.1 Designation requirements
| Requirement | Description |
|---|---|
| Formal designation | In writing - official e-mail, HR system, or document signed by a manager |
| Documented responsibilities | Submission of exceptions, periodic validations, risk communication, maintenance of the compliance repository |
| Minimum training completed | The Security Champion must have completed the mandatory security training track for their function |
| Designated substitute | For continuity during prolonged absences (mandatory for L3) |
4.2 Centralised register
The organisation must maintain a centralised register of all active Security Champions, with identification of the application, identity, date of designation and training status. This register is the source of truth for escalation, risk communication and audit.
The designation of a Security Champion does not exempt the other team members from the security responsibilities that fall to them under the applicable policies. The Security Champion is the point of coordination and accountability - not the only person responsible for the security of the application.
5. Periodic compliance validations
Periodic compliance validations are intended to verify whether the requirements of SbD-ToE remain applied and effective, to detect deviations and to collect up-to-date evidence.
5.1 Validation cadence
| Level | Cadence | Additional triggers |
|---|---|---|
| L1 | Annual | Significant architecture change |
| L2 | Half-yearly | Major release; security incident; change of level |
| L3 | Quarterly | Major release; incident; change of owner; external audit |
5.2 Validation process
Each validation cycle must cover:
- Verification of the status of each applicable SbD-ToE chapter (checklist per chapter)
- Collection of up-to-date evidence for chapters with status
Sim(link to reports, scans, reviews) - Review of active exceptions: validity, remediation progress, need for renewal
- Identification of new deviations or of chapters without up-to-date evidence
- Action plan for identified deviations (owner, deadline, priority)
- Update of the compliance repository with the validation result
5.3 Result and decision
The validation result must be documented with:
- Overall status:
Conforme / Conforme com desvios / Não conforme - List of identified deviations with severity
- Action plan with owners and deadlines
- Date of the next validation
6. Organisational dashboard
The organisation must maintain aggregated visibility of the compliance status of its application portfolio:
| Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Compliance status dashboard per application | Not applicable | Recommended | Mandatory |
| Adoption metrics per SbD-ToE chapter | Not applicable | Recommended | Mandatory |
| Visibility of active and expired exceptions | Not applicable | Recommended | Mandatory |
| Automatic alerts for critical deviations | Not applicable | Recommended | Mandatory |
| Periodic reports for executive management | Not applicable | Half-yearly | Quarterly |
The dashboard does not replace the compliance repository per application - it is an aggregated view for management and executive decision-making. The data must be derived from the individual compliance repositories to maintain consistency.
7. Auditable evidence
All compliance evidence must meet the following requirements to be considered auditable:
| Requirement | Description |
|---|---|
| Traceability | The evidence must be linkable to the practice, the chapter and the application it supports |
| Dating | Timestamp of production and of validation |
| Authorship | Identity of the person responsible for production or validation |
| Immutability | Evidence that cannot be altered after production (e.g. signed pipeline artefact, archived report) |
| Accessibility | Available to internal and external auditors without depending on access to production systems |
7.1 Accepted types of evidence
| Type | Examples |
|---|---|
| Tool reports | SAST, SCA, DAST, PenTest report - with tool version, date and scope |
| Pipeline logs | Evidence of execution of a security gate with result and timestamp |
| Review records | Pull request with documented approval and a reference to a security checklist |
| Exception decisions | Exception record with approval, justification and expiry date |
| Results of periodic tests | Reports of tabletop, war room or playbook simulation |
8. Retention of compliance artefacts
| Artefact | Minimum retention |
|---|---|
| Compliance repository (current status and history) | Lifetime of the application + 3 years |
| Validation evidence (package per release) | 1 year (L1), 2 years (L2), 3 years (L3) |
| Security Champion designation records | Duration of the designation + 2 years |
| Periodic validation reports | 3 years |
| Exception records (including expired ones) | In line with Policy 06 §10: 1 year (L1), 2 years (L2), 3 years (L3) after closure or expiry |
The periods in this table are the minimum recommended by the Manual (the Manual's choice). The most demanding of EU law, national legislation, supervisory guidance and normal sector expectations prevails, always within the GDPR limit where personal data are involved — see the precedence clause of Policy 29 §7; the value adopted is recorded in the organisation's retention map.
9. Responsibilities
| Role | Responsibility |
|---|---|
| Security Champion | Keep the application's compliance repository up to date; run or coordinate periodic validations; submit exceptions; communicate risk to GRC |
| AppSec Engineer | Define the structure and requirements of the compliance repository; support validations at L3; audit the quality of evidence; feed the organisational dashboard |
| Tech Lead | Ensure that the team maintains compliance practices; approve action plans for identified deviations |
| GRC / Compliance | Manage the centralised register of owners; run or audit periodic validations; produce reports for executive management; verify regulatory compliance |
| Management / CISO | Analyse portfolio status reports; take strategic risk decisions; ensure resources for the resolution of critical deviations |
10. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- An audit that identifies gaps in the traceability status of one or more applications
- A change to the chapter structure of SbD-ToE that requires the compliance repositories to be updated
- A regulatory change that modifies the evidence or retention requirements
11. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 14 - Governance and Contracting | US-04: organisational traceability; US-08: compliance repository; US-09: designation of owners; US-10: periodic validation; US-13: systematic control per chapter |
Security Governance KPIs Policy (35_policy-kpis-governacao.md) | Metrics derived from the traceability data |
Secure Contracting Policy (33_policy-contratacao-segura.md) | Traceability of suppliers and contractors |
| NIST SSDF - PO.3, PO.7 | Implementation of security practices and traceability |
| OWASP SAMM - PO2, PO3 | Organisational security maturity |
| ISO/IEC 27001 - A.18 | Compliance and information security reviews |
| DORA - Art. 6(5) | ICT risk management documentation and evidence |
| NIS2 - Art. 21 | Cybersecurity measures and accountability |