AC-1: Policy and Procedures

AC-1 requires you to create, document, approve, and distribute an Access Control (AC) policy and the procedures that make the policy executable, then keep them current and provable in audits. Operationalize it by assigning a single owner, defining required artifacts, setting a review cadence, and collecting evidence that staff can find and follow the runbooks. ¹

Key takeaways:

• AC-1 is a documentation-and-dissemination control: auditors expect a policy plus step-by-step procedures people actually use. ¹
• Treat “policy” and “procedures” as separate artifacts with separate approval and update workflows. ¹
• Your pass/fail hinges on evidence: version control, approvals, distribution list, training/attestation, and operating records tied to the procedures.

The ac-1: policy and procedures requirement is where access control programs either become auditable or become folklore. You can have strong technical controls (SSO, MFA, RBAC, PAM), but if you cannot show a current AC policy, mapped procedures, and proof that the organization received and follows them, you will struggle in a NIST SP 800-53 assessment and most customer due diligence.

AC-1 sits at the “foundation” layer of the Access Control control family. It does not ask you to configure systems; it asks you to govern them. That governance has to be concrete: who owns access control decisions, what standards apply, what workflows must be followed, what tools are authoritative, what exceptions are allowed, and what evidence demonstrates operation.

For a CCO, GRC lead, or security compliance owner, the fastest path is to write a policy that states “what and why,” then write procedures that state “who does what, in which system, with which approvals, and what evidence is produced.” Your goal is simple: any trained operator should be able to execute access control consistently, and any auditor should be able to trace execution from requirement to artifact to record. ¹

AC-1: Policy and Procedures (requirement-level implementation)

Regulatory text

Excerpt (provided): “Develop, document, and disseminate to {{ insert: param, ac-1_prm_1 }}:” ²

What the operator must do with that text

• Develop: decide and write down your access control governance expectations (scope, roles, standards, and decision rights). ¹
• Document: maintain controlled documents (policy and procedures) with versioning, approval, and change history. ¹
• Disseminate: distribute the documents to the right audience so personnel can find them and are expected to follow them. Track distribution and acceptance where feasible. ¹

Because the excerpt includes a variable parameter for recipients, your implementation must explicitly define who receives the policy and procedures (for example: all workforce members, privileged admins, application owners, and third parties with administrative access) and how dissemination is verified (for example: GRC attestation, LMS assignment, or documented team acknowledgements). ¹

Plain-English interpretation

AC-1 requires an Access Control Policy and Access Control Procedures that are:

1. written,
2. approved and controlled,
3. distributed to the right people, and
4. kept current enough that teams actually use them during onboarding, access changes, and offboarding.

A policy without procedures fails in practice. Procedures without policy fail in audits because there is no governing intent, scope, or authority.

Who it applies to

Entities

• Federal information systems, federal contractors, contractor systems handling federal data, and service organizations aligning to NIST SP 800-53. ¹

Operational context (where AC-1 shows up)

• Any environment where identities and access must be managed consistently across systems: HR-driven joiner/mover/leaver workflows, privileged admin access, SaaS administration, cloud IAM, and third-party access pathways (consultants, outsourced IT, MSSPs).
• Especially relevant when you must demonstrate governance to external assessors: ATO processes, customer security reviews, and independent audits against NIST-based control sets. ¹

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

Step 1: Establish control ownership and scope

1. Name an AC-1 owner (role title, not a person’s name) accountable for policy/procedure currency and audit response.
2. Define scope boundaries: which environments (corp IT, production, cloud accounts, endpoints), which identity sources, and which third parties are in scope.
3. Define “authoritative systems”: your source of truth for identity, access approvals, and logging (for example, HRIS, IdP, ticketing).

Operator tip: Put scope in the policy, but put system-by-system mechanics in the procedures so updates do not require rewriting the policy every time a tool changes.

Step 2: Draft the Access Control Policy (what/why)

Write a short, enforceable document that covers:

• Purpose and scope
• Roles and responsibilities (requestor, approver, system owner, IAM admin, security)
• Access principles (least privilege, separation of duties, unique IDs, privileged access rules)
• Approval requirements (who can approve what)
• Access review expectations (periodic review concept, triggers)
• Exceptions process (when allowed, who approves, how documented)
• References to related standards (password/MFA, logging/monitoring, incident response) as internal cross-links

Keep it testable: every statement should map to a procedure, a configuration, or an evidence record.

Step 3: Write executable procedures (who/what/how)

Create procedures as runbooks. Minimum set most auditors expect to see:

• Joiner/Mover/Leaver procedure: provisioning, role changes, termination handling, and emergency removals.
• Privileged access procedure: admin access requests, elevated access time-bounding (if applicable), break-glass, and post-use review.
• Third-party access procedure: onboarding, contract prerequisites, least-privilege scoping, access expiry, and offboarding.
• Access review procedure: who runs it, inputs, how findings are tracked, and closure validation.
• Exception handling procedure: request, risk acceptance, compensating controls, expiry, and revalidation.

Each procedure should specify:

• Trigger events (new hire, ticket type, contract signed, system launch)
• Required inputs (manager approval, system owner approval, training completion, background check if applicable)
• Execution steps (click-path at a high level, or at least tool/queue ownership)
• Expected outputs (ticket, approval record, group membership change record)
• Evidence storage location (GRC repository, ticketing system link, IAM export)

Step 4: Approvals and document control

Implement basic governance:

• Document owner
• Reviewer(s): security, IT, HR, legal/privacy as needed
• Approver: CISO/Head of Security or delegated authority
• Versioning and change log
• Effective date and next review date (your chosen cadence)

Common audit hangup: A beautiful policy in a wiki with no approval history. Fix this by routing approvals through a ticket or document workflow and retaining the approval record.

