System Development Life Cycle (SDLC) is the structured process used to plan, build, test, deploy, operate, and retire a system. Security teams use it to insert requirements, threat modelling, code review, testing, and change control early, because leaving security to the end increases rework, defects, and release-time exposure.
Why SDLC matters for security
SDLC is more than a delivery sequence, it is the point where security can shape design choices before they become expensive defects. When requirements, threat modelling, code review, and testing are introduced early, teams reduce avoidable rework and lower the chance that insecure defaults ship into production.
That matters because late security review usually finds issues that are already embedded in architecture, dependencies, or implementation patterns. At that stage, fixing them often means changing code, redesigning components, or delaying release, all of which is harder than building the control in from the start.
Security activities embedded across the lifecycle
In a secure SDLC, security is not a single gate at the end. It appears in planning through secure requirements, in design through threat modelling and architecture review, in implementation through secure coding and peer review, and in verification through dynamic, static, and dependency testing.
That lifecycle view is important because different defects surface at different stages. A design weakness may be visible in modelling, while an injection flaw or exposed secret may only appear in code review or automated testing. The SDLC gives teams a structure for placing the right check at the right time.
For application teams, Application Security Guide is the broader programme view of how these practices fit together, while secure coding guidance is the more tactical layer where implementation issues are prevented before they spread.
Delivery, change control, and release discipline
SDLC also governs how changes move from development into production, so it is a control point for approvals, testing evidence, and release readiness. Security teams use that structure to make sure high-risk changes are reviewed, exceptions are visible, and deployment decisions are not made blindly under schedule pressure.
This is where security becomes operationally real. A team can have strong design principles and still create exposure if emergency changes, unreviewed hotfixes, or poorly controlled third-party updates bypass the normal lifecycle. The SDLC helps preserve consistency when delivery velocity increases.
For the code-level side of that discipline, Secure Coding Guide connects development practice to the implementation details that SDLC controls are intended to catch.
Retirement, maintenance, and security debt
The lifecycle does not end at deployment. Systems eventually need support updates, configuration changes, dependency refreshes, and retirement planning. If those stages are unmanaged, outdated components, unsupported libraries, and forgotten integrations become security debt that survives long after the original project is complete.
Retirement is especially important because decommissioning is often treated as an operational task rather than a security one. In practice, unused systems, stale environments, and orphaned data stores can remain attack surface unless the SDLC includes ownership, cutover, archival, and disposal decisions.
Risk and Threat Considerations
SDLC failures create both security exposure and delivery risk. When security is bolted on late, organisations tend to discover design flaws, insecure code paths, and weak dependencies after they are expensive to fix, which increases the chance of shipping known problems or deferring them into production.
Failure mechanism: The lifecycle loses its preventive function when requirements, review, testing, and change control are skipped, rushed, or treated as optional, allowing defects, misconfigurations, and unsafe design assumptions to persist until release.
Impact: The result can be rework, release delays, persistent vulnerabilities, and a larger attack surface that is harder to remediate once the system is live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-3 — System Development Life Cycle | Defines secure development expectations across the lifecycle. |
| SA-11 — Developer Testing and Evaluation | Requires testing and evaluation of system security before deployment. | |
| CM-3 — Configuration Change Control | Directly governs controlled changes through development and release. | |
| Recommendation — Embed security requirements and reviews into each SDLC phase. Require security-focused testing before release approval. Enforce formal change control for production-bound updates. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Covers secure design and implementation practices in software delivery. |
| Recommendation — Use secure design and coding requirements during implementation reviews. | ||
| OWASP SAMM | SAMM — Software Assurance Maturity Model | Measures how security is built into the software delivery lifecycle. |
| Recommendation — Assess and improve security maturity across build and release practices. | ||
Practitioner Guidance
Why practitioners should care: SDLC is one of the few places where security can influence cost, quality, and exposure at the same time. Teams that treat it as a documentation exercise usually miss the real value, which is to make security a normal part of build, test, release, operate, and retire decisions.
Governance implication: Owners should define where security checks live in the lifecycle, who approves exceptions, and what evidence is required before a system moves forward. That avoids ambiguity when delivery teams are under pressure and ensures security decisions are repeatable rather than ad hoc.