RMFInsider

Reciprocity means a receiving Authorizing Official accepts another DoD component’s assessment results and risk determination instead of putting the system through a second full RMF cycle. The receiving AO reviews the body of evidence, tests only the configuration differences created by the new environment, and issues an Authorization to Use rather than a brand new ATO. Controls that are built into the system and do not change on deployment are not retested. That is the written default in DoD policy, not a courtesy you are begging for.

What follows is the policy you can cite, the exact artifacts you hand over, what the receiving side is allowed to test, how to run the request end to end, and what happens when an AO refuses. If you want the parent policy in plain English first, start with the DoDI 8510.01 walkthrough and come back.

What reciprocity actually is

CNSSI 4009 defines reciprocity as an agreement among participating organizations to accept each other’s security assessments, to reuse system resources, and to accept each other’s assessed security posture in order to share information. The DoD Cybersecurity Reciprocity Playbook, dated January 2, 2024 and published by the DoD CIO, is explicit that this is not passive acceptance. The receiving AO still runs a risk based review of the body of evidence and still owns the decision for their enclave.

The line that matters is the one about testing. Security controls built into the system that do not change when the system is deployed do not need to be retested, and a receiving organization cannot require additional validation or verification testing except for configuration differences introduced by the new environment.

Nobody argues against reciprocity in a meeting. They just ask for one more ACAS scan because they would rather see it come out of their own instance, then a fresh set of STIG checklists because the granting component’s are three months old, and six weeks later you are running the assessment the policy said you did not need.

The policy stack you should be able to quote

• DoDI 8510.01, effective July 19, 2022: the DoD Information Enterprise will use cybersecurity reciprocity to reduce redundant testing, assessing, documenting, and the associated costs in time and resources.
• DoD Cybersecurity Reciprocity Playbook, January 2, 2024: the operational procedure, including body of evidence contents, refusal reporting, and escalation.
• CNSSI 4009: the definition of reciprocity used across national security systems.
• CNSSI 1254: RMF documentation and the reciprocity process for national security systems.
• CNSSP 22: cybersecurity risk management policy, referenced directly by DoDI 8510.01.
• NIST SP 800-37 Revision 2: defines the Authorization to Use as a streamlined authorization mechanism for a system another organization has already authorized.

DoDI 8510.01 also hands you a blunt instrument. It states that the DoD Information Security Risk Management Committee makes enterprise level risk acceptance determinations for authorized enterprise systems, and that if the committee accepts risk on behalf of the DoD Information Enterprise, the receiving organization may not refuse to deploy the system. If your system carries an enterprise risk acceptance, quote that sentence early.

Reciprocity, inheritance, and type authorization are not the same thing

These three get used interchangeably in meetings and they mean different things on paper. Getting the vocabulary right is the difference between a clean request and a confused one.

• Reciprocity: the receiving AO accepts another AO’s assessment and risk determination for a system being deployed into a new environment, and issues an Authorization to Use.
• Control inheritance: your package consumes controls provided by a hosting enclave or enterprise service, and the provider’s assessment satisfies those control bodies in your own system record. Read the control inheritance breakdown if you are wiring this up in eMASS.
• Type authorization: the granting AO authorizes a system intended for deployment to multiple sites with a fixed baseline, and each site AO issues a site specific approval covering the local implementation and physical environment.

The body of evidence you hand over

The Playbook names five core documents. If you are the granting side, package these before anyone asks. If you are the receiving side, ask for all five in one request instead of three rounds of email.

1. System Security Plan, including the authorization boundary description.
2. Security Assessment Report, finding by finding, not a summary slide.
3. Risk Assessment Report with the residual risk statements.
4. POA&M with open items, scheduled completion dates, and any accepted risk entries.
5. Authorization decision document, meaning the signed ATO letter with its terms, conditions, and authorization termination date.

Beyond the five, the Playbook expects deployment instructions, configuration specifications, and the authorization boundary diagram. In practice you should also expect current STIG checklists, ACAS scan output, and the hardware and software baseline list. The RMF artifacts checklist covers what a complete set looks like.

What the receiving organization may not retest

