AC-1 Policy and procedures: evidence

What AC-1 policy and procedures requires before an assessor arrives

When an agency, contract or FedRAMP package requires NIST SP 800-53, the first access control control an assessor reads is AC-1. AC-1 asks for a documented access control policy and the procedures that implement it, distributed to defined roles, managed by a designated official, and reviewed and updated at an organization-defined frequency and after defined events. Every other AC control, from account management in AC-2 to remote access in AC-17, is judged against the rules this document sets. If the policy is missing, out of date or disconnected from how accounts are really created and removed, the assessor has little reason to trust the evidence that follows.

AC-1 looks like paperwork, which is why it is harder than it appears. The assessor will check that the policy names a specific official, that the roles it is distributed to can be identified, and that the procedures describe steps people actually follow. The organization must also define its own review frequency and triggering events, such as a significant system change, a staffing change in a responsible role or an incident involving access. Those values are set by the organization, so confirm them with your assessor before drafting. AC-1 has no control enhancements and is selected in the low, moderate, high and privacy baselines in SP 800-53B. Release 5.2.0 of 27 August 2025 also revised the related controls of every -1 policy and procedures control, including AC-1, so check the current wording in the NIST CPRT catalog before you map existing documents.

Start by listing every document that touches access, then decide which one is the policy and which are procedures. Confirm who signed off on the current version, when it was last reviewed, and whether the review record exists. Ask whether the policy still matches the account management and access enforcement procedures used by your identity systems. Any gap found now is cheaper to close than one an assessor finds during testing. Clearly separate what your organization owns, namely the policy approval and review decisions, from what an implementation partner can help prepare, such as document templates, drafting support and evidence collection. Only an independent assessor issues the assessment outcome.

Which systems, teams and documents AC-1 covers

AC-1 is written once at policy level but applied to every system and team it governs. The cards below separate the decisions that set the size of the work: which layer of documentation you write, which baseline selects the control, who must receive it, and which outside parties fall under it.

Organization-wide policy versus system procedures

The access control policy is usually one organization-level document approved by a designated official. The procedures that implement it are written per system or service, such as the directory platform, the VPN concentrator or a line-of-business application. Assessors will look for both layers and for a clear trace from each procedure back to a policy statement. Check that every in-scope system has a named procedure owner and that no system is governed only by an informal runbook.

Baselines that select AC-1

AC-1 is selected in the low, moderate and high security control baselines and in the privacy baseline. Its inclusion does not depend on system impact level, so a low-impact system still needs a documented policy and procedures. Confirm which baseline your system's categorization selects, then confirm whether any overlay or tailoring decision removes or adds related scope. Record that decision in the system security plan so the assessor can see the basis.

Roles that receive the policy

The control requires the policy and procedures to be distributed to defined roles. In practice this list usually includes system owners, administrators of identity and directory services, help desk staff who perform account changes, managers who approve access and auditors who review it. Assessors often ask for the distribution list and evidence of acknowledgment. Confirm that the roles in your distribution list match the people who actually perform account actions, since a gap between the two is a common finding.

Third parties whose access the policy governs

The policy must reach people outside the organization who hold access, including managed service providers, contractors, outsourced developers and cloud support staff. Their accounts and remote sessions fall under the same rules as employee access, even when a contract is the only written link. Ask each third party which of their staff hold credentials, how those credentials are approved, and whether your procedures or their contract terms cover revocation when the engagement ends.

Review frequency and triggering events

The organization defines how often the policy and procedures are reviewed and which events force an earlier review, such as a significant system change, a security incident or a change in legal requirements. The date of the last review and the approval record are the first items an assessor requests. Confirm the review interval you have defined, the events that trigger an extra review and who owns each review. Note that Release 5.2.0 updated the related controls of all -1 policy controls, so check whether your policy references need revision.

How assessors test AC-1 with 17 determination statements

This table compares the parts of AC-1 that SP 800-53A assesses with the examine and interview methods, the evidence an assessor will ask for, and the findings that most often come up. Read each row as a question the assessor will put to the organization, then check whether your documents and staff can answer it with dated, owned records. The main takeaway is that AC-1 is usually lost on evidence of ownership and review, not on the existence of a policy.

Assessment focus	Evidence requested	Common findings
Policy existence and content	Current access control policy covering purpose, scope, roles, responsibilities, commitment and coordination among entities	Policy is generic or copied from a template and does not describe the organization's actual systems
Procedures that implement the policy	Documented procedures for account handling, access reviews and remote access, tied to the policy	Procedures exist for some systems only or describe tools that were retired
Designated official	Named individual or role who manages the policy and procedures, with the appointment recorded	Policy names no owner, or names a team whose members have changed
Dissemination to defined roles	Distribution list, acknowledgment records or publication log showing who received each version	No record of distribution, or staff say they never saw the current version
Review frequency and triggers	Review schedule, review history with dates, and records of reviews after defined events such as incidents or organizational changes	Review dates are stale or the review cycle is not the one the policy states
Consistency with the system security plan	System security plan entries for access control that match the policy and procedures	Plan describes controls the running system does not enforce
Interview with access control personnel	Walkthrough by administrators and account managers explaining how they apply the procedures day to day	Staff describe practices that differ from the written procedures or cannot find the document

Writing and maintaining the AC-1 policy in six steps

This sequence turns AC-1 from a document that exists into a governed set of access control policy and procedures, with a named owner, a review cycle and records that show each step happened. Each step produces an artifact an assessor can examine.

Name the designated official
Assign one named official to own the access control policy and its procedures. AC-1 expects a designated official to manage the document, so this person should have the authority to approve changes and the access to coordinate across system owners, identity teams and compliance staff. Record the appointment in a signed memo or governance charter that states the role and its scope. The step is done when the assignment is written down and the official has accepted it in writing.
Set the review frequency and triggering events
Define how often the policy and procedures are reviewed and which events force an earlier review, such as a significant change to the identity platform, a security incident involving access, or a change in the regulations the organization must meet. AC-1 requires these values to be organization-defined, so they must be stated explicitly in the policy rather than left implied. Confirm the chosen frequency against any contract, regulator or authorizing body that applies to the system. The output is a short section of the policy that names the cadence and the triggers.
Draft the access control policy
Write the policy at the organization level. It should state its purpose and scope, the roles and responsibilities for access control, the principles that govern access decisions, and the link to the wider security program. Map each statement to the systems it covers so an assessor can trace the policy to the system security plan. Keep the language specific enough to test, for example by naming who approves access and where approvals are recorded. The output is a draft policy document with a version number and an owner field.
Write procedures for each system or service
Turn the policy into procedures for each system, platform or service in scope. Procedures describe the steps an administrator follows to request, approve, provision, review and remove access in that environment. Where two systems share a process, write one procedure and reference it from both. Each procedure should name the system owner who maintains it. The output is a procedures register that lists every procedure, its system, its owner and its last review date, so the set of procedures can be checked for completeness.
Approve and distribute with acknowledgment records
Obtain formal approval of the policy from the official or governing body that the organization designates, and record the approval date and approver. Distribute the approved policy and the relevant procedures to the defined roles, such as system owners, administrators, help desk staff and managers who request access. Ask each recipient to acknowledge receipt. The output is an approval record, a distribution log that shows who received which version, and a set of acknowledgments that an assessor can sample during interviews.
Run the first review cycle
Conduct the first documented review against the review frequency and the triggers set earlier. Compare the policy and each procedure with how the systems actually operate today, record gaps, and decide which changes are needed. Route updates through the same approval and distribution steps so the version history stays intact. The output is a review record that lists the reviewer, the date, the findings and the resulting changes, and that becomes the baseline for the next cycle. Confirm with your assessor which evidence format they expect for this record.

Which documents pass AC-1 and how to keep them current

An assessor testing AC-1 Policy and procedures reads the documents first and the people second. The six artifacts below form one chain: the policy sets intent, the procedures show how it runs, and the approval, distribution and review records prove that the documents were authorized, reached the right roles and stayed current. Each card names what the assessor checks and how to keep that artifact accurate between audits.

Access control policy

The policy is the top-level document that states the purpose, scope, roles, and management commitment for access control. An assessor checks that it names an owner, carries a version and effective date, and covers every system in the authorization boundary. Confirm that the policy uses the organization-defined frequency for review and states the events, such as a significant organizational change or a security incident, that trigger an earlier review. A policy that names no owner is the most common reason a first assessment stalls.

Access control procedures

Procedures describe how each role carries out the policy, step by step, for account requests, reviews and enforcement. Assessors compare them against the policy to confirm that every requirement has a matching procedure and that the procedures name the role that performs each step. Keep procedures in the same repository as the policy, with their own version history, so a change to a workflow does not leave the policy describing an old process. Procedures tied to a specific tool should name the tool version and configuration location, such as a directory service or ticketing system.

System security plan entries

The system security plan records how each control is implemented in a specific system, and its AC-1 entry should point to the current policy and procedures by version. Assessors check that the referenced versions match the documents in circulation and that the plan names the designated official responsible for the control. Update the entry whenever the policy changes, not only at the annual plan refresh, because a stale reference is a finding even when the policy itself is sound. Confirm the plan's review date against the organization-defined frequency.

Distribution and acknowledgment records

Distribution records show that the policy and procedures reached the defined roles, such as system owners, administrators and managers who approve access. An assessor looks for a dated distribution list, the version sent and a method that produces proof, such as an acknowledgment in the document system or a signed attestation. Reconcile the list against role changes each quarter so new administrators receive the current version. Records of who received an outdated version should be retained with the replacement notice, since they show the gap was detected and closed.

Review and update history

The review history shows that the policy and procedures were examined at the organization-defined frequency and after each defined event. Assessors compare the log of reviews with the calendar of required reviews and look for any missed cycle, along with a stated reason for each change. Version control in a documentation platform helps here, because it records what changed, when and by whom, and lets reviewers compare any two versions. Record a review even when no edits are made, so the absence of change is also evidenced.

Approval record

The approval record shows that a named official reviewed and accepted the policy and procedures before they took effect. Assessors check that the approver holds the authority the policy assigns, that the approval date precedes the effective date, and that the approved version matches the one distributed. Keep the signed approval or workflow ticket next to the document, and tie each new version to its own approval. An approval that refers to a draft, or to a version never distributed, will not satisfy the assessor.

What writing and maintaining AC-1 costs in money and effort

This table breaks down the cost components of writing, approving and maintaining the AC-1 access control policy and procedures, marking each as one-time or recurring and naming what moves it up or down. Use it to scope internal effort, decide what to outsource and build a quote request. No prices or durations are stated because none are supplied for this control.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it, and what to ask for in a quote
Drafting the policy and procedures	Internal policy writers, or an outside consultant paid for drafting hours	One-time, then recurring with each revision	Number of systems and roles in scope. Ask for the named writers, the number of drafting rounds and whether the output is mapped to your system security plan.
Designated official oversight	Senior security or compliance owner, internal time	Recurring	Size of the organization and number of approval bodies. Ask who holds the official role and how much of their time is assumed in the quote.
Legal, HR and governance review	Legal counsel, HR and risk committee members, internal or external	One-time per version, recurring at each review cycle	Number of reviewing functions and jurisdictions. Ask whether the quote includes review cycles or only the initial draft.
Distribution and role-based training	Training owners, managers, and the people who must read and acknowledge the policy	Recurring with each update and each new hire or role change	Number of roles and third parties who must acknowledge it. Ask how acknowledgments are collected and stored as evidence.
Document tooling	Software licenses or self-hosted platform setup and hosting staff	One-time setup, recurring licenses or hosting	Choice between commercial and self-hosted tools. Self-hosted wikis such as XWiki (LGPL-2.1-or-later) or BookStack (MIT) avoid license fees but need hosting and administration. Ask for version history and role-based permissions in the design.
Recurring review and change tracking	Policy owner and system owners, internal time	Recurring at the organization-defined review frequency and after defined events	Rate of change to systems, staff and third parties. Ask how change triggers are logged and who signs off each revision.
Assessor preparation and sampling	Internal evidence owners, plus an independent assessor or auditor if engaged	Recurring at each assessment cycle	Number of procedures the assessor samples and how current the evidence is. Ask the assessor to confirm the evidence list before fieldwork.
Optional external review or partner support	Independent reviewer or implementation partner, paid by fixed scope or retainer	One-time for a gap review, recurring if retained	Internal skill gaps and the number of systems covered. Ask for a written scope, deliverables and timeline before work starts.

Using XWiki and BookStack to version and control AC-1 documents

AC-1 is judged on documents that are approved, distributed, reviewed and updated on a defined schedule. Two self-hosted, open-source wikis can hold those documents and keep a visible trail of who changed them, when and who may read them. The cards below cover what each tool records, where its access model fits the policy, and what your own workflow still needs to confirm.

XWiki version history as review evidence

XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom. For AC-1, this gives assessors a dated record of each revision of the access control policy and procedures. Check that your review cycle produces a saved version for each approval, and that the page history shows the approver, not only the editor. Confirm with your assessor how long history must be kept.

Comparing and rolling back policy versions

XWiki lets users compare any two versions of a page and roll back to an earlier one. This matters when an assessor asks what the policy said on a past date or when an unapproved edit must be reverted. Rollback restores content but adds its own history entry, so the reversal remains visible. Document in your procedure who may perform a rollback of a policy page and what approval it needs.

BookStack roles and user abilities

BookStack, licensed under MIT, assigns user abilities through the roles each user holds. Policy owners, reviewers and readers can be given different roles, which matches the AC-1 expectation that procedures reach defined roles. Confirm that only designated policy administrators can publish or edit AC-1 documents, and that the role list is itself reviewed as part of your access control program.

Per-object permission overrides

BookStack lets permissions be overridden per role at the shelf, book, chapter or page level. You can restrict the access control policy page to a small group while leaving general guidance visible to all staff. Test each override in a staging instance, because a permissive override on a parent shelf can expose a restricted page unless you check the effective permissions. Record the final permission matrix in the policy package.

Approval and retention checks to confirm

Neither tool, on its own, enforces a sign-off workflow that matches your governance. Confirm whether your approvals happen inside the wiki or in a separate ticket, and whether the approval record is retained alongside the document. Check retention settings for page history and backups against the period your organization and assessor require. Hosting the wiki inside your own infrastructure means these backups are your responsibility to design and test.

Access records for the policy itself

Assessors may also ask who viewed or changed the policy and when. Confirm which access and audit logs each wiki produces, where they are stored and whether they can be exported to your central log platform. Where the wiki's built-in history does not cover read access, add web server or reverse proxy logs to the evidence set and document the retention period for both.

Who writes, approves and assesses AC-1

Your organization owns AC-1. Senior management or a designated official must approve the access control policy, name the person accountable for it, and decide who receives the procedures. Those decisions cannot be delegated to an outside party, and an assessor will ask for proof that the owner made them. Ownership also means keeping the policy current, which is why AC-1 requires a defined review frequency and review after defined events.

Accountable official: Name the role that owns the access control policy and the procedures, and record that appointment in a document an assessor can examine.
Approval record: Keep signed approvals, dated versions and the change history that shows who approved each revision.
Distribution: Maintain a list of the defined roles that receive the policy and procedures, and evidence that they received them.
Review cadence: Set the review frequency and triggering events in your own terms, then record each review even when no change results.
Interviews: Make sure the people who administer access can explain the policy in their own words, because assessors interview them.

Before assessment, confirm that every approval, review and distribution record exists for the period the assessor will examine.

Where AC-1 programs usually fall short and how to close the gap

AC-1 looks simple on paper, yet most assessment findings come from the gap between a written policy and how it runs day to day. The cards below cover the failures assessors see most often, the fix for each, and the record that proves the fix works. Work through them together, because a policy that names no owner also tends to have reviews nobody records and procedures nobody maintains.

Policy with no designated official

AC-1 requires that the access control policy be managed by a designated official. When the document carries only a team name or the author's name, assessors cannot tell who answers for it. Name one accountable role, record the appointment in the policy header, and confirm the role holder has authority to approve procedure changes. Evidence: the signed approval page, the role description, and the appointment memo or directory entry that names the person.

Reviews that are not recorded

Many organizations say the policy is reviewed annually, but cannot show when the last review happened or what changed. AC-1 expects reviews at an organization-defined frequency and after defined events, so the frequency you state must match what you actually do. Keep a review log with the date, reviewer, decision and version number. Document-version history in your wiki or document store can serve as this record when it keeps author, timestamp and diffs.

Procedures for a tool no longer in use

Procedures often name an old directory, ticket queue or admin console after a migration, so staff follow steps that no longer apply. Assessors interview operators and compare what they say with the written steps. Tie each procedure to the system it governs, assign an owner, and review procedures whenever the identity provider, ticketing tool or access request workflow changes. Evidence: procedure version history, change tickets that reference the procedure, and a walkthrough showing the current tool.

Distribution without acknowledgment

AC-1 requires the policy and procedures to be distributed to defined roles, yet an email broadcast or a shared folder link does not show that the right people received them. Define the roles that must receive each document, such as system owners, access approvers and help desk staff, and require a recorded acknowledgment from each. Track gaps when people change roles. Evidence: the distribution list for each role, dated acknowledgments, and the reminder records for anyone who has not acknowledged.

External systems and contractors not covered

Policies written for employees often ignore contractor accounts, personal devices and systems the organization does not operate. Because AC-20 and AC-2 address these populations, the access control policy should state which external parties and system types are in scope and where their requirements are set. Check that the contractor onboarding process and any external system agreements point back to the policy. Evidence: a scope statement that names external populations, and sample contractor agreements that reference the policy.

Mismatch with the system security plan

Assessors compare the access control policy with the system security plan, and any difference in roles, account types or review frequency becomes a finding. Walk through AC-1 alongside the AC family entries in the plan and confirm that each control statement names the same policy version, owner and review cycle. Record any change in the plan's revision history. Evidence: a traceability table linking AC-1 to the relevant plan sections, and the plan's revision record for the matching policy version.

How much work AC-1 takes and what buyers ask before hiring help

How long does writing an AC-1 access control policy take?

No fixed duration applies because the effort depends on the size of the organization, how many systems fall under the policy, and whether access rules already exist in writing. NIST does not set implementation timelines for SP 800-53, so the duration is set by your own program and your assessor's expectations. Effort usually rises with the number of business units, the number of systems in scope, the number of approval layers and how many existing standards must be reconciled into one document. Ask any partner to show how the work is split into drafting, review, approval and rollout, and to state which parts depend on your staff's availability.

Can our own team write the AC-1 policy without outside help?

Yes, an internal team can write the AC-1 policy and procedures, because the control asks for documents that the organization owns and approves. The harder part is usually the procedures, which must show how the policy is implemented in real systems, and the review cycle, which must be kept current. Teams that lack an information security lead, or that already run access processes across several tools with no single owner, often find the drafting easier than the evidence trail. An outside partner can prepare the drafts and map them to your systems, but the policy must still be approved and owned by your designated official.

What does the work need from our staff?

The work needs named people who can make decisions, not only people who can review drafts. Typical inputs include a designated official for the policy, owners of identity and access systems, HR contacts who handle joiners, movers and leavers, and business owners who can describe which roles need which access. Interviews are a large part of what an assessor does for AC-1, so the people who would be interviewed must know the policy and be able to explain their part of it. Ask the partner to list these roles in the written scope so your staff time is agreed before work starts.

Does a written AC-1 policy alone pass an assessment?

No, a written AC-1 policy alone does not pass an assessment. The control requires a policy and procedures that are distributed to defined roles, managed by a designated official and reviewed on a defined schedule. An assessor will examine the documents and interview personnel to confirm that people know the policy and follow the procedures, and will check the system security plan for consistency. Evidence such as distribution records, approval history and review logs matters as much as the text. Your assessor, not the partner, decides whether the evidence is sufficient.

How often must the access control policy be reviewed?

The control requires review and update at a frequency that your organization defines, plus updates after defined events, so the answer comes from your own policy and the authorizing body's requirements. NIST leaves the specific interval to the organization and to the framework or contract that applies to you. Set the interval in writing, state the events that trigger an earlier review, such as a significant system change or an incident, and keep a record of each review. Confirm the expected interval with your assessor or contracting authority before you fix it in the policy.

How does an implementation partner differ from an auditor?

An implementation partner prepares your systems, documents and evidence, while an independent auditor or assessor tests them and issues any conclusion. DeployOpen, for example, can draft the AC-1 policy and procedures, configure the evidence trail and prepare the materials assessors will request, but it does not issue assessment reports, attestations or certifications. Your organization owns the controls and the decisions. Keep the roles separate in your contracts so that the party that built the evidence is not the party that judges it.

What should we ask for in a fixed-scope quote for AC-1 work?

Ask for a written scope that lists the deliverables, the systems and business units covered, the assumptions about your staff, the review and approval steps, and the handover items. A fixed-scope quote should state what is excluded, such as assessment fees or future policy reviews, and which items are one-time and which recur. Ask how changes to scope are priced and approved, and what your staff must provide for the schedule to hold. DeployOpen agrees scope, deliverables and timelines in writing before work starts and gives a quote from that scope, and it does not publish a price list.

Which parts of AC-1 can a partner take over and which must stay in-house?

A partner can draft the policy, build procedure templates, prepare distribution and review records, and organize the evidence an assessor will request. The organization must keep ownership of the policy, the designated official role, the approval decision and the interviews, because these show that leadership accepts the access rules. Ongoing reviews are usually kept in-house or moved to a retainer, depending on how often your environment changes. Agree this split in writing so that no part of AC-1 is assumed to be covered when it is not.

How DeployOpen prepares AC-1 policy and evidence

DeployOpen helps organizations prepare the AC-1 policy, procedures and supporting records that an assessor will examine, working inside the client's own infrastructure. The organization still owns its access control policy and approves it, and an independent assessor reviews the result.

How we scope

Agree in writing which systems, business units and access control procedures the AC-1 work covers before any drafting starts.
Confirm who the designated official is, who must receive the policy and procedures, and which roles approve them.
Record the review frequency and triggering events the organization has defined, so the scope states what must be maintained over time.

How we build

Draft or revise the access control policy and implementing procedures against the AC-1 determination statements in SP 800-53A.
Align the procedures with the system security plan and the account, enforcement and session procedures that AC-1 points to.
Set up document control in the client's self-hosted wiki or documentation platform so versions, authors and approvals are recorded.

How we hand over

Deliver the approved policy, procedures, revision history and distribution records in the client's own repository.
Walk the designated official and control owners through the documents and the evidence an assessor will request for AC-1.
Provide a list of open items, owners and dates so the organization can close gaps before the independent assessment.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts and a quote following from that scope.
Ongoing support, upgrades and reviews of the AC-1 documents are available as a retainer if the organization wants continued help.
DeployOpen prepares documents and evidence but does not issue audit reports, attestations or certifications; confirm assessor requirements with the assessing body.