Summary
The organisation must retain the governance and compliance evidence its SDLC controls generate, such as review outcomes, test evidence, scan results, approval records, deployment records, build artefacts, and audit logs, for at least as long as regulatory, contractual, and audit obligations require, and must keep those records immutable for that period so they can be produced on demand and trusted as evidence.
Description
SDLC activity generates records and artefacts across the lifecycle. Each is produced by a more specific mitigation elsewhere in this catalogue, for example SDLC-PREV-001 for review outcomes and SDLC-PREV-014 for test evidence. This mitigation does not replace those record producing controls; it sets how long their output must survive and how it must be protected while it does, so that a control which operated correctly can still be shown to have done so.
This mitigation exists to address SDLC-RC-005 (Audit and Compliance Evidence Failure), which recurs in three forms: a record is deleted or overwritten before the retention window needed to cover an examination period has elapsed, a record survives but its integrity cannot be trusted because it was modifiable after the fact, or a record lives only in third-party or SaaS tooling that the organisation’s retention controls were never extended to, so it is lost to the vendor’s own default retention or to offboarding. The requirements below address each in turn: a minimum retention period, immutability for that period, and retention that extends to third-party tooling.
Disposal once a record is no longer required is still necessary, since evidence with no end date becomes its own unmanaged exposure. How disposal is carried out (sanitisation methods, legal holds, decommissioning) sits outside the SDLC: it is the organisation’s general data retention and disposal policy applied to this record class, and this control does not redefine it.
Requirements
- The organisation MUST classify SDLC-generated governance record and artefact types (such as review outcomes, test evidence, scan results, approval records, deployment records, build artefacts, audit logs, and exception records) and assign each class a minimum retention period
- The minimum retention period for a record class MUST NOT be less than the longest applicable regulatory, contractual, or audit cycle requirement for that class
- Records MUST be immutable and tamper-evident for the duration of their minimum retention period; they MUST NOT be modifiable, deletable, or replaceable outside an approved and auditable exception process
- Retention for the record classes and minimum periods established above MUST cover SDLC records held in third-party or SaaS tooling (such as CI/CD, ticketing, code review, and artefact repositories), through contractual terms, configuration, or export before offboarding
- An exception process MUST exist for disposing of a record class before its minimum retention period has elapsed, or for extending retention beyond policy
- Disposal of a record class once its minimum retention period has elapsed MUST follow the organisation’s data retention and disposal policy, unless a legal hold or an approved retention exception applies
Examples & Commentary
-
Immutability in practice: Write once storage, object lock or retention lock settings on artefact repositories, and append only audit log configurations are the common ways to make the immutability requirement concrete rather than a paper policy.
-
Third-party flow-down: Where CI/CD, ticketing, or artefact hosting is outsourced to a SaaS vendor, the retention obligation should appear in the vendor contract, including the vendor’s obligation to support export before offboarding. The organisation remains accountable for the record even though it does not control the storage.