CA-1: Policy and Procedures

CA-1 sits in the NIST SP 800-53 “Security Assessment and Authorization” (CA) family and sets the expectation that your assessment program is governed, repeatable, and auditable. If your organization handles federal data as a contractor, or operates a federal information system, CA-1 becomes the front door to assessment readiness because it forces you to define how security assessments are planned, executed, reported, and kept current.

For a CCO or GRC lead, CA-1 is also a practical accelerator. Many assessment findings come from “we do this, but it isn’t written down” gaps: teams run risk assessments, track POA&Ms, or complete ATO steps, but can’t show a single authoritative policy, a usable procedure, and evidence of distribution and review. CA-1 closes that gap by making the “how we do CA work here” explicit.

This page gives requirement-level implementation guidance you can operationalize quickly: who must own CA-1, what documents to draft, how to distribute them, what artifacts to retain, and the exam questions you should pre-answer with your evidence package.

Requirement overview (plain English)

CA-1 requires you to write down how your organization governs security assessment and authorization, then make that guidance available to the people who need it, and keep it current. In practice, you need:

• A CA policy (management intent, scope, roles, compliance expectations).
• CA procedures (step-by-step instructions that implement the policy).
• A defined dissemination method (where it lives, who is notified, how access is granted).
• A maintenance loop (review triggers, approval workflow, version control, exceptions).

This is not a “write a PDF and forget it” control. CA-1 is passed when your documents match reality and you can prove the organization follows them.

Who it applies to

CA-1 applies in environments aligning to NIST SP 800-53 Rev. 5, including:

• Federal information systems.
• Contractor systems handling federal data (for example, systems supporting federal programs or processing federal information).

Operationally, it applies to teams that plan, execute, approve, or rely on assessments and authorizations, such as:

• GRC / security compliance
• Information security (CISO org)
• System owners and application owners
• Internal audit (where applicable)
• Engineering/operations teams supporting remediation
• Third-party assessors (as recipients of process guidance, not owners)

Regulatory text

NIST SP 800-53 Rev. 5 states: “Develop, document, and disseminate to {{ insert: param, ca-1_prm_1 }}:” ¹.

What the operator must do with this text

Even though the excerpt in your source data truncates the recipient list (the parameter placeholder), the operator expectation is still clear and testable:

1. Develop CA policy and CA procedures (create them intentionally; don’t rely on tribal knowledge).
2. Document them in controlled documents with approvals, versions, and ownership.
3. Disseminate them to the roles that execute or oversee CA activities (and retain proof of dissemination).
4. Operate them as the authoritative process for assessments and authorizations, with periodic updates consistent with your governance model ².

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

Step 1: Assign ownership and scope (make it auditable)

Create a CA-1 control record that answers, in one place:

• Control owner (name/title), backup owner
• In-scope systems (or the boundary definition method)
• Related documents (policy, procedures, standards, templates)
• Evidence cadence (what artifacts will exist “because the process ran”)

A simple way to operationalize CA-1 is to follow the recommended mapping control: map CA-1 to a control owner, implementation procedure, and recurring evidence artifacts ¹.

Step 2: Draft the CA policy (1–3 pages, executive tone)

Your CA policy should be short and enforceable. Include:

• Purpose and scope (systems, data types, business units)
• Roles and responsibilities (system owner, authorizing official or equivalent, security/GRC, assessors)
• Requirement to perform security assessments and maintain authorization decisions
• Required artifacts (assessment plans, assessment reports, POA&Ms, authorization packages, exception approvals)
• Governance: approval authority, review triggers (material system change, control baseline changes, major incidents), and document review expectations
• Exception handling: how deviations are requested, approved, time-bounded, and tracked

Avoid copying NIST text into a policy without your local decisions. Auditors want to see your operating model.

Step 3: Write CA procedures (operational checklists, not essays)

Procedures must be executable by practitioners. Build procedures around your actual workflows, for example:

• Assessment planning procedure: how scope is set, how controls are selected, how evidence is requested, and who approves the plan.
• Assessment execution procedure: how interviews/testing occur, how findings are rated, and how evidence is stored.
• Reporting procedure: how reports are reviewed, issued, and retained.
• Remediation/POA&M procedure: how owners accept findings, set milestones, and document completion.
• Authorization decision procedure: who reviews the package, how risk acceptance is documented, and how the decision is recorded.
• Continuous monitoring alignment: how reassessments are triggered and how changes are handled.

Write procedures so a new hire can run the process without “asking the one person who knows.”

Step 4: Disseminate with proof (treat this like a control test)

“Disseminate” is where many programs fail because distribution is informal. Pick a dissemination method you can evidence:

• Publish in a controlled repository (GRC tool, policy portal, or controlled document system).
• Require read-acknowledgment for defined roles (GRC team, system owners, assessors).
• Announce releases via ticketing or change management notes.
• Ensure access is role-appropriate (no broken links, no permission barriers for responsible staff).

Retain a dissemination log: audience list, date published, notification method, acknowledgment status, and link to the version.

Step 5: Tie CA-1 directly to recurring artifacts (your exam-ready evidence loop)

CA-1 becomes easy to audit when you can show artifacts created by the procedures, such as:

• A current assessment plan and completed assessment report for an in-scope system
• A POA&M with ownership and status tracking
• Authorization decision records (or equivalent governance sign-off)
• Meeting minutes or review notes showing governance operation
• Version history showing periodic policy/procedure updates

The point: evidence that the documents are not shelfware.

Step 6: Establish maintenance, review, and change control

Define:

• Who can update policy/procedures
• Required approvals (legal/compliance, security leadership, risk committee as applicable)
• How often you review (set your own cadence and triggers; don’t copy a number you can’t meet)
• How exceptions are handled and documented
• How you retire old versions and ensure teams use current versions

Required evidence and artifacts to retain

Use this as your minimum CA-1 evidence package:

Artifact	What it must show	Common auditor check
CA Policy	Approved, versioned, scoped, roles defined	Approval date, owner, applicability
CA Procedures	Step-by-step workflows that match practice	Procedures align to actual artifacts
Dissemination record	Who received it and when	Role coverage and access proof
Document control log	Version history, change summary	Controlled updates, not ad hoc edits
Training or acknowledgment	Staff can find and follow the process	Read receipts or LMS completion
Sample assessment artifacts	Proof the procedure runs	Traceability to policy/procedure

Common exam/audit questions and hangups

Expect these questions and pre-build the answers into your evidence binder:

1. Who owns CA-1 and how do they know it’s working? Show the control record and KPIs you track (for example, open assessment actions, overdue remediation items).
2. Where are the policy and procedures stored, and how do staff access them? Demonstrate live access during the exam.
3. Show an example of the procedures being followed. Produce a completed assessment package with timestamps and approvals.
4. How do you handle deviations? Provide an exception template and one redacted example.
5. How do you keep documents current after system changes? Point to change management hooks and review triggers.

Frequent implementation mistakes (and how to avoid them)

• Mistake: A policy exists but procedures don’t. Fix: write procedures as checklists tied to real artifacts (plans, reports, POA&Ms).
• Mistake: Procedures describe an ideal workflow no one follows. Fix: document the workflow you actually run, then improve it through controlled revisions.
• Mistake: No dissemination proof. Fix: require acknowledgments for roles, or maintain a ticketed release record tied to the document version.
• Mistake: One generic policy for all control families. Fix: keep enterprise policy structure consistent, but make CA-specific decisions explicit (assessment triggers, authorization governance).
• Mistake: Evidence sprawl. Fix: define a recurring evidence list per procedure and store it in a single system-of-record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CA-1 primarily as an assessment-readiness and governance risk control, not a penalty-citation control in this context. The practical risk is straightforward: if you cannot show documented and disseminated CA policy/procedures, assessors can’t rely on your assessment program, and downstream controls (assessments, authorization decisions, remediation tracking) become harder to defend ².

Practical 30/60/90-day execution plan

First 30 days (stabilize the minimum)

• Name the CA-1 owner and approvers; create the CA-1 control record.
• Inventory existing CA-related documents, templates, and repositories.
• Draft CA policy (short) and identify the procedure set you must document.
• Decide dissemination method and build a distribution list by role.

Days 31–60 (make it executable and testable)

• Write CA procedures as checklists aligned to your current assessment workflow.
• Build required templates: assessment plan, assessment report, POA&M entries, authorization memo, exception request.
• Publish documents in the controlled repository with versioning.
• Run a tabletop walkthrough: take one system through the procedure and capture artifacts.

Days 61–90 (make it durable)

• Close gaps found in the walkthrough (missing approvals, unclear steps, broken dissemination).
• Implement an acknowledgment mechanism for relevant roles.
• Set change triggers (system change, baseline change, major incident) and document review workflow.
• Prepare an “audit ready” evidence packet with one complete, redacted example package.

How Daydream fits (without changing your operating model)

If you struggle with CA-1 because ownership, procedures, and evidence are scattered, Daydream can serve as the control system-of-record: one place to map CA-1 to the control owner, link procedures, and define the recurring evidence artifacts your team will produce each assessment cycle. That mapping is the fastest way to turn CA-1 from a document exercise into a repeatable program.

Frequently Asked Questions

What is the difference between the CA policy and CA procedures?

The policy states management intent, roles, scope, and governance expectations. Procedures are the step-by-step instructions and templates that staff follow to produce assessment and authorization artifacts.

Who should receive (be “disseminated”) the CA-1 documents?

Disseminate to the roles responsible for executing or governing assessments and authorizations, such as GRC, system owners, security leadership, and assessors. Keep a role-based distribution list and proof of access or acknowledgment.

Can we meet CA-1 with a single enterprise security policy?

Only if it clearly covers security assessment and authorization and is paired with implementable procedures. Auditors typically expect CA-specific procedures that produce repeatable artifacts tied to assessments and authorization decisions.

What evidence is most persuasive in an audit for CA-1?

A current, approved policy and procedures plus a complete example assessment package that traces directly to your documented steps. Add dissemination records and version history to prove governance and maintenance.

How do we operationalize CA-1 across many systems without drowning in paperwork?

Standardize procedures and templates, then scope by system boundary and reuse the same workflow. Keep a central evidence register so each assessment produces a predictable set of artifacts.

We use a third party assessor. Does that change CA-1 ownership?

You can outsource execution tasks, but you still own the policy, procedures, and governance. Document how third parties engage your process and how you review and accept their outputs.

Footnotes

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

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON