Policy and Procedures

To meet the NIST SP 800-53 Rev. 5 CA-1 “Policy and Procedures” requirement in a FedRAMP Moderate context, you must publish an assessment, authorization, and continuous monitoring (A&A/ConMon) policy plus detailed procedures, then prove they’re approved, current, and actually used by the teams running your ATO lifecycle ¹. Treat CA-1 as the “operating manual” for how you govern security assessments and ongoing monitoring.

Key takeaways:

• CA-1 requires both a policy (management intent) and procedures (how-to steps) for assessment, authorization, and monitoring ¹.
• Examiners look for evidence of governance and adoption: approval, dissemination, training/acknowledgment, and operational records mapped to the procedures.
• The fastest path is to standardize artifacts: one policy, a small set of procedures, a RACI, and a review cadence tied to ATO and change management.

CA-1 is a foundational control because it defines how your organization runs the full security authorization lifecycle: preparing for assessment, obtaining/maintaining authorization, and continuously monitoring the system after authorization. In a FedRAMP Moderate environment, this requirement is less about writing a “nice policy” and more about demonstrating repeatable execution. Auditors and assessors expect you to show that roles are assigned, leadership has explicitly committed to the program, and the procedures are followed in real operational workflows.

Most implementation failures come from two gaps. First, teams publish a high-level security policy but never write procedures that a security engineer, GRC analyst, or system owner can execute without interpretation. Second, organizations write procedures that are technically correct but disconnected from how work actually moves through tickets, change control, vulnerability management, and the continuous monitoring calendar.

This page gives you requirement-level implementation guidance: what CA-1 asks for, who must comply, how to build the minimum viable policy/procedure set, which artifacts to retain, and how to handle common audit traps. The goal is speed with defensibility: documents that map cleanly to operations and are easy to evidence.

Regulatory text

Requirement (excerpt): “Develop, document, and disseminate an assessment, authorization, and monitoring policy and procedures that address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance.” ¹

What the operator must do:
You need two layers of documentation, both formally approved and distributed to the workforce responsible for A&A and continuous monitoring:

1. Policy that states what your organization requires for assessment, authorization, and monitoring (the governance “what” and “why”), including leadership commitment.
2. Procedures that specify how work gets done (the operational “how”), including coordination points and compliance expectations ¹.

Plain-English interpretation (what CA-1 really means)

CA-1 means: “Write down how you run your ATO program, make leadership own it, and make your teams follow it.” Your policy sets the rules of the road; your procedures translate those rules into checklists, workflows, and required artifacts. If you cannot show repeatability (same inputs, same steps, consistent outputs), CA-1 is not met in practice even if the documents exist.

CA-1 also creates a control spine for related activities. If your assessment planning, POA&M handling, continuous monitoring submissions, and authorization decisions are inconsistent across systems or teams, CA-1 is where an assessor will anchor that finding.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) pursuing or maintaining a FedRAMP Moderate Authorization to Operate (ATO).
• Federal Agencies authorizing and overseeing systems, including agency ATO processes and ongoing monitoring expectations ¹.

Operationally, this touches:

• GRC/Compliance (program ownership, SSP/POA&M governance)
• Security Engineering (assessment support, evidence production, monitoring)
• System Owners and Product/Platform Engineering (system changes and risk acceptance inputs)
• Vulnerability Management, Incident Response, Change Management (continuous monitoring dependencies)
• Internal Audit (if present), and external assessors/3PAOs (interfaces and evidence)

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

1) Define your CA-1 document set (minimum viable and audit-ready)

Create a short list of controlled documents:

• A&A/Continuous Monitoring Policy (one document)
• A&A/ConMon Procedures (one or more documents, but keep it readable)
• RACI matrix covering CA activities (can be embedded in procedures)
• Document control standard (may be part of your overall policy framework, but it must apply here)

A workable structure is one policy and 3–6 procedures (assessment, authorization package management, POA&M, continuous monitoring reporting, exception handling, and document control).

2) Draft the policy to explicitly cover the required elements

