Summary
An organisation cannot produce, on demand and for any point in time within the required retention period, the records that demonstrate its SDLC governance operated as intended — including policy approvals, control design decisions, risk acceptance sign-offs, exception management, security design reviews, test evidence, and release gate outcomes — creating exposure to regulatory enforcement, failed audits, and loss of certifications essential to operating in financial services.
Description
This risk concerns the evidentiary problem: whether the organisation can prove what its SDLC governance did and when. It is distinct from configuration drift (ri-7), which concerns divergence between declared and actual system state, and from unauthorised change (ri-8), which concerns whether individual changes were properly approved. Evidence failure can exist even when controls are well-designed and consistently applied, if the records that attest to their operation are unavailable, incomplete, cannot withstand scrutiny, or cannot be tied to specific points in time.
SDLC governance generates a broad set of artefacts: architectural decision records, threat models, risk assessments, control design documentation, waiver and exception records, change advisory board decisions, security review findings, penetration test results and remediation traces, release gate approvals, and control ownership assignments. The inability to produce any of these when requested by a regulator, auditor, or enterprise customer constitutes an evidence failure regardless of whether the underlying activity took place.
- Inability to reconstruct SDLC change history within audit timelines — The organisation cannot produce, when requested, a verifiable record linking code changes to their corresponding reviews, approvals, and deployment decisions across the period under examination
- Inability to demonstrate continuous control operation — Evidence covers only point-in-time snapshots (audit preparation periods, certification renewals) and does not demonstrate that controls operated consistently across the full audit period
- Evidence that fails integrity or authenticity scrutiny — Records presented as evidence can be shown to have been created, modified, or deleted after the fact, or cannot be attributed to a specific actor with a trustworthy timestamp
- Broken traceability between governance decisions and the artefacts they govern — Approval records, review outcomes, and risk assessments exist but cannot be linked to the specific code changes, releases, or deployments they relate to, preventing end-to-end reconstruction of the control chain
- Records do not survive their required retention period — SDLC governance artefacts are deleted, overwritten, or become inaccessible before the end of the regulatory retention window, leaving the organisation unable to respond to examination requests covering prior periods
- Inability to demonstrate control ownership and decision accountability at a point in time — The organisation cannot show who owned a control, who was accountable for a governance decision, or who authorised an exception at the time the activity occurred
Consequences
- Regulatory enforcement actions — Banking and financial regulators treat unsubstantiated controls as absent controls. Inability to produce SDLC governance evidence during an examination can result in formal enforcement actions, mandatory remediation programmes, restrictions on technology change activity, and heightened supervisory scrutiny.
- SOX Section 404 material weakness findings — Auditors assessing internal controls over financial reporting may classify insufficient SDLC evidence as a material weakness or significant deficiency, requiring disclosure and remediation with direct impact on financial reporting timelines.
- PCI DSS compliance failure — Requirements covering secure development (Req 6) and targeted risk analysis (Req 12.3) require documented evidence of control operation. Inability to produce this evidence during a QSA assessment can result in loss of attestation of compliance.
- DORA Article 6 non-compliance — The Digital Operational Resilience Act requires financial entities to maintain comprehensive ICT risk management frameworks with demonstrable governance. Evidence gaps in SDLC controls constitute a gap in the ICT risk management documentation DORA mandates.
- GLBA Safeguards Rule exposure — Financial institutions subject to the Gramm-Leach-Bliley Act must demonstrate that their information security programme — including software development controls — is documented and operating effectively.
- SOC 2 Type II report qualifications — Service organisations require evidence of continuous control operation across the entire examination period. Incomplete or point-in-time-only evidence results in qualified opinions or exceptions that damage commercial relationships with enterprise customers.
- Failed customer and partner audits — Enterprise customers in regulated industries increasingly require SDLC governance evidence as part of vendor due diligence and ongoing third-party risk management. Evidence failures result in lost contracts, exclusion from procurement processes, and damage to commercial reputation.
- Increased cost of compliance — Organisations that cannot produce evidence on demand face extended audit cycles, higher audit fees, and resource-intensive evidence reconstruction efforts that divert engineering and governance capacity from productive work.