UNCLASSIFIEDThe Department of Defense
CLEAREDFor Open Publication
May 15, 2024
Department of Defense

OFFICE OF PREPUBLICATION AND SECURITY REVIEWCybersecurity Reciprocity Playbook
Version 1.0
March 2024

UNCLASSIFIEDUNCLASSIFIEDDoD Cybersecurity Reciprocity Playbook
The DoD Cybersecurity Reciprocity Playbook is designed to provide clear, credible information
on key Department priorities for employing cybersecurity reciprocity in DoD systems, consistent
with DoD Instruction (DoDI) 8510.01, “Risk Management Framework for DoD Systems” Pleasecontact the Chief, Cybersecurity (CS) Implementation / Risk Management Framework TechnicalAdvisory Group (RMF TAG) Chair on specific matters. (osd.pentagon.dod-cio.mbx.rmf-tagsecretariat@mail.mil)Contents

1. Importance of Cybersecurity ................................................................................................... 1
1.1 RMF Role in Cybersecurity ........................................................................................................ 1
2. Cybersecurity Activities ........................................................................................................... 3
3. Definition of Reciprocity .......................................................................................................... 3
3.1 Benefits of Leveraging Reciprocity .................................................................................... 4
3.2 Risks of Failing to Leverage Reciprocity .......................................................................... 5
4. Reciprocity Use Cases ............................................................................................................... 5
4.1. Enterprise – Cloud ............................................................................................................. 5
4.2. Enterprise – ISRMC .......................................................................................................... 6
4.3 Community – Consortium of AOs ................................................................................... 10
4.4 One-to-One (Re-use of Artifacts) ..................................................................................... 12
4.5 DoD and Intelligence Community ................................................................................... 15
5. Role of Various Types of AOs in Reciprocity ....................................................................... 17
6. Security Configuration Guides & Secure Configurations .................................................. 18
7. eMASS Reciprocity Search .................................................................................................... 19
8. List of Enterprise AOs ............................................................................................................ 20
9. DoD CIO Role in Resolving Reciprocity Conflicts .............................................................. 20
10. Conclusion ............................................................................................................................. 21
Glossary ....................................................................................................................................... 22
References .................................................................................................................................... 24

UNCLASSIFIEDUNCLASSIFIED

1. IMPORTANCE OF CYBERSECURITY

Cybersecurity is a paramount concern that underpins the nation's ability to safeguard its criticalassets, information, and operations in an increasingly interconnected digital landscape. The
Department recognizes that malicious cyber activities pose significant threats to national security,
economic stability, and public safety. As technology evolves and adversaries become moresophisticated, ensuring the confidentiality, integrity, and availability of sensitive data and systems
has become an imperative mission.

1.1 RMF ROLE IN CYBERSECURITY

The DoD Risk Management Framework (RMF) plays a crucial role in our cybersecurity
strategy by providing a comprehensive framework for identifying, assessing, and mitigating
cyber risks across the entire spectrum of DoD operations. RMF enables a consistent approachto cybersecurity by establishing a set of processes and guidelines for managing risks associatedwith applications, systems, and networks which can be tailored based on system/networkneeds. By adhering to RMF principles, the Department sets the standards and guidelines for
Components to categorize assets, implement appropriate security controls, evaluate
vulnerabilities, authorize these assets, and continuously monitor and respond to emerging
threats.
The significance of RMF lies not only in its ability to bolster the resilience of the Department’s
digital infrastructure but also in its capacity to promote a proactive and adaptive cybersecurity
culture. The framework fosters collaboration among various stakeholders, (e.g., systemdevelopers, administrators, and security professionals) ensuring that cybersecurity
considerations are integrated from the inception of a system throughout its lifecycle,
facilitating the “re-use” of capabilities proven secure within the DoD. As the threat landscapeevolves, RMF allows the DoD to make informed risk-based decisions and allocate resources
effectively, ultimately enabling the DoD to maintain a robust and effective cybersecurity
posture in the face of evolving challenges.
The Federal Risk and Authorization Management Program (FedRAMP) is another way the
Department maintains cognizance of its cybersecurity posture. FedRAMP is a governmentwide program that provides a standardized approach to security assessment, authorization, andcontinuous monitoring that cloud service providers (CSPs) must follow to gain authorization
to work with federal agencies. This is especially important as the Department continues toadopt cloud technologies to modernize its digital infrastructure and operations as it emphasizes
security and protection of federal information and helps accelerate the adoption of secure cloud
solutions. The DoD can leverage FedRAMP or independently initiate a DoD Provisional
Authorization for cloud service offerings (CSOs) that DoD must use. Mission Owners (MOs)must understand the type of data, the authorized impact level, and the conditions outlined in
the Provisional authorization when choosing an authorized CSO. Determination of theappropriate Impact Level for a specific mission and mission data will be the responsibility ofthe mission AO.
UNCLASSIFIED

1

UNCLASSIFIED

•

•

•

Impact Level 2 (IL2) accommodates publicly releasable data or nonpublic unclassified
data where the unauthorized disclosure of information could be expected to have alimited adverse effect on organizational operations, organizational assets, orindividuals. This includes all data cleared for public release as well as some low
confidentiality unclassified information not designated as Controlled Unclassified
Information (CUI) or military/contingency operations mission data, but the information
may require some minimal level of access control (e.g., user ID and password). This
Impact Level accommodates non-CUI information categorizations based on
Committee on National Security Systems Instruction (CNSSI)1253 at moderate
Confidentiality, Integrity, and Availability (C-I-A). For noncontrolled unclassified
information, Impact Level 2 CSP/CSO customers include whomever the CSP chooses
to market the CSO to, which may include government customers, commercial
customers, and the public within the same Impact Level 2 cloud environment. Accessto CSO at this impact level is via the internet. DoD has reciprocity with FedRAMP for
use of CSOs on the FedRAMP Marketplace for all DoD mission systems that process
IL2 data.
Impact Level 4 (IL4) accommodates nonpublic, unclassified data where theunauthorized disclosure of information could be expected to have a serious adverse
effect on organizational operations, organizational assets, or individuals. This
encompasses CUI and/or other mission data, including that used in direct support ofmilitary or contingency operations. CUI is information the federal government createsor possesses that a law, regulation, or government-wide policy requires, or specificallypermits, an agency to handle by means of safeguarding or dissemination controls.
Impact Level 4 CSOs may support a U.S. government community or a DOD-onlycommunity (i.e., the CSO is DOD Private). Commercial Impact Level 4 CSP/CSO
customers include all U.S. government customers (federal, state, local, and tribal) andcommercial customers that support them. In some cases, an Impact Level 4 PA may be
granted to CSOs that support other commercial entities but not the public.
Impact Level 5 (IL5) accommodates nonpublic, unclassified National Security
Systems (NSS) data (i.e., unclassified National Security Information) or nonpublic,
unclassified data where the unauthorized disclosure of information could be expected
to have a serious adverse effect on organizational operations, organizational assets, orindividuals. This includes CUI and/or other mission data that may require a higher levelof protection than that afforded by Impact Level 4 as deemed necessary by the
information owner, public law, or other government regulation. This Impact Level
accommodates NSS and CUI information categorizations at High-High-X (H-H-X).
Per CNSS Policy (CNSSP) 32, the minimum requirement for all unclassified NSS is
equivalent to the FedRAMP High baseline. Impact Level 5 CSOs may support DOD
private clouds such as a federal government community or DOD-only community.
2
UNCLASSIFIEDUNCLASSIFIED•

Impact Level 6 (IL6) accommodates nonpublic, classified NSS data (i.e., classified
National Security Information) or nonpublic, unclassified data where the unauthorized
disclosure of information could be expected to have a serious adverse effect onorganizational operations, organizational assets, or individuals. At this time, only
information classified as SECRET or below, in accordance with the applicable
executive orders, is permitted to be hosted at this Impact Level. Access to the CSO is
via one or more private SIPRNet connections or approved CNSSP 11 circuits.

2. CYBERSECURITY ACTIVITIES

Effective monitoring and analysis capabilities, incident response procedures, efficient
communication management and control, and timely reporting are critical activities to ensure
healthy network operations on which strong network security is built. These cybersecurity
activities cannot be oversimplified or ignored for the sake of operational expediency. RMF
emphasizes and then requires that such activities be implemented for a capability to obtain an
Authorization to Operate (ATO). All systems without an ATO must begin the RMF process,regardless of the system life-cycle stage (e.g., acquisition, operation).

3. DEFINITION OF RECIPROCITY

As defined in the Committee on National Security Systems Instruction (CNSSI) 4009,
cybersecurity reciprocity (hereinafter referred to as “reciprocity”) is the “agreement among
participating organizations to accept each other’s security assessments, to reuse system resources,
and/or to accept each other’s assessed security posture to share information”. During thereciprocity process, Authorizing Officials (AOs) make system authorization decisions byreviewing the body of evidence (BoE). The BoE is the complete set of RMF documentation on thetesting, implementation, and assessment of security controls, consisting of the RMF core
documents and RMF data elements as defined in Annex C of CNSSI 1254. According to CNSSI
1254, the RMF core documents are the:
1.
2.
3.
4.

System Security plan (SSP)
Security Assessment Report (SAR)
Risk Assessment Report (RAR)
Plan of Action and Milestones (POA&M)
5. Authorization Decision Document
DoD CIO issued a memorandum in October 2016 (reference g), reiterating the Department’s
Cybersecurity Reciprocity policy, as established in DoDI 8510.01, and as implemented by thecybersecurity reciprocity related content pages on the RMF Knowledge Service (KS)(rmfks.osd.mil/rmf/PolicyandGovernance/Reciprocity/Pages/default.aspx). The memorandumemphasized that reciprocity is the default for assessment and authorization of a system already
UNCLASSIFIED

3

UNCLASSIFIED
deployed in the Department and Components will maximize the use of previous assessment results
and authorizations of common information technology systems and software by fellow Department
Components in their risk determination and authorization process. Additionally, DoD CIO issued
a memorandum in March 2023 (reference j), supporting the reissuance of DoDI 8510.01, whichemphasized Components should leverage reciprocity to the greatest extent possible by utilizing arobust BoE.
To improve the use of reciprocity, CIO has emphasized in policy the “re-use” of security testing
evidence as the foundation for reciprocity, eliminating and invalidating the practice to issue an
authorization decision memo without examining the body of evidence. DoDI 8510.01 states, “TheDoD Information Enterprise will use cybersecurity reciprocity to reduce redundant testing,assessing, documenting, and the associated costs in time and resources.” By focusing on “re-use”,
CIO ensures data is provided to Components to enable risk-based decision making, whileeliminating duplication of effort.
Reciprocity is not a passive acceptance of security assessments, certifications, or authorizations
from other entities without careful consideration, and comprehensive review of the context, risk
factors, sensitivity of the data, and relevance to the specific systems or networks within its purview.
Instead, reciprocity involves a thoughtful, risk-based assessment process and a careful examinationof the BoE to determine their applicability and suitability within a specific security landscape.
In essence, reciprocity emphasizes the importance of maintaining a strong security posture while
maximizing efficiency through the re-use of the BoE. Thus, reciprocity demands a discerning
approach that safeguards the integrity of its systems, while leveraging the insights and efforts oftrusted partners to enhance its cybersecurity resilience.

3.1 BENEFITS OF LEVERAGING RECIPROCITY

Reciprocity is designed to expedite authorization through the re-use of assessments andartifacts, which leads to cost reduction. Executed appropriately, reciprocity reduces redundanttesting, assessment and documentation, and the associated costs in time and resources.
To support reciprocity, DoD Components share security authorization packages with affected
information owners and interconnected system owners. The re-use of artifacts allows AOs toaccept assessments done on systems they intend to deploy rather than repeat the assessments.
Acceptance of relevant artifacts from similar assessments results in fewer costly assessments,
allowing systems to be authorized more quickly and efficiently.
In some cases, an organization may want to deploy a capability developed by anotherorganization. It can leverage the existing authorization package if both organizations have
similar mission requirements and plan to deploy the same system components with similar
4
UNCLASSIFIEDUNCLASSIFIED
dataflows and network architectures. In these cases, the Receiving organization becomes thesystem owner and, while not needing to re-authorize the system, it must issue an authorization
to use (ATU). This ATU includes a statement by the Receiving AO granting approval for a
Granting system to connect to the hosting/receiving system where the systems are linked
through inheritance in the RMF Inventory Tool (e.g., eMASS, Xacta). It also provides a copyof implementing documentation to the Granting AO and notifies and provides guidance tosubordinate site(s) that the system is authorized to operate and/or connect only in theauthorized configuration. Overall, this re-use can result in significant resource savings.

