Control statement
- a.Acquire, develop, and manage the system using [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.
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](#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.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use System Development Life Cycle as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure acquisition, engineering, development lifecycle, supplier expectations, and system integrity by design.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- security requirements in contracts and specifications
- architecture and design review records
- development lifecycle evidence
- supplier assessment and acceptance records
Common failure patterns
- security requirements added after procurement
- supplier claims accepted without evidence
- development exceptions become permanent
- security architecture not tied to testable requirements
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- SA-03a.
- SA-03a.[01]the system is acquired, developed, and managed using [Organization-defined: system-development life cycle] that incorporates information security considerations;
- SA-03a.[02]the system is acquired, developed, and managed using [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
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
SA-3(1) — Manage Preproduction Environment
Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service.
Official discussion
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.
Assessment objectives and methods
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
Related controls
SA-3(2) — Use of Live or Operational Data
- (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.
Official discussion
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.
Assessment objectives and methods
- 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
Related controls
SA-3(3) — Technology Refresh
Plan for and implement a technology refresh schedule for the system throughout the system development life cycle.
Official discussion
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.
Assessment objectives and methods
- 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
Related controls
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.