Category: Risk Management Framework

System Development Life Cycle

Also known as: SDLC, Systems Development Life Cycle, Software Development Life Cycle, System Development Lifecycle

Simply put

The System Development Life Cycle (SDLC) is the overall process organizations use to plan, build, operate, and eventually retire an information system, broken into a series of defined steps or phases. It provides a structured way to move a system from initial concept through design, development, testing, and deployment. Treating security as part of each phase generally helps ensure protections are built in rather than added after the fact.

Formal definition

The SDLC is a multistep, structured process for developing, implementing, and retiring information systems, typically organized into sequential or iterative phases such as planning, design, development, testing, deployment, operation, and disposal. In practice the specific phase names and boundaries vary by the governing standard or organizational policy, so implementers should confirm the phase model and minimum required considerations defined by the applicable authoritative source. From a compliance standpoint, security activities are generally integrated across the SDLC phases rather than performed as a single discrete step; the evidence provided here defines the SDLC concept but does not specify how it maps to particular control frameworks, so readers should verify integration requirements against current official guidance.

Why it matters

The SDLC matters because it determines when and how security is addressed as a system moves from concept to retirement. When organizations treat security as an activity woven through each phase of the life cycle rather than a check performed at the end, protections are more likely to be designed into the system's architecture instead of bolted on after deployment. For compliance officers and information system security managers, the SDLC provides the structural backbone against which security requirements, testing, and documentation can be aligned as a system evolves.

A disciplined SDLC also supports accountability and traceability. Because the life cycle breaks development into defined phases such as planning, design, development, testing, deployment, operation, and disposal, it creates natural checkpoints where security considerations, risk decisions, and required approvals can be recorded and reviewed. This is especially relevant in defense and public sector environments, where authorization and continuous monitoring depend on being able to demonstrate that security was considered throughout a system's existence rather than at a single point in time.

It is important not to overstate what the SDLC alone accomplishes. A structured life cycle is a process framework, not a control catalog, and following an SDLC does not by itself establish compliance with any particular standard. The evidence available here defines the SDLC concept but does not specify how its phases map to specific control frameworks, so organizations should confirm the required phases, minimum considerations, and security integration points against the governing standard or organizational policy that applies to their systems.

Who it's relevant to

Information System Security Managers and Security Engineers

These practitioners are responsible for ensuring that security considerations are integrated into each SDLC phase rather than addressed only at deployment. Because phase models and the security activities expected within them vary by governing standard, they should confirm the applicable phase structure and minimum required considerations against their organization's authoritative SDLC policy or standard.

Compliance Officers and Auditors

Compliance and audit personnel use the SDLC's defined phases as checkpoints for verifying that security requirements, decisions, and documentation are captured throughout a system's life. They should keep in mind that following an SDLC is a process discipline and does not by itself demonstrate compliance with a specific control framework; the mapping between SDLC phases and framework requirements must be verified against current official guidance.

System Owners and Program Managers

Those accountable for planning, building, operating, and retiring information systems rely on the SDLC to structure a system's progression from concept through disposal. They should confirm the minimum required phases and considerations defined by the standard or organizational policy that governs their systems, since these can differ across organizations and environments.

Government Contractors and Development Teams

Contractors and development teams that design and build systems apply the SDLC to organize planning, design, development, testing, and deployment work. They should verify which phase model and security integration expectations apply to their specific engagement, as contractual and framework-specific requirements are out of scope for this general definition and must be confirmed against authoritative sources.

Inside SDLC

Initiation / Planning Phase

The stage in which the need for a system is identified and its purpose, scope, and high-level requirements are defined. In federal and defense contexts, security categorization considerations generally begin here, informing later control selection.

Requirements / Development Phase

The stage where functional and security requirements are elaborated and the system is designed and built. Security requirements are typically derived from applicable control baselines (for example, NIST SP 800-53 baselines for federal systems), though specific selections depend on categorization and agency tailoring.

Implementation / Assessment Phase

The stage in which the system is deployed and its security controls are assessed for effectiveness. This corresponds to activities such as security control assessment; note that assessment is distinct from the separate authorization decision.

Operations and Maintenance Phase

The stage during which the system runs in production and is maintained. Under the Risk Management Framework (RMF), this phase generally includes continuous monitoring, since an Authority to Operate (ATO) is time-bound and subject to ongoing review rather than permanent.

Disposal / Retirement Phase

