CA-6(2): Joint Authorization — Inter-organization

The ca-6(2): joint authorization — inter-organization requirement shows up when your system’s risk is not yours alone to accept. That happens in shared services, multi-tenant environments supporting government programs, interconnections between organizations, contractor-operated systems handling federal information, and platforms where another organization depends on your controls to meet their mission.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat CA-6(2) as an authorization governance requirement, not a technical control. Your job is to make sure (1) joint authorization is triggered under defined conditions, (2) the external authorizing official is identified and empowered to approve or reject risk acceptance, and (3) evidence proves the approval was informed by the system’s security posture and residual risk.

This page translates the control text into an operational playbook: who must be involved, what to document, how to run the decision, what artifacts to retain, and how to avoid the most common audit failures.

Regulatory text

Requirement (quoted): “Employ a joint authorization process for the system that includes multiple authorizing officials with at least one authorizing official from an organization external to the organization conducting the authorization.” ¹

Operator meaning: you cannot treat the authorization decision as a single internal sign-off when another organization is materially exposed to the system’s risks. Your authorization package and decision record must show:

• Multiple AOs participated (not just reviewers).
• At least one AO is external to your organization.
• The joint decision covers the system (or the defined authorization boundary) and includes explicit risk acceptance.
  ²

Plain-English interpretation (what the control is really asking)

CA-6(2) is about shared accountability for risk acceptance. If an external organization is relying on your system, connecting to it, or inheriting controls from it, they need a seat at the table when risk is accepted. This is common in:

• Inter-agency or inter-organization data sharing
• Contractor-operated information systems supporting a federal customer
• Shared platforms where one organization hosts and another consumes services
• Federated identity, network interconnections, and cross-boundary dependencies

A clean mental model: If their mission depends on your system, they get a vote on whether the residual risk is acceptable.

Who it applies to (entity + operational context)

Applies to:

• Federal information systems with cross-organization reliance or interconnections. ²
• Contractor systems handling federal data where the federal customer (or another external organization) must accept risk tied to the system’s operation. ²

Operational contexts that typically trigger CA-6(2):

• System interconnection where another organization connects networks or exchanges sensitive information.
• Shared authorization / inherited controls (e.g., your system provides a common security capability another organization inherits).
• Joint operations (your system supports a joint mission or a combined operational environment).
• External governance requirements where a customer AO must approve the authorization outcome.

What you actually need to do (step-by-step)

Step 1: Define your CA-6(2) trigger criteria

Write down conditions that force joint authorization. Keep it simple and auditable:

• The system has an external interconnection or external dependency where another organization is exposed to confidentiality, integrity, or availability risk.
• The system processes information owned by another organization and that organization requires formal risk acceptance.

Deliverable: CA-6(2) applicability statement (one page) that says when joint authorization is required and who makes the call (usually the system owner + GRC).

Step 2: Identify the authorizing officials (internal + external) and document authority

You need named roles, not “reviewed by customer.”

• Internal AO(s): typically your organization’s AO or delegated executive with risk acceptance authority.
• External AO: an AO (or formally delegated equivalent) from the external organization.

Deliverables:

• Role/authority memo or delegation letter showing the external AO’s authorization authority for this system decision.
• RACI for authorization activities (who prepares package, who assesses, who signs, who monitors).

Step 3: Align the authorization boundary and shared responsibility model

Joint authorization fails when organizations do not agree on what is being authorized.

• Define the system boundary (what components, environments, tenants, and interconnections are in-scope).
• Define shared responsibility (who owns which controls; what is inherited vs customer-managed).
• Map risks that cross boundaries (e.g., identity federation, network links, shared logging).

Deliverables:

• Boundary diagram(s)
• Shared responsibility matrix
• Interconnection description and, where applicable, an interconnection agreement aligned to the boundary

Step 4: Build an authorization package that supports an informed decision

Your authorization package needs to let an AO credibly say: “I understand the residual risk and accept it.” Minimum content most programs expect to see aligned to NIST authorization practices:

• Security plan content that describes controls and implementations
• Assessment results (what was tested, what failed, what is untested)
• POA&M or remediation plan for known gaps
• Risk summary that translates findings into operational impact and acceptance rationale

Deliverable: Authorization decision briefing (short) plus supporting package (detailed). Keep the briefing readable for executives.

Step 5: Run the joint authorization decision meeting and capture the decision

Operationalize the process so it is repeatable:

• Pre-brief both AOs on major risks and planned mitigations.
• Confirm that both organizations agree on the boundary and shared responsibility.
• Record conditions of authorization (e.g., required remediation actions, monitoring requirements, constraints on use).

Deliverables (critical evidence):

• Meeting agenda and attendee list
• Decision record with explicit outcomes: authorization granted/denied, terms, expiration/reauthorization triggers
• Signatures or secure e-sign approvals from multiple AOs, including the external AO

Step 6: Connect authorization conditions to continuous monitoring

CA-6(2) is not “sign once and forget.” If the external organization is a joint authorizer, they typically expect visibility into:

