CA-1 Policy and procedures: requirements and evidence

CA-1 policy and procedures: what the requirement asks for and why assessors start here

When an agency, contract or FedRAMP-style assessment requires NIST SP 800-53, assessors look at the CA family early, and CA-1 is the first control they check. CA-1 requires a written assessment, authorization and monitoring policy, plus the implementing procedures that carry it out. The policy must be distributed to defined roles, managed by a designated official, and reviewed and updated at a defined frequency and after defined events. In practice, the organization owns this document, and it is the rulebook that the control assessments (CA-2), information exchange agreements (CA-3), plans of action and milestones (CA-5), authorizations (CA-6) and continuous monitoring (CA-7) all depend on.

The risk CA-1 addresses is simple to describe and expensive to discover late. When assessments and authorizations run on undocumented, inconsistent or stale practice, two teams can assess the same system in different ways, a required assessment can be skipped without anyone noticing, and an authorizing official can sign off on evidence that does not match how the system is operated. CA-1 has no control enhancements in SP 800-53 Release 5.2.0, so the whole requirement is the policy and procedures themselves. Because the other CA controls point back to them, a weak CA-1 tends to surface as findings in every later CA assessment.

Two things usually make CA-1 hard. The first is agreeing roles: the policy has to name who owns it, who approves it, who runs each procedure and who receives it, and those people often sit in security, risk, IT operations and system ownership with different views. The second is keeping the procedures aligned with real practice after the first draft. Confirm with your assessor or the authorizing body how often they expect the review, which events trigger an out-of-cycle update, and which evidence of distribution and acknowledgment they will accept. Recording the approved version and its change history in a controlled, versioned location makes that proof much easier to produce.

Which systems, teams and baselines CA-1 applies to

CA-1 is selected in the low, moderate and high SP 800-53B baselines and in the privacy baseline, so the policy and procedures must reach every system those baselines cover. The cards below cover the scoping decisions that determine who owns the policy, who must receive it and who performs the work it governs.

Organization-level versus system-level policy

Decide whether one organization-wide assessment, authorization and monitoring policy will cover all systems, or whether individual systems need their own procedures layered on top. Most programs use one policy with system-specific procedures, so each system's security plan can point to the rules that apply to it. Check that every system in scope for the low, moderate, high or privacy baseline can be traced to a procedure, and that no system falls between two documents.

Roles that must receive the policy

CA-1 requires distribution to defined roles, so the policy is only as good as the list of people it reaches. Typical recipients include system owners, authorizing officials, security control assessors, information system security officers and personnel who run continuous monitoring. Record the distribution list, the date each version was sent and how acknowledgment is captured. Confirm that the list is updated when staff change roles.

Common control inheritance and ownership

When a system inherits controls from a shared service, the policy must say which party owns the procedure behind each inherited control. The inheriting system owner still needs evidence that the inherited control is in place and reviewed. Map each common control provider to the procedures it supplies, and record the boundary in the system security plan. Gaps usually appear where a provider assumes the consumer runs the review and the consumer assumes the reverse.

Third-party and contractor assessors

Contractors and outside firms may draft procedures, run control assessments or prepare evidence, but the organization still owns the policy and the official who manages it. Confirm in the contract which deliverables the contractor produces, who approves them and where the policy's review records are kept. Independent assessors and certification bodies, not implementation partners, issue assessment reports and authorization decisions. Ask each provider which documents they draft and which they only review.

Baseline selection drives coverage

Start from the baseline assigned to each system, then check whether the policy's scope statement matches it. A system categorized at the low level still needs the CA-1 policy, and the same is true at moderate and high, and for systems processing personal information under the privacy baseline. Record the baseline for each system in its security plan so the policy's coverage can be checked against the inventory. Revisit the mapping when a system's impact level changes.

How to write, approve and distribute CA-1 procedures

This sequence turns CA-1 from an obligation into a governed document set: a scoped policy, procedures that assign each assessment, authorization and monitoring activity to a named role, approved and versioned records, and evidence that the right people received and accepted them.