The final stage covering decommissioning of the system, including secure disposition of data and media. Requirements for handling residual data may differ depending on whether the system processes CUI, national security information, or civilian agency data, and should be verified against applicable guidance.

Integration of Security Throughout

The principle that security activities are embedded across all phases rather than added at the end. This concept aligns with RMF integration into the SDLC and generally aims to reduce cost and risk compared with retrofitting security late in development.

Common questions

Answers to the questions practitioners most commonly ask about SDLC.

Does completing the SDLC mean my system is compliant and can begin operating?

No. Progressing through the SDLC is not the same as achieving authorization. In most federal and DoD implementations, security activities embedded across the SDLC feed into a separate authorization decision, and a system generally cannot operate until an authorizing official issues an Authority to Operate (ATO). Completing development phases demonstrates that engineering work is done, not that the risk has been formally accepted. You should confirm the specific authorization requirements against current official guidance for your environment.

Isn't the SDLC just a software engineering process with no real security or compliance role?

That is a common misconception. While the SDLC originates as a systems and software engineering framework, security is generally expected to be integrated throughout its phases rather than added at the end. Building security and compliance considerations into each phase is often described as more effective and less costly than retrofitting controls later. Treating the SDLC as purely an engineering exercise separate from security tends to create gaps that surface during assessment or authorization.

At what point in the SDLC should security requirements first be identified?

Security and compliance requirements are generally identified as early as possible, typically during the initiation or requirements phases, rather than after design or implementation. Identifying applicable requirements early allows them to shape architecture and design decisions. The precise mapping of activities to phases can vary by organization and by the governing methodology in use, so you should align your approach to your organization's documented process and any applicable official guidance.

How do SDLC phases relate to the activities in a risk management process?

Many risk management activities are intended to be performed in parallel with, and integrated into, corresponding SDLC phases rather than as a wholly separate track. The intent in most implementations is that security categorization, control selection, implementation, assessment, and ongoing monitoring align with the development, deployment, and operational stages of the system. Because the exact alignment depends on the methodology and framework you follow, verify the specific mappings against the applicable authoritative publications.

What SDLC considerations apply when a system reaches the end of its life?

The disposal or retirement phase generally addresses activities such as preserving or transferring information, sanitizing or destroying media, and formally decommissioning the system and any associated authorizations. These activities help ensure that data, including any sensitive or controlled information, is handled appropriately at end of life. The specific sanitization and disposition requirements depend on the data type and applicable policy, so confirm them against current official guidance for your environment.

How should security be handled when changes are made to a system already in operation?

Changes to an operational system are typically managed through change and configuration management processes that revisit relevant SDLC and security activities rather than treating the system as static. Significant changes may require reassessment and can affect an existing authorization, since authorizations are time-bound and subject to continuous monitoring. The threshold for what constitutes a significant change and the required response should be determined against your organization's policy and applicable authoritative guidance.

Common misconceptions

The SDLC is purely a software engineering process with no role for security or compliance staff.

Security and compliance activities are generally intended to be integrated into every SDLC phase. For federal and defense systems, RMF activities are typically aligned to SDLC phases so that categorization, control selection, assessment, and monitoring occur alongside development rather than separately.

Once a system passes its assessment and receives an ATO, the SDLC's security work is complete.

An ATO is time-bound and subject to continuous monitoring during the operations and maintenance phase. Assessment is not the same as authorization, and neither is a one-time event; ongoing monitoring and reauthorization are generally required as conditions and control effectiveness change.

Completing SDLC phases means the system is secure.

Following an SDLC process demonstrates that defined activities occurred; it does not by itself guarantee security. Compliance with a process or control baseline is not equivalent to being secure, and residual risk should be evaluated against the system's actual threat environment.

Best practices

Integrate security and compliance activities into each SDLC phase from initiation onward, rather than treating them as a final checkpoint before deployment.

Align SDLC phases to the applicable authorization framework (for example, RMF for DoD and federal systems) and confirm the current governing publication and revision before relying on specific control mappings.

Perform security categorization early so that control selection and tailoring reflect the system's impact level and the type of information it handles, whether CUI, national security information, or civilian agency data.

Treat assessment and authorization as distinct activities, and plan for continuous monitoring during operations because any ATO is time-bound and subject to ongoing review.

Address secure data and media disposition explicitly in the disposal phase, verifying requirements against the guidance applicable to the system's data type.

Document security decisions and evidence throughout the life cycle so that assessors and authorizing officials can trace requirements from initiation through disposal.