3.2 RISKS OF FAILING TO LEVERAGE RECIPROCITY

Failing to leverage reciprocity to the greatest extent possible can lead to redundant andresource-intensive efforts. Without recognizing the assessments conducted by other entities,
the organization might be compelled to undertake its own comprehensive evaluations ofsystems and networks, even when similar assessments have already been performed by trusted
partners. This results in a wasteful allocation of time, manpower, and financial resources,
hindering the organization’s ability to efficiently manage and enhance its cybersecurity
posture.
Moreover, the lack of reciprocity undermines interagency collaboration and information
sharing. In an era characterized by the rapid evolution of cyber threats, the ability to quickly
share cybersecurity insights and findings across different government agencies andorganizations is critical. Reciprocity fosters a culture of cooperation and trust, enabling the
Department to benefit from the expertise and perspectives of other entities, thereby enhancing
its ability to detect, prevent, and respond to emerging threats effectively.
Not leveraging reciprocity hampers resource optimization and hinders collaborative efforts.
Embracing reciprocity promotes efficiency, interagency cooperation, and information sharing,
thereby contributing to a stronger and more robust cybersecurity posture that aligns with the
evolving threat landscape.

4. RECIPROCITY USE CASES

The following use cases do not represent all possible reciprocity circumstances. The cases in
sections 4.1 through 4.5 demonstrate how reciprocity is leveraged across the Department in someof the most common applications.

4.1. ENTERPRISE – CLOUDA CSP with a service offering already approved by FedRAMP at the moderate baseline iseligible for use under reciprocity by the DoD for public data. To obtain the BoE for review,
the MO must submit a FedRAMP Package Access Request form at:https://www.fedramp.gov/assets/resources/documents/Agency_Package_Request_Form.pdf.

UNCLASSIFIED

5

UNCLASSIFIED
For data categorized at IL4/5/6, DoD issues a PA. The security authorization package andinheritance is made available in the Enterprise Mission Assurance Support System (eMASS)
for MOs to leverage when obtaining their department's ATOs.
•••

For IL4 and IL5, MOs inherit security controls from eMASS for CSOs and use the SSP
and Security Requirements Traceability Matrix (SRTM) to understand control
implementation guidance (inherited, hybrid or fully on MOs) and assess additional
security controls based on MO’s need for awarding an ATO.
For IL2 (Public Data), the DISA AO issued a reciprocity memo for CSOs assessed,
authorized, and listed in the FedRAMP marketplace at a minimum of the FedRAMP
moderate Baseline. If that IL2 needs be uplifted to IL4/5, a DoD Sponsor must utilize
the DoD Cloud Authorization Services (DCAS) SharePoint page:https://dod365.sharepoint-mil.us/sites/DISA-RE-Apps/cas/SitePages/CASHome.aspx
to request DISA to begin the Cloud Authorization Process.
All DoD PAs for authorized CSOs, including the DISA Memorandum on IL2
Reciprocity (reference k), can be found on DCAS.

4.2. ENTERPRISE – ISRMC

The DoD Information Security Risk Management Committee (ISRMC) is a cross-functional
committee responsible for overseeing the Enterprise risk management process for DoD
systems and networks and one of the key stakeholders responsible for executing and supporting
reciprocity for an enterprise system.
An “Enterprise system" is designed to satisfy a DoD-wide requirement and is deployed tomultiple DoD Components across the DoD Information Enterprise. The following activities
describe how to achieve reciprocity when a DoD Component deploys an Enterprise system(i.e., major application):
4.2.1 Granting Organization Activities
a. Initiate the security authorization package.
b. Provide the Defense Security/Cybersecurity Authorization Working Group (DSAWG),
through the organization’s DSAWG Representative, an electronic copy of the SSP,
SAR, RAR, the System POA&M, Authorization Decision Document, and list of
deployment sites and projected deployment dates.
(1) Granting AOs must also provide the complete security authorization package
and body of evidence to Receiving AOs.
(2) Program managers (PMs) and system owners – who deploy systems acrossmultiple DoD Components – can accomplish this sharing by posting security
authorization documentation and the associated body of evidence to eMASS or
UNCLASSIFIED

6

UNCLASSIFIED
other automated assessment and authorization tools to provide visibility ofauthorization status and documentation to planned Receiving sites.
a. For organizations inheriting from incompatible or interoperable record
keeping systems, or RMF inventory tools, the “manual inheritance”
capability will be utilized.
c. This information sharing ensures all parties involved have visibility of the system’s
security artifacts and documentation.
(1) Granting systems with valid authorizations (from a DoD organization orother U.S. Government agency) into Receiving organizations may affect the
security posture of the Receiving organization. Receiving organizations must
review the Granting system’s authorization and POA&M to ensure
mitigations that reduce residual risk can be applied in the Receivingorganization. The Receiving organization would request read-only access to
the Granting system’s authorization record, as no additional validation orverification testing is required.
(2) Configuration differences, introduced by using the system in a new ordifferent environment, require additional testing.
a. If a baseline is changed, the local AO must authorize the new
configuration based on additional testing.
(3) System owners and PMs from Granting organizations must coordinate
system security requirements with Receiving organizations’ representatives
early and throughout system development.
d. Provide authorization status briefs to the DSAWG, as requested.
e. In coordination with the Receiving organization, ensure security assessments address
any and all additional Receiving organization security controls or requested
adjustments to the assigned security controls identified during DSAWG security
reviews.
f. Ensure the Enterprise system complies with Information Assurance Vulnerability
Management (IAVM) Program directions and operational orders issued by Joint Force
Headquarters - Department of Defense Information Network (JFHQ-DODIN)
g. Register the Enterprise system in the DoD Ports, Protocols, and Services Management(PPSM) Registry.
UNCLASSIFIED

7

UNCLASSIFIED

