Knowledge is Power
BARE METAL CYBERKnowledge is Power

Sitewide Search

Search Bare Metal Cyber

Search courses, individual lessons, wiki entries, books, podcasts, magazine articles, Daily Cyber News, and Darwin.

NIST SP 800-53 Learning Center

SA-4 — Acquisition Process

Read the official control and assessment content, then use the separately labeled Bare Metal Cyber perspective to connect the requirement to implementation, evidence, and sustained operation.

12Enhancements
2Parameters
4Baseline memberships
3Assessment methods

SA — System and Services Acquisition · NIST SP 800-53 Release 5.2.0

LowModerateHighPrivacy
Official NIST control content

Control statement

Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service:

  1. a.Security and privacy functional requirements;
  2. b.Strength of mechanism requirements;
  3. c.Security and privacy assurance requirements;
  4. d.Controls needed to satisfy the security and privacy requirements.
  5. e.Security and privacy documentation requirements;
  6. f.Requirements for protecting security and privacy documentation;
  7. g.Description of the system development environment and environment in which the system is intended to operate;
  8. h.Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
  9. i.Acceptance criteria.
Official NIST discussion

Discussion

Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2](#sa-2) . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) describes the process of requirements engineering as part of the system development life cycle. Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle. Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement. Organizations can determine other requirements that support security and operations, to include responsibilities for the organization and developer, and notification and timing requirements for support, maintenance and updates.

Official OSCAL parameters

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.

sa-04_odp.01
contract languagecontract language is defined (if selected);
Original Bare Metal Cyber perspective

From control text to operational evidence

Use Acquisition Process 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?
Official NIST SP 800-53A content

Assessment objectives and methods

Show the assessment objective
  1. SA-04a.
    1. SA-04a.[01]security functional requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04a.[02]privacy functional requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  2. SA-04b.strength of mechanism requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  3. SA-04c.
    1. SA-04c.[01]security assurance requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04c.[02]privacy assurance requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  4. SA-04d.
    1. SA-04d.[01]controls needed to satisfy the security requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04d.[02]controls needed to satisfy the privacy requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  5. SA-04e.
    1. SA-04e.[01]security documentation requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04e.[02]privacy documentation requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  6. SA-04f.
    1. SA-04f.[01]requirements for protecting security documentation, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04f.[02]requirements for protecting privacy documentation, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  7. SA-04g.the description of the system development environment and environment in which the system is intended to operate, requirements, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
  8. SA-04h.
    1. SA-04h.[01]the allocation of responsibility or identification of parties responsible for information security requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service;
    2. SA-04h.[02]the allocation of responsibility or identification of parties responsible for privacy requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01];
    3. SA-04h.[03]the allocation of responsibility or identification of parties responsible for supply chain risk management requirements, descriptions, and criteria are included explicitly or by reference using [Organization-defined: sa-04_odp.01];
  9. SA-04i.acceptance criteria requirements and descriptions are included explicitly or by reference using [Organization-defined: sa-04_odp.01] in the acquisition contract for the system, system component, or system service.

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 acquisition process
  • configuration management plan
  • acquisition contracts for the system, system component, or system service
  • system design documentation
  • system security plan
  • supply chain risk management plan
  • privacy plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with information security and privacy responsibilities
  • system/network administrators
  • organizational personnel with supply chain risk management responsibilities

Test

  • Organizational processes for determining system security and privacy functional, strength, and assurance requirements
  • organizational processes for developing acquisition contracts
  • mechanisms supporting and/or implementing acquisitions and the inclusion of security and privacy requirements in contracts
Official relationships

Related controls

These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.

CM-6CM-8PS-7SA-3SA-5SA-8SA-11SA-15SA-16SA-17SA-21SR-3SR-5
Official NIST enhancements

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.

Official NIST control enhancement

SA-4(1) — Functional Properties of Controls

ModerateHigh

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.

Official discussion

Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls.

Assessment objectives and methods

the developer of the system, system component, or system service is required to provide a description of the functional properties of the controls to be implemented.

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • procedures addressing the integration of security and privacy requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system component, or system services
  • system security plan
  • privacy plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with information security and privacy responsibilities
  • system developers

Test

  • Organizational processes for determining system security functional requirements
  • organizational processes for developing acquisition contracts
  • mechanisms supporting and/or implementing acquisitions and the inclusion of security and privacy requirements in contracts
Official NIST control enhancement

SA-4(2) — Design and Implementation Information for Controls

ModerateHigh

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [Organization-defined: sa-04.02_odp.01] at [Organization-defined: level of detail].

Official discussion

Organizations may require different levels of detail in the documentation for the design and implementation of controls in organizational systems, system components, or system services based on mission and business requirements, requirements for resiliency and trustworthiness, and requirements for analysis and testing. Systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules and the interfaces between modules providing security-relevant functionality. Design and implementation documentation can include manufacturer, version, serial number, verification hash signature, software libraries used, date of purchase or download, and the vendor or download source. Source code and hardware schematics are referred to as the implementation representation of the system.

Organization-defined parameters (3)
sa-04.02_odp.01
design and implementation informationdesign and implementation information is defined (if selected);
level of detaillevel of detail is defined;
Assessment objectives and methods

the developer of the system, system component, or system service is required to provide design and implementation information for the controls that includes using [Organization-defined: sa-04.02_odp.01] at [Organization-defined: level of detail].

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system components, or system services
  • design and implementation information for controls employed in the system, system component, or system service
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility to determine system security requirements
  • system developers or service provider
  • organizational personnel with information security responsibilities

Test

  • Organizational processes for determining the level of detail for system design and controls
  • organizational processes for developing acquisition contracts
  • mechanisms supporting and/or implementing the development of system design details
Official NIST control enhancement

SA-4(3) — Development Methods, Techniques, and Practices

Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:

  1. (a)[Organization-defined: systems engineering methods];
  2. (b)[Organization-defined: sa-04.03_odp.02] ; and
  3. (c)[Organization-defined: sa-04.03_odp.05].
Official discussion

Following a system development life cycle that includes state-of-the-practice software development methods, systems engineering methods, systems security and privacy engineering methods, and quality control processes helps to reduce the number and severity of latent errors within systems, system components, and system services. Reducing the number and severity of such errors reduces the number of vulnerabilities in those systems, components, and services. Transparency in the methods and techniques that developers select and implement for systems engineering, systems security and privacy engineering, software development, component and system assessments, and quality control processes provides an increased level of assurance in the trustworthiness of the system, system component, or system service being acquired.

Organization-defined parameters (8)
systems engineering methodssystems engineering methods are defined;
sa-04.03_odp.02
system security engineering methodssystem security engineering methods are defined (if selected);
privacy engineering methodsprivacy engineering methods are defined (if selected);
sa-04.03_odp.05
software development methodssoftware development methods are defined (if selected);
testing, evaluation, assessment, verification, and validation methodstesting, evaluation, assessment, verification, and validation methods are defined (if selected);
quality control processesquality control processes are defined (if selected);
Assessment objectives and methods
  1. SA-04(03)(a)the developer of the system, system component, or system service is required to demonstrate the use of a system development life cycle process that includes [Organization-defined: systems engineering methods];
  2. SA-04(03)(b)the developer of the system, system component, or system service is required to demonstrate the use of a system development life cycle process that includes [Organization-defined: sa-04.03_odp.02];
  3. SA-04(03)(c)the developer of the system, system component, or system service is required to demonstrate the use of a system development life cycle process that includes [Organization-defined: sa-04.03_odp.05].

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • procedures addressing the integration of security and privacy requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • list of systems security and privacy engineering methods to be included in the developer’s system development life cycle process
  • list of software development methods to be included in the developer’s system development life cycle process
  • list of testing, evaluation, or validation techniques to be included in the developer’s system development life cycle process
  • list of quality control processes to be included in the developer’s system development life cycle process
  • system security plan
  • privacy plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with information security and privacy responsibilities
  • organizational personnel with system life cycle responsibilities
  • system developers or service provider

Test

  • Organizational processes for development methods, techniques, and processes
Official NIST control enhancement

SA-4(4) — Assignment of Components to Systems

Withdrawn

This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.

Official NIST control enhancement

SA-4(5) — System, Component, and Service Configurations

High

Require the developer of the system, system component, or system service to:

  1. (a)Deliver the system, component, or service with [Organization-defined: security configurations] implemented; and
  2. (b)Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.
Official discussion

Examples of security configurations include the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), and any limitations on functions, ports, protocols, and services. Security characteristics can include requiring that default passwords have been changed.

Organization-defined parameters (1)
security configurationssecurity configurations for the system, component, or service are defined;
Assessment objectives and methods
  1. SA-04(05)(a)the developer of the system, system component, or system service is required to deliver the system, component, or service with [Organization-defined: security configurations] implemented;
  2. SA-04(05)(b)the configurations are used as the default for any subsequent system, component, or service reinstallation or upgrade.