Confirm systems and baselines in scope
Start by listing the information systems the policy will govern and the SP 800-53B baseline each one is categorized under, whether low, moderate, high or privacy. The CA family applies to every system in that inventory, so the scope statement must match the system inventory and the security categorization records your organization already keeps. Ask the system owners and the authorizing official to confirm the list. The output is a scope statement with an approved system list, and the step is complete when no in-scope system is missing from it.
Name the designated official and defined roles
CA-1 requires the policy to be managed by a designated official and distributed to defined roles, so the organization must name both. Typical roles include the authorizing officials, system owners, security control assessors, information system security officers and the staff who maintain the plan of action and milestones. Record each name or position, its responsibility and its backup. Your governance body should approve the assignments. The output is a roles and responsibilities table signed off by the official who owns the policy, and the step closes when every CA activity has a named owner.
Draft the assessment, authorization and monitoring policy
Write the policy at the level of intent: why the organization assesses and authorizes systems, which systems fall under it, how the program relates to organization-wide risk management, and who has authority over it. Refer to the CA family by control ID and title, and map the policy's purpose to the risk management process your organization already runs. Avoid restating control language word for word. The output is a draft policy with a purpose, scope, roles, compliance statement and references, ready for review by the designated official and legal or compliance staff.
Draft procedures mapped to each CA activity
Write one procedure section for each CA activity, covering control assessments, information exchange agreements, plans of action and milestones, authorization, continuous monitoring and penetration testing. For each activity, state the responsible role, the trigger, the steps, and the record it produces, such as an assessment plan, an assessment report, an exchange agreement or a monitoring status report. Where a defined frequency or event is needed, leave a clear placeholder for the organization to set. The output is a procedure set with an activity-to-role-to-record matrix, and the step is complete when a reviewer can trace every CA activity to a record.
Approve and version the documents
Route the policy and procedures through the approval path your governance process defines, and record who approved them and when. Keep each document under version control so a reviewer can see what changed, when and by whom. Wiki platforms such as XWiki record page history and allow comparison and rollback between versions, and permission models such as those in BookStack assign editing and approval rights by role. Confirm with your own governance team whether an existing document management system must be used instead. The output is an approved version with a change log and an approval record.
Distribute and capture acknowledgement
Publish the approved policy and the procedures to the defined roles, using the location the staff already use for governance documents. Ask each recipient to acknowledge that they received and understood the documents, and keep a dated record of the acknowledgements. Track recipients who have not responded and escalate them through the designated official. Access to the documents should follow the role model so that only the intended audience can edit them. The output is a distribution list with acknowledgement records, and the step closes when every defined role has either acknowledged or been escalated.
Set review frequency and trigger events
CA-1 requires the policy and procedures to be reviewed and updated at a defined frequency and after defined events. The organization sets both values and should confirm them against its own governance calendar, its internal audit requirements and any contractual or regulatory obligations it carries. Typical trigger events include a significant change to the authorization boundary, a failed assessment, a new regulatory requirement, or a change in the designated official. Record the frequency and the trigger list in the policy, and add them to the governance calendar. The output is an approved review schedule and trigger list, and the step is complete when both are visible to the designated official and the owners of each CA activity.

How an assessor tests CA-1 against its 17 determination statements

This table walks through the test approaches SP 800-53A uses for CA-1, showing what the assessor examines or asks, the evidence to have ready and the findings that most often come up. Use it to check your policy set before an assessor arrives, and confirm the exact determination statements in the CPRT or OSCAL content, since the wording there governs.