h. Brief the ISRMC for approval or disapproval of the Enterprise system no later than 60
business days prior to the planned deployment.
(1) If approved by the ISRMC, the Granting AO can issue an ATO for theEnterprise system and the version being deployed.
(2) If disapproved by the ISRMC, the Granting AO must work with the DSAWG
to adjust the Enterprise system, as needed, to comply with ISRMC guidance so
it can receive an ATO.
i. Provide installation and configuration requirements documents to Receiving AOs prior
to the Enterprise system deployment. This must include all applicable DoD Security
Technical Implementation Guides (STIGs).
4.2.2 ISRMC Activities
a. Approve or disapprove the Enterprise system connection based on the DSAWG
recommendation and other factors identified during the Granting organization’s
decision briefing.
b. If approved, the ISRMC will monitor the acceptability of the residual risk fororganizations receiving the Enterprise system at Component sites and authorize
connection to the DoD Information Network (DoDIN). Any change in acceptability ofrisk that cannot be mitigated will require a re-boarding at the ISRMC.
(1) The Receiving organization would use the ISRMC risk acceptance as an RMF
artifact to approve the change request in adding the Enterprise Capability into
their system authorization record.
c. If disapproved, the ISRMC provides guidance through the DSAWG to the Granting
organization on actions and mitigations that will result in an approval to connect to the
DoDIN.
d. The ISRMC will not grant its approval until the Granting organization documents andmitigates any remaining risks, as directed by the ISRMC, in the Enterprise system
POA&M.
4.2.3 Receiving Organization Activities
a. Maintain situational awareness of the Granting Enterprise system assessment activities
via eMASS or other automated tools.

UNCLASSIFIED

8

UNCLASSIFIED
b. Make the system(s) security authorization package available to the Granting
organization.
c. Determine the security impact of connecting the Granting Enterprise system within the
Receiving system and use their DSAWG representative to identify issues that may
preclude the system from connecting, such as requests for adjustments to the assigned
security controls or requirements for additional controls.
d. Test security controls, as appropriate.
(1) The Receiving organization must review the controls and the deployment guideto ensure that the local security posture meets the deployment conditions andimplement inherited controls and deploy the system in accordance with (IAW)
the deployment guide.
(2) Security controls that are built into the system must not change when the system
is deployed and do not need to be re-tested.
(3) The Receiving organization must establish inheritance for the hybrid controls,
providing supporting evidence to support implementation within the Receiving
system.
e. Augment any security controls required for deploying the Enterprise system to a
Receiving site.
(1) The authorization documentation for the systems receiving/hosting theEnterprise system will be updated, as required.
(2) This includes any installation and configuration requirement documents
provided by the Granting organization and testing results of any configurationdifferences, if needed.
f. Execute a documented agreement with the Granting organization, such as a
Memorandum of Understanding (MOU), Memorandum of Agreement (MOA), or
Service Level Agreement (SLA), for maintaining and monitoring the system’s security
posture, including the system’s security controls and cybersecurity service provider(CSSP). At a minimum, the agreement document must address: operating constraints,
operation environment, monitoring requirements, security maintenance, vulnerability
scanning, IAVM compliance, lifecycle replacement of software and components, androles and responsibilities.

UNCLASSIFIED

9

UNCLASSIFIED
g. Issue a formal authorization to use and operate the Enterprise system. Not a new ATO,
this determination includes a statement by the Receiving AO granting approval for a
Granting system to connect to the Receiving system.
(1) This “ATU” differs from the authorization issued by DISA for connection to
the DISN. This “authorization to use” formally incorporates the Granting
system into the Receiving system.
(2) However, if multiple systems are reused but separately owned, managed, andmaintained by different organizations, they are considered isolated instancesand require separate authorizations. In these cases, Receiving organizations canuse available completed test and assessment results to the greatest extent
possible.
(3) The Receiving AO provides a copy of implementing documentation, such as
the “ATU”, to the Granting AO.
(4) The Receiving AO will notify subordinate sites that the Granting Enterprisesystem (i.e., major application) is authorized to operate or connect to the
Receiving organization’s systems, but only in the authorized configuration
found in the updated system’s ATO documentation.
h. Update system authorization and connection documentation to reflect the incorporationand connection of the Enterprise systems.
i. Ensure all parts of the Receiving organization implement major application installation
guidance and applicable DoD security configuration requirements.
j. Implement and maintain mitigations identified in the Granting Enterprise systems’
POA&M.
In summary, the execution of Enterprise reciprocity is a collaborative effort. Each party has
distinct responsibilities, and this cooperative approach ensures that cybersecurity assessments
and authorizations within the DoD are efficient and aligned while maintaining the security andintegrity of the systems involved.

4.3 COMMUNITY – CONSORTIUM OF AOS

To address the challenge of reciprocity in complex authorization environments such as manyof the DoD capabilities (e.g., Weapon Systems, Enterprise Systems, Clouds, DevSecOps,
Coalition environments, Cross service environments, etc.), where there are multiple
stakeholders and AOs involved, an AO Consortium (hereinafter referred to as an “AO

UNCLASSIFIED

10

UNCLASSIFIED
Committee”) method was established as a tool to streamline the assessment and authorization
process while maintaining a high level of security assurance.
The main objective of the AO Committee is to provide a mechanism for all stakeholders withauthorization equity to have insight to the risk posture of the system, to participate in theongoing assessments and to have awareness of the Continuous Monitoring (CONMON) andpriorities established by the system/capability AO, which allow the identification andadjudication of any reciprocity challenges early as part of the continuous assessment andauthorization process of the system/capability. The AO Committee provides the forum andstructure to allow all authorization stakeholders the ability to participate in, understand, andtrust the risk assessment of the system AO and the ability to correlate that to their risk tolerance,
and their environment, achieving reciprocity as an outcome.
The committee of AOs would outline an interconnection service agreement (ISA); defining therelationships; roles and responsibilities, steps to address gaps between authorization
boundaries and/or enterprise services, PPSM coordination, CSSP identification, incident
response, and agreement review requirements to address later changes in technology andauthorization statuses.
The following are the outcomes of utilizing an AO Committee to leverage reciprocity:
Outcome 1• Allow all stakeholders a structured way to evaluate systems coming into
their authorization boundary to participate in the development of the risk
assessment of the system/capability.
• Understand the environment for the agreement being worked, as well as theassumptions and constraints.
• Work through the agreements and handoffs required between environments.
• Encourage AO-to-AO level communications.
o This leads to: Increased confidence and trust between the Authorization
stakeholders, allowing increased ability to achieve
reciprocity.
 A tangential benefit of getting past the narrow view ofcompliance to artifacts and allowing focus on the intent andrisk management objectives.