Anything baked into the product that does not change on deployment. If the vendor implements IA-5 password complexity in the application layer and that code ships identically to your enclave, the granting SAR already covers it. Asking for a fresh test of AC-7 unsuccessful logon attempts on an unchanged binary is exactly what the policy is written to stop.

What the receiving organization must test

Configuration differences created by the new environment, plus the enclave controls that were never the granting component’s to assess. That realistically means SC-7 boundary protection at your perimeter, CA-3 interconnections you are creating, AC-2 account management for local accounts and groups, the local group policy deltas, any STIG deviations your site applies, and physical and environmental controls at your facility. If the baseline itself changes, the local AO authorizes the new configuration on the strength of that additional testing.

Authorization to Use, not a second ATO

The output of a successful reciprocity request is an Authorization to Use. The granting organization keeps the authorization baseline, coordinates patches and updates, and is responsible for notifying receivers about system changes, newly discovered vulnerabilities, and decommissioning plans. Under the Playbook the granting organization also assigns a JFHQ-DODIN accredited cybersecurity service provider for continuous monitoring.

The receiving organization deploys using the authorized configuration, implements inherited controls and any local mitigations, executes the MOU, MOA, or SLA, and maintains the baseline through patch management and STIG compliance. Reciprocity moves the assessment burden. It does not move the operational burden, and it does not make your continuous monitoring reporting go away.

How to run a reciprocity request end to end

1. Confirm the granting authorization is current. Pull the decision document and write down the authorization termination date before anything else.
2. Request the full body of evidence in one written ask, listing the five core documents plus the boundary diagram and deployment instructions.
3. Diff the configuration. Put the granting baseline next to your intended deployment and list every delta: network placement, accounts, interconnections, STIG deviations, and any local software.
4. Write a delta test plan that maps each configuration difference to the specific controls it touches. Keep it to one page if you can.
5. Draft the agreement. An MOU or MOA covers responsibilities, and an SLA covers patch cadence and notification timelines.
6. Register the system in eMASS on the receiving side and record the reciprocity and inheritance relationships so the audit trail exists.
7. Route the delta results and the granting body of evidence to your AO for an Authorization to Use decision.
8. Set the continuous monitoring handshake in writing: who scans, who reports, who notifies whom, and on what schedule.

When the receiving AO says no

A receiving AO can decline. The Playbook preserves that right when the authorization package lacks sufficient content to demonstrate the security posture, or when the system poses excessive risk to the receiving enclave. What the Playbook does not do is make refusal cost free. Reciprocity refusals are documented and reported within 10 business days, and the conflict resolution path escalates from AO to AO discussion, to mediation by the RMF Technical Advisory Group chair, to the AO Council chaired by the DoD CISO.

Knowing that escalation path exists changes the tone of the conversation. You rarely need to use it. You need the other side to know you know it.

One timing rule is worth putting on your calendar now: granting organizations are expected to notify receiving organizations at least six months before any reauthorization event. If you are consuming someone else’s ATO, that notice is your early warning, and it is the same clock covered in what changes when an ATO expires.

Three arguments that move a reluctant AO

• Scope the delta narrowly and show your work. An AO who is handed a one page delta test plan with named controls is far more likely to sign than one handed a request to trust a stranger’s package.
• Give them the SAR finding by finding. Summaries read like sales. A finding list with severities and residual risk statements reads like engineering.
• Offer a bounded term. An Authorization to Use with a shorter authorization termination date and a defined reassessment trigger gives a cautious AO an exit ramp, which is usually what they actually want.

What to do this week

• Find out whether anything in your portfolio is already authorized somewhere else in DoD. Duplicate assessments of the same product across components are common and nobody flags them for you.
• Save a local copy of the Reciprocity Playbook and highlight the testing paragraph and the 10 business day refusal reporting line.
• Build a reusable delta test plan template so the next request takes an afternoon instead of a month.
• Add the granting system’s authorization termination date to your own calendar with a six month reminder.

Reciprocity is one of the few places in RMF where the policy is on the side of doing less work. The catch is that the burden of proof quietly lands on whoever wants the shortcut, so the winning move is to show up with a complete body of evidence, a narrow delta, and a citation ready. If you want the full artifact and evidence sequence in one place before you build the package, grab the RMF Checklist and work it top to bottom.