Test approach	What the assessor examines or asks	Evidence requested	Common findings
Examine policy content and approval	Whether the assessment, authorization, and monitoring policy covers purpose, scope, roles, responsibilities, management commitment and coordination among entities	Approved policy document with version, approval date and approver named	Undated policies, or policies signed by no one with authority over the program
Examine procedures	Whether implementing procedures exist for each CA control and match the policy's scope and terms	Procedure documents for control assessment, authorization and continuous monitoring, cross-referenced to the policy	Policy exists but no procedures, or procedures that cite roles or forms no longer in use
Examine the system security plan	Whether the SSP references the CA policy and procedures and describes assessment and monitoring activities consistently with them	Current SSP with the CA-related sections, plus the date it was last reviewed	SSP describes a monitoring cadence that the policy does not mention, or the reverse
Examine the privacy plan	Whether the privacy plan aligns with the assessment and monitoring policy where privacy controls are assessed	Current privacy plan and a mapping showing where privacy assessment fits the CA procedures	Privacy plan written separately with no reference to the CA policy or its review cycle
Interview policy owners	Who is the designated official for the policy and procedures, and how they decide when updates are needed	Named official in the policy, appointment or role description, and minutes of recent reviews	Owner named only by title, or the person named has left the role without a handover
Interview personnel with assessment, authorization and monitoring duties	Whether staff know the policy exists, where it is stored and which procedure they follow for their task	Training or acknowledgment records, and a short walkthrough of one recent assessment or authorization step	Staff describe practice that differs from the written procedure
Check distribution and acknowledgment	Whether the policy and procedures reached the defined roles and whether the organization can show it	Distribution list, access logs from the document repository, or signed acknowledgments	Policy posted on a shared drive with no record of who received or read it
Check review and update records	Whether reviews happen at the defined frequency and after defined triggering events, such as a significant change or an assessment finding	Review log with dates, reviewer, changes made and the trigger for each update	Review cycle set in the policy but no review recorded, or updates made without a version change

Evidence that passes CA-1 and how to keep it current

CA-1 is tested on documents that exist, name the right people and show that someone reviewed them on schedule. The six artifacts below are what an assessor typically asks for, and each one decays unless someone owns its update cycle between assessments. Wiki and documentation platforms with version control can hold these records, but the organization must confirm what each tool retains for its own audit window.

Approved policy with version history

The assessment, authorization, and monitoring policy itself, with an approval record, an owner and a version number. Keep every approved revision, not only the current one, so an assessor can see what was in force during the audit period. Version control in XWiki records what changed, when and by whom, and lets reviewers compare two versions or roll back. Check that the approval step is recorded outside the wiki's edit history, because an edit log alone does not prove sign-off by the designated official. Confirm the retention period for old revisions before relying on them.

Procedures with role assignments

The implementing procedures for control assessment, authorization and monitoring, each step tied to a named role. CA-1 expects procedures that someone can actually follow, so list who requests an assessment, who approves a plan of action and milestones, and who signs an authorization. In BookStack, user abilities come from assigned roles, and permissions can be overridden per shelf, book, chapter or page. Use that to restrict edit rights on procedure pages to the owning team, and review the role map whenever responsibilities change.

Distribution and acknowledgement records

Evidence that the policy and procedures reached the people who must follow them, with a date and a recorded acknowledgement from each recipient. Assessors commonly sample a few individuals with assessment responsibilities and check whether they received the current version. Keep distribution lists generated from role assignments rather than manual lists, so new staff and role changes are reflected. Record acknowledgements against a specific version number, since an acknowledgement of an outdated revision does not show current awareness.

Review log with dates and reviewer

A running log that shows each periodic review and each event-driven review, with the date, the reviewer, the outcome and any resulting change. CA-1 requires review at a frequency and after events that the organization defines, so the log must match those defined triggers, not an assumed schedule. Record reviews that found no change as well, because an unchanged policy still needs evidence that it was examined. Confirm the frequency and triggers in your own policy text before setting reminders.

Designated official appointment

A signed or formally recorded appointment naming the official who manages the policy and procedures, with the scope of that responsibility and the effective date. The appointment should state what the official must do, such as approving revisions and ensuring reviews happen, and should be updated when the person changes. Assessors check that the named official matches the owner shown on the policy, so a mismatch between the appointment and the document header is a common finding. Store the appointment where access is controlled and retained beyond the owner's tenure.

Cross-references in the system security plan

