CA-6 Authorization: requirements and evidence

What CA-6 authorization asks before a system goes live

CA-6 requires an organization to assign a senior official as the authorizing official for the system and for any inheritable common controls, to have that official authorize the system to operate and accept inherited common controls before operations begin, and to update the authorization at a defined frequency. If an agency, contract or FedRAMP requirement asks for a documented authorization decision, this control is the one it is asking about. The risk it addresses is simple: a system runs in production with no named senior owner who has formally accepted the residual risk. In practice the control breaks down in three predictable places. Ownership is unclear because the person who signs is not the person who runs the system. Inheritance is undocumented, so a team relies on a provider's controls without a written record of what was accepted and by whom. And the authorization is treated as a one-time signature, not a decision that must be revisited when the system or its threats change.

The control is selected in the low, moderate and high security control baselines and in the privacy baseline in SP 800-53B Release 5.2.0, so a system categorized at any impact level will carry it. Its two enhancements, CA-6(1) and CA-6(2), are not selected in any of those baselines, which means an assessor will test the base control unless your authorization agreement or contract adds them. Confirm that scope early with the authorizing official and the party requesting the authorization, because it determines what evidence the assessor will ask for. Before any assessment begins, ask three questions: who is the authorizing official for the system and for each common control, which controls are inherited and from which documented source, and on what date the authorization must be revisited. Written answers to those three questions are the foundation of the authorization package that an independent assessor will review.

Which systems, common controls and inherited services fall under CA-6

CA-6 applies to each information system and to any common controls that other systems inherit, so the first scoping decision is where one authorization boundary ends and another begins. The impact level from security categorization then determines which SP 800-53B baseline applies and how much documentation the authorizing official has to review.

Each information system needs its own authorization

CA-6 asks for an authorization decision per system, so the boundary has to be drawn before anyone signs. Check whether a shared platform, a database cluster or a set of applications has one owner, one set of components and one risk decision. If the boundary is drawn too wide, the authorizing official reviews more than they can assess. If it is drawn too narrow, the organization ends up with many authorizations that cannot be compared. Confirm the boundary in the system security and privacy plan.

Common control providers and their authorizations

A common control provider implements controls that several systems inherit, such as a central logging service or a physical data center. CA-6 requires an authorizing official for these inheritable common controls, separate from the systems that depend on them. Ask who owns each common control, who accepts it, and how often that acceptance is revisited. A system that inherits a control without a current common control authorization has an unsupported assumption in its own authorization.

Cloud and third-party services that supply inherited controls

Hosting providers, managed identity services and SaaS tools often supply controls the organization does not run itself. Those inherited controls still need to be documented, scoped and accepted by the authorizing official before operations begin. Request the provider's control responsibility matrix and any authorization evidence it holds, then record which controls are inherited, which are shared and which remain with the organization. Where a provider's evidence does not cover a control, the gap belongs in the authorization record.

Impact level sets the baseline

The security categorization of a system determines whether it falls in the low, moderate or high SP 800-53B baseline. CA-6 is selected in all three baselines, but the controls around it, and the depth of the documentation placed before the authorizing official, grow with impact level. Confirm the categorization was approved before the baseline was selected. A system categorized too low will reach authorization with fewer controls and less evidence than its risk requires.

Privacy baseline systems need their own decision

Systems that process personally identifiable information carry the privacy baseline, which applies regardless of impact level. CA-6 is selected in that baseline too, so the authorizing official decides on privacy controls alongside security controls. Check that the privacy plan is an input to the authorization package and that privacy-specific assessment results reach the decision. Treating privacy as a separate review that happens after authorization leaves the decision unsupported.

Updating authorizations when the system changes

An authorization covers the system as it was assessed, so changes to boundary, components, providers or impact level can invalidate the decision. Track change requests, inherited control changes from providers and new interconnections against the authorization record. Ask who decides whether a change needs a new or updated authorization and how that decision is written down. Changes that arrive through inherited services are the ones most often missed.

How an assessor tests CA-6 with six determination statements

This table maps how an assessor works through the CA-6 procedure in SP 800-53A, from the determination statements to the examine, interview and test objects that show whether authorization is real. Read each row as a question the assessor will ask and the evidence that answers it. Confirm the exact wording of every determination statement on CSRC before you build an assessment plan from this summary.

Assessment focus	What the assessor checks	Evidence that passes	Where it usually fails
Authorizing official assignment	A senior official is named as authorizing official for the system and for inheritable common controls, and the assignment is current	Signed designation memo, role description and the authorization statement naming the official	No documented authorizing official, or a designation that lapsed after a reorganization
Authorization before operation	The system is authorized to operate before operations begin, not after go-live	Authorization statement dated before the production cutover, linked to the assessment report and POA&M	Authorization signed after go-live, or production traffic running under an informal approval
Acceptance of inherited common controls	Common controls provided by another organization or internal program are accepted by the authorizing official before operations begin	Inheritance statements in the system security plan, acceptance记录 from the common control provider's authorizing official	Inherited controls assumed accepted without a recorded decision, or provider authorization is out of date
Defined update frequency	Authorizations are updated at the frequency the organization defined, and triggered updates occur after significant changes	Authorization history showing each update, the defined frequency in policy and change records tied to re-authorization	Missed update cycles, or no trigger that reopens authorization after major system changes
Examine: documents	Assessor reviews the objects SP 800-53A lists for CA-6, including the system security plan, privacy plan, assessment report, POA&M and authorization statement	Documents that agree on system boundary, control status and risk acceptance decisions	Plans and authorization statements that describe different boundaries or control states
Interview: authorization personnel	Assessor interviews personnel with authorization responsibilities about their role, decisions and update process	Consistent answers from the authorizing official, system owner and security lead, backed by records	Staff unaware of who holds authority or how updates are triggered
Test: authorization mechanisms	Assessor tests the mechanisms that facilitate authorizations and updates, such as workflow, approval tooling and tracking records	Working workflow with timestamps, approvals and retained versions of each authorization decision	Approvals handled by email with no retained record or no way to trace a decision to a version

Steps to get a signed authorization decision

The sequence below takes a system from a confirmed impact level to a documented authorization decision with stated conditions. Each step produces a record that the authorizing official and an assessor can both trace back to the controls.

Confirm the security categorization and baseline
The system owner and the information security lead confirm the impact level of the information and services the system handles, then select the SP 800-53B baseline that matches it. Tailoring decisions, such as added or removed controls and any overlays, are recorded in the system security and privacy plan. Done means the categorization, the selected baseline and each tailoring decision are approved and filed with the plan. Confirm with your own risk office how categorization is documented, since the review path varies by organization.
Name the authorizing official and document the delegation
Senior management assigns a senior official as the authorizing official for the system and a separate senior official for any common controls that other systems inherit. The assignment is written, names the official's authority to accept residual risk, and is signed by the official's management chain. Done means each authorizing official has a dated appointment on file. Ask whether your organization allows delegated authority for routine decisions and how that delegation is recorded.
Define the common control provider and the inheritance map
The organization identifies which controls are provided at the enterprise or shared-service level and which remain the system's own responsibility. The common control provider documents each inherited control, the party that operates it and the evidence the receiving system can rely on. Done means an inheritance register lists every common control, its provider, its status and the authorization it depends on. Keep this register current, because inherited controls change when the provider's authorization changes.
Complete the control assessment and assessment report
Assessors independent of the people who built the controls test them against the SP 800-53A assessment procedures, using examine, interview and test methods. The assessor records findings in an assessment report, including which determination statements were satisfied, partly satisfied or not satisfied. Done means a signed assessment report covers every selected control, including inherited controls that the receiving system relies on. An independent assessor or auditor issues this report, not the implementation partner.
Produce the plan of action and milestones
The system owner turns each weakness or deficiency in the assessment report into a plan of action and milestones entry with an owner, a planned remediation action and a completion point. Open items that cannot be closed before the decision are labeled so the authorizing official sees them clearly. Done means the plan of action and milestones is complete, reviewed by the assessor for accuracy and attached to the authorization package. Confirm how your organization sets milestone dates and who must approve extensions.
Present the residual risk to the authorizing official
The system owner and the security lead brief the authorizing official on the risk that remains after controls and open remediation items are considered. The briefing covers the assessment results, the open plan of action and milestones items, any inherited control gaps and the conditions under which operation would be acceptable. Done means the authorizing official has reviewed the full authorization package and has asked any questions needed to decide. A clear summary of residual risk is more useful to the decision than a long list of findings.
Record the authorization decision and its conditions
The authorizing official signs an authorization statement that states whether the system is authorized to operate, the time period the authorization covers if your program sets one, any conditions attached to operation and the date of the decision. The decision is also recorded for each common control the official accepts for inheritance. Done means the signed statement is stored with the system security and privacy plan and is visible to every party that inherits from the system. Consider the decision's conditions as the first items your continuous monitoring must track.
Set the update frequency tied to continuous monitoring
The organization defines when the authorization must be reviewed and what changes trigger an earlier review, such as a significant change to the system or to an inherited control. Continuous monitoring data, including assessment results and plan of action and milestones progress, feeds that review. Done means the review schedule and triggers are written into the authorization record and assigned to a named owner. Ask your authorizing official and your program office which triggers they expect for your environment.

Authorization evidence an assessor will ask for

An assessor testing CA-6 does not just ask whether an authorization exists. They trace the decision backward: who had the authority to make it, what the authorizing official reviewed, which inherited controls were accepted, and whether the authorization was kept current as the system changed. The artifacts below are the records that show that chain, and each one needs an owner who keeps it current between assessments.

Signed authorization statement

The authorization decision itself, signed by the authorizing official, with the date, the system or common control set covered, the authorization boundary and any conditions attached. Assessors check that the statement names the scope precisely and that it predates the start of operations. Keep the signed version in the system's authorization package and record the expiration or next review date beside it. The system owner usually drafts the statement, but only the authorizing official signs it.

Authorizing official appointment record

The written delegation that gives a senior official the authority to authorize the system and any inheritable common controls. Assessors look for the official's title, their position in the organization and the date of appointment, and they confirm the person signing the decision is the one named. Update the record whenever the role changes hands, and keep the previous appointment on file so older authorizations can still be traced to the right official.

Inheritance register and common control letters

A register listing each common control the system inherits, the provider that owns it, and the date the authorizing official accepted it. Assessors compare the register against the system security plan to confirm that no inherited control is claimed without an accepted provider statement. Maintain the register with the platform team that owns common controls, and reissue the acceptance letter whenever the provider changes a control it supplies.

Assessment report and POA&M behind the decision

The assessment report and plan of action and milestones that the authorizing official reviewed before deciding. Assessors check that the authorization references a specific report version and that open weaknesses appear in the POA&M with owners and dates, not in the signed statement as a silent exception. Store both as a fixed pair in the authorization package, and link each POA&M item back to the assessment finding it came from.

Update schedule and records of past updates

The defined frequency at which the authorization is reviewed or renewed, together with a log of each prior update, its trigger and its outcome. Assessors compare the schedule in the organization's policy against the dates in the log, and they look for gaps. The compliance lead owns the schedule and records each review even when the decision is unchanged, because a missing entry reads as a lapsed authorization.

Significant change records triggering re-authorization

Change tickets, architecture diffs and impact analyses for significant changes that required the authorization to be revisited, such as a new internet-facing interface, a move to another hosting environment or a change in the data categories processed. Assessors sample recent changes from the configuration management records and ask whether each significant one was routed to the authorizing official. The change manager owns the classification step, and the system owner confirms the impact analysis.

What CA-6 authorization costs in staff time, tooling and assessment

This table breaks the cost of an SP 800-53 CA-6 authorization into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to see where open-source tooling removes license spend while labor stays. NIST does not publish compliance cost estimates, so the figures you need must come from your own scope and quotes.

Cost component	Who is paid or who spends time	One-time or recurring	Main cost drivers
Authorizing official time for review and signature	Senior official in the organization, plus staff who brief them	Recurring at each authorization decision and update	Number of systems, number of common control packages, and how often authorizations are renewed
Engineering time to build the inheritance register and package	Internal engineers or an implementation partner under a written scope	One-time build, then recurring maintenance	Number of inherited control providers, depth of the inheritance mapping, and quality of existing documentation
System security and privacy plan tooling and records	Licenses for commercial governance tools, or self-hosted open-source platforms with internal admin time	License spend is recurring; setup labor is one-time	Choice of tool, hosting effort, integration with scanners and ticketing, and whether frameworks must be maintained
Independent assessment effort that feeds the decision	Independent assessor or assessment team selected by the organization	Recurring at each assessment cycle, with one-time onboarding	Selected baseline, number of controls in scope, evidence readiness, and how many findings reach the plan of action and milestones
Inherited control acceptance and provider documentation	Internal owners of common controls and external providers that supply evidence	Recurring when providers change or reassess	Number of providers, contract terms that give access to evidence, and how often inherited controls change
Periodic updates and significant change reviews	Security and engineering staff who manage system changes	Recurring for the life of the system	Change frequency, release cadence, and whether updates trigger a new authorization decision
Tooling and hosting for open-source platforms	Internal platform team or implementation partner for installation, hardening and backups	Setup is one-time; hosting and upkeep are recurring	Infrastructure choice, number of users, upgrade cadence and the staff who operate the tool

How CISO Assistant can hold authorization records

CISO Assistant is an open-source governance tool that a team can evaluate for keeping CA-6 records in one place. Its README describes it as shipping more than 200 frameworks, including NIST CSF, and running audits and compliance assessments against them with automatic mapping between frameworks. For CA-6, the practical question is whether a team can record the authorizing official's decision, the authorization date and conditions, the authorization boundary, the inherited common control list and the open findings from the assessment report in linked objects, so that a reviewer can trace an authorization back to its evidence. Confirm before adopting it that its SP 800-53 content matches the Release 5.2.0 control and enhancement set your assessor uses, and that its authorization workflow can represent your organization's own approval steps, reauthorization triggers and signature requirements. Do not assume the mappings it generates are the same as NIST's crosswalk, which does not list CA-6 against any CSF 2.0 subcategory.

Ask the vendor or community maintainers to demonstrate a sample system record end to end: a system with a named authorizing official, one common control inherited from another system, one open POA&M item tied to an assessment finding, and a scheduled update to the authorization. Confirm where each of those fields lives, who can edit them, and whether changes are logged. If the tool cannot record the authorization statement itself as a controlled document, plan to keep that signed artifact in your document repository and link to it from the record. Treat the tool as a system of record for tracking only. The authorizing official still makes the decision, and an independent assessor still reviews the evidence.

The license matters before any customization. CISO Assistant is licensed under AGPL-3.0-only. If your organization modifies the software and makes it available to others, including users who interact with it over a network, the AGPL-3.0-only terms generally require you to offer the corresponding source of your modified version under the same license. Internal use without distribution carries different obligations. Have your legal counsel review the license against your planned deployment, especially if you add custom SP 800-53 content or integrations and then expose them to a contractor, agency or customer. Keeping customizations in separate configuration or content files can simplify that review, but counsel should confirm the approach for your situation.

What your team, a partner and the auditor each do for CA-6

Under CA-6, the organization owns the authorization decision and everything that stands behind it. The authorizing official, a senior official with the authority to accept risk on the organization's behalf, is the person who decides whether the system may operate. The system owner keeps the day-to-day record of how the system is secured, and the security office runs the process that connects those records to the decision. Your team holds these responsibilities whether or not an outside party helps with the work.

Authorizing official: Assigns the authorization decision, reviews the risk described in the assessment results and plan of action and milestones, and signs the authorization statement for the system and for any inheritable common controls.
System owner: Maintains the system security plan, the inheritance map that shows which controls come from common control providers, and the operating conditions the authorization depends on.
Security office: Defines the authorization process, sets the update triggers and frequency, tracks open remediation items and confirms that significant changes are reviewed before they reach production.
Common control providers: Accept or reject inherited controls in writing, and tell authorizing officials when their own controls change.
Records: Keep the signed authorization, its date, its conditions and its expiry or review point in a place an assessor can reach.

Confirm that each named role has a written appointment and that the authorizing official has authority over the risk the system carries.

Where CA-6 authorizations usually fail and how to close each gap

CA-6 authorizations tend to fail on paperwork that should have been done before operations began, not on the technical controls themselves. The six gaps below cover who signs, what is accepted, when the decision is made, when it is refreshed, what the remediation plan does, and how systems with different baselines are grouped. Each one has a fix and an artifact an assessor can check.

No formally appointed authorizing official

CA-6 requires a senior official to be assigned as the authorizing official for the system and for inheritable common controls. Many programs have a capable senior leader who signs informally, but no written appointment that names the role, its scope and its authority to accept residual risk. Confirm that the appointment exists, names the official for each system boundary and common control set, and is dated before the first authorization decision. Ask who can accept risk in the absence of that official.

Inherited controls assumed accepted

Systems often inherit controls from a hosting platform, a shared service or a common control provider, and teams treat that inheritance as settled. CA-6 expects the authorizing official to accept inherited common controls, which needs a written acceptance that names each control, the provider's responsibility and the evidence reviewed. Check that every inherited control in the system security plan links to a signed acceptance, and that the acceptance is revisited when the provider's control set changes.

Authorization dated after production launch

A system that goes live and is authorized weeks later has operated without authorization, which is the condition CA-6 is written to prevent. Teams often hold the authorization decision as a formality after deployment, or tie it to a document that is still being revised. Set the decision as a gate in the release process, and keep a record that shows the authorization date precedes the first production transaction or user access. Ask for that date in the authorization statement and compare it with the deployment log.

Authorization not refreshed after change

CA-6 requires authorizations to be updated at a defined frequency, and a significant change to the system, its boundary or its inherited controls can make an earlier decision inaccurate. Many organizations keep the original authorization letter and never link it to change records. Define in the program which changes trigger a reassessment and a new decision, then tie them to the change management tickets. Check whether the last authorization still describes the current architecture, components and data flows.

POA&M that does not inform the decision

The plan of action and milestones records weaknesses from assessments, and the authorizing official needs to see it before deciding whether residual risk is acceptable. In many programs the POA&M is maintained by a separate team, reviewed after the decision, or has overdue items that nobody escalated. Include the open POA&M items, their risk ratings and their planned dates in the authorization package, and record the official's acceptance of any item that remains open. Confirm that the POA&M version attached to the decision is the one dated on the decision day.

One authorization across different baselines

Grouping several systems under one authorization is efficient, but it becomes a gap when they carry different impact levels or selected controls from different SP 800-53B baselines. A decision written for a moderate system may not cover a component that requires high-baseline controls, such as the penetration testing requirement in CA-8. Build the boundary from the security categorization of each system, document which baseline applies to each component, and confirm the authorization statement names every system and its selected control set.

Questions buyers ask about CA-6 authorization cost, time and scope

What does CA-6 authorization require in plain terms?

CA-6 requires the organization to assign a senior official as the authorizing official for the system and for any common controls that other systems inherit, and to have that official authorize the system to operate, and accept inherited common controls, before operations begin. The authorization must then be updated at a frequency the organization defines. The authorization is a management decision that accepts the residual risk of running the system, so it is not a technical test. Assessment work, documentation and evidence feed that decision, but the decision itself stays with the official. You can read the control summary in the NIST CPRT catalog.

Who can act as the authorizing official under CA-6?

The authorizing official must be a senior official within your organization who has the authority to accept risk on its behalf. Organizations usually assign this to an executive such as a chief information officer, a chief risk officer or a business owner with budget authority over the system, and they document the assignment in writing. The role cannot be delegated to an outside consultant, auditor or implementation partner. The person should understand the mission impact of the system, the open risks listed in the plan of action and milestones, and what the authorization decision commits the organization to. Confirm your own delegation rules and the wording of your governing policy before you name the official.

Can an implementation partner make the authorization decision for us?

No. An implementation partner can prepare the system, the system security plan, the assessment inputs and the authorization package, but it cannot make the authorization decision or sign on behalf of your authorizing official. Under the scope DeployOpen works in, we plan, implement, harden and document self-hosted open-source platforms inside your infrastructure and prepare the evidence for compliance assessments. We do not issue audit reports, attestations or certifications. Decisions about accepting risk and granting authorization belong to your organization, and any independent assessment belongs to an independent assessor you select.

How long does CA-6 preparation take, and what drives the timeline?

No researched duration is available for CA-6 preparation, so do not rely on a generic number from a vendor or forum. Ask for a timeline in the written scope before work starts. The timeline depends on the number of systems and common controls in scope, how complete your existing system security plan and assessment report are, the impact level and baseline you selected, how many inherited controls need to be documented and accepted, and how quickly your authorizing official can review the package. Ask the partner to list each milestone, the internal reviews it needs and the dependencies on other teams.

What does the work need from our internal team?

The work needs named internal owners and scheduled time from several groups. Expect the following to be required:

An authorizing official who is available for review and decision.
System owners who confirm boundaries, components and interconnections.
Security and compliance staff who review the system security plan, the assessment report and the plan of action and milestones.
Infrastructure and application engineers who confirm configurations and provide access to evidence.
Legal or procurement staff when inherited controls come from a cloud or shared service provider.

Assign these owners before the engagement starts, because delays in review usually extend the authorization timeline more than technical work does.

Can we do CA-6 authorization in-house without outside help?

Yes, an organization can perform CA-6 in-house if it has an authorizing official, staff who understand the SP 800-53 control set, and the capacity to prepare the system security plan, assessment inputs and authorization package. Many organizations do the decision and governance work internally and bring in outside help for specialist tasks such as hardening, evidence collection tooling or testing. Consider outside help when the team lacks SP 800-53 experience, when several systems share common controls, or when a contract requires a specific authorization format. Whichever path you choose, the written scope should separate what your staff does from what the partner delivers.

How often must the CA-6 authorization be updated?

CA-6 requires the authorization to be updated at a frequency the organization defines, so the answer comes from your own policy and the contract or framework that applies to you, not from a fixed number in NIST's control text. Common triggers for an update include a significant change to the system, a change to inherited common controls, new critical findings in the plan of action and milestones, and the end of the defined period. Document the frequency and the triggers in your policy, and confirm with your assessor or contract owner that the cycle you chose meets their expectations.

What does CA-6 authorization cost, and what should a quote include?

No price or cost range for CA-6 authorization is supplied here, so direct cost questions to a written quote. The cost has several components: the internal staff time for the authorizing official and system owners, any independent assessment that you commission, and the implementation partner's fixed-scope work on documentation, hardening and evidence. Some costs are one-time, such as the first authorization package, while others recur, such as periodic updates and continuous monitoring. Ask any partner for a quote that lists deliverables, the systems and common controls in scope, assumptions about your existing documents, the roles you must staff and what is excluded.

How DeployOpen prepares CA-6 authorization evidence

DeployOpen works on CA-6 Authorization as an implementation partner: it prepares the system, the authorization package and the evidence an authorizing official needs to decide. The organization still assigns its own authorizing officials and makes the authorization decision, and only an independent assessor or the authorizing process itself produces the authorization outcome.

How we scope

We confirm the system boundary, impact level and the baseline the organization selects for CA-6 Authorization before any work starts.
We identify which authorizing officials, common controls and inherited controls the written scope covers, and who signs each decision.
Engagements are fixed-scope, so deliverables and timelines for the CA-6 evidence package are agreed in writing before work begins.

How we build

We prepare the system security and privacy plan, assessment report, POA&M and authorization statement that the authorization decision will rely on.
We document how common controls are inherited, so each receiving system can show which controls it accepts and which it must still implement.
We test the mechanisms that record authorizations and trigger updates, so the update frequency defined by the organization can be shown to work.

How we hand over

We deliver the authorization package with a traceable index mapping each CA-6 determination statement to the document or record that addresses it.
We provide a handover session so authorizing officials and assessors can walk through the package and ask questions before the decision.
We leave the organization with the source documents and configuration needed to refresh the package when the system or its inherited controls change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for systems that need authorizations updated over time.
Retainer scope for CA-6 covers changes to the system boundary, inherited control sets and update records, agreed in writing.
An independent assessor or certification body, not DeployOpen, reviews the package and issues any formal assessment outcome the organization requires.