Browse 1,193 controls and enhancements across 20 security and privacy families. Use the GovRAMP crosswalk to locate controls referenced by Security Snapshot, Core, and Moderate.
A shared catalog supports common-control planning; designation as a common, hybrid, or system-specific control depends on your organization’s implementation and inheritance decisions.
Sources and crosswalk scope
NIST OSCAL content 5.1.1+u4, retrieved 2026-09-18. GovRAMP Snapshot v1.4 and Core selection from Moderate v1.06 reference the December 2020 Rev. 5 text. Mappings establish exact identifier correspondence, not identical requirements, inherited implementation, or GovRAMP authorization. GovRAMP parameters and additional requirements remain authoritative for each program. Full Moderate, High, and other programs are not mapped here. Withdrawn controls are retained for reference.
Official pinned NIST sourceSHA-256: 81cf2de45ede9aef3de7ce09d65ea9d32f662c483bbf916f6e346292b22f7763
Risk Assessment · Enhancement
RA-5(2) · Update Vulnerabilities to Be Scanned
View parent controlControl statement and discussion
NIST control statement
Update the system vulnerabilities to be scanned [Selection (one-or-more): [Assignment: frequency] ; prior to a new scan; when new vulnerabilities are identified and reported].
Discussion
Due to the complexity of modern software, systems, and other factors, new vulnerabilities are discovered on a regular basis. It is important that newly discovered vulnerabilities are added to the list of vulnerabilities to be scanned to ensure that the organization can take steps to mitigate those vulnerabilities in a timely manner.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · RA-5 (2) — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Enhancement
RA-5(3) · Breadth and Depth of Coverage
View parent controlControl statement and discussion
NIST control statement
Define the breadth and depth of vulnerability scanning coverage.
Discussion
The breadth of vulnerability scanning coverage can be expressed as a percentage of components within the system, by the particular types of systems, by the criticality of systems, or by the number of vulnerabilities to be checked. Conversely, the depth of vulnerability scanning coverage can be expressed as the level of the system design that the organization intends to monitor (e.g., component, module, subsystem, element). Organizations can determine the sufficiency of vulnerability scanning coverage with regard to its risk tolerance and other factors. Scanning tools and how the tools are configured may affect the depth and coverage. Multiple scanning tools may be needed to achieve the desired depth and coverage. [SP 800-53A](#a21aef46-7330-48a0-b2e1-c5bb8b2dd11d) provides additional information on the breadth and depth of coverage.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · RA-5 (3) — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Enhancement
RA-5(4) · Discoverable Information
View parent controlControl statement and discussion
NIST control statement
Determine information about the system that is discoverable and take [Assignment: corrective actions].
Discussion
Discoverable information includes information that adversaries could obtain without compromising or breaching the system, such as by collecting information that the system is exposing or by conducting extensive web searches. Corrective actions include notifying appropriate organizational personnel, removing designated information, or changing the system to make the designated information less relevant or attractive to adversaries. This enhancement excludes intentionally discoverable information that may be part of a decoy capability (e.g., honeypots, honeynets, or deception nets) deployed by the organization.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Enhancement
RA-5(5) · Privileged Access
View parent controlControl statement and discussion
NIST control statement
Implement privileged access authorization to [Assignment: system components] for [Assignment: vulnerability scanning activities].
Discussion
In certain situations, the nature of the vulnerability scanning may be more intrusive, or the system component that is the subject of the scanning may contain classified or controlled unclassified information, such as personally identifiable information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.
GovRAMP crosswalk
- GovRAMP Security Snapshot Readiness · RA-5 (5) — Direct NIST identifier reference. GovRAMP source matrix
- GovRAMP Core Readiness — 60 Controls · RA-5 (5) — Direct NIST identifier reference. GovRAMP source matrix
- GovRAMP Moderate Readiness · RA-5 (5) — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Enhancement
RA-5(6) · Automated Trend Analyses
View parent controlControl statement and discussion
NIST control statement
Compare the results of multiple vulnerability scans using [Assignment: automated mechanisms].
Discussion
Using automated mechanisms to analyze multiple vulnerability scans over time can help determine trends in system vulnerabilities and identify patterns of attack.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Enhancement
RA-5(8) · Review Historic Audit Logs
View parent controlControl statement and discussion
NIST control statement
Review historic audit logs to determine if a vulnerability identified in a [Assignment: system] has been previously exploited within an [Assignment: time period].
Discussion
Reviewing historic audit logs to determine if a recently detected vulnerability in a system has been previously exploited by an adversary can provide important information for forensic analyses. Such analyses can help identify, for example, the extent of a previous intrusion, the trade craft employed during the attack, organizational information exfiltrated or modified, mission or business capabilities affected, and the duration of the attack.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Enhancement
RA-5(10) · Correlate Scanning Information
View parent controlControl statement and discussion
NIST control statement
Correlate the output from vulnerability scanning tools to determine the presence of multi-vulnerability and multi-hop attack vectors.
Discussion
An attack vector is a path or means by which an adversary can gain access to a system in order to deliver malicious code or exfiltrate information. Organizations can use attack trees to show how hostile activities by adversaries interact and combine to produce adverse impacts or negative consequences to systems and organizations. Such information, together with correlated data from vulnerability scanning tools, can provide greater clarity regarding multi-vulnerability and multi-hop attack vectors. The correlation of vulnerability scanning information is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols). During such transitions, some system components may inadvertently be unmanaged and create opportunities for adversary exploitation.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Enhancement
RA-5(11) · Public Disclosure Program
View parent controlControl statement and discussion
NIST control statement
Establish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.
Discussion
The reporting channel is publicly discoverable and contains clear language authorizing good-faith research and the disclosure of vulnerabilities to the organization. The organization does not condition its authorization on an expectation of indefinite non-disclosure to the public by the reporting entity but may request a specific time period to properly remediate the vulnerability.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · RA-5 (11) — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Base control
RA-6 · Technical Surveillance Countermeasures Survey
Control statement and discussion
NIST control statement
Employ a technical surveillance countermeasures survey at [Assignment: locations] [Selection (one-or-more): [Assignment: frequency] ; when [Assignment: events or indicators] ].
Discussion
A technical surveillance countermeasures survey is a service provided by qualified personnel to detect the presence of technical surveillance devices and hazards and to identify technical security weaknesses that could be used in the conduct of a technical penetration of the surveyed facility. Technical surveillance countermeasures surveys also provide evaluations of the technical security posture of organizations and facilities and include visual, electronic, and physical examinations of surveyed facilities, internally and externally. The surveys also provide useful input for risk assessments and information regarding organizational exposure to potential adversaries.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Base control
RA-7 · Risk Response
Control statement and discussion
NIST control statement
Respond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.
Discussion
Organizations have many options for responding to risk including mitigating risk by implementing new controls or strengthening existing controls, accepting risk with appropriate justification or rationale, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. Risk response addresses the need to determine an appropriate response to risk before generating a plan of action and milestones entry. For example, the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately so that a plan of action and milestones entry is not needed. However, if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · RA-7 — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Base control
RA-8 · Privacy Impact Assessments
Control statement and discussion
NIST control statement
Conduct privacy impact assessments for systems, programs, or other activities before:
a. Developing or procuring information technology that processes personally identifiable information; and
b. Initiating a new collection of personally identifiable information that:
1. Will be processed using information technology; and
2. Includes personally identifiable information permitting the physical or virtual (online) contacting of a specific individual, if identical questions have been posed to, or identical reporting requirements imposed on, ten or more individuals, other than agencies, instrumentalities, or employees of the federal government.
Discussion
A privacy impact assessment is an analysis of how personally identifiable information is handled to ensure that handling conforms to applicable privacy requirements, determine the privacy risks associated with an information system or activity, and evaluate ways to mitigate privacy risks. A privacy impact assessment is both an analysis and a formal document that details the process and the outcome of the analysis.
Organizations conduct and develop a privacy impact assessment with sufficient clarity and specificity to demonstrate that the organization fully considered privacy and incorporated appropriate privacy protections from the earliest stages of the organization’s activity and throughout the information life cycle. In order to conduct a meaningful privacy impact assessment, the organization’s senior agency official for privacy works closely with program managers, system owners, information technology experts, security officials, counsel, and other relevant organization personnel. Moreover, a privacy impact assessment is not a time-restricted activity that is limited to a particular milestone or stage of the information system or personally identifiable information life cycles. Rather, the privacy analysis continues throughout the system and personally identifiable information life cycles. Accordingly, a privacy impact assessment is a living document that organizations update whenever changes to the information technology, changes to the organization’s practices, or other factors alter the privacy risks associated with the use of such information technology.
To conduct the privacy impact assessment, organizations can use security and privacy risk assessments. Organizations may also use other related processes that may have different names, including privacy threshold analyses. A privacy impact assessment can also serve as notice to the public regarding the organization’s practices with respect to privacy. Although conducting and publishing privacy impact assessments may be required by law, organizations may develop such policies in the absence of applicable laws. For federal agencies, privacy impact assessments may be required by [EGOV](#7b0b9634-741a-4335-b6fa-161228c3a76e) ; agencies should consult with their senior agency official for privacy and legal counsel on this requirement and be aware of the statutory exceptions and OMB guidance relating to the provision.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
Risk Assessment · Base control
RA-9 · Criticality Analysis
Control statement and discussion
NIST control statement
Identify critical system components and functions by performing a criticality analysis for [Assignment: systems, system components, or system services] at [Assignment: decision points in the system development life cycle].
Discussion
Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and external to the system.
The operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.
Criticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in [RA-2](#ra-2).
GovRAMP crosswalk
- GovRAMP Moderate Readiness · RA-9 — Direct NIST identifier reference. GovRAMP source matrix
Risk Assessment · Base control
RA-10 · Threat Hunting
Control statement and discussion
NIST control statement
a. Establish and maintain a cyber threat hunting capability to:
1. Search for indicators of compromise in organizational systems; and
2. Detect, track, and disrupt threats that evade existing controls; and
b. Employ the threat hunting capability [Assignment: frequency].
Discussion
Threat hunting is an active means of cyber defense in contrast to traditional protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and Security Information and Event Management technologies and systems. Cyber threat hunting involves proactively searching organizational systems, networks, and infrastructure for advanced threats. The objective is to track and disrupt cyber adversaries as early as possible in the attack sequence and to measurably improve the speed and accuracy of organizational responses. Indications of compromise include unusual network traffic, unusual file changes, and the presence of malicious code. Threat hunting teams leverage existing threat intelligence and may create new threat intelligence, which is shared with peer organizations, Information Sharing and Analysis Organizations (ISAO), Information Sharing and Analysis Centers (ISAC), and relevant government departments and agencies.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-1 · Policy and Procedures
Control statement and discussion
NIST control statement
a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (one-or-more): organization-level; mission/business process-level; system-level] system and services acquisition policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;
b. Designate an [Assignment: official] to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and
c. Review and update the current system and services acquisition:
1. Policy [Assignment: frequency] and following [Assignment: events] ; and
2. Procedures [Assignment: frequency] and following [Assignment: events].
Discussion
System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-1 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Base control
SA-2 · Allocation of Resources
Control statement and discussion
NIST control statement
a. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
b. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
c. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.
Discussion
Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-2 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Base control
SA-3 · System Development Life Cycle
Control statement and discussion
NIST control statement
a. Acquire, develop, and manage the system using [Assignment: 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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-3 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-3(1) · Manage Preproduction Environment
View parent controlControl statement and discussion
NIST control statement
Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service.
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-3(2) · Use of Live or Operational Data
View parent controlControl statement and discussion
NIST control statement
(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
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-3(3) · Technology Refresh
View parent controlControl statement and discussion
NIST control statement
Plan for and implement a technology refresh schedule for the system throughout the system development life cycle.
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-4 · Acquisition Process
Control statement and discussion
NIST control statement
Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection (one-or-more): standardized contract language; [Assignment: contract language] ] in the acquisition contract for the system, system component, or system service:
a. Security and privacy functional requirements;
b. Strength of mechanism requirements;
c. Security and privacy assurance requirements;
d. Controls needed to satisfy the security and privacy requirements.
e. Security and privacy documentation requirements;
f. Requirements for protecting security and privacy documentation;
g. Description of the system development environment and environment in which the system is intended to operate;
h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
i. Acceptance criteria.
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-4 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-4(1) · Functional Properties of Controls
View parent controlControl statement and discussion
NIST control statement
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.
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-4 (1) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-4(2) · Design and Implementation Information for Controls
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [Selection (one-or-more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: design and implementation information] ] at [Assignment: level of detail].
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-4 (2) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-4(3) · Development Methods, Techniques, and Practices
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:
(a) [Assignment: systems engineering methods];
(b) [Selection (one-or-more): [Assignment: system security engineering methods] ; [Assignment: privacy engineering methods] ] ; and
(c) [Selection (one-or-more): [Assignment: software development methods] ; [Assignment: testing, evaluation, assessment, verification, and validation methods] ; [Assignment: quality control processes] ].
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-4(5) · System, Component, and Service Configurations
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Deliver the system, component, or service with [Assignment: security configurations] implemented; and
(b) Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-4(6) · Use of Information Assurance Products
View parent controlControl statement and discussion
NIST control statement
(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
(b) Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.
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).
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