Your policy must address (verbatim concepts from CA-1) ¹:

• Purpose: Why you run assessment, authorization, and monitoring (risk management and authorization decisions).
• Scope: Which systems, environments, and teams are in scope (include boundaries: production, staging, corporate IT if it supports the system).
• Roles & responsibilities: Name functions, not people (e.g., Authorizing Official, System Owner, ISSO, GRC Lead).
• Management commitment: Signed approval by accountable leadership; include resourcing and enforcement expectation.
• Coordination: Required handoffs (security ↔ engineering ↔ change management; CSP ↔ agency; third party assessors).
• Compliance: What “must” happen, what artifacts are mandatory, and consequences for noncompliance (at least escalation paths).

Operator tip: Keep the policy short. Put the “how” in procedures so you can update workflows without rewriting executive policy every time.

3) Build procedures that map to real workflows (tickets, tools, and calendars)

Procedures should be executable. For each procedure, include:

• Trigger: What starts the process (new system onboarding, major change, annual assessment activity, vulnerability discovery).
• Inputs: Required artifacts (SSP sections, scan results, inventory exports, change tickets).
• Steps: Numbered steps with decision points.
• Outputs: Required deliverables (assessment plan, evidence package, updated POA&M items, monitoring reports).
• Owners: Who performs and who approves.
• Tooling: Where records live (GRC system, ticketing system, repository).
• Quality checks: What must be reviewed before submission/closure.

Examples of procedure topics that align tightly to CA-1:

• Security assessment procedure: evidence request intake, evidence validation, assessor Q&A tracking, remediation validation steps.
• Authorization package procedure: SSP update workflow, control ownership attestations, internal review gates, submission to AO/agency.
• Continuous monitoring procedure: vulnerability scanning intake, POA&M workflow, monthly/quarterly reporting package, exception handling.
• Coordination procedure: meeting cadence, stakeholder list, escalation thresholds, third party dependencies.

4) Formal approval and dissemination (this is where many teams fail)

CA-1 explicitly requires dissemination ¹. Do all of the following:

• Route documents through your document control/approval workflow.
• Obtain management sign-off (policy at minimum).
• Publish to an authoritative location (controlled repository).
• Require acknowledgment for in-scope roles (GRC, security, system owners). Track it.

If you use Daydream, treat it as your system of record for: policy versioning, approval workflows, control-to-artifact mapping, and evidence requests. The operational win is fast retrieval during a 3PAO review.

5) Prove the procedures are operating

Write documents, then generate operational proof:

• Sample tickets showing assessment support activities
• POA&M entries created/updated per procedure
• Continuous monitoring submissions built from the defined workflow
• Meeting notes or decision logs showing coordination and authorization decisions

Your assessor will ask whether “disseminated” means “available” or “trained.” Don’t debate. Produce acknowledgments and training records.

6) Set a review/update mechanism tied to change and authorization events

CA-1 does not give a specific review frequency in the provided text, so do not over-promise. Define review triggers that align to how FedRAMP work changes:

• Review upon major process/tool change
• Review after assessment cycles or authorization events
• Review after significant findings, process failures, or audit feedback

Document the review, even if no changes were needed.

Required evidence and artifacts to retain

Keep evidence that proves existence, approval, dissemination, and operation:

• Approved A&A/ConMon policy with version history and signatory
• Approved procedures with version history
• Document control records (change log, approvals, effective dates)
• RACI or role descriptions mapped to processes
• Distribution evidence: training completion, acknowledgments, intranet publication records
• Operational records: assessment evidence request logs, package review checklists, POA&M workflow records, continuous monitoring deliverables
• Coordination proof: stakeholder meeting minutes, decision memos, authorization decision tracking

Common exam/audit questions and hangups

Expect these questions:

• “Show me the policy and procedures that govern assessment, authorization, and monitoring.” ¹
• “Who is accountable for the authorization package and continuous monitoring submissions?”
• “How do you ensure procedures are followed, not optional?”
• “Where is dissemination documented? Who has acknowledged?”
• “Show a recent example where the procedure produced the required output (POA&M update, monitoring report, assessment evidence set).”
• “How do you coordinate security, engineering, and the agency/3PAO?”

