Traceability and Audit Policy
1. Objective​
This policy defines the cross-cutting traceability and audit requirements that must be met throughout the entire lifecycle of each application.
Traceability is the ability to reconstruct, at any moment, the chain of decisions, evidence and artefacts that support an application's security posture - from the defined requirements to the code in production, including the validations executed, the exceptions approved and the operational events recorded.
Without effective traceability:
- Security audits become exercises in speculative reconstruction
- Incident investigation loses rigour and reach
- Regulatory compliance cannot be demonstrated objectively
- Risk decisions are left without associated evidence
This policy is cross-cutting - it applies to all domains of the SbD-ToE Manual in which evidence, approvals, artefacts or auditable events are produced.
2. Scope​
This policy covers the following dimensions of traceability:
| Dimension | Description | Chapters |
|---|---|---|
| Requirements | Traceability between security requirements, backlog work and validation evidence | Ch. 02 |
| Code and pipeline | Traceability commit → build → pipeline → release → deploy | Ch. 07 |
| Artefacts | Provenance and integrity of build artefacts (SBOM, signatures, SCA) | Ch. 05, 07, 09 |
| Infrastructure | Traceability IaC file → resource → environment | Ch. 08 |
| Validation evidence | Archive of SAST, DAST, fuzzing and SCA reports and exceptions | Ch. 06, 10 |
| Operational events | Structured logs with guaranteed integrity, correlatable with incidents | Ch. 12 |
| Security decisions | Approvals, exceptions, risk acceptances, threat modelling results | Ch. 01, 03, 14 |
| Regulatory compliance | Mapping between technical controls and normative requirements | Ch. 12, 14 |
3. Fundamental principles​
- Bidirectional traceability - it must be possible to navigate from the requirement to the code and from the code to the requirement
- Executable evidence - reports produced by real execution, never by manual declaration without technical support
- Immutability - audit evidence must not be alterable after it is produced; WORM storage recommended at L2/L3
- Correlation - events from different sources (commit, pipeline, log, incident) must be correlatable through common identifiers
- Proportionality - the level of detail and formality scales with the application's criticality level
4. Requirements traceability (Ch. 02)​
4.1 Requirements by level​
| Practice | L1 | L2 | L3 |
|---|---|---|---|
| Security requirements in the backlog with tags | Recommended | Mandatory | Mandatory |
| Cross-reference requirement → validation | Recommended | Mandatory | Mandatory |
| Exportable traceability report | Optional | Recommended | Mandatory |
| Independent traceability review | Not applicable | Recommended | Mandatory |
4.2 Minimum requirements​
- All applicable security requirements identified with a traceable taxonomy (e.g.
SEC-L2-AUT-001) - Each requirement linked to at least one backlog item, PR or technical task
- Validation evidence (test, review, report) associated with each applied requirement
- Exceptions to requirements formally recorded with a reference to the requirement under exception
5. Code and pipeline traceability (Ch. 07)​
5.1 Mandatory chain​
Traceability must cover the complete chain:
commit SHA → execução de pipeline → artefacto produzido → release tag → deployment
5.2 Requirements by level​
| Element | L1 | L2 | L3 |
|---|---|---|---|
| Commit SHA associated with the artefact | Recommended | Mandatory | Mandatory |
| Pipeline logs retained | Basic | Mandatory (90 days) | Mandatory (1 year) |
| Scanner results correlated with the commit | Optional | Mandatory | Mandatory |
| Immutable export of pipeline logs | Not applicable | Recommended | Mandatory |
| Non-repudiation of irreversible promotions | Not applicable | Recommended | Mandatory |
5.3 Minimum requirements​
- Unique correlation ID per pipeline execution
- Security reports (SAST, DAST, SCA) archived as pipeline artefacts with a reference to the commit
- Pipeline logs retained as per the table above
- Promotions to production associated with traceable human approval (name, timestamp, context)
6. Artefact traceability (Ch. 05, 07, 09)​
6.1 Requirements by level​
| Element | L1 | L2 | L3 |
|---|---|---|---|
| SBOM generated per build | Recommended | Mandatory | Mandatory |
| Artefact signing | Not applicable | Mandatory | Mandatory |
| Recorded provenance (who/when/how) | Not applicable | Mandatory | Mandatory |
| Signature verification at deploy | Not applicable | Mandatory | Mandatory |
| Digest-only for container images | Recommended | Mandatory | Mandatory |
6.2 Minimum requirements​
- SBOM in CycloneDX or SPDX format, generated automatically per build and archived
- Release artefacts signed with a managed key that is rotated periodically
- Provenance metadata (who built it, when, from which commit) associated with the artefact
7. Infrastructure traceability (Ch. 08)​
7.1 Minimum requirements​
- Each IaC file traceable to the resource it provisions and to the environment in which it was applied
-
planandapplyhistory retained and auditable - Infrastructure changes associated with a PR with a documented review
- Drift detected and recorded with a reference to the expected state
8. Archive of validation evidence (Ch. 06, 10)​
8.1 Requirements by level​
| Evidence | L1 | L2 | L3 |
|---|---|---|---|
| SAST reports archived | Recommended | Mandatory | Mandatory |
| DAST reports archived | Optional | Mandatory | Mandatory |
| SCA reports archived | Recommended | Mandatory | Mandatory |
| Fuzzing reports archived | Optional | Mandatory | Mandatory |
| WORM storage or equivalent | Not applicable | Recommended | Mandatory |
| Evidence index per application/release | Optional | Recommended | Mandatory |
8.2 Minimum requirements​
- Evidence repository defined, with appropriate access control
- Automatic export per build/release to the evidence repository
- Evidence retained in line with the defined retention periods (see section 10)
- Evidence not alterable after archiving (WORM or equivalent at L2/L3)
9. Operational event traceability (Ch. 12)​
9.1 Minimum requirements​
- Logs in a structured format (JSON or equivalent) with minimum fields: timestamp, level, event, origin, context
- Correlation identifier (
request_idor equivalent) propagated across all logs of the same flow - Logs sent to a centralised system (L2/L3)
- Access to logs restricted and audited - no direct access by production functions
- Verifiable log integrity (hash or signature) at L2/L3
- WORM retention enabled in storage at L3
10. Minimum retention periods​
| Type of evidence | L1 | L2 | L3 |
|---|---|---|---|
| Application logs | 30 days | 90 days | 1 year |
| Security logs (authentication, authorisation, changes) | 90 days | 1 year | 2 years |
| Audit logs (administrative operations, access to sensitive data) | 1 year | 1 year | 3 years |
| CI/CD pipeline logs | 30 days | 90 days | 1 year |
| Security reports per run (SAST/DAST/SCA, fuzzing, image scanning, IaC) | 30 days | 90 days | 1 year |
| Validation evidence package per release (index + signed export) | 1 year | 2 years | 3 years |
| Build artefacts and SBOM | Per release | 1 year | 2 years |
| Approval records | 1 year | 2 years | 3 years |
| Records of exceptions and risk acceptances (including expired ones), with approvals and reassessments | 1 year after closure or expiry | 2 years after closure or expiry | 3 years after closure or expiry |
| Incident records (timeline, post-mortem, notifications) | 1 year | 1 year | 3 years |
| Classification and reassessment records | 2 years | 3 years | 5 years |
note
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. For products within the scope of the CRA, the evidence package and the SBOM that form part of the technical documentation are kept available for at least 10 years after placing on the market or for the support period, whichever is longer (CRA, Article 13(13)), regardless of level. For high-risk AI systems, the provider keeps the technical documentation and the artefacts that feed it for 10 years after placing on the market or putting into service (AI Act, Article 18(1)), also regardless of level.
11. Traceability of security decisions​
The following decisions must always be recorded with complete traceability:
| Decision | Minimum elements of the record |
|---|---|
| Exception approval | Who approved, when, for which control, with what deadline |
| Residual risk acceptance | Who approved, severity, mitigation, TTL |
| Pipeline gate override | Who authorised, context, timestamp |
| Change of classification level | Who decided, justification, date |
| Release approval | Who approved, checklist executed, open findings |
| Threat modelling result | Threats identified, mitigation or acceptance decisions, approval |
12. Responsibilities​
| Role | Responsibility |
|---|---|
| Developer / Tech Lead | Ensure traceability tags in the backlog and PRs; produce validation evidence |
| DevOps / SRE | Configure automatic archiving of artefacts and logs; ensure retention and immutability |
| AppSec Engineer | Verify the completeness of traceability in security reviews and audits |
| GRC / Compliance | Maintain the centralised evidence index; issue compliance reports |
| CISO | Oversee the traceability programme; ensure alignment with regulatory requirements |
13. Review and audit of this policy​
This policy must be reviewed annually or after any of the following events:
- Incident in which the lack of traceability hindered the investigation
- Regulatory change with an impact on retention periods or evidence requirements
- Significant change to the pipeline or logging architecture
The evidence index and the audit logs must be made available in full in internal and external audits.
14. Normative and technical references​
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 02 - Security Requirements | Traceability requirement → control → validation |
| SbD-ToE Ch. 06 - Secure Development | Central archive of validation evidence |
| SbD-ToE Ch. 07 - Secure CI/CD | Traceability commit → pipeline → release |
| SbD-ToE Ch. 08 - IaC and Infrastructure | Traceability file → resource → environment |
| SbD-ToE Ch. 09 - Containers and Images | Provenance and signing of images |
| SbD-ToE Ch. 12 - Monitoring and Operations | Log integrity and retention |
| SbD-ToE Ch. 14 - Governance and Contracting | Organisational traceability and compliance |
| ISO/IEC 27001 - Clause 9.1 | Monitoring, measurement, analysis and evaluation |
| NIST SP 800-92 | Guide to Computer Security Log Management |
| SSDF PW.8 | Archive and protect each software release |
| NIS2 - Articles 21 and 23 | Risk-management measures and reporting obligations |
| DORA - Article 10 | Traceability of events and logs |