Examine

  • System and services acquisition policy
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • security configurations to be implemented by the developer of the system, system component, or system service
  • service level agreements
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility to determine system security requirements
  • system developers or service provider
  • organizational personnel with information security responsibilities

Test

  • Mechanisms used to verify that the configuration of the system, component, or service is delivered as specified
Official NIST control enhancement

SA-4(6) — Use of Information Assurance Products

  1. (a)Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and
  2. (b)Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.
Official discussion

Commercial off-the-shelf IA or IA-enabled information technology products used to protect classified information by cryptographic means may be required to use NSA-approved key management. See [NSA CSFC](#3d575737-98cb-459d-b41c-d7e82b73ad78).

Assessment objectives and methods
  1. SA-04(06)(a)only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted are employed;
  2. SA-04(06)(b)these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.

Examine

  • Supply chain risk management plan
  • system and services acquisition policy
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • security configurations to be implemented by the developer of the system, system component, or system service
  • service level agreements
  • list of deployed IT products/solutions
  • NSA-approved list
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility to determine system security requirements
  • organizational personnel responsible for ensuring information assurance products are NSA-approved and are evaluated and/or validated products in accordance with NSA-approved procedures
  • organizational personnel with information security responsibilities

Test

  • Organizational processes for selecting and employing evaluated and/or validated information assurance products and services that compose an NSA-approved solution to protect classified information
Related controls
SC-8SC-12SC-13
Official NIST control enhancement

SA-4(7) — NIAP-approved Protection Profiles

  1. (a)Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and
  2. (b)Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved.
Official discussion

See [NIAP CCEVS](#795aff72-3e6c-4b6b-a80a-b14d84b7f544) for additional information on NIAP. See [NIST CMVP](#1acdc775-aafb-4d11-9341-dc6a822e9d38) for additional information on FIPS-validated cryptographic modules.

Assessment objectives and methods
  1. SA-04(07)(a)the use of commercially provided information assurance and information assurance-enabled information technology products is limited to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists;
  2. SA-04(07)(b)if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that cryptographic module is required to be FIPS-validated or NSA-approved.

Examine

  • Supply chain risk management plan
  • system and services acquisition policy
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • solicitation documents
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • list of deployed IT products/solutions
  • NAIP-approved protection profiles
  • FIPS-validation information for cryptographic functionality
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility for determining system security requirements
  • organizational personnel responsible for ensuring that information assurance products have been evaluated against a NIAP-approved protection profile or for ensuring products relying on cryptographic functionality are FIPS-validated
  • organizational personnel with information security responsibilities

Test

  • Organizational processes for selecting and employing products/services evaluated against a NIAP-approved protection profile or FIPS-validated products
Related controls
IA-7SC-12SC-13
Official NIST control enhancement

SA-4(8) — Continuous Monitoring Plan for Controls

Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.

Official discussion

The objective of continuous monitoring plans is to determine if the planned, required, and deployed controls within the system, system component, or system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into continuous monitoring programs implemented by organizations. Continuous monitoring plans can include the types of control assessment and monitoring activities planned, frequency of control monitoring, and actions to be taken when controls fail or become ineffective.

Assessment objectives and methods

the developer of the system, system component, or system service is required to produce a plan for the continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.

Examine

  • System and services acquisition policy
  • procedures addressing developer continuous monitoring plans
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • developer continuous monitoring plans
  • security assessment plans
  • acquisition contracts for the system, system component, or system service
  • acquisition documentation
  • solicitation documentation
  • service level agreements
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility for determining system security requirements
  • system developers
  • organizational personnel with information security responsibilities

Test

  • Vendor processes for continuous monitoring
  • mechanisms supporting and/or implementing developer continuous monitoring
Related controls
CA-7
Official NIST control enhancement

SA-4(9) — Functions, Ports, Protocols, and Services in Use

ModerateHigh

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.

Official discussion

The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design stages) allows organizations to influence the design of the system, system component, or system service. This early involvement in the system development life cycle helps organizations avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services or requiring system service providers to do so. Early identification of functions, ports, protocols, and services avoids costly retrofitting of controls after the system, component, or system service has been implemented. [SA-9](#sa-9) describes the requirements for external system services. Organizations identify which functions, ports, protocols, and services are provided from external sources.

Assessment objectives and methods
  1. SA-04(09)[01]the developer of the system, system component, or system service is required to identify the functions intended for organizational use;
  2. SA-04(09)[02]the developer of the system, system component, or system service is required to identify the ports intended for organizational use;
  3. SA-04(09)[03]the developer of the system, system component, or system service is required to identify the protocols intended for organizational use;
  4. SA-04(09)[04]the developer of the system, system component, or system service is required to identify the services intended for organizational use.

Examine

  • System and services acquisition policy
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • system design documentation
  • system documentation, including functions, ports, protocols, and services intended for organizational use
  • acquisition contracts for systems or services
  • acquisition documentation
  • solicitation documentation
  • service level agreements
  • organizational security requirements, descriptions, and criteria for developers of systems, system components, and system services
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility for determining system security requirements
  • system/network administrators
  • organizational personnel operating, using, and/or maintaining the system
  • system developers
  • organizational personnel with information security responsibilities
Related controls
CM-7SA-9
Official NIST control enhancement

SA-4(10) — Use of Approved PIV Products

LowModerateHigh

Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.

Official discussion

Products on the FIPS 201-approved products list meet NIST requirements for Personal Identity Verification (PIV) of Federal Employees and Contractors. PIV cards are used for multi-factor authentication in systems and organizations.

Assessment objectives and methods

only information technology products on the FIPS 201-approved products list for the Personal Identity Verification (PIV) capability implemented within organizational systems are employed.

Examine

  • Supply chain risk management plan
  • system and services acquisition policy
  • procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
  • solicitation documentation
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • service level agreements
  • FIPS 201 approved products list
  • system security plan
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility for determining system security requirements
  • organizational personnel with the responsibility for ensuring that only FIPS 201- approved products are implemented
  • organizational personnel with information security responsibilities

Test

  • Organizational processes for selecting and employing FIPS 201-approved products
Related controls
IA-2IA-8PM-9
Official NIST control enhancement

SA-4(11) — System of Records

Include [Organization-defined: Privacy Act requirements] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.

Official discussion

When, by contract, an organization provides for the operation of a system of records to accomplish an organizational mission or function, the organization, consistent with its authority, causes the requirements of the [PRIVACT](#18e71fec-c6fd-475a-925a-5d8495cf8455) to be applied to the system of records.

Organization-defined parameters (1)
Privacy Act requirementsPrivacy Act requirements for the operation of a system of records are defined;
Assessment objectives and methods

[Organization-defined: Privacy Act requirements] are defined in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • procedures addressing the integration of Privacy Act requirements into systems of records operated by external organizations
  • solicitation documentation
  • acquisition documentation
  • acquisition contracts for the system, system component, or system service
  • service level agreements
  • system security plan
  • privacy plan
  • personally identifiable information processing policy
  • privacy program plan
  • privacy impact assessment
  • privacy risk assessment documentation
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition responsibilities
  • organizational personnel with information security and privacy responsibilities

Test

  • Contract management processes to verify Privacy Act requirements are defined for the operation of a system of records
  • vendor processes for demonstrating incorporation of Privacy Act requirements in its operation of a system of records
Related controls
PT-6
Official NIST control enhancement

SA-4(12) — Data Ownership

  1. (a)Include organizational data ownership requirements in the acquisition contract; and
  2. (b)Require all data to be removed from the contractor’s system and returned to the organization within [Organization-defined: time frame].
Official discussion

Contractors who operate a system that contains data owned by an organization initiating the contract have policies and procedures in place to remove the data from their systems and/or return the data in a time frame defined by the contract.

Organization-defined parameters (1)
time frametime frame to remove data from a contractor system and return it to the organization is defined;
Assessment objectives and methods
  1. SA-04(12)(a)organizational data ownership requirements are included in the acquisition contract;
  2. SA-04(12)(b)all data to be removed from the contractor’s system and returned to the organization is required within [Organization-defined: time frame].

Examine

  • System and services acquisition policy
  • system and services acquisition procedures
  • procedures addressing the integration of information security and privacy requirements, descriptions, and criteria into the acquisition process
  • procedures addressing the disposition of personally identifiable information
  • solicitation documentation
  • acquisition documentation
  • acquisition contracts for the system or system service
  • personally identifiable information processing policy
  • service level agreements
  • information sharing agreements
  • memoranda of understanding
  • system security plan
  • privacy plan
  • privacy impact assessment
  • privacy risk assessment documentation
  • other relevant documents or records

Interview

  • Organizational personnel with acquisition/contracting responsibilities
  • organizational personnel with the responsibility for data management and processing requirements
  • organizational personnel with information security and privacy responsibilities

Test

  • Contract management processes to verify that data is removed as required
  • vendor processes for removing data in required timeframe
  • mechanisms verifying the removal and return of data
Source record

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.