Hangups that derail audits:

• Procedures exist but don’t match actual tool workflows.
• Roles are generic (“Security Team”) with no clear ownership.
• Documents are in draft, unsigned, or stored in personal drives.
• No evidence of dissemination beyond “it’s on SharePoint.”

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Writing a policy that reads like a textbook.
   Avoid it: Make policy statements testable (“must,” “required artifacts,” “approval authority”).

2. Mistake: Combining policy and procedures into one unwieldy document.
   Avoid it: Keep policy stable; update procedures as workflows evolve.

3. Mistake: No coordination mechanics.
   Avoid it: Define handoffs explicitly (security review gates in change management, engineering SLAs for evidence, escalation path to AO/System Owner).

4. Mistake: Dissemination is assumed, not proven.
   Avoid it: Track acknowledgments for in-scope roles and retain records.

5. Mistake: Procedures don’t specify outputs.
   Avoid it: Each procedure should end with “Records generated” and where they’re stored.

Risk implications (why operators should care)

Weak CA-1 implementation creates predictable failures: inconsistent assessments, missing monitoring deliverables, and unclear ownership for POA&Ms. That translates into late packages, poor-quality evidence, and avoidable findings during assessment activities. In FedRAMP work, those issues are operational blockers because they slow authorization decisions and force rework.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Identify system(s) and teams in scope for A&A/ConMon under FedRAMP Moderate.
• Assign a CA-1 owner (typically GRC) and confirm executive approver for the policy.
• Inventory existing documents and workflows (tickets, GRC tool modules, repositories).
• Draft the A&A/ConMon policy outline covering purpose, scope, roles, responsibilities, management commitment, coordination, compliance ¹.

By 60 days (Documented and approved)

• Finalize and obtain approval signatures for the policy and initial procedure set.
• Publish documents in a controlled repository with versioning.
• Implement dissemination: role-based acknowledgments and onboarding/training content for in-scope teams.
• Build templates/checklists: evidence request log, authorization package internal review checklist, ConMon submission checklist.

By 90 days (Operational proof and audit readiness)

• Run at least one “tabletop” walk-through of the procedures with Security, GRC, and Engineering.
• Collect operating evidence from real work (tickets, POA&M updates, review checklists).
• Hold a coordination review with stakeholders; document gaps and update procedures.
• In Daydream (or your GRC system), map CA-1 to each artifact and store retrieval links so an assessor can pull evidence quickly.

Frequently Asked Questions

Do we need both a policy and procedures for CA-1?

Yes. CA-1 explicitly requires an assessment, authorization, and monitoring policy and procedures ¹. Auditors typically expect separate documents or clearly separated sections with different approval/maintenance patterns.

What counts as “disseminated” in practice?

“Disseminated” should mean more than “posted somewhere.” Treat it as controlled publication plus role-based communication and tracked acknowledgment for personnel who execute A&A/ConMon activities.

Can we reuse our corporate security policy?

You can reuse it only if it explicitly covers assessment, authorization, and continuous monitoring with the required elements (purpose, scope, roles, management commitment, coordination, compliance) ¹. Most corporate policies are too high-level and need CA-specific procedures attached.

How detailed do procedures need to be?

Detailed enough that a new team member can execute the workflow and produce the required records without guessing. If an assessor can’t trace inputs → steps → outputs, the procedure is not operationally useful.

Who should sign the policy to show “management commitment”?

The signer should be an accountable leader with authority to fund and enforce the program (often the CISO, CIO, or equivalent). Match the signatory to your governance model, but make sure it is not a purely administrative role.

How do we show procedures are actually followed?

Keep operating records: change tickets with security gates, evidence request logs, POA&M workflows, and monitoring deliverables that match the procedure steps. During assessment, produce a small sample set that demonstrates end-to-end execution.

Footnotes

1. NIST Special Publication 800-53 Revision 5