Step 5: Dissemination (prove people received it)

Define dissemination channels by audience:

• All staff: security policy portal + onboarding training assignment
• Privileged admins: admin handbook + quarterly acknowledgement (or equivalent internal control)
• System owners: procedure links in system onboarding checklist
• Third parties: contractual obligations + access onboarding checklist + acknowledgment

Retain evidence that dissemination occurred (see “Evidence” section). ¹

Step 6: Build the “minimum evidence bundle” and run control health checks

Turn AC-1 into an operating control with a predictable evidence package:

• Current policy + current procedures (versioned)
• Approval records
• Distribution/attestation records
• Proof of operation: sample tickets/access requests showing procedures followed
• Exceptions log and review outcomes

Then run recurring control health checks:

• Are procedures still aligned with tooling?
• Are owners still correct?
• Are exceptions expiring and being revisited?
• Do access tickets contain required approvals?

This is where tools like Daydream fit naturally: store the control card (owner, triggers, steps), define the evidence bundle, schedule health checks, and track remediation to closure so AC-1 stays “alive” between audits.

Required evidence and artifacts to retain (audit-ready)

Use this as your AC-1 evidence checklist:

Artifact	What auditors look for	Where it usually lives
Access Control Policy	Current version, scope, roles, approval authority	Document repository / GRC
Access Control Procedures (runbooks)	Step-by-step workflows tied to tools	Wiki + controlled PDF export, or GRC
Version history / change log	Proof of maintenance	Document control system
Approval records	Named approver, date, version	Workflow ticket, e-sign, or GRC
Dissemination evidence	Audience targeted + proof of delivery	LMS, email campaign record, attestations
Operational samples	Tickets or logs demonstrating procedure execution	Ticketing/IAM exports
Exceptions register	Documented exceptions + expiry + approval	GRC risk register

Common exam/audit questions and hangups

Auditors and assessors tend to press on:

• “Show me the approved AC policy and the procedures referenced by the policy.” ¹
• “Who are the recipients for dissemination, and how do you know they received it?” ¹
• “How do you keep procedures current when tools change?”
• “Show evidence that the procedures were followed for a sample of access requests.”
• “Where are exceptions documented, who approved them, and when do they expire?”

Hangups that cause findings:

• Procedures exist, but teams follow a different reality (Slack approvals, undocumented admin actions).
• Policy is generic and does not name roles, systems, or approval paths.
• Dissemination is assumed, not evidenced.

Frequent implementation mistakes and how to avoid them

1. Writing only a policy.
   Fix: publish procedures as runbooks tied to real workflows and systems.

2. Conflating “dissemination” with “posted somewhere.”
   Fix: define audiences and maintain attestations or training assignments for key groups.

3. No owner, no lifecycle.
   Fix: assign a control owner, set review triggers (tool change, org change, incident), and track changes.

4. Procedures that are too detailed and break immediately.
   Fix: document decision points and required approvals; keep click-by-click details in tool-specific appendices.

5. Evidence scattered across tools with no retrieval path.
   Fix: define the minimum evidence bundle and a single index (control card) that points to exact locations.

Risk implications (why AC-1 matters operationally)

AC-1 failures usually do not look like “missing paperwork” during an incident. They show up as:

• inconsistent approvals for privileged access,
• inability to prove who authorized access,
• inconsistent third-party access onboarding/offboarding,
• delayed access revocation.

Those conditions raise breach and fraud risk, and they also raise assurance risk: customers and assessors may treat the control environment as unreliable if basic governance is missing.

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Assign AC-1 owner and approver.
• Inventory existing documents and actual workflows (how access is granted today).
• Draft AC policy (short) and draft the top procedures (joiner/mover/leaver and privileged access).
• Create a control card: objective, scope, owner, triggers, steps, exceptions, evidence locations.
• Decide where evidence will be retained and how it will be retrieved during an audit.

Days 31–60 (operationalize and prove dissemination)

• Finalize approvals and publish controlled versions.
• Implement dissemination by audience (LMS, attestations, admin team acknowledgements).
• Align ticketing forms to procedures (mandatory fields: approver, system, role, justification).
• Start collecting “operational samples” and store links in the evidence bundle.

Days 61–90 (reduce drift)

• Add procedures for third-party access, access reviews, and exceptions management.
• Run the first control health check and open remediation items with due dates.
• Validate you can answer the top audit questions in one sitting using the evidence bundle.
• If using Daydream, schedule recurring health checks and automate evidence requests so AC-1 does not depend on heroics.

Frequently Asked Questions

Do we need separate documents for the AC policy and AC procedures?

Yes in practice, even if they live in the same repository. Auditors expect policy-level intent plus step-by-step procedures that show how the intent is executed. ¹

What does “disseminate” mean for AC-1?

It means you defined the intended audience and distributed the policy/procedures in a way they can reasonably access, with proof of distribution or acknowledgement for key roles. ¹

Can a wiki page satisfy AC-1?

It can, if you have document control (versioning, approvals, change history) and you can show dissemination and use. A wiki without approval records or stable versioning is a common audit failure.

How do we handle third-party access under AC-1?

Include third parties in scope, document a third-party access onboarding/offboarding procedure, and retain evidence that access was approved, time-bounded where appropriate, and removed at termination of need.

What evidence should we hand an auditor first?

Start with the current approved AC policy, the procedure set, and the evidence index (control card) that points to approvals, dissemination, and a few operational samples.

How often should we review the AC policy and procedures?

Set a defined review trigger and cadence that matches your change rate (tooling changes, org changes, incidents). Auditors care more about a consistent lifecycle and proof of updates than a specific interval. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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