CA-6(1): Joint Authorization — Intra-organization

CA-6(1) requires you to run a joint system authorization where more than one authorizing official inside your organization participates in the authorization decision and signs off under a defined process. To operationalize it fast, define which systems require joint authorization, assign the authorizing officials, build a repeatable decision workflow, and retain signed authorization records and meeting artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define a documented joint authorization workflow with named intra-organization authorizing officials for in-scope systems. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Make joint authorization evidence audit-ready: approval package, sign-offs, decision rationale, and conditions of authorization. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Prevent “rubber-stamp” approvals by requiring independent review inputs and a recorded resolution process for disagreements. (NIST SP 800-53 Rev. 5 OSCAL JSON)

CA-6(1): joint authorization — intra-organization requirement is about governance discipline at the moment risk is formally accepted. Instead of a single Authorizing Official (AO) making the call, the control enhancement expects a joint authorization process where multiple authorizing officials from the same organization conduct the authorization. That design reduces single-person bias, forces cross-functional accountability (security, mission/business, privacy, operations), and creates a cleaner trail of who accepted what risk and under what conditions. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat CA-6(1) like a workflow requirement with a clear “definition of done”: (1) scope which systems require joint authorization, (2) name the authorizing officials and alternates, (3) standardize the authorization package and meeting cadence, and (4) lock down the evidence set so you can prove the joint decision happened. If your authorization process already exists (ATO, internal security authorization, production go-live), CA-6(1) is usually an upgrade, not a rebuild. The work is mostly governance: roles, gates, and artifacts that an assessor can follow end-to-end. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (verbatim): “Employ a joint authorization process for the system that includes multiple authorizing officials from the same organization conducting the authorization.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What an operator must do

You must implement an authorization process where:

1. More than one authorizing official participates, and
2. Those officials are within the same organization, and
3. They conduct the authorization (meaning they review the authorization basis and render the decision, not just get copied on an email). (NIST SP 800-53 Rev. 5 OSCAL JSON)

This is a process control. Auditors will look for repeatability, role clarity, and evidence that the joint decision actually occurred for each in-scope authorization event. (NIST SP 800-53 Rev. 5)

Plain-English interpretation

CA-6(1) means: for certain systems, you cannot have a lone AO approve operation based on a security package in isolation. You need a joint decision by multiple authorizing officials inside the organization, with a defined method for review, concurrence, and final approval (or documented dissent and escalation). (NIST SP 800-53 Rev. 5 OSCAL JSON)

A practical way to read it:

• “Joint authorization process” = a documented workflow with steps, inputs, and outputs.
• “Multiple authorizing officials” = named roles (not a generic “committee”), each empowered to accept risk within their remit.
• “Same organization” = do not substitute external parties (integrators, consultants, third parties) as authorizing officials, even if they advise. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entities

• Federal information systems and programs implementing NIST SP 800-53 controls.
• Contractor systems handling federal data where NIST SP 800-53 controls are contractually flowed down or used to meet federal requirements. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational contexts where CA-6(1) shows up

• ATO/authorization to operate cycles (initial authorization, reauthorization).
• Major changes that trigger a reauthorization decision (architecture shifts, hosting moves, new data types, new external connections).
• Boundary changes (shared services, new interconnections, acquisitions/mergers where system ownership changes).
• High-risk environments where the organization wants tighter risk acceptance discipline, even when not strictly mandated. (NIST SP 800-53 Rev. 5)

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

Step 1: Define in-scope “joint authorization required” triggers

Write a short rule set that answers: “When do we require joint authorization rather than single-AO authorization?” Keep it operational:

• System category (mission critical, high-impact, externally facing, processes regulated data).
• Authorization event type (initial, reauth, major change).
• Exceptions (and who can approve an exception). (NIST SP 800-53 Rev. 5)

Artifact: Joint Authorization Applicability Standard (1–2 pages) mapped to your system inventory. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Appoint the authorizing officials (and alternates) with written authority

Pick at least two authorizing officials from inside the organization. Common pairings:

• Security AO + Business/Mission AO
• System Owner executive + CISO delegate
• CIO/CTO delegate + Privacy/Compliance signatory (as applicable)

Document:

• Name/title
• Scope of authority (systems, business units)
• Decision rights (approve, approve with conditions, deny, time-bound approval)
• Alternate(s) and delegation rules. (NIST SP 800-53 Rev. 5)

Practical constraint: If your org chart doesn’t support multiple “AOs,” define “authorizing official” as a role in policy and assign it. The control cares that multiple empowered officials conduct the authorization. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 3: Standardize the joint authorization workflow

Build a repeatable workflow that produces the same evidence each time. Minimum viable workflow:

1. Package readiness check (GRC verifies the authorization package is complete).
2. Independent review by each authorizing official (recorded comments/risks).
3. Joint decision meeting (or asynchronous concurrence with recorded deliberation).
4. Decision output: approve, approve with conditions, or deny.
5. Conditions tracking: link conditions to POA&M items, owners, due dates, and closure evidence. (NIST SP 800-53 Rev. 5)

Operator tip: Put the workflow in a ticketing system or GRC tool so timestamps, assignees, and approvals are automatically recorded. Daydream can act as the control system of record: assign control ownership, embed the procedure, and schedule recurring evidence requests so CA-6(1) doesn’t degrade into “we did it once.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 4: Define how disagreements are resolved

Joint authorization fails in practice when two officials disagree and the org improvises. Set rules:

• What counts as “non-concurrence”
• How it’s recorded
• Escalation path (e.g., to a risk executive/steering group)
• Whether conditional approval is allowed and what minimum conditions must include. (NIST SP 800-53 Rev. 5)

Artifact: Joint Authorization Decision Procedure (including dissent handling). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 5: Train the participants and rehearse once