• High-risk POA&M items and remediation status
• Significant changes that could invalidate the authorization basis
• Incident notifications tied to shared risk

Deliverables:

• Continuous monitoring plan extracts relevant to the external AO
• Change control hooks: what changes trigger re-briefing or reauthorization
• Reporting cadence and distribution list that includes the external organization (as appropriate)

Required evidence and artifacts to retain

Auditors will ask you to prove the joint authorization was real, informed, and properly approved. Keep these artifacts in a controlled repository:

Governance and scoping

• CA-6(2) trigger criteria and applicability determination for the system
• AO appointment/delegation evidence for internal and external AOs
• RACI for authorization and continuous monitoring

Authorization boundary and dependencies

• System boundary diagrams and narrative
• Shared responsibility matrix
• Interconnection documentation aligned to the authorized boundary

Decision support

• Security plan sections relevant to control implementation
• Assessment outputs and risk/exceptions summaries
• POA&M with owners and timelines
• Authorization decision briefing

Decision and approval

• Joint authorization decision record
• Approvals/signatures from multiple AOs, including external AO
• Conditions of authorization and follow-up obligations

Practical tip: store a single “Joint Authorization Evidence Packet” PDF export for audits, even if the source artifacts live in multiple tools.

Common exam/audit questions and hangups

Expect these, and prepare crisp answers:

• “Why did CA-6(2) apply here?” Show your trigger criteria and the specific inter-organization dependency.
• “Who is the external AO and what authority do they have?” Produce the delegation memo or contract clause plus the named AO.
• “Show me the decision record.” Auditors want a dated decision, scope, residual risk statement, and signatures.
• “What changed since authorization?” Be ready with change logs and continuous monitoring outputs tied to authorization conditions.
• “How do you handle disagreements between AOs?” Your process should define escalation and tie-break rules.

Frequent implementation mistakes (and how to avoid them)

1. Treating the external organization as a reviewer, not an authorizer.
   Fix: require external AO sign-off in the workflow, not optional “review.”

2. No documented boundary alignment.
   Fix: include boundary diagrams and a shared responsibility matrix in the packet; make both AOs attest to scope.

3. External AO is not actually external.
   Fix: verify organizational affiliation and delegation. Contractors supporting the same organization are not “external” for CA-6(2) purposes.

4. Approval without risk acceptance language.
   Fix: decision record must state residual risk acceptance (or denial) and any conditions.

5. Evidence scattered across email threads.
   Fix: centralize approvals and export audit-ready evidence packets from your GRC system.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this control enhancement, so you should plan for audit and oversight risk rather than case-law-driven expectations. The operational risk is straightforward: if a cross-organization system suffers an incident or control failure, the absence of a documented joint authorization can be treated as a governance breakdown and may affect continued operation approvals, renewals, or customer trust. ²

A practical 30/60/90-day execution plan

First 30 days (stand up the mechanism)

• Assign a CA-6(2) owner in GRC and name backups.
• Publish joint authorization trigger criteria and a one-page procedure.
• Identify systems that likely require joint authorization (interconnections, shared services, contractor-operated federal workloads).
• Draft templates: decision record, boundary attestation, shared responsibility matrix.

Days 31–60 (run it once, end-to-end)

• Pick one in-scope system and run a full joint authorization dry run.
• Confirm external AO identity and delegation evidence.
• Build the authorization briefing and evidence packet.
• Hold the decision meeting, record conditions, and capture approvals.

Days 61–90 (make it repeatable and auditable)

• Integrate CA-6(2) gates into change management (what changes trigger re-brief or reauthorization).
• Add continuous monitoring reporting pathways for the external AO where required.
• Run an internal audit-style evidence check: can you produce the full packet in one request?
• Automate reminders and evidence collection in your GRC tool. Daydream is a natural fit here because it can map CA-6(2) to a control owner, a documented procedure, and recurring evidence artifacts so your joint authorization packet stays audit-ready without rebuilding it each cycle. ¹

Frequently Asked Questions

Does CA-6(2) mean every system needs an external authorizing official?

No. It applies when the system’s authorization decision must be shared across organizations. Define trigger criteria so teams can consistently determine when joint authorization is required.

Who counts as an “external” authorizing official?

An AO from an organization outside the one conducting the authorization. Validate this with written delegation or formal documentation that ties the AO to the external entity.

Can the external AO delegate approval to a technical contact?

Only if the delegation is documented and grants authorization authority for risk acceptance. Keep the delegation evidence with the authorization decision record.

What if the external organization refuses to sign?

Treat it as a governance issue, not an administrative delay. Escalate per your procedure, document the disagreement, and do not represent the system as jointly authorized without the required approval.

How do we handle joint authorization for a shared cloud environment or managed service?

Start with boundary definition and a shared responsibility matrix. Joint authorization should clearly state what parts of the environment are covered, what controls are inherited, and what risks remain with each party.

What evidence is most important in an audit?

The signed joint authorization decision record (with an external AO), plus traceability to the boundary definition and the risk/assessment materials that informed the decision.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5