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
System and Services Acquisition · Base control
SA-10 · Developer Configuration Management
Control statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
a. Perform configuration management during system, component, or service [Selection (one-or-more): design; development; implementation; operation; disposal];
b. Document, manage, and control the integrity of changes to [Assignment: configuration items];
c. Implement only organization-approved changes to the system, component, or service;
d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and
e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: personnel].
Discussion
Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.
The configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-10 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-10(1) · Software and Firmware Integrity Verification
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components.
Discussion
Software and firmware integrity verification allows organizations to detect unauthorized changes to software and firmware components using developer-provided tools, techniques, and mechanisms. The integrity checking mechanisms can also address counterfeiting of software and firmware components. Organizations verify the integrity of software and firmware components, for example, through secure one-way hashes provided by developers. Delivered software and firmware components also include any updates to such components.
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-10(2) · Alternative Configuration Management Processes
View parent controlControl statement and discussion
NIST control statement
Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team.
Discussion
Alternate configuration management processes may be required when organizations use commercial off-the-shelf information technology products. Alternate configuration management processes include organizational personnel who review and approve proposed changes to systems, system components, and system services and conduct security and privacy impact analyses prior to the implementation of changes to systems, components, or services.
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-10(3) · Hardware Integrity Verification
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to enable integrity verification of hardware components.
Discussion
Hardware integrity verification allows organizations to detect unauthorized changes to hardware components using developer-provided tools, techniques, methods, and mechanisms. Organizations may verify the integrity of hardware components with hard-to-copy labels, verifiable serial numbers provided by developers, and by requiring the use of anti-tamper technologies. Delivered hardware components also include hardware and firmware updates to such components.
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-10(4) · Trusted Generation
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to employ tools for comparing newly generated versions of security-relevant hardware descriptions, source code, and object code with previous versions.
Discussion
The trusted generation of descriptions, source code, and object code addresses authorized changes to hardware, software, and firmware components between versions during development. The focus is on the efficacy of the configuration management process by the developer to ensure that newly generated versions of security-relevant hardware descriptions, source code, and object code continue to enforce the security policy for the system, system component, or system service. In contrast, [SA-10(1)](#sa-10.1) and [SA-10(3)](#sa-10.3) allow organizations to detect unauthorized changes to hardware, software, and firmware components using tools, techniques, or mechanisms provided by developers.
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-10(5) · Mapping Integrity for Version Control
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to maintain the integrity of the mapping between the master build data describing the current version of security-relevant hardware, software, and firmware and the on-site master copy of the data for the current version.
Discussion
Mapping integrity for version control addresses changes to hardware, software, and firmware components during both initial development and system development life cycle updates. Maintaining the integrity between the master copies of security-relevant hardware, software, and firmware (including designs, hardware drawings, source code) and the equivalent data in master copies in operational environments is essential to ensuring the availability of organizational systems that support critical mission and business functions.
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-10(6) · Trusted Distribution
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to execute procedures for ensuring that security-relevant hardware, software, and firmware updates distributed to the organization are exactly as specified by the master copies.
Discussion
The trusted distribution of security-relevant hardware, software, and firmware updates help to ensure that the updates are correct representations of the master copies maintained by the developer and have not been tampered with during distribution.
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-10(7) · Security and Privacy Representatives
View parent controlControl statement and discussion
NIST control statement
Require [Assignment: organization-defined security and privacy representatives] to be included in the [Assignment: organization-defined configuration change management and control process].
Discussion
Information security and privacy representatives can include system security officers, senior agency information security officers, senior agency officials for privacy, and system privacy officers. Representation by personnel with information security and privacy expertise is important because changes to system configurations can have unintended side effects, some of which may be security- or privacy-relevant. Detecting such changes early in the process can help avoid unintended, negative consequences that could ultimately affect the security and privacy posture of systems. The configuration change management and control process in this control enhancement refers to the change management and control process defined by organizations in [SA-10b](#sa-10_smt.b).
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-11 · Developer Testing and Evaluation
Control statement and discussion
NIST control statement
Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:
a. Develop and implement a plan for ongoing security and privacy control assessments;
b. Perform [Selection (one-or-more): unit; integration; system; regression] testing/evaluation [Assignment: frequency to conduct] at [Assignment: depth and coverage];
c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
d. Implement a verifiable flaw remediation process; and
e. Correct flaws identified during testing and evaluation.
Discussion
Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes—including upgrading or replacing applications, operating systems, and firmware—may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches.
Developers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation.
GovRAMP crosswalk
- GovRAMP Core Readiness — 60 Controls · SA-11 — Direct NIST identifier reference. GovRAMP source matrix
- GovRAMP Moderate Readiness · SA-11 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-11(1) · Static Code Analysis
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.
Discussion
Static code analysis provides a technology and methodology for security reviews and includes checking for weaknesses in the code as well as for the incorporation of libraries or other included code with known vulnerabilities or that are out-of-date and not supported. Static code analysis can be used to identify vulnerabilities and enforce secure coding practices. It is most effective when used early in the development process, when each code change can automatically be scanned for potential weaknesses. Static code analysis can provide clear remediation guidance and identify defects for developers to fix. Evidence of the correct implementation of static analysis can include aggregate defect density for critical defect types, evidence that defects were inspected by developers or security professionals, and evidence that defects were remediated. A high density of ignored findings, commonly referred to as false positives, indicates a potential problem with the analysis process or the analysis tool. In such cases, organizations weigh the validity of the evidence against evidence from other sources.
GovRAMP crosswalk
- GovRAMP Core Readiness — 60 Controls · SA-11 (1) — Direct NIST identifier reference. GovRAMP source matrix
- GovRAMP Moderate Readiness · SA-11 (1) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-11(2) · Threat Modeling and Vulnerability Analyses
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that:
(a) Uses the following contextual information: [Assignment: information];
(b) Employs the following tools and methods: [Assignment: tools and methods];
(c) Conducts the modeling and analyses at the following level of rigor: [Assignment: organization-defined breadth and depth of modeling and analyses] ; and
(d) Produces evidence that meets the following acceptance criteria: [Assignment: organization-defined acceptance criteria].
Discussion
Systems, system components, and system services may deviate significantly from the functional and design specifications created during the requirements and design stages of the system development life cycle. Therefore, updates to threat modeling and vulnerability analyses of those systems, system components, and system services during development and prior to delivery are critical to the effective operation of those systems, components, and services. Threat modeling and vulnerability analyses at this stage of the system development life cycle ensure that design and implementation changes have been accounted for and that vulnerabilities created because of those changes have been reviewed and mitigated.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-11 (2) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-11(3) · Independent Verification of Assessment Plans and Evidence
View parent controlControl statement and discussion
NIST control statement
(a) Require an independent agent satisfying [Assignment: independence criteria] to verify the correct implementation of the developer security and privacy assessment plans and the evidence produced during testing and evaluation; and
(b) Verify that the independent agent is provided with sufficient information to complete the verification process or granted the authority to obtain such information.
Discussion
Independent agents have the qualifications—including the expertise, skills, training, certifications, and experience—to verify the correct implementation of developer security and privacy assessment plans.
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-11(4) · Manual Code Reviews
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to perform a manual code review of [Assignment: specific code] using the following processes, procedures, and/or techniques: [Assignment: processes, procedures, and/or techniques].
Discussion
Manual code reviews are usually reserved for the critical software and firmware components of systems. Manual code reviews are effective at identifying weaknesses that require knowledge of the application’s requirements or context that, in most cases, is unavailable to automated analytic tools and techniques, such as static and dynamic analysis. The benefits of manual code review include the ability to verify access control matrices against application controls and review detailed aspects of cryptographic implementations and controls.
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-11(5) · Penetration Testing
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to perform penetration testing:
(a) At the following level of rigor: [Assignment: organization-defined breadth and depth of testing] ; and
(b) Under the following constraints: [Assignment: constraints].
Discussion
Penetration testing is an assessment methodology in which assessors, using all available information technology product or system documentation and working under specific constraints, attempt to circumvent the implemented security and privacy features of information technology products and systems. Useful information for assessors who conduct penetration testing includes product and system design specifications, source code, and administrator and operator manuals. Penetration testing can include white-box, gray-box, or black-box testing with analyses performed by skilled professionals who simulate adversary actions. The objective of penetration testing is to discover vulnerabilities in systems, system components, and services that result from implementation errors, configuration faults, or other operational weaknesses or deficiencies. Penetration tests can be performed in conjunction with automated and manual code reviews to provide a greater level of analysis than would ordinarily be possible. When user session information and other personally identifiable information is captured or recorded during penetration testing, such information is handled appropriately to protect privacy.
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-11(6) · Attack Surface Reviews
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to perform attack surface reviews.
Discussion
Attack surfaces of systems and system components are exposed areas that make those systems more vulnerable to attacks. Attack surfaces include any accessible areas where weaknesses or deficiencies in the hardware, software, and firmware components provide opportunities for adversaries to exploit vulnerabilities. Attack surface reviews ensure that developers analyze the design and implementation changes to systems and mitigate attack vectors generated as a result of the changes. The correction of identified flaws includes deprecation of unsafe functions.
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-11(7) · Verify Scope of Testing and Evaluation
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to verify that the scope of testing and evaluation provides complete coverage of the required controls at the following level of rigor: [Assignment: organization-defined breadth and depth of testing and evaluation].
Discussion
Verifying that testing and evaluation provides complete coverage of required controls can be accomplished by a variety of analytic techniques ranging from informal to formal. Each of these techniques provides an increasing level of assurance that corresponds to the degree of formality of the analysis. Rigorously demonstrating control coverage at the highest levels of assurance can be achieved using formal modeling and analysis techniques, including correlation between control implementation and corresponding test cases.
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-11(8) · Dynamic Code Analysis
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.
Discussion
Dynamic code analysis provides runtime verification of software programs using tools capable of monitoring programs for memory corruption, user privilege issues, and other potential security problems. Dynamic code analysis employs runtime tools to ensure that security functionality performs in the way it was designed. A type of dynamic analysis, known as fuzz testing, induces program failures by deliberately introducing malformed or random data into software programs. Fuzz testing strategies are derived from the intended use of applications and the functional and design specifications for the applications. To understand the scope of dynamic code analysis and the assurance provided, organizations may also consider conducting code coverage analysis (i.e., checking the degree to which the code has been tested using metrics such as percent of subroutines tested or percent of program statements called during execution of the test suite) and/or concordance analysis (i.e., checking for words that are out of place in software code, such as non-English language words or derogatory terms).
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-11(9) · Interactive Application Security Testing
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to employ interactive application security testing tools to identify flaws and document the results.
Discussion
Interactive (also known as instrumentation-based) application security testing is a method of detecting vulnerabilities by observing applications as they run during testing. The use of instrumentation relies on direct measurements of the actual running applications and uses access to the code, user interaction, libraries, frameworks, backend connections, and configurations to directly measure control effectiveness. When combined with analysis techniques, interactive application security testing can identify a broad range of potential vulnerabilities and confirm control effectiveness. Instrumentation-based testing works in real time and can be used continuously throughout 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-15 · Development Process, Standards, and Tools
Control statement and discussion
NIST control statement
a. Require the developer of the system, system component, or system service to follow a documented development process that:
1. Explicitly addresses security and privacy requirements;
2. Identifies the standards and tools used in the development process;
3. Documents the specific tool options and tool configurations used in the development process; and
4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and
b. Review the development process, standards, tools, tool options, and tool configurations [Assignment: frequency] to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: [Assignment: organization-defined security and privacy requirements].
Discussion
Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-15 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-15(1) · Quality Metrics
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Define quality metrics at the beginning of the development process; and
(b) Provide evidence of meeting the quality metrics [Selection (one-or-more): [Assignment: frequency] ; [Assignment: program review] ; upon delivery].
Discussion
Organizations use quality metrics to establish acceptable levels of system quality. Metrics can include quality gates, which are collections of completion criteria or sufficiency standards that represent the satisfactory execution of specific phases of the system development project. For example, a quality gate may require the elimination of all compiler warnings or a determination that such warnings have no impact on the effectiveness of required security or privacy capabilities. During the execution phases of development projects, quality gates provide clear, unambiguous indications of progress. Other metrics apply to the entire development project. Metrics can include defining the severity thresholds of vulnerabilities in accordance with organizational risk tolerance, such as requiring no known vulnerabilities in the delivered system with a Common Vulnerability Scoring System (CVSS) severity of medium or high.
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-15(2) · Security and Privacy Tracking Tools
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to select and employ security and privacy tracking tools for use during the development process.
Discussion
System development teams select and deploy security and privacy tracking tools, including vulnerability or work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with development processes.
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-15(3) · Criticality Analysis
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to perform a criticality analysis:
(a) At the following decision points in the system development life cycle: [Assignment: decision points] ; and
(b) At the following level of rigor: [Assignment: organization-defined breadth and depth of criticality analysis].
Discussion
Criticality analysis performed by the developer provides input to the criticality analysis performed by organizations. Developer input is essential to organizational criticality analysis because organizations may not have access to detailed design documentation for system components that are developed as commercial off-the-shelf products. Such design documentation includes functional specifications, high-level designs, low-level designs, source code, and hardware schematics. Criticality analysis is important for organizational systems that are designated as high value assets. High value assets can be moderate- or high-impact systems due to heightened adversarial interest or potential adverse effects on the federal enterprise. Developer input is especially important when organizations conduct supply chain criticality analyses.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-15 (3) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-15(5) · Attack Surface Reduction
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to reduce attack surfaces to [Assignment: thresholds].
Discussion
Attack surface reduction is closely aligned with threat and vulnerability analyses and system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within systems, system components, and system services. Attack surface reduction includes implementing the concept of layered defenses, applying the principles of least privilege and least functionality, applying secure software development practices, deprecating unsafe functions, reducing entry points available to unauthorized users, reducing the amount of code that executes, and eliminating application programming interfaces (APIs) that are vulnerable to attacks.
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-15(6) · Continuous Improvement
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to implement an explicit process to continuously improve the development process.
Discussion
Developers of systems, system components, and system services consider the effectiveness and efficiency of their development processes for meeting quality objectives and addressing the security and privacy capabilities in current threat environments.
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-15(7) · Automated Vulnerability Analysis
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service [Assignment: frequency] to:
(a) Perform an automated vulnerability analysis using [Assignment: tools];
(b) Determine the exploitation potential for discovered vulnerabilities;
(c) Determine potential risk mitigations for delivered vulnerabilities; and
(d) Deliver the outputs of the tools and results of the analysis to [Assignment: personnel or roles].
Discussion
Automated tools can be more effective at analyzing exploitable weaknesses or deficiencies in large and complex systems, prioritizing vulnerabilities by severity, and providing recommendations for risk mitigations.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