Run one tabletop using a real authorization package. Validate:

• Each official knows what they are expected to review.
• The meeting produces a decision and conditions that can be tracked.
• Evidence output is complete without post-hoc reconstruction. (NIST SP 800-53 Rev. 5)

Step 6: Operationalize recurrence and monitoring

CA-6(1) is assessed on operation, not intent. You need:

• A cadence for upcoming authorizations (calendar + pipeline).
• A mechanism to ensure no in-scope system is authorized without joint sign-off.
• Periodic quality checks of the evidence package for completeness. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Keep evidence at two levels: process design and per-authorization execution.

Process design evidence

• Policy or standard requiring joint authorization for defined triggers. (NIST SP 800-53 Rev. 5)
• Role letters / appointment memo for each authorizing official and alternates. (NIST SP 800-53 Rev. 5)
• Joint authorization procedure (workflow steps, required inputs/outputs, dissent handling). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Template approval record (decision options, conditions fields, signatory blocks). (NIST SP 800-53 Rev. 5)

Execution evidence ¹

• Authorization package index (what was reviewed and where it lives).
• Evidence of independent review (comments, annotated risk memo, review tasks completed).
• Meeting agenda + minutes (or recorded decision log) showing participation.
• Signed authorization decision record with multiple internal authorizing officials.
• Conditions of authorization and linkage to POA&M tracking with closure evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Expect assessors to test “joint” and “authorizing” as real decision authority.

1. Who are the authorizing officials, and where is their authority documented? Provide appointment memos and policy references. (NIST SP 800-53 Rev. 5)
2. Show a recent authorization and prove more than one official conducted it. Produce the signed decision plus deliberation artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. Was the joint authorization required for this system/event? Show your trigger criteria and the system’s classification. (NIST SP 800-53 Rev. 5)
4. How do you handle disagreement or non-concurrence? Show the procedure and at least one example if available. (NIST SP 800-53 Rev. 5)
5. How do you ensure conditions are tracked to closure? Show POA&M linkage and evidence of follow-through. (NIST SP 800-53 Rev. 5)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “joint authorization” as CC’ing multiple leaders	Presence is not the same as conducting the decision	Require independent review tasks and recorded concurrence/non-concurrence. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Using a committee with no clear decision rights	Auditors will ask “who is accountable?”	Name specific authorizing officials and document authority and alternates. (NIST SP 800-53 Rev. 5)
No dissent mechanism	Disagreements lead to ad hoc approvals	Define escalation, required documentation, and acceptable conditional approvals. (NIST SP 800-53 Rev. 5)
Evidence is reconstructed after the fact	Creates gaps and credibility issues	Build the workflow in your GRC/ticketing tool so approvals and timestamps are native records. (NIST SP 800-53 Rev. 5)
Conditions of authorization are not tracked	You “approved” risk but didn’t manage it	Tie conditions to POA&M items with owners and closure evidence. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CA-6(1). Treat the risk as assurance and accountability risk: if you cannot prove joint authorization happened, you will struggle to demonstrate compliant authorization governance during assessments or customer due diligence, and you increase the chance of unmanaged risk acceptance (approvals without cross-functional scrutiny). (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Confirm which systems and authorization events require joint authorization, and document triggers. (NIST SP 800-53 Rev. 5)
• Identify and appoint the authorizing officials and alternates; collect written authority documentation. (NIST SP 800-53 Rev. 5)
• Draft the joint authorization workflow and the decision record template. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Day 31–60 (operationalize)

• Implement the workflow in your system of record (GRC platform or ticketing). Configure required fields so approvals cannot close without multiple signatories. (NIST SP 800-53 Rev. 5)
• Pilot on one real authorization package; capture the full evidence set. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Add conditions-to-POA&M linkage and define ownership for follow-up. (NIST SP 800-53 Rev. 5)

Day 61–90 (scale and audit-proof)

• Roll out to all in-scope systems; update your authorization calendar and gating so no joint-required authorization bypasses the process. (NIST SP 800-53 Rev. 5)
• Run an internal control check: sample authorizations and verify evidence completeness end-to-end. (NIST SP 800-53 Rev. 5)
• In Daydream, map CA-6(1) to a control owner, embed the procedure, and set recurring evidence expectations so you can answer audits with a consistent package. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does CA-6(1) require a specific number of authorizing officials?

The text requires “multiple authorizing officials,” so you need more than one. Define the exact number in your internal procedure and apply it consistently across in-scope systems. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Can the ISSO, ISO, or system security engineer count as an authorizing official?

They can participate, but “authorizing official” implies documented authority to accept risk for operation. If the role does not have that authority in writing, treat it as advisory and keep the actual joint signatories as authorized officials. (NIST SP 800-53 Rev. 5)

Can we satisfy this with an internal risk committee instead of named officials?

Only if the committee process identifies the actual officials who have authority and captures their concurrence/non-concurrence as the authorization decision. A meeting attendee list without empowered sign-off usually will not be enough. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is most likely to fail an audit?

Missing signatories, unclear authority for the signers, or no record that the officials reviewed the package before approval. Build the workflow so those artifacts are created automatically as part of the approval gate. (NIST SP 800-53 Rev. 5)

How do we handle urgent go-live decisions?

Define an emergency joint authorization path that still requires multiple internal officials to approve, even if asynchronously, and require a follow-up ratification meeting with documented conditions. Keep the exception criteria narrow and documented. (NIST SP 800-53 Rev. 5)

How should we map CA-6(1) in our GRC tool?

Create a control record with a named owner, attach the procedure, and define recurring evidence artifacts (appointment memos, decision records, meeting minutes, POA&M linkage). Daydream supports this style of mapping so evidence collection stays consistent across authorizations. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Footnotes

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