Outcome 2• Provide a mechanism to track the visibility of actions between AOs andboundaries to form Government-to-Government collaborations and focus
priorities of efforts across the authorization community toward theintegrated efforts of the cyber security community.
UNCLASSIFIED

11

UNCLASSIFIEDo AO Committees allow a simple way for actions and items to beaddressed, adjudicated, and worked at the principal level in waysthat would normally take longer.
Outcome 3• When the Test communities (Director, Operational Test & Evaluation(DOT&E) and Operational Test & Evaluation (OT&E)) are involved in the
AO Committee, it helps integrate the assessments done by all parties into a
more holistic input for the AO to consider in rendering their determination.
• By partnering with the Test communities, AOs and system owners can be
more proactive to assess the risk posture over time, as the findings andanalysis are a valued part of the continuous assessing and authorizing
approach and prioritization of mitigations.
 This integration and collaboration leads to:• Increased confidence in the risk posture andassurance of the systems/capabilities.
• Forged collaborations between the AOs.
• Increased confidence in the assurance that the higher
priority risks, given the operational context and risk
tolerance are prioritized in a way that is supported byanalytics of findings, vice compliance alone.
Overall, the Department's use of reciprocity within an AO Committee enhances efficiency,
reduces redundancy, and promotes collaboration among various Components while
maintaining a consistent and robust security posture across the entire system.

4.4 ONE-TO-ONE (RE-USE OF ARTIFACTS)

The responsibility for executing reciprocity in a one-to-one scenario (re-use of artifacts) is
shared among various stakeholders. The Department recognizes that leveraging reciprocity
through the re-use of cybersecurity artifacts can enhance efficiency and streamline theassessment process. In this scenario, the primary responsibility falls on both the Granting andReceiving organization involved in the artifact exchange. The following process steps detailthe responsibilities of both organizations:
Prior to entering into a reciprocity agreement, both Receiving and Granting organizations
need to complete several tasks. These tasks may include:••

Identifying who is responsible for providing the resources (e.g., funding, hardware,
software, lifecycle replacement of system component, and personnel) required to
manage and operate the system.
Verifying compliance and maintenance of the reciprocity authorization by the Granting
organization.
UNCLASSIFIED

12

UNCLASSIFIED
•

•
•
•
•

Ensuring the Receiving organization implements the appropriate security controls
required by the authorization package and applies mitigation strategies as directed by
the Granting organization's POA&M.
Ensuring the interconnected systems are not adversely affected by new (or aggregated)vulnerabilities.
Verifying and maintain the correct configuration.
Ensuring all stakeholders have access to the complete security authorization package,
including configuration specifications.
Formally documenting all tasks that must be completed and the associated responsibleorganization, as the result of agreement between the Granting and Receivingorganizations.

4.4.1 Responsibilities of Granting Organizationo Provide the security authorization package and deployment instructions (or accessto it), including a current POA&M, to Receiving organizations.
o Communicate all changes to the system during its lifecycle, such as version
updates, to Receiving organizations.
o Notify Receiving organizations of any new findings, such as new threats,
discovered vulnerabilities, or similar information, throughout the authorization life
cycle.
o Gather requirements from potential leveraging organizations before developing thesystem to ensure the widest use of a standardized configuration and avoid
modifications driving separate authorizations.
o Provide a point of contact (POC) to Receiving organizations requesting
information.
o Notify Receiving organizations at least six months prior to any reauthorization
events to ensure consideration of any input from Receiving organizations.
(Acknowledgment of receipt required by impacted organizations).
o Notify Receiving organizations of any plans that may affect their use of the system,
such as decommissioning or version changes. (Acknowledgement of receipt
required by impacted organizations).
o Identify factors or conditions justifying termination of the MOU/MOA.
o Communicate and provide patches and updates in accordance with DoD and
USCYBERCOM requirements and timelines, maintain the Enterprise Capability
authorization baseline within the established DoD and USCYBERCOM timelines.
o Maintain deployment locations of the system within the Granting organizational
authorization tracking tool.
o Ensure assignment of a JFHQ-DODIN accredited CSSP to maintain continuous
monitoring, patch management, the IAVM Program, End Point Security Services(ESS) monitoring, Security Information and Event Management (SIEM)
13
UNCLASSIFIEDUNCLASSIFIED
monitoring, operational orders, POA&Ms, annual reviews, and quarterly ormonthly reviews of authorized systems.
4.4.2 Responsibilities of Receiving Organizationo Request Security Authorization Package and deployment instructions (or access toit), including a current POA&M, from the Granting organization.
o Review the Granting organization AO's authorization decision and work with theGranting organization to implement the Enterprise Capability with any required
mitigations.
o Deploy the system using configuration requirements in the security authorization
package and deployment instructions.
o Provide all inherited security controls, mitigations, or support functions required by
the reciprocity authorization.
o Obtain any necessary authorization to connect and operate the system within theorganization's network.
o Provide a single POC to Granting organizations.
o Update necessary authorization tracking tools within the organization.
o Implement required patches and changes in accordance with Project Management(PM) guidance.
o Notify Granting organizations of any new findings, such as new threats, discovered
vulnerabilities, or similar information throughout the authorization life cycle.
o Implement mitigations in accordance with the Granting Information Technology
Security POA&M.
o Maintain the Enterprise Capability baseline by applying IAVAs and STIGs as new
guidance is released, updating the POAM for any updates or configurations thatcannot be applied.
Note: Additional testing may be required to satisfy all RMF requirements. However,systems must re-use existing security testing and assessment results to the greatest
extent possible and the Granting and Receiving organizations must agree to allchanges or additions to agreements in writing.
4.4.3 Change Management
All organizations must identify technical POCs as part of their MOU, MOA, or SLA to
support the management and operation of the authorized system. Organizations must
communicate to the PM and original AO any event that may affect the security posture of
the authorized system or the installed environment. Agreements must include processes,
timing, and notification requirements. Examples of events requiring notification include:o Security incidents
UNCLASSIFIED

14

UNCLASSIFIED
o
o
o
o
o
o
o
o
o

