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.
System and Services Acquisition · Enhancement
SA-8(18) · Trusted Communications Channels
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of trusted communications channels in [Assignment: systems or system components].
Discussion
The principle of trusted communication channels states that when composing a system where there is a potential threat to communications between components (i.e., the interconnections between components), each communication channel is trustworthy to a level commensurate with the security dependencies it supports (i.e., how much it is trusted by other components to perform its security functions). Trusted communication channels are achieved by a combination of restricting access to the communication channel (to ensure an acceptable match in the trustworthiness of the endpoints involved in the communication) and employing end-to-end protections for the data transmitted over the communication channel (to protect against interception and modification and to further increase the assurance of proper end-to-end communication).
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-8(19) · Continuous Protection
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of continuous protection in [Assignment: systems or system components].
Discussion
The principle of continuous protection states that components and data used to enforce the security policy have uninterrupted protection that is consistent with the security policy and the security architecture assumptions. No assurances that the system can provide the confidentiality, integrity, availability, and privacy protections for its design capability can be made if there are gaps in the protection. Any assurances about the ability to secure a delivered capability require that data and information are continuously protected. That is, there are no periods during which data and information are left unprotected while under control of the system (i.e., during the creation, storage, processing, or communication of the data and information, as well as during system initialization, execution, failure, interruption, and shutdown). Continuous protection requires adherence to the precepts of the reference monitor concept (i.e., every request is validated by the reference monitor; the reference monitor is able to protect itself from tampering; and sufficient assurance of the correctness and completeness of the mechanism can be ascertained from analysis and testing) and the principle of secure failure and recovery (i.e., preservation of a secure state during error, fault, failure, and successful attack; preservation of a secure state during recovery to normal, degraded, or alternative operational modes).
Continuous protection also applies to systems designed to operate in varying configurations, including those that deliver full operational capability and degraded-mode configurations that deliver partial operational capability. The continuous protection principle requires that changes to the system security policies be traceable to the operational need that drives the configuration and be verifiable (i.e., it is possible to verify that the proposed changes will not put the system into an insecure state). Insufficient traceability and verification may lead to inconsistent states or protection discontinuities due to the complex or undecidable nature of the problem. The use of pre-verified configuration definitions that reflect the new security policy enables analysis to determine that a transition from old to new policies is essentially atomic and that any residual effects from the old policy are guaranteed to not conflict with the new policy. The ability to demonstrate continuous protection is rooted in the clear articulation of life cycle protection needs as stakeholder security requirements.
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-8(20) · Secure Metadata Management
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure metadata management in [Assignment: systems or system components].
Discussion
The principle of secure metadata management states that metadata are "first class" objects with respect to security policy when the policy requires either complete protection of information or that the security subsystem be self-protecting. The principle of secure metadata management is driven by the recognition that a system, subsystem, or component cannot achieve self-protection unless it protects the data it relies on for correct execution. Data is generally not interpreted by the system that stores it. It may have semantic value (i.e., it comprises information) to users and programs that process the data. In contrast, metadata is information about data, such as a file name or the date when the file was created. Metadata is bound to the target data that it describes in a way that the system can interpret, but it need not be stored inside of or proximate to its target data. There may be metadata whose target is itself metadata (e.g., the classification level or impact level of a file name), including self-referential metadata.
The apparent secondary nature of metadata can lead to neglect of its legitimate need for protection, resulting in a violation of the security policy that includes the exfiltration of information. A particular concern associated with insufficient protections for metadata is associated with multilevel secure (MLS) systems. MLS systems mediate access by a subject to an object based on relative sensitivity levels. It follows that all subjects and objects in the scope of control of the MLS system are either directly labeled or indirectly attributed with sensitivity levels. The corollary of labeled metadata for MLS systems states that objects containing metadata are labeled. As with protection needs assessments for data, attention is given to ensure that the confidentiality and integrity protections are individually assessed, specified, and allocated to metadata, as would be done for mission, business, and system data.
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-8(21) · Self-analysis
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of self-analysis in [Assignment: systems or system components].
Discussion
The principle of self-analysis states that a system component is able to assess its internal state and functionality to a limited extent at various stages of execution, and that this self-analysis capability is commensurate with the level of trustworthiness invested in the system. At the system level, self-analysis can be achieved through hierarchical assessments of trustworthiness established in a bottom-up fashion. In this approach, the lower-level components check for data integrity and correct functionality (to a limited extent) of higher-level components. For example, trusted boot sequences involve a trusted lower-level component that attests to the trustworthiness of the next higher-level components so that a transitive chain of trust can be established. At the root, a component attests to itself, which usually involves an axiomatic or environmentally enforced assumption about its integrity. Results of the self-analyses can be used to guard against externally induced errors, internal malfunction, or transient errors. By following this principle, some simple malfunctions or errors can be detected without allowing the effects of the error or malfunction to propagate outside of the component. Further, the self-test can be used to attest to the configuration of the component, detecting any potential conflicts in configuration with respect to the expected configuration.
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-8(22) · Accountability and Traceability
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of accountability and traceability in [Assignment: organization-defined systems or system components].
Discussion
The principle of accountability and traceability states that it is possible to trace security-relevant actions (i.e., subject-object interactions) to the entity on whose behalf the action is being taken. The principle of accountability and traceability requires a trustworthy infrastructure that can record details about actions that affect system security (e.g., an audit subsystem). To record the details about actions, the system is able to uniquely identify the entity on whose behalf the action is being carried out and also record the relevant sequence of actions that are carried out. The accountability policy also requires that audit trail itself be protected from unauthorized access and modification. The principle of least privilege assists in tracing the actions to particular entities, as it increases the granularity of accountability. Associating specific actions with system entities, and ultimately with users, and making the audit trail secure against unauthorized access and modifications provide non-repudiation because once an action is recorded, it is not possible to change the audit trail. Another important function that accountability and traceability serves is in the routine and forensic analysis of events associated with the violation of security policy. Analysis of audit logs may provide additional information that may be helpful in determining the path or component that allowed the violation of the security policy and the actions of individuals associated with the violation of the security policy.
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-8(23) · Secure Defaults
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure defaults in [Assignment: systems or system components].
Discussion
The principle of secure defaults states that the default configuration of a system (including its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that follow a "deny unless explicitly authorized" strategy. The initial configuration aspect of this principle requires that any "as shipped" configuration of a system, subsystem, or system component does not aid in the violation of the security policy and can prevent the system from operating in the default configuration for those cases where the security policy itself requires configuration by the operational user.
Restrictive defaults mean that the system will operate "as-shipped" with adequate self-protection and be able to prevent security breaches before the intended security policy and system configuration is established. In cases where the protection provided by the "as-shipped" product is inadequate, stakeholders assess the risk of using it prior to establishing a secure initial state. Adherence to the principle of secure defaults guarantees that a system is established in a secure state upon successfully completing initialization. In situations where the system fails to complete initialization, either it will perform a requested operation using secure defaults or it will not perform the operation. Refer to the principles of continuous protection and secure failure and recovery that parallel this principle to provide the ability to detect and recover from failure.
The security engineering approach to this principle states that security mechanisms deny requests unless the request is found to be well-formed and consistent with the security policy. The insecure alternative is to allow a request unless it is shown to be inconsistent with the policy. In a large system, the conditions that are satisfied to grant a request that is denied by default are often far more compact and complete than those that would need to be checked in order to deny a request that is granted by default.
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-8(24) · Secure Failure and Recovery
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure failure and recovery in [Assignment: organization-defined systems or system components].
Discussion
The principle of secure failure and recovery states that neither a failure in a system function or mechanism nor any recovery action in response to failure leads to a violation of security policy. The principle of secure failure and recovery parallels the principle of continuous protection to ensure that a system is capable of detecting (within limits) actual and impending failure at any stage of its operation (i.e., initialization, normal operation, shutdown, and maintenance) and to take appropriate steps to ensure that security policies are not violated. In addition, when specified, the system is capable of recovering from impending or actual failure to resume normal, degraded, or alternative secure operations while ensuring that a secure state is maintained such that security policies are not violated.
Failure is a condition in which the behavior of a component deviates from its specified or expected behavior for an explicitly documented input. Once a failed security function is detected, the system may reconfigure itself to circumvent the failed component while maintaining security and provide all or part of the functionality of the original system, or it may completely shut itself down to prevent any further violation of security policies. For this to occur, the reconfiguration functions of the system are designed to ensure continuous enforcement of security policy during the various phases of reconfiguration.
Another technique that can be used to recover from failures is to perform a rollback to a secure state (which may be the initial state) and then either shutdown or replace the service or component that failed such that secure operations may resume. Failure of a component may or may not be detectable to the components using it. The principle of secure failure indicates that components fail in a state that denies rather than grants access. For example, a nominally "atomic" operation interrupted before completion does not violate security policy and is designed to handle interruption events by employing higher-level atomicity and rollback mechanisms (e.g., transactions). If a service is being used, its atomicity properties are well-documented and characterized so that the component availing itself of that service can detect and handle interruption events appropriately. For example, a system is designed to gracefully respond to disconnection and support resynchronization and data consistency after disconnection.
Failure protection strategies that employ replication of policy enforcement mechanisms, sometimes called defense in depth, can allow the system to continue in a secure state even when one mechanism has failed to protect the system. If the mechanisms are similar, however, the additional protection may be illusory, as the adversary can simply attack in series. Similarly, in a networked system, breaking the security on one system or service may enable an attacker to do the same on other similar replicated systems and services. By employing multiple protection mechanisms whose features are significantly different, the possibility of attack replication or repetition can be reduced. Analyses are conducted to weigh the costs and benefits of such redundancy techniques against increased resource usage and adverse effects on the overall system performance. Additional analyses are conducted as the complexity of these mechanisms increases, as could be the case for dynamic behaviors. Increased complexity generally reduces trustworthiness. When a resource cannot be continuously protected, it is critical to detect and repair any security breaches before the resource is once again used in a secure context.
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-8(25) · Economic Security
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of economic security in [Assignment: systems or system components].
Discussion
The principle of economic security states that security mechanisms are not costlier than the potential damage that could occur from a security breach. This is the security-relevant form of the cost-benefit analyses used in risk management. The cost assumptions of cost-benefit analysis prevent the system designer from incorporating security mechanisms of greater strength than necessary, where strength of mechanism is proportional to cost. The principle of economic security also requires analysis of the benefits of assurance relative to the cost of that assurance in terms of the effort expended to obtain relevant and credible evidence as well as the necessary analyses to assess and draw trustworthiness and risk conclusions from the evidence.
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-8(26) · Performance Security
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of performance security in [Assignment: systems or system components].
Discussion
The principle of performance security states that security mechanisms are constructed so that they do not degrade system performance unnecessarily. Stakeholder and system design requirements for performance and security are precisely articulated and prioritized. For the system implementation to meet its design requirements and be found acceptable to stakeholders (i.e., validation against stakeholder requirements), the designers adhere to the specified constraints that capability performance needs place on protection needs. The overall impact of computationally intensive security services (e.g., cryptography) are assessed and demonstrated to pose no significant impact to higher-priority performance considerations or are deemed to provide an acceptable trade-off of performance for trustworthy protection. The trade-off considerations include less computationally intensive security services unless they are unavailable or insufficient. The insufficiency of a security service is determined by functional capability and strength of mechanism. The strength of mechanism is selected with respect to security requirements, performance-critical overhead issues (e.g., cryptographic key management), and an assessment of the capability of the threat.
The principle of performance security leads to the incorporation of features that help in the enforcement of security policy but incur minimum overhead, such as low-level hardware mechanisms upon which higher-level services can be built. Such low-level mechanisms are usually very specific, have very limited functionality, and are optimized for performance. For example, once access rights to a portion of memory is granted, many systems use hardware mechanisms to ensure that all further accesses involve the correct memory address and access mode. Application of this principle reinforces the need to design security into the system from the ground up and to incorporate simple mechanisms at the lower layers that can be used as building blocks for higher-level mechanisms.
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-8(27) · Human Factored Security
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of human factored security in [Assignment: systems or system components].
Discussion
The principle of human factored security states that the user interface for security functions and supporting services is intuitive, user-friendly, and provides feedback for user actions that affect such policy and its enforcement. The mechanisms that enforce security policy are not intrusive to the user and are designed not to degrade user efficiency. Security policy enforcement mechanisms also provide the user with meaningful, clear, and relevant feedback and warnings when insecure choices are being made. Particular attention is given to interfaces through which personnel responsible for system administration and operation configure and set up the security policies. Ideally, these personnel are able to understand the impact of their choices. Personnel with system administrative and operational responsibilities are able to configure systems before start-up and administer them during runtime with confidence that their intent is correctly mapped to the system’s mechanisms. Security services, functions, and mechanisms do not impede or unnecessarily complicate the intended use of the system. There is a trade-off between system usability and the strictness necessary for security policy enforcement. If security mechanisms are frustrating or difficult to use, then users may disable them, avoid them, or use them in ways inconsistent with the security requirements and protection needs that the mechanisms were designed to satisfy.
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-8(28) · Acceptable Security
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of acceptable security in [Assignment: systems or system components].
Discussion
The principle of acceptable security requires that the level of privacy and performance that the system provides is consistent with the users’ expectations. The perception of personal privacy may affect user behavior, morale, and effectiveness. Based on the organizational privacy policy and the system design, users should be able to restrict their actions to protect their privacy. When systems fail to provide intuitive interfaces or meet privacy and performance expectations, users may either choose to completely avoid the system or use it in ways that may be inefficient or even insecure.
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-8(29) · Repeatable and Documented Procedures
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of repeatable and documented procedures in [Assignment: systems or system components].
Discussion
The principle of repeatable and documented procedures states that the techniques and methods employed to construct a system component permit the same component to be completely and correctly reconstructed at a later time. Repeatable and documented procedures support the development of a component that is identical to the component created earlier, which may be in widespread use. In the case of other system artifacts (e.g., documentation and testing results), repeatability supports consistency and the ability to inspect the artifacts. Repeatable and documented procedures can be introduced at various stages within the system development life cycle and contribute to the ability to evaluate assurance claims for the system. Examples include systematic procedures for code development and review, procedures for the configuration management of development tools and system artifacts, and procedures for system delivery.
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-8(30) · Procedural Rigor
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of procedural rigor in [Assignment: systems or system components].
Discussion
The principle of procedural rigor states that the rigor of a system life cycle process is commensurate with its intended trustworthiness. Procedural rigor defines the scope, depth, and detail of the system life cycle procedures. Rigorous system life cycle procedures contribute to the assurance that the system is correct and free of unintended functionality in several ways. First, the procedures impose checks and balances on the life cycle process such that the introduction of unspecified functionality is prevented.
Second, rigorous procedures applied to systems security engineering activities that produce specifications and other system design documents contribute to the ability to understand the system as it has been built rather than trusting that the component, as implemented, is the authoritative (and potentially misleading) specification.
Finally, modifications to an existing system component are easier when there are detailed specifications that describe its current design instead of studying source code or schematics to try to understand how it works. Procedural rigor helps ensure that security functional and assurance requirements have been satisfied, and it contributes to a better-informed basis for the determination of trustworthiness and risk posture. Procedural rigor is commensurate with the degree of assurance desired for the system. If the required trustworthiness of the system is low, a high level of procedural rigor may add unnecessary cost, whereas when high trustworthiness is critical, the cost of high procedural rigor is merited.
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-8(31) · Secure System Modification
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure system modification in [Assignment: systems or system components].
Discussion
The principle of secure system modification states that system modification maintains system security with respect to the security requirements and risk tolerance of stakeholders. Upgrades or modifications to systems can transform secure systems into systems that are not secure. The procedures for system modification ensure that if the system is to maintain its trustworthiness, the same rigor that was applied to its initial development is applied to any system changes. Because modifications can affect the ability of the system to maintain its secure state, a careful security analysis of the modification is needed prior to its implementation and deployment. This principle parallels the principle of secure evolvability.
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-8(32) · Sufficient Documentation
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of sufficient documentation in [Assignment: systems or system components].
Discussion
The principle of sufficient documentation states that organizational personnel with responsibilities to interact with the system are provided with adequate documentation and other information such that the personnel contribute to rather than detract from system security. Despite attempts to comply with principles such as human factored security and acceptable security, systems are inherently complex, and the design intent for the use of security mechanisms and the ramifications of the misuse or misconfiguration of security mechanisms are not always intuitively obvious. Uninformed and insufficiently trained users can introduce vulnerabilities due to errors of omission and commission. The availability of documentation and training can help to ensure a knowledgeable cadre of personnel, all of whom have a critical role in the achievement of principles such as continuous protection. Documentation is written clearly and supported by training that provides security awareness and understanding of security-relevant responsibilities.
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-8(33) · Minimization
View parent controlControl statement and discussion
NIST control statement
Implement the privacy principle of minimization using [Assignment: processes].
Discussion
The principle of minimization states that organizations should only process personally identifiable information that is directly relevant and necessary to accomplish an authorized purpose and should only maintain personally identifiable information for as long as is necessary to accomplish the purpose. Organizations have processes in place, consistent with applicable laws and policies, to implement the principle of minimization.
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-9 · External System Services
Control statement and discussion
NIST control statement
a. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: [Assignment: controls];
b. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and
c. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: [Assignment: processes, methods, and techniques].
Discussion
External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-9 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-9(1) · Risk Assessments and Organizational Approvals
View parent controlControl statement and discussion
NIST control statement
(a) Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and
(b) Verify that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: personnel or roles].
Discussion
Information security services include the operation of security devices, such as firewalls or key management services as well as incident monitoring, analysis, and response. Risks assessed can include system, mission or business, security, privacy, or supply chain risks.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-9 (1) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-9(2) · Identification of Functions, Ports, Protocols, and Services
View parent controlControl statement and discussion
NIST control statement
Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: [Assignment: external system services].
Discussion
Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be useful when the need arises to understand the trade-offs involved in restricting certain functions and services or blocking certain ports and protocols.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-9 (2) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-9(3) · Establish and Maintain Trust Relationship with Providers
View parent controlControl statement and discussion
NIST control statement
Establish, document, and maintain trust relationships with external service providers based on the following requirements, properties, factors, or conditions: [Assignment: organization-defined security and privacy requirements, properties, factors, or conditions defining acceptable trust relationships].
Discussion
Trust relationships between organizations and external service providers reflect the degree of confidence that the risk from using external services is at an acceptable level. Trust relationships can help organizations gain increased levels of confidence that service providers are providing adequate protection for the services rendered and can also be useful when conducting incident response or when planning for upgrades or obsolescence. Trust relationships can be complicated due to the potentially large number of entities participating in the consumer-provider interactions, subordinate relationships and levels of trust, and types of interactions between the parties. In some cases, the degree of trust is based on the level of control that organizations can exert on external service providers regarding the controls necessary for the protection of the service, information, or individual privacy and the evidence brought forth as to the effectiveness of the implemented controls. The level of control is established by the terms and conditions of the contracts or service-level agreements.
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-9(4) · Consistent Interests of Consumers and Providers
View parent controlControl statement and discussion
NIST control statement
Take the following actions to verify that the interests of [Assignment: external service providers] are consistent with and reflect organizational interests: [Assignment: actions].
Discussion
As organizations increasingly use external service providers, it is possible that the interests of the service providers may diverge from organizational interests. In such situations, simply having the required technical, management, or operational controls in place may not be sufficient if the providers that implement and manage those controls are not operating in a manner consistent with the interests of the consuming organizations. Actions that organizations take to address such concerns include requiring background checks for selected service provider personnel; examining ownership records; employing only trustworthy service providers, such as providers with which organizations have had successful trust relationships; and conducting routine, periodic, unscheduled visits to service provider facilities.
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-9(5) · Processing, Storage, and Service Location
View parent controlControl statement and discussion
NIST control statement
Restrict the location of [Selection (one-or-more): information processing; information or data; system services] to [Assignment: locations] based on [Assignment: requirements].
Discussion
The location of information processing, information and data storage, or system services can have a direct impact on the ability of organizations to successfully execute their mission and business functions. The impact occurs when external providers control the location of processing, storage, or services. The criteria that external providers use for the selection of processing, storage, or service locations may be different from the criteria that organizations use. For example, organizations may desire that data or information storage locations be restricted to certain locations to help facilitate incident response activities in case of information security incidents or breaches. Incident response activities, including forensic analyses and after-the-fact investigations, may be adversely affected by the governing laws, policies, or protocols in the locations where processing and storage occur and/or the locations from which system services emanate.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-9 (5) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-9(6) · Organization-controlled Cryptographic Keys
View parent controlControl statement and discussion
NIST control statement
Maintain exclusive control of cryptographic keys for encrypted material stored or transmitted through an external system.
Discussion
Maintaining exclusive control of cryptographic keys in an external system prevents decryption of organizational data by external system staff. Organizational control of cryptographic keys can be implemented by encrypting and decrypting data inside the organization as data is sent to and received from the external system or by employing a component that permits encryption and decryption functions to be local to the external system but allows exclusive organizational access to the encryption keys.
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-9(7) · Organization-controlled Integrity Checking
View parent controlControl statement and discussion
NIST control statement
Provide the capability to check the integrity of information while it resides in the external system.
Discussion
Storage of organizational information in an external system could limit visibility into the security status of its data. The ability of the organization to verify and validate the integrity of its stored data without transferring it out of the external system provides such visibility.
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-9(8) · Processing and Storage Location — U.S. Jurisdiction
View parent controlControl statement and discussion
NIST control statement
Restrict the geographic location of information processing and data storage to facilities located within in the legal jurisdictional boundary of the United States.
Discussion
The geographic location of information processing and data storage can have a direct impact on the ability of organizations to successfully execute their mission and business functions. A compromise or breach of high impact information and systems can have severe or catastrophic adverse impacts on organizational assets and operations, individuals, other organizations, and the Nation. Restricting the processing and storage of high-impact information to facilities within the legal jurisdictional boundary of the United States provides greater control over such processing and storage.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
