CA-6: Authorization

CA-6: Authorization requires you to formally assign a senior official to act as the system’s Authorizing Official (AO) and to make that assignment explicit, documented, and auditable. Operationally, you need an AO designation memo/charter, clear decision authority for risk acceptance, and recurring evidence that the AO is identified and engaged in authorization decisions. ¹

Key takeaways:

• CA-6 is an accountability control: name the senior official who can accept risk for the system. ¹
• Auditors look for a documented AO assignment tied to a specific system boundary and current organization structure. ²
• “Assigned” must be provable: keep artifacts that show who, when, scope, and authority of the AO role. ¹

CA-6: Authorization is easy to underestimate because the control text is short. The operational reality is that it anchors your entire authorization model: who has the authority to accept security risk for a system and on what terms. If you cannot name that person, prove they are senior enough, and show their authority covers the system boundary, you create a governance gap that shows up in assessments as “no accountable risk owner.”

This requirement comes up in federal environments and in contractor environments handling federal data where system authorization practices are expected. It also appears indirectly when you map to authorization and governance expectations in related programs, even if your organization uses different internal terms (for example, “executive risk owner” rather than “Authorizing Official”).

This page focuses on fast operationalization: what to decide, what to document, what to retain as evidence, and what assessors typically challenge. The goal is a clean, defensible CA-6 implementation you can sustain through org changes, system boundary changes, and reauthorizations. ²

Regulatory text

Requirement (excerpt): “Assign a senior official as the authorizing official for the system;” ¹

What the operator must do

You must:

1. Identify the system boundary you are authorizing (what’s “the system” for purposes of CA-6).
2. Assign a senior official to be the Authorizing Official (AO) for that system.
3. Document the assignment so an assessor can verify who the AO is, that they are senior, and that the assignment is current and scoped to the right system.

This control is about role assignment and accountability. It does not, by itself, define how you run your authorization process, but it is a prerequisite for making authorization decisions defensible. ¹

Plain-English interpretation (what CA-6 is really asking)

CA-6 asks: “Who is the executive who can say ‘yes’ to operating this system with known risks?” You are expected to designate a real person (not a committee name), ensure they are sufficiently senior to accept risk on behalf of the organization, and be able to prove that designation on demand.

If your organization uses a risk committee model, you can still comply, but you need one accountable senior official as AO for the system. The committee can advise; the AO is the accountable decision-maker for authorization. ²

Who it applies to

Entity types

• Federal information systems
• Contractor systems handling federal data ¹

Operational contexts where it becomes “exam-critical”

• You operate systems that require a formal authorization decision and documented risk acceptance.
• Your system boundary includes shared services, cloud components, or inherited controls where accountability can get blurry.
• You have frequent org changes (reorgs, M&A, leadership turnover) that can silently invalidate AO designations.
• You have multiple systems and need consistent, system-specific AO assignment (one AO per system, or a defined AO scope that covers multiple systems explicitly).

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

Step 1: Define the authorization boundary you are assigning an AO to

• Confirm the system name, system identifier, and authorization boundary align across your SSP, asset inventory, and ATO artifacts (or your internal equivalents).
• Decide whether the AO is assigned per system or per portfolio, but document the scope either way.

Deliverable: System boundary statement (often embedded in the SSP). ²

Step 2: Select the Authorizing Official (senior official)

Pick a person who:

• Is senior enough to accept risk for mission/business outcomes.
• Has authority to allocate resources for remediation or accept residual risk.
• Is not so far removed that they cannot reasonably perform the AO responsibilities.

Practical test: If a serious risk is accepted and later challenged, would your organization credibly defend that this person had the authority to accept it for this system?

Deliverable: Named AO candidate and role justification (short rationale). ¹

Step 3: Create a formal AO designation artifact

Create one of these (pick what fits your governance):

• AO Designation Memo (preferred for clarity)
• AO Charter / Delegation of Authority Letter
• Governance policy section plus a system-specific AO appointment record

Minimum contents to include:

• System name and boundary reference
• AO full name, title, and org
• Effective date (and end date or “until superseded” language)
• Authority statement (what the AO can approve/accept)
• Signature by an appropriate appointing authority (often the agency head, CIO, CISO, or equivalent in your structure)

Deliverable: Signed AO designation artifact mapped to the system. ¹

Step 4: Tie CA-6 to an owner, procedure, and recurring evidence (so it survives audits)

CA-6 often fails in practice because it is treated as a one-time checkbox. Make it operational:

• Assign a control owner (typically GRC, Information Security, or the system program owner).
• Write a short procedure: how AO assignments are created, updated, reviewed after reorgs, and verified during authorization cycles.
• Define recurring evidence: what you will show every time someone asks “Who is the AO right now?”

This aligns to the recommended practice: map CA-6 to a control owner, implementation procedure, and recurring evidence artifacts. ¹

Step 5: Integrate the AO into your authorization workflow

Even though CA-6 is “assignment,” assessors often test whether the role is real.

• Ensure your authorization package or decision record references the same AO.
• Ensure POA&M risk decisions that require acceptance route to the AO (or documented delegate).
• If you use a tool (including Daydream), ensure the AO assignment is visible, reportable, and included in audit-ready exports.

Deliverable: Workflow evidence (ticket routing rules, approval records, decision logs). ²

Required evidence and artifacts to retain

Use this as your audit-ready checklist:

Evidence item	What it proves	Owner
Signed AO designation memo/charter	A senior official is assigned as AO for the system	GRC / Security
System boundary reference (SSP excerpt or boundary statement)	The AO assignment applies to the correct “system”	System Owner
Org chart excerpt or role description (as needed)	AO is plausibly “senior” and positioned to accept risk	HR / GRC
Authorization decision record (if your program has one)	AO is the decision-maker for authorization	GRC
POA&M risk acceptance records (where applicable)	AO participates in acceptance of residual risk	System Owner / GRC
Control mapping record for CA-6	CA-6 is assigned to a control owner with defined evidence cadence	GRC 1

Retention tip: keep “superseded” AO memos too. Auditors sometimes sample historic periods and ask who the AO was at that time.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where the Authorizing Official is assigned for this system.” ¹
• “How do you know the AO is a senior official?”
• “What triggers an AO reassignment (reorg, system boundary change, new system owner)?”
• “Is the AO assignment consistent across SSP, ATO letter (if used), and GRC tooling?”
• “Who acts as AO when the AO is unavailable, and where is delegation documented?”

Hangup pattern: teams can produce a policy that defines the AO role generally, but cannot produce a system-specific designation tied to the boundary.

Frequent implementation mistakes (and how to avoid them)

1. Assigning a group, not a person.
   Fix: Name an individual AO; committees can advise but do not replace accountability. ¹

2. AO assignment exists, but not scoped to the system.
   Fix: Include system identifier/boundary reference in the designation memo; cross-reference the SSP boundary.

3. AO is not “senior” in practice.
   Fix: Document why the role meets “senior official” intent (title, delegated authority, reporting line). If you must delegate, document delegation explicitly and keep the senior official as the AO.

4. Evidence goes stale after org changes.
   Fix: Add an operational trigger: revalidate AO assignments during reorgs, leadership changes, and authorization cycles.

5. CA-6 is not mapped to ongoing control operations.
   Fix: Maintain a CA-6 control mapping entry: control owner, procedure, and recurring evidence artifacts. Daydream-style control mapping makes this easy to keep current across systems. ¹

Risk implications (why auditors care)

If CA-6 is weak, the authorization decision becomes hard to defend. In practice, that causes:

• Unclear risk acceptance, leading to remediation delays and “decision vacuum”
• Conflicting approvals (CISO says one thing, IT says another)
• Assessment findings framed as governance failure rather than a technical gap

Even though CA-6 is a “paper” control, it affects whether technical risk decisions are legitimate and traceable to accountable leadership. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Inventory systems in scope for NIST SP 800-53 and identify missing AO assignments.
• Confirm system boundaries for high-priority systems (start with the ones assessed most often).
• Draft and route AO designation memos for signature.
• Create a CA-6 control record: owner, procedure, and evidence list. ¹

Days 31–60 (operationalize and connect to workflows)

• Update SSPs (or equivalent) to reference the AO consistently.
• Update authorization workflows so AO approval is captured in a system of record (ticketing/GRC tool).
• Add a revalidation trigger for AO assignment changes (reorg, system boundary changes, leadership turnover).
• Train system owners and GRC analysts on what evidence to produce on request.

Days 61–90 (make it audit-proof)

• Run an internal mini-assessment: pick a system and rehearse “show me the AO” evidence end-to-end.
• Validate that POA&M acceptance, exceptions, and authorization decisions route to the AO.
• Centralize evidence storage and versioning so you can answer point-in-time questions.
• If you manage many systems, standardize AO memo templates and track assignments in Daydream for reporting and audit exports. ²

Frequently Asked Questions

Does CA-6 require a formal ATO letter?

CA-6 only states you must assign a senior official as the authorizing official for the system. ¹ Many programs document authorization decisions in an ATO letter, but the requirement here is the AO assignment itself.

Can the CISO be the Authorizing Official?

Possibly, if your governance model gives the CISO senior authority to accept risk for the system. Document the scope and authority clearly in the AO designation artifact. ¹

We have a risk committee that approves exceptions. Is that enough?

CA-6 calls for assignment of a senior official as the authorizing official for the system. ¹ Committees can support decisions, but you still need a named AO accountable for authorization.

How do we handle AO delegation when the AO is unavailable?

Keep the senior official as the AO, and document delegation of signing authority separately with scope and effective dates. Ensure the delegate’s approvals are traceable back to that delegation record. ²

What is the minimum evidence an auditor will accept for CA-6?

A signed, current AO designation memo/charter tied to the system boundary is the cleanest evidence. Back it up with consistent references in your SSP or authorization documentation set. ¹

We have many systems. Can one AO cover all of them?

The control requires an AO “for the system.” ¹ One person can be AO for multiple systems if you document the scope explicitly and keep system-level traceability so it is unambiguous during audits.

Footnotes

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

2. NIST SP 800-53 Rev. 5