Disasters and other contingencies
Material changes to system configuration, such as quarterly STIG releases
Personnel changes in critical positions
New user types, such as Foreign Nationals
Changes to the operating environment (such as a facility once cleared foropen storage no longer having such clearance)
When the network the system is connected to is given a Denial of
Authorization to Operate (DATO)IAVM program reporting
Lifecycle Replacement requirements (such as an operating system or
equipment firmware no longer supported by the vendor)
Changes to Enterprise Tools or Capabilities (such as migration to a new
ESS anti-virus tool)

Ultimately, successful execution of reciprocity in a one-to-one scenario (re-use of artifacts)
hinges on collaboration, transparency, and a mutual commitment to cybersecurity bestpractices. Both the Granting and Receiving organizations play vital roles in upholding the
integrity of the artifacts and ensuring that the security posture of the systems involved
remains robust and aligned with the Department's cybersecurity objectives.

4.5 DOD AND INTELLIGENCE COMMUNITY

Both DoDI 8510.01 and Intelligence Community Directive (ICD) 503 emphasize the context
of reciprocity for assessment only and acknowledge the needed testing for configuration
changes that arise from the movement of capabilities.
DoDI 8510.01, the RMF KS, and ICD 503 align to assert the following regarding reciprocity:a. Components of the DoD and IC will make appropriate authorization decision
documentation available to other IC elements, to the non-IC parts of the DoD(i.e., Military Departments, Combatant Commands and Defense Agencies), andto non-IC agencies of the Federal Government.
b. Authorizing Officials of DoD and IC Components will make appropriate
security assessment documentation of a system available to other IC elements,
to the non-IC parts of the DoD, and to other non-IC agencies of the Federal
Government.
c. DoD and IC Components will accept the security assessment of a system byanother Component without requiring or requesting any additional validationor verification testing of the system with the following caveats.

UNCLASSIFIED

15

UNCLASSIFIED
i. Components of the DoD and the IC will test only the configurationdifferences introduced by using the system in a new or different
environment.
ii. AOs and Authorizing Official Designated Representatives (AODRs) of
DoD and IC Receiving organization will consider the Granting
organization’s security assessment when making the authorization
decision for placing a system into operation as a new or additional partof any system for which the AO or AODR exercises authorization
authority.
iii. Additional consideration must be given to Security Control Overlays(e.g., Intelligence A (INT-A), INT-B, INT-C, Cross Domain Transfer
Cross Domain, Cross Domain Access, Privacy, etc.)
4.5.1 Body of Evidence Sharing
IC and DoD agencies utilize one of only a few major RMF inventory tool suites tomanage their RMF documentation (e.g., eMASS, Xacta). These tools grant eachagency the ability to customize their workflows, essential elements of information,and policy mappings captured within its RMF implementation.
The IC released the Extensible Markup Language (XML) Data EncodingSpecification for Body of Evidence (BOE.XML) as a standard for the way the BoE
is stored within RMF inventory tools. This specification has been closely alignedwith CNSSI 1254 and associated policies to facilitate this exchange and is intended
to provide the data fields that are necessary to capture and convey the relevant
information that would be used to facilitate the acceptance and reciprocity of
established systems and their security authorizations.
When sharing a BOE, each IC and DoD AO and Chief Information Security Officer(CISO) understands the technological complexity, cybersecurity strengths andweaknesses, and mission critical portions of their IT enterprise. Each AO must decide
the right balance of cybersecurity risk against the need to execute critical mission at
any point in time. As such, there are several overall cybersecurity risk items that mayvary amongst agencies and must be considered before a decision on authorization for areciprocal capability is rendered.
To facilitate the exchange of BoE for reciprocity, the DoD and IC worked together toestablish the following initiatives:•

Alignment to the BOE.XML specification across all DOD and IC systems tosimplify ease of sharing amongst RMF system of record tools.
16
UNCLASSIFIEDUNCLASSIFIED••

Establishment of centralized access to RMF BoE by CISO organizations forServices of Common Concern (SoCC), Programs of Record, or community
wide service providers (e.g., Commercial Cloud Enterprise (C2E)).
Use of Security Content Automation Protocol (SCAP) protocols within
automated and manual assessment activities (e.g., Open Vulnerability andAssessment Language (OVAL), Open Checklist Interactive Language (OCIL),
Extensible Configuration Checklist Description Format (XCCDF), etc.) as welltheir use within Commercial off the Shelf (COTS) RMF support tools.

5. ROLE OF VARIOUS TYPES OF AOS IN RECIPROCITY

To maintain the narrowest scope, we identified that with reciprocity, there are two types of AOs– ‘Granting’ or ‘Receiving’, as outlined in the “Reciprocity MOA MOU” template (available on
the related reciprocity pages on the RMF KS) which provides the guidelines to be applied as thebasis for practicing reciprocity, in accordance with Department of Defense Instruction (DoDI)
8510.01, Risk Management Framework for DoD Systems, 19 July 2022.

The default option is for Components to use each system/application in its native environment.
This use case will be referred to as “co-use” and will only require authorization by the Granting
organization. Granting organization are responsible for establishing notification processes (e.g.,cybersecurity incidents, PII breaches, etc.) for co-use systems, applications, and cloud services.
When an authorized, operational system and/or application in one environment is designated for
install and use in another environment, cybersecurity reciprocity will be the default method forassessment and authorization by the Receiving organization.
Prior to initiating testing or a risk assessment for a system to be hosted in the Receivingorganization’s environment, the Receiving AO is responsible for determining whether the system
has been authorized by another AO. If a current authorization exists, the Receiving AO and SCA
will proceed with reciprocity based on RMF documentation required by DoDI 8510.01.
When the specific documents required by DoDI 8510.01 are not available, the Receiving AO must
consider the body of evidence available from the Program Office or system owner, to include, but
not limited to the following information:••••

The Enterprise Capability POA&M, listing the open vulnerabilities, justification,and residual risk.
Residual risk assessment for each “High” or “Very High” risk vulnerability
The authorization boundary diagram sometimes referred to as the network.
diagram, depicting the Defense-in-depth security architecture for the platform(building, ship, Humvee, command center, etc.) and enclave.
Data-flow diagrams, interface diagrams and cross-domain interfaces that specify
type of interface, direction of data flow, and any in-line security solutions.
UNCLASSIFIED

17

UNCLASSIFIED••••

Impact and technical justification for any “High” or “Very High” risk
vulnerabilities that remain.
IAVM plan, Continuity of Operations Plan (COOP), Disaster Recovery Plan, andincident management plans.
Hardware and software lists, with the associated STIG checklists.
Validation or verification test results.

Requests for documentation not included in the Granting organization’s RMF package must be
endorsed by the requesting Component CISO, or equivalent, before being forwarded to the
Receiving AO.
The Granting AO will ensure documentation providing the body of evidence is freely shared with
the Receiving organization.
The Receiving organization becomes responsible for establishing and maintaining a fullauthorization if it continues using any system, application, or cloud service that is no longer
supported by the Granting organization.

6. SECURITY CONFIGURATION GUIDES & SECURE CONFIGURATIONS

Within the Department, secure configuration guides take various forms, such as STIGs andSecurity Requirement Guides (SRGs). These guides offer detailed step-by-step instructions forsecuring specific technologies, platforms, and environments, ranging from operating systems andapplications to cloud services. By following these guides, Components establish a consistentbaseline security posture, reducing the attack surface and potential vulnerabilities that adversaries
could exploit.
These guides facilitate reciprocity by providing standardized and approved security
configurations. When a system adheres to the recommended settings outlined in these guides, it
becomes easier for other Components to trust the security of that system, accelerating theauthorization and deployment process. This not only streamlines operations but also enhances theoverall security posture of the DoD by maintaining a consistent level of security across theenterprise.
While the SRGs define the high-level requirements for various technology families andorganizations, STIGs are the detailed guidelines for specific products. STIGs provide productspecific information for validating, attaining, and continuously maintaining compliance withrequirements defined in the SRG for that product’s technology area. The security requirements
contained within the SRGs and STIGs, in general, are applicable to and required by all DoDadministered systems, all systems connected to DoD networks, and all systems operated and/or
UNCLASSIFIED

18

UNCLASSIFIED
administrated on behalf of the DoD. This requirement remains in force for all mission owners
building systems in a cloud service.
In the case of cloud service, where CSP systems must comply with configuration guidanceconsistent with the National Institute of Standards and Technology Special Publication (NIST SP)
800-53 security control “CM-6 Configuration Settings” by using STIGs/SRGs. Secure
configuration guides, such as the Cloud Computing SRG, play an essential role in ensuring thatcloud deployments align with DoD cloud security requirements. As the Department increasingly
leverages cloud technologies, these guides offer a roadmap for configuring cloud resources,
addressing shared security responsibilities, and meeting compliance standards. By adopting secure
configurations outlined in these guides, the Department can confidently extend its reciprocity to
CSOs, fostering a secure and agile cloud environment that supports its mission-critical operations.

7. eMASS RECIPROCITY SEARCH

Certain capabilities exist within eMASS to support reciprocity activities across Federal
Organizations. Among these capabilities is the eMASS “Reciprocity” user role, which grants a set
number of reciprocity users per eMASS instance—to be appointed by an Organization-definedEnterprise role (e.g., AO, CISO, CIO)— access to the eMASS reciprocity search function,
allowing them to find reciprocity systems more easily. Reciprocity users can utilize this function
to search across eMASS for the re-use and acceptance of systems that have an existing RMF
assessment and authorization by another Organization. The eMASS Reciprocity Job Aid(https://rmfks.osd.mil/rmf/HelpandResources/References/Reference%20Library/eMASS_Recipro
city_Job_Aid.pdf) is intended to assist a Reciprocity user in searching for and viewing Systemsecurity assessments located in any eMASS instance.
Accordingly, the “Interagency Partners” capability is intended to provide better support for thesecases of collaboration or information sharing efforts. Organizations, via their eMASS System
Administrators and Organization System Administrator, can identify and grant the Interagency
Partner (IP) role to their users as appropriate. The Interagency Partner role appears as an“Additional” role that can be granted to a user’s account. The eMASS Interagency Partner Job Aid(https://rmfks.osd.mil/rmf/HelpandResources/References/Reference%20Library/eMASS_InteragencyPartner_Job_Aid.pdf) is intended to assist an Interagency Partner user in searching for andviewing System security assessments located in external eMASS instances.
By default, all new records are listed as reciprocity systems when registering. Users must list a
reciprocity exemption justification if the option is deselected. Systems can also be designated as areciprocity system at any time through the “System Information” page. Systems that are enabled
for reciprocity will be visible to certain users across the various eMASS instances.

UNCLASSIFIED

19

UNCLASSIFIED
Reciprocity users can search for systems with reciprocity enabled using the “Search Reciprocity
Systems” hyperlink on the eMASS homepage. After entering search criteria and searching forsystems, eMASS will display the results and list all available systems and their associatedorganizations. (Systems will not appear in search results if they are decommissioned, have a DATO
authorization status, or have opted-out of the eMASS reciprocity capability.)Once a system is selected, users will have view-only access to system information, security control
assessments, POA&M items, artifacts, and system-level reports. This feature is designed to allow
users to find similar systems and utilize their existing RMF assessments more easily. For moredetailed information on eMASS capabilities, please refer to the eMASS Functionality guide(https://rmfks.osd.mil/rmf/HelpandResources/References/Reference%20Library/eMASS_Functio
nality_Guide.pdf ).

8. LIST OF ENTERPRISE AOS

The full list of Enterprise AOs will be made available on the RMF KS site(https://rmfks.osd.mil/rmf/PolicyandGovernance/RMFRoles/Pages/RoleDirectory.aspx) and it
will also be uploaded to the “Help” section in eMASS.

9. DOD CIO ROLE IN RESOLVING RECIPROCITY CONFLICTS

The Deputy Secretary of Defense (DSD) issued a memorandum in March 2024 (reference i),emphasizing the importance of a culture of collaboration in cybersecurity testing and reciprocity
in order to accelerate delivery of innovative capabilities while maintaining our cybersecurity
standards. The DSD expects testing re-use and reciprocity to be implemented except when the
cybersecurity risk is proven to be too great.
In a collaborative cybersecurity reciprocity culture, AOs trust one another and are inclined to
granting reciprocity, thereby accepting the risk determination to deploy a capability made byanother AO unless there are compelling operational and procedural reasons that prevent the risk
acceptance (i.e., to refuse reciprocity). Therefore, the Receiving AO should make every attempt toaccept the risk determination made by the Granting AO. However, before making the decision,
Receiving AOs must thoroughly review the security authorization package provided by the
Granting AO, focusing on content and not the organization or format. The content should clearly
demonstrate the security posture, risk assessment, and rationale for the risk determination.
Receiving AOs have the right to refuse participating in reciprocity with another organization due
to insufficient content demonstrating an informed understanding of the security posture, risk
assessment of the system, and the rationale for the risk determination as defined on the RMF KS,
or due to excessive risk to the enclave or site, as determined by the site AO. However, theReceiving AO must document and report this refusal to the Granting organization’s AO within 10
business days. If a refusal does occur, both organizations will continue to work, and re-work, theATO package to reach an agreement, if at all possible. When AOs cannot reach an agreement to
UNCLASSIFIED

20

UNCLASSIFIED
leverage re-use and reciprocity, both parties must use the following resolution process to gain
assistance in resolving the impasse:
1. If a conflict arises, due to reciprocity refusal there should be an attempt to resolve it at the
AO level. This could include, but not limited to, the Granting AO conducting newassessments.
2. If the conflict cannot be resolved at the AO level, the RMF TAG Secretariat will be notified
and the RMF TAG Chair will attempt to mediate the dispute as appropriate.
3. If the RMF TAG Chair cannot reach a resolution, the issue will be taken to the AO Council,
chaired by the DoD CISO, who will serve as a mediator for the dispute.
In addition to potentially mediating conflicts, DoD CIO plays a strategic role in shaping reciprocity
policies and frameworks. This includes advocating for standardized processes, fostering the
adoption of best practices, and championing the importance of leveraging trusted assessments fromother agencies or entities. By providing strategic direction and promoting a cohesive approach toreciprocity, DoD CIO contributes significantly to the organization's overall cybersecurity
resilience and effectiveness in an increasingly complex threat landscape.

10. CONCLUSION

In conclusion, this playbook serves as an invaluable starting point for organizations seeking tonavigate the intricate landscape of cybersecurity reciprocity. However, recognizing the dynamic
nature of the cybersecurity landscape, we encourage continuous improvement and collaboration.
Therefore, should you identify areas for enhancement or have innovative ideas to contribute to theplaybook, we invite you to engage with the RMF TAG Secretariat (osd.pentagon.dod-cio.mbx.rmftag-secretariat@mail.mil). Through this ongoing dialogue and collective efforts, we can continue
to fortify our defenses and employ cybersecurity reciprocity in DoD systems.

UNCLASSIFIED

21

UNCLASSIFIEDGLOSSARY
ACRONYMS
Acronym
3PAO

Meaning
third party assessment organization

AO
AODR
ATO
ATU

authorizing official
authorizing official designated representative
authorization to operateauthorization to use

BOEbody of evidence

CIO
CISO
CNSSI
CNSSP
CSO
CSP
CSSP
CUI

chief information officer
chief information security officer
Committee on National Security Systems Instruction
Committee on National Security Systems Policy
cloud service offering
cloud service provider
cybersecurity service provider
controlled unclassified information

DATO
DISA
DoD ISRMC
DoDI
DSAWG

denial of authorization to operate
Defense Information Systems Agency
DoD Information Security Risk Management Committee
DoD Instruction
Defense Security/Cybersecurity Authorization Working GroupeMASSEnterprise Mission Assurance Support Service

FedRAMP

Federal Risk and Authorization Management Program

IAVM
IL

Information Assurance Vulnerability Management
impact level

JAB
JFHQ-DODIN

Joint Authorization Board
Joint Force Headquarters-Department of Defense Information
Network

UNCLASSIFIED

22

UNCLASSIFIED
AcronymKS

Meaningknowledge service (RMF)

MO
MOA
MOU

mission owner
memorandum of agreement
memorandum of understanding

NIST
NSS

National Institute of Standards and Technology
National Security System

PA
PAO
P-ATO
POA&M
PM
POC

provisional authorization
principal authorizing official
provisional authority to operateplans of action and milestones
program manager
point of contact

RAR
RMF

risk assessment reportrisk management framework (for DoD systems)

SAR
SCA
SCA-R
SP
SRG
SRTM
SSP
STIG

security assessment reportsecurity control assessor
security control assessor-representative
special publication
security requirements guidesecurity requirements traceability matrix
system security plan
security technical implementation guide

TAG

Technical Advisory Group (RMF)

USCYBERCOM

United States Cyber Command

UNCLASSIFIED

23

UNCLASSIFIEDREFERENCES
a. Committee on National Security Systems Instruction Number 4009, “Committee on Nationalb. Security Systems (CNSS) Glossary,” March 2, 2022
c. Committee on National Security Systems Instruction Number 1254, “Risk Management
Framework Documentation, Data Element Standards, and Reciprocity Process for National
Security System” August 2016
d. Department of Defense Cybersecurity Resource and Reference Guide, 28 February 2022
e. Department of Defense Instruction (DoDI) 8510.01, Risk Management Framework for DoD
Systems, 19 July 2022
f. Department of Defense Manual (DoDM) 8530.01, Cybersecurity Activities Support
Procedures, 31 May 2023
g. Department of Defense Memorandum, Cybersecurity Reciprocity, 18 October 2016h. Department of Defense Memorandum, DoD Information System Certification andAccreditation Reciprocity, July 2009
i. Department of Defense Memorandum, Resolving Risk Management Framework andCybersecurity Reciprocity Issues, March 2024
j. Department of Defense Memorandum, Supporting Guidance on the Reissuance of DoD
Instruction (DoDI) 8510.01, “Risk Management Framework (RMF) for DoD Systems”, 29
March 2023
k. DISA Memorandum, Department of Defense (DoD) Memorandum of Reciprocity for
FedRAMP Authorized Moderate Baseline Cloud Service Offerings (CSO) at Impact Level 2(IL2), 15 August 2019l. Intelligence Community Directive Number 503, Intelligence Community Information
Technology Systems Security Risk Management, 21 July 2015
m. National Institute of Standards and Technology Special Publication 800-53, “Security andPrivacy Controls for Information Systems and Organizations,” December 10, 2020

UNCLASSIFIED

24