Links from the system security plan to the assessment, authorization and monitoring policy and procedures, showing that the system's documented controls rely on the organizational policy. CA-1 relates to PM-9, PS-8 and SI-12, so check that those related policies are referenced consistently rather than restated in conflicting wording. Keep the cross-reference current when the policy is revised, using the version identifier so an assessor can confirm the plan points to the approved document. Record any system-specific deviations explicitly instead of letting them sit silently in the plan.

Why stale procedures fail more often than missing ones

Most CA-1 weaknesses come from procedures that were once accurate and no longer describe how assessments and authorizations actually run. A missing policy is easy to spot. A policy that names the wrong roles, cites an assessment cycle the program abandoned, or predates the current catalog is harder to see and tends to survive audits until an assessor compares it line by line with the records. NIST's Release 5.2.0 of 27 August 2025 updated the related controls of every -1 policy and procedures control, CA-1 included, so any policy written against an earlier release should be checked against the current catalog in CPRT or the OSCAL files before the next assessment. The check is mechanical: list the related controls for CA-1, compare them with the release your policy cites, and record the result with a date and a named reviewer.

CA-1 carries cross-references to PM-9, PS-8 and SI-12, and a change in any of them should trigger a review of the procedures that depend on it. PM-9 concerns the organization-wide risk management strategy, PS-8 concerns personnel sanctions, and SI-12 concerns information handling and retention. A revision to one of those controls can change who approves an assessment, how sanctions are recorded when an assessor finds a bypassed control, or how assessment artifacts are retained. Assign an owner to each cross-reference, then ask that owner to confirm, at each periodic review, whether the CA procedures still reflect it. Confirm the exact related-control list against the release your organization has adopted, since the catalog governs.

A practical way to keep procedures from drifting is to tie every procedure step to a named record. For example, if the procedure says the assessment plan is approved before testing begins, name the approval record, its storage location and the role that signs it. If a step cannot point to a record, either the step is aspirational or the record does not exist, and both are findings waiting to happen. When an assessment report, POA&M entry or authorization decision is produced, the record it leaves behind should be the proof that the step ran. Version history in your documentation platform, such as the page history that XWiki keeps for every change, shows when a procedure was edited, and a record that stops appearing in practice is the first visible sign that the procedure has gone stale.

Where CA-1 implementations usually fall short

CA-1 is rarely missing outright. It usually exists as a document that no one owns, runs or refreshes. The gaps below share one root cause: the policy describes intent while the procedures, distribution records and review cycle that prove it are missing or stale.

Policy with no designated official

CA-1 requires that the policy and procedures be managed by a designated official, so an assessor will ask who that person is and what they actually do. Many policies carry a department name instead of a named role, or an owner who left the organization. Close the gap by naming one accountable role in the policy, recording the appointment in the governance charter, and listing that role as the approver on each revision. Evidence that proves the fix is the signed appointment and the approval history on the policy page.

Procedures no one runs

The procedures must describe how assessments, authorizations and monitoring are carried out, and an assessor will compare them with what happened last cycle. A common failure is a procedure written for an ideal process that the team has since replaced with spreadsheets or ticket queues. Walk through the procedure with the people who perform each step, then correct the document to match practice. Evidence includes a completed cycle, such as an assessment plan and report, that follows the written steps in order.

Distribution without a record

CA-1 requires the policy and procedures to reach defined roles, but many organizations cannot show who received them. A shared drive link or an email with no acknowledgment does not prove distribution. Maintain a list of the defined roles, publish the document to a versioned repository, and collect acknowledgments from each role. Evidence is the distribution list, the acknowledgment records and the access log showing the current version was opened by those roles.

Review dates that lapse

The policy must be reviewed and updated at a defined frequency and after defined events, and assessors check the revision date against the stated cycle. Review dates often pass silently because no one owns the calendar. Set the frequency and triggering events in the policy itself, create a tracked review task with the designated official as owner, and record the outcome even when the review finds no change. Evidence is the dated review log with reviewer names and the decision made.

Privacy baseline systems left out of scope

CA-1 is selected in the privacy baseline as well as the security baselines, so a policy scoped only to high-impact security systems leaves privacy-scoped systems without a documented assessment and monitoring procedure. Check the system inventory against the privacy baseline selection and state in the policy which systems each procedure covers. Evidence is the scope statement in the policy, a mapping from each in-scope system to its applicable baseline, and the assessment records for those systems.

No update after the 5.2.0 changes

Release 5.2.0 updated the related controls of every -1 policy and procedures control, CA-1 included, and it also revised CA-7, which the assessment procedures depend on. Organizations that adopted Rev. 5 earlier may still cite the older control text in their policies. Compare the current CA-1 entry in the catalog with the policy, record which related controls changed, and issue a revision with a change summary. Evidence is the dated revision, the change record and the approval of the designated official.

What meeting CA-1 costs in money and effort

This table lists the cost components of writing, approving, distributing and reviewing the CA-1 policy and procedures, showing who carries each cost and whether it recurs. CA-1 has no tool license requirement of its own, so most spending is internal time, and NIST does not estimate compliance costs, so ask any provider for a written scope and quote before budgeting.

Cost component	One-time or recurring, and what drives it	How to keep it down
Internal drafting and approval time	One-time for the first version, then recurring at each review. Scope of the systems covered and the number of approvers drive it up.	Reuse an existing enterprise policy template and limit the document to assessment, authorization and monitoring.
Designated official time	Recurring. The official who manages the policy must keep it current and answer questions, so the time grows with the number of systems in the program.	Name one accountable official with a clear deputy and a fixed review calendar.
Distribution and role training	One-time rollout, then recurring for new staff and changed roles. Headcount and turnover in assessor, authorizing and system owner roles drive it up.	Publish to a single controlled location and tie training to onboarding and role changes.
Review and update cycles	Recurring at the defined frequency and after defined events such as major system changes or updates to related controls. Frequency and the number of triggering events drive it up.	Map review triggers to existing change and assessment cycles so reviews happen once.
Document tooling	Recurring hosting and administration effort. Self-hosted XWiki (LGPL-2.1-or-later) keeps version history and rollback, and self-hosted BookStack (MIT) offers role-based permissions. Confirm license terms and hosting needs with each project before adoption.	Use tooling your organization already runs, and keep the policy in one format the assessor can read.
External policy review	One-time or periodic, billed by the reviewer under a written scope. Breadth of the review and the number of policy documents in scope drive it up.	Ask for a fixed-scope review of CA-1 and its procedures, not a full policy suite.
Assessor time during the audit	Recurring at each assessment. The assessor examines the policy and interviews personnel, so unclear ownership or stale versions add time.	Keep version history, approval records and distribution evidence ready before the assessment starts.

In-house, implementation partner and auditor roles for CA-1

Your organization owns CA-1. The policy must name a designated official who is accountable for the assessment, authorization and monitoring policy and its procedures, and that official must have the authority to approve it. Leadership and the designated official decide the scope of the policy, the defined roles it reaches, and the frequency and events that trigger review. Staff who hold these responsibilities in practice, such as the authorizing official and the security control assessors, must be able to explain them in interviews.

Ownership: Name one designated official and record the role in the policy itself, not only in a org chart.
Approval: Keep dated approval records, signed by the people who hold the authority to approve, for each version.
Defined values: Set the review frequency and the events that trigger a review, then record them in the policy.
Interviews: Make sure the people who run assessments and authorizations can describe the procedures without reading from a draft.
Distribution: Track who received each version and who acknowledged it.

Before an assessment, check that every approval, date and assignment in the policy matches what your people will say in interviews.

Questions buyers ask about CA-1 effort, timing and outside help

How much effort does CA-1 policy and procedures work take?

The effort depends on how many systems the policy must cover, how many roles already own parts of assessment, authorization and monitoring, and how many procedures already exist in writing. CA-1 itself has no control enhancements, but SP 800-53A assesses it with 17 determination statements and the examine and interview methods, so an assessor will check both the document and the people who run it. Effort is usually highest when the organization has no written assessment or authorization process and must agree on owners first. Ask any outside party to break its estimate into drafting, review, approval and distribution.

How long does it take to get a CA-1 policy approved?

NIST does not set implementation timelines for SP 800-53. Its risk management FAQ leaves federal timing to OMB Circular A-130, so any duration you hear should be treated as a planning assumption. The answer depends on scope, the number of systems and organizational units the policy covers, and the approval cycle of your governance bodies. Before committing dates, confirm who signs the policy, how often your leadership meets to approve policies, and whether legal or works council review is required.

Can our team write the CA-1 policy and procedures on its own?

Yes, many teams draft it internally, provided someone understands the control and the roles it names. The policy must be documented, distributed to defined roles, managed by a designated official, and reviewed at a defined frequency and after defined events. Internal teams often struggle with the procedures layer, because procedures must describe how the work is actually done and who does it. A useful test is whether each procedure can be followed by someone who did not write it.

What does the CA-1 work need from our staff?

Expect to name an accountable official, a few subject matter owners for assessments, authorization and monitoring, and reviewers from security, risk and the system owners who receive the policy. Interviews are part of how an assessor tests CA-1, so the people named in the policy must be able to explain their responsibilities and show recent activity. Staff time is mainly spent on decisions and review, not on writing. Confirm named individuals and their backups before drafting starts.

Will an auditor accept a CA-1 policy drafted with outside help?

An auditor or assessor tests whether the policy exists, is approved, is distributed, is current and is followed, not who typed it. The organization owns the policy, and the outside party only prepares the draft, the procedures and the evidence trail. Only an independent auditor, assessor or certification body issues reports or certificates, and DeployOpen does not issue audit reports, attestations or certifications. Ask your assessor early what documentation format and approval evidence they expect.

Can open-source tools hold the CA-1 policy and review records?

Yes, a self-hosted wiki or documentation platform can store the policy, its version history and its review records inside your own infrastructure. XWiki keeps every change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack assigns abilities through roles and lets permissions be overridden per shelf, book, chapter or page. Confirm that the platform's retention, access logging and approval workflow meet your own evidence requirements before relying on it.

How is a fixed-scope CA-1 engagement agreed with DeployOpen?

Most DeployOpen engagements are fixed-scope, meaning the scope, deliverables and timelines are agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. To compare proposals, ask each provider to list the systems in scope, the documents to be produced, the review rounds included, who approves each deliverable, and what the organization must supply. Ongoing support and reviews can be set up as a retainer after the initial scope is complete.

How DeployOpen prepares CA-1 policy and evidence

DeployOpen prepares the policy, procedures and evidence trail that CA-1 asks for, inside your own infrastructure, on self-hosted open-source platforms. Your organization owns the policy and its approval, and an independent assessor tests the result.

How we scope

Engagements are fixed-scope, with the CA-1 deliverables, systems and roles agreed in writing before work starts.
Scope confirms which systems fall under the assessment, authorization and monitoring policy and which official owns it.
We confirm the review frequency and triggering events your organization has defined, or agree them with you first.
Ongoing support for policy reviews is available as a retainer after the initial scope is delivered.

How we build

We draft the policy and implementing procedures in a self-hosted wiki or document platform, for your organization to review and approve.
Procedures map each assessment, authorization and monitoring step to a named role, so assessors can trace responsibility.
We configure role-based access so that only designated owners can publish or change the policy.
We check that the policy aligns with the system security plan and related CA controls before handover.

How we hand over

You receive the approved policy, procedures, role assignments and a revision history showing who changed what and when.
Documentation covers how to distribute the policy, collect acknowledgments and record each periodic review.
We provide a checklist of CA-1 assessment objects so your team can confirm evidence before an assessor arrives.
Your organization and its independent assessor decide whether the evidence meets the requirement.

How we support

Retainer support can cover scheduled policy reviews, updates after significant system changes and updates for new NIST releases.
We can keep version history and distribution records current so the evidence trail stays complete between assessments.
Support is delivered inside your environment, so policy documents and access logs stay under your control.
Ask us to confirm the review cycle and update triggers in writing before the retainer begins.