SA-3 System Development Life Cycle
Guidance: draftPolicy clause: draftWhat these mean
sa3ctl| Baselines | Implementation level | Enhancements |
|---|---|---|
| Low, Moderate, High, Privacy | Organization | 3 (0 in a baseline) |
Related controls: AT-3, PL-8, PM-7, SA-4, SA-5, SA-8, SA-11, SA-15, SA-17, SA-22, SR-3, SR-4, SR-5, SR-9
Control statement
Section titled “Control statement”- a. Acquire, develop, and manage the system using [Assignment: organization-defined system-development life cycle] that incorporates information security and privacy considerations;
- b. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;
- c. Identify individuals having information security and privacy roles and responsibilities; and
- d. Integrate the organizational information security and privacy risk management process into system development life cycle activities.
NIST discussion
A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in SA-8 help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.
The effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle.
Control enhancements
Section titled “Control enhancements”SA-3(1) Manage Preproduction Environment
Section titled “SA-3(1) Manage Preproduction Environment”Baselines: Not in a baseline
Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service.
Discussion and assessment objectives for SA-3(1)
The preproduction environment includes development, test, and integration environments. The program protection planning processes established by the Department of Defense are examples of managing the preproduction environment for defense contractors. Criticality analysis and the application of controls on developers also contribute to a more secure system development environment.
Determine if system pre-production environments are protected commensurate with risk throughout the system development life cycle for the system, system component, or system service.
Examine: System and services acquisition policy; procedures addressing the integration of security and supply chain risk management into the system development life cycle process; system development life cycle documentation; procedures addressing program protection planning; criticality analysis results; security and supply chain risk management strategy/program documentation; system security plan; supply chain risk management plan; other relevant documents or records.
Interview: Organizational personnel with security and system life cycle development responsibilities; organizational personnel with information security responsibilities.
Test: Organizational processes for defining and documenting the system development life cycle; organizational processes for identifying system development life cycle roles and responsibilities; organizational process for integrating security risk management into the system development life cycle; mechanisms supporting and/or implementing the system development life cycle.
SA-3(2) Use of Live or Operational Data
Section titled “SA-3(2) Use of Live or Operational Data”Baselines: Not in a baseline
- (a) Approve, document, and control the use of live data in preproduction environments for the system, system component, or system service; and
- (b) Protect preproduction environments for the system, system component, or system service at the same impact or classification level as any live data in use within the preproduction environments.
Discussion and assessment objectives for SA-3(2)
Live data is also referred to as operational data. The use of live or operational data in preproduction (i.e., development, test, and integration) environments can result in significant risks to organizations. In addition, the use of personally identifiable information in testing, research, and training increases the risk of unauthorized disclosure or misuse of such information. Therefore, it is important for the organization to manage any additional risks that may result from the use of live or operational data. Organizations can minimize such risks by using test or dummy data during the design, development, and testing of systems, system components, and system services. Risk assessment techniques may be used to determine if the risk of using live or operational data is acceptable.
Determine if:
- SA-03(02)a.
- SA-03(02)a.[01] the use of live data in pre-production environments is approved for the system, system component, or system service;
- SA-03(02)a.[02] the use of live data in pre-production environments is documented for the system, system component, or system service;
- SA-03(02)a.[03] the use of live data in pre-production environments is controlled for the system, system component, or system service;
- SA-03(02)b. pre-production environments for the system, system component, or system service are protected at the same impact or classification level as any live data in use within the pre-production environments.
Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing the integration of security and privacy into the system development life cycle process; system development life cycle documentation; security risk assessment documentation; privacy impact assessment; privacy risk assessment documentation; system security plan; privacy plan; data mapping documentation; personally identifiable information processing policy; procedures addressing the authority to test with personally identifiable information; procedures addressing the minimization of personally identifiable information used in testing, training, and research; other relevant documents or records.
Interview: Organizational personnel with information security and privacy responsibility; organizational personnel with system life cycle development responsibilities.
Test: Organizational processes the use of live data in pre-production environments; mechanisms for protecting live data in pre-production environments.
SA-3(3) Technology Refresh
Section titled “SA-3(3) Technology Refresh”Baselines: Not in a baseline
Plan for and implement a technology refresh schedule for the system throughout the system development life cycle.
Discussion and assessment objectives for SA-3(3)
Technology refresh planning may encompass hardware, software, firmware, processes, personnel skill sets, suppliers, service providers, and facilities. The use of obsolete or nearing obsolete technology may increase the security and privacy risks associated with unsupported components, counterfeit or repurposed components, components unable to implement security or privacy requirements, slow or inoperable components, components from untrusted sources, inadvertent personnel error, or increased complexity. Technology refreshes typically occur during the operations and maintenance stage of the system development life cycle.
Determine if:
- SA-03(03)[01] a technology refresh schedule is planned for the system throughout the system development life cycle;
- SA-03(03)[02] a technology refresh schedule is implemented for the system throughout the system development life cycle.
Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing technology refresh planning and implementation; system development life cycle documentation; technology refresh schedule; security risk assessment documentation; privacy impact assessment; privacy risk assessment documentation; system security plan; privacy plan; other relevant documents or records.
Interview: Organizational personnel with information security and privacy responsibilities; organizational personnel with system life cycle development responsibilities.
Test: Organizational processes for defining and documenting the system development life cycle; organizational processes for identifying system development life cycle roles and responsibilities; organizational processes for integrating security and privacy risk management into the system development life cycle; mechanisms supporting and/or implementing the system development life cycle.
Assessment objectives (SP 800-53A)
Section titled “Assessment objectives (SP 800-53A)”Objectives and methods for SA-3
Determine if:
- SA-03a.
- SA-03a.[01] the system is acquired, developed, and managed using [Assignment: organization-defined system-development life cycle] that incorporates information security considerations;
- SA-03a.[02] the system is acquired, developed, and managed using [Assignment: organization-defined system-development life cycle] that incorporates privacy considerations;
- SA-03b.
- SA-03b.[01] information security roles and responsibilities are defined and documented throughout the system development life cycle;
- SA-03b.[02] privacy roles and responsibilities are defined and documented throughout the system development life cycle;
- SA-03c.
- SA-03c.[01] individuals with information security roles and responsibilities are identified;
- SA-03c.[02] individuals with privacy roles and responsibilities are identified;
- SA-03d.
- SA-03d.[01] organizational information security risk management processes are integrated into system development life cycle activities;
- SA-03d.[02] organizational privacy risk management processes are integrated into system development life cycle activities.
Examine: System and services acquisition policy; system and services acquisition procedures; procedures addressing the integration of information security and privacy and supply chain risk management into the system development life cycle process; system development life cycle documentation; organizational risk management strategy; information security and privacy risk management strategy documentation; system security plan; privacy plan; privacy program plan; enterprise architecture documentation; role-based security and privacy training program documentation; data mapping documentation; other relevant documents or records.
Interview: Organizational personnel with information security and privacy responsibilities; organizational personnel with system life cycle development responsibilities; organizational personnel with supply chain risk management responsibilities.
Test: Organizational processes for defining and documenting the system development life cycle; organizational processes for identifying system development life cycle roles and responsibilities; organizational processes for integrating information security and privacy and supply chain risk management into the system development life cycle; mechanisms supporting and/or implementing the system development life cycle.
Policy statement
- The System owner shall acquire, develop and manage the system using Fill in: system development life cycle Typical: the organization’s documented system development life cycle, with security and privacy activities and a review gate in each phase: initiation, development or acquisition, implementation and assessment, operations and maintenance, and disposal that incorporates information security and privacy considerations. (SA-3a)
- The Chief Information Security Officer and the Senior privacy official shall define and document the information security and privacy roles and responsibilities for each phase of the system development life cycle. (SA-3b)
- The System owner shall identify, in the system security plan, the individuals who hold information security and privacy roles and responsibilities for the system. (SA-3c)
- The System owner shall integrate the organization’s information security and privacy risk management process into the system development life cycle, so that categorization, control selection, implementation, assessment, authorization and monitoring take place in the phases the risk management process assigns them to. (SA-3d)
Federal systems
OMB Circular A-130, Appendix I, section 4.b(2), requires agencies to ensure that information security and privacy are addressed throughout the life cycle of each agency information system. As of September 2026.
- The System owner shall ensure information security and privacy are addressed in every phase of the system’s life cycle, from planning and acquisition through operation, maintenance and disposal, as OMB Circular A-130, Appendix I, section 4.b(2), requires. (SA-3a)
From the System and Services Acquisition Policy template (draft). Highlighted fields are values your organization sets.
How to apply it
Section titled “How to apply it”SA-3 asks you to run each system through a documented system development life cycle (SDLC) with security and privacy built into it. Define who holds security and privacy roles in each phase, name those people for each system, and fit the Risk Management Framework’s tasks into the phases. NIST SP 800-37 Rev. 2 (December 2018, current as of September 2026) ties each RMF task to an SDLC phase, so the RMF is the usual way to meet item d.
The life cycle model is yours to choose, sequential or iterative. NIST’s SA-3 discussion calls for qualified people in the process, such as security and privacy architects and engineers, and role-based training for them (AT-3). It also notes that external suppliers, developers and integrators take part, which brings in acquisition and supply chain controls.
Common implementations. A written SDLC with five phases and a gate at the end of each, where the system owner cannot proceed without security and privacy sign-off:
| Phase | Typical security and privacy activities |
|---|---|
| Initiation | Security categorization, privacy threshold analysis, high-level requirements and costs (SA-2) |
| Development or acquisition | Control selection, security and privacy requirements in the contract (SA-4), design review against the engineering principles (SA-8), developer testing (SA-11) |
| Implementation and assessment | Secure configuration, control assessment, authorization |
| Operations and maintenance | Change control, continuous monitoring, reauthorization |
| Disposal | Media sanitization, records disposition, removal from inventories and agreements |
Teams that release often put the recurring activities into each release instead: threat review of new features, security tests in the pipeline and a security impact analysis for each change. A roles table names the CISO, the senior privacy official, the system owner, the system security officer, the security architect and the developers against each phase. The system security plan, section 5, names the individuals for the system.
Organization-defined parameters. Typical value, which your organization may set differently:
| Parameter | Typical value |
|---|---|
| System development life cycle (a) | The organization’s documented system development life cycle, with security and privacy activities and a review gate in each phase: initiation, development or acquisition, implementation and assessment, operations and maintenance, and disposal |
The phase names are those SP 800-37 Rev. 2 uses. In the System and Services Acquisition policy, the CISO and the senior privacy official define the roles for each phase, and the system owner names the people in the security plan.
Evidence assessors ask for.
- The documented SDLC, with the security and privacy activities and gates in each phase
- The roles and responsibilities for each phase
- The security plan’s list of people who hold security and privacy roles for the system
- Gate records for the system, or for a sample of projects, showing the security and privacy reviews took place
- Training records for the people in security and privacy roles (AT-3)
Inheritance. The SDLC itself is usually an organization-level common control. The system owns naming its people and showing that its own project followed the gates, so SA-3 is often a hybrid control.
Common findings.
- An SDLC document that no project follows, or that mentions security only at the end, before go-live.
- Gates passed with no record of who reviewed what.
- No disposal phase activities, so retired systems keep accounts, data and connections.
- The security plan names roles but not the individuals who hold them (item c).
- Agile teams working outside the documented life cycle, with no equivalent security activities per release.
Enhancements in the Moderate baseline. SA-3 has none in any baseline. SA-3(1) managing the preproduction environment, SA-3(2) use of live or operational data and SA-3(3) technology refresh are in no baseline. The SA policy still limits live personally identifiable information in developer testing, under SA-11 and SI-12(2).
Federal systems (as of September 2026). OMB Circular A-130, Appendix I, section 4.b(2), requires agencies to ensure that information security and privacy are addressed throughout the life cycle of each agency information system.
Artifacts
Independent guidance, not an official NIST publication. Control text is from NIST SP 800-53 Rev. 5 and SP 800-53A (public domain). Original content is licensed CC BY 4.0; program templates and the downloadable kit are dedicated to the public domain under